code reusability

Thomas Girod

11 Jun 2010 11 Jun '10

7:34 a.m.

Hi there. I'm currently working on a chuck project that is progressively increasing in size. Some parts of this project are already quite generic, and I will probably use them in other projects later (namely, an interface to communicate with the novation's monome ripoff). So I start to wonder: how can I organize my code for easy reuse ? What are the options / good practices to write less monolithic chuck code ? Is it possible to write something that could behave as a library ? Thanks for your attention Tom

Show replies by date

Kassen

11 Jun 11 Jun

8:08 a.m.

Hi Thomas! What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred. At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI. If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project. Hope that helps? Kas. On 11 June 2010 13:34, Thomas Girod wrote:

...

Hi there.

I'm currently working on a chuck project that is progressively increasing in size. Some parts of this project are already quite generic, and I will probably use them in other projects later (namely, an interface to communicate with the novation's monome ripoff).

So I start to wonder: how can I organize my code for easy reuse ? What are the options / good practices to write less monolithic chuck code ? Is it possible to write something that could behave as a library ?

Thanks for your attention

Tom

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Thomas Girod

9:32 a.m.

Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks ! Tom On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...

Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

Daniel Trueman

10 a.m.

i believe in the next release you'll be able to open MIDI/Hid devices by name... On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...

Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

mike clemow

12:08 p.m.

Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm... I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop. LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.: $ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;). On the other hand, if I could just put: #include (LiCK); at the head of my code... easy peasy. Or, if I only wanted part of LiCK imported: #include (FloatIterator); That's my buck-oh-five. Mike On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote:

...

i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until

...
of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In

...
of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote: the name the case the

...
long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Andrew C. Smith

1:17 p.m.

Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do. Andrew On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

...

Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote: i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

mike clemow

1:50 p.m.

Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well. maybe some perl guru would be willing to have a go at modifying it. Mike 2010/6/11 Andrew C. Smith

...

Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote:

...
i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until

...
of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In

...
of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote: the name the case the

...
long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Andrew C. Smith

3:02 p.m.

It's not clear to me--does #ifdef work? If not, you'd end up instantiating the same public class more than once. Also, a single file can only define one public class at a time, right? So, you'd have to spork a different shred for every class, and not just throw them all into one file. I may be misunderstanding the code though, because I don't know Perl very well at all, and I'm preoccupied with something else right now. On Jun 11, 2010, at 1:50 PM, mike clemow wrote:

...

Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well.

maybe some perl guru would be willing to have a go at modifying it.

Mike

2010/6/11 Andrew C. Smith Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

...
Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote: i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

mike clemow

3:47 p.m.

You make non-public classes, and the perl script basically appends those classes to your script and creates a temporary file to send to the vm. it's hacky, but it works. #ifdef does NOT work. only #include (myfile) mike 2010/6/11 Andrew C. Smith

...

It's not clear to me--does #ifdef work? If not, you'd end up instantiating the same public class more than once.

Also, a single file can only define one public class at a time, right? So, you'd have to spork a different shred for every class, and not just throw them all into one file. I may be misunderstanding the code though, because I don't know Perl very well at all, and I'm preoccupied with something else right now.

On Jun 11, 2010, at 1:50 PM, mike clemow wrote:

Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well.

maybe some perl guru would be willing to have a go at modifying it.

Mike

2010/6/11 Andrew C. Smith

...
Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote:

...
i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until

...
of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In

...
of controllers with leds you'd probably also have member-functions

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote: the name the case that your

...
code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Andrew C. Smith

11:42 p.m.

Yeah, that's my concern. I mean, that doesn't really work for using public classes as buses or something. Or, in my case, I use a public class called Scala to control the global tuning of all my microtonal Scala.mtof(int midiNote) functions. Anyway, good to see this. Maybe we can collectively work to make something even more adaptable? I'm willing to learn Perl a bit better. Andrew On Jun 11, 2010, at 3:47 PM, mike clemow wrote:

...

You make non-public classes, and the perl script basically appends those classes to your script and creates a temporary file to send to the vm.

it's hacky, but it works.

#ifdef does NOT work. only #include (myfile)

mike

2010/6/11 Andrew C. Smith It's not clear to me--does #ifdef work? If not, you'd end up instantiating the same public class more than once.

Also, a single file can only define one public class at a time, right? So, you'd have to spork a different shred for every class, and not just throw them all into one file. I may be misunderstanding the code though, because I don't know Perl very well at all, and I'm preoccupied with something else right now.

On Jun 11, 2010, at 1:50 PM, mike clemow wrote:

...
Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well.

maybe some perl guru would be willing to have a go at modifying it.

Mike

2010/6/11 Andrew C. Smith Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

...
Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote: i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

mike clemow

12 Jun 12 Jun

11:21 a.m.

I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. I would love to be able to be able to create a wrapper for the executable keeps Chuck VM alive and adds the appropriate class definitions to the running VM. When Chuck crashes, for instance, this process should notice Chuck is not running, restart the VM and load up the last library set used (unless the user begins a new session). This would actually reduce the need for #include <blah> statements, since your library could just be loaded when Chuck starts--public classes and all. Lucky for us, Andrew, we live in the same city. :) If you're into this, I have some time coming up and would be glad to start working on this sooner rather than later. Mike 2010/6/11 Andrew C. Smith

...

Yeah, that's my concern. I mean, that doesn't really work for using public classes as buses or something. Or, in my case, I use a public class called Scala to control the global tuning of all my microtonal Scala.mtof(int midiNote) functions.

Anyway, good to see this. Maybe we can collectively work to make something even more adaptable? I'm willing to learn Perl a bit better.

Andrew

On Jun 11, 2010, at 3:47 PM, mike clemow wrote:

You make non-public classes, and the perl script basically appends those classes to your script and creates a temporary file to send to the vm.

it's hacky, but it works.

#ifdef does NOT work. only #include (myfile)

mike

2010/6/11 Andrew C. Smith

...
It's not clear to me--does #ifdef work? If not, you'd end up instantiating the same public class more than once.

Also, a single file can only define one public class at a time, right? So, you'd have to spork a different shred for every class, and not just throw them all into one file. I may be misunderstanding the code though, because I don't know Perl very well at all, and I'm preoccupied with something else right now.

On Jun 11, 2010, at 1:50 PM, mike clemow wrote:

Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well.

maybe some perl guru would be willing to have a go at modifying it.

Mike

2010/6/11 Andrew C. Smith

...
Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman
...
wrote:

...
i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until

...
of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In

...
of controllers with leds you'd probably also have member-functions

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote: the name the case that your

...
code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Andrew C. Smith

4:26 p.m.

Oh wait, that's true. Hi Mike. Yes, I know Python better than Perl as well. Let's do it. That's an interesting idea--the wrapper to keep chuck going. Particularly, I think it would be important to have some kind of wrapper that runs independent of any possible upgrades that might happen to the chuck program. I confess I don't know Python all that well, and I've never used it to actively monitor another process, but I suppose I'll do what I can. I would still like a preprocessor that sorts through a chuck file. It should, however, work with chuck without having two separate source files (i.e., work in the mini or in this Python wrapper). So, something like "//include", "//ifdef" and "//define" would do the trick because the VM would ignore the comments anyway. I feel like a monitoring process (that automatically restarts the VM) and an inclusion preprocessor are two different aspects of some sort of idea--the ability to monitor what classes are currently defined without crashing chuck. I'm definitely up for working on the inclusion thing, and we can just get together and decide on a way to have the inclusion messages routed to your VM monitor, so that your VM monitor can restart chuck with all the proper libraries if it crashes--if you want, anyway. I'm still writing this on-list, because we should take syntax suggestions if we're going to work on this. One idea is to use "//include <Scala>" as an example of a public class (my VM-wide microtonal mtof), and something like "//include "SawPlayer" " as an inclusion for a non-public class. Is this advantageous? Would anyone else use it? So, I'm just monster busy for like a month, working extra to make up for a three-week break I'm taking. However, if you'd want to get together in the next week or two and sketch something out, we could probably then just send some code back and forth when I leave town, and continue polishing in earnest in August. Vacation's for writing stuff like this. Hey, maybe we can have it done and stable by the end of the summer even. That sounds like a reasonable goal. Andrew On Jun 12, 2010, at 11:21 AM, mike clemow wrote:

...

I would be happy to help make something too, although I would say we should use Python for two reasons:

1) I know Python much better than Perl. 2) Python enforces much more legible code.

I would love to be able to be able to create a wrapper for the executable keeps Chuck VM alive and adds the appropriate class definitions to the running VM. When Chuck crashes, for instance, this process should notice Chuck is not running, restart the VM and load up the last library set used (unless the user begins a new session). This would actually reduce the need for #include <blah> statements, since your library could just be loaded when Chuck starts--public classes and all.

Lucky for us, Andrew, we live in the same city. :) If you're into this, I have some time coming up and would be glad to start working on this sooner rather than later.

Mike

2010/6/11 Andrew C. Smith Yeah, that's my concern. I mean, that doesn't really work for using public classes as buses or something. Or, in my case, I use a public class called Scala to control the global tuning of all my microtonal Scala.mtof(int midiNote) functions.

Anyway, good to see this. Maybe we can collectively work to make something even more adaptable? I'm willing to learn Perl a bit better.

Andrew

On Jun 11, 2010, at 3:47 PM, mike clemow wrote:

...
You make non-public classes, and the perl script basically appends those classes to your script and creates a temporary file to send to the vm.

it's hacky, but it works.

#ifdef does NOT work. only #include (myfile)

mike

2010/6/11 Andrew C. Smith It's not clear to me--does #ifdef work? If not, you'd end up instantiating the same public class more than once.

Also, a single file can only define one public class at a time, right? So, you'd have to spork a different shred for every class, and not just throw them all into one file. I may be misunderstanding the code though, because I don't know Perl very well at all, and I'm preoccupied with something else right now.

On Jun 11, 2010, at 1:50 PM, mike clemow wrote:

...
Scott Wheeler's script is exactly that. You should have a look. The only thing is that it doesn't handle chuck command line args well.

maybe some perl guru would be willing to have a go at modifying it.

Mike

2010/6/11 Andrew C. Smith Hm, what about setting up some kind of python (or perl, etc...) script to pre-process ChucK and handle all statements preceded by a #? So, you could totally do the whole #IFDEF thing and make that work. That might be a worthwhile library of stuff to do.

Andrew

On Jun 11, 2010, at 12:08 PM, mike clemow wrote:

...
Hey, I'd like to recall this thread: https://lists.cs.princeton.edu/pipermail/chuck-users/2008-October/003408.htm...

I used Scott Wheeler's chuck preprocessor (a Perl script) for a long time. I really liked the concept. It did not work well with command line arguments, however, the benefits as far as code-reuse were really nice. Obviously, things had to be imported in the correct order, but I think that there might be a way around it, if each file you import also imported its prerequisites. IMHO, Chuck really needs something like this in order to make a library a pleasure to use and a helpful thing to develop.

LiCK would be trivial to use if Chuck had import/include statements built in. It's okay at the moment to do what Michael described above, i.e.:

$ chuck --loop & $ chuck + import.ck // imports entire library $ chuck + myChuckScript.ck

on the command line, however, in miniAudicle, it's kind of annoying to have to also open the import.ck file and run it before running any other code. You have to repeat all this when it crashes (which is something that happens from time to time when developing new things ;).

On the other hand, if I could just put:

#include (LiCK);

at the head of my code... easy peasy.

Or, if I only wanted part of LiCK imported:

#include (FloatIterator);

That's my buck-oh-five.

Mike

On Fri, Jun 11, 2010 at 10:00 AM, Daniel Trueman wrote: i believe in the next release you'll be able to open MIDI/Hid devices by name...

On Jun 11, 2010, at 9:32 AM, Thomas Girod wrote:

...
Okay, that's pretty much what I did. Trying all the devices until I find the one with the proper name is a good idea, thanks !

Tom

On Fri, Jun 11, 2010 at 02:08:38PM +0200, Kassen wrote:

...
Hi Thomas!

What I use for this kind of case (my Akai LPD8, for example) is a class with it's own sporked listener shred.

At instantiation it could try to open all MIDI devices in turn, until the name of the device is whatever the name of your controller is. from there on you can add members and member functions that reflect whatever you want to do with the device, including a public event that other shreds could wait for. In the case of controllers with leds you'd probably also have member-functions that your code could use to set these, with your class handling the MIDI.

If you build something like that once it will save you a lot of time in the long run and only having to do MIDI (with all of its magic numbers) once should make your coding a lot more pleasant. The class could sit in its own file (if you make it public), or you could simply copy and paste it to the bottom of your current project.

Hope that helps? Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Joe McMahon

10:29 p.m.

2010/6/12 mike clemow :

...

I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. Okay, well, I'll take a look at the Perl version; let's see what we can come up with.

By the way: good programmers enforce legible code, not languages. :) Programming languages can help out, but it's possible to write crap code in any language. Having written both, I think that writing good Perl does indeed require more discipline, but the power advantages (especially CPAN) help a lot.

mike clemow

15 Jun 15 Jun

2:57 p.m.

...

By the way: good programmers enforce legible code, not languages. :)

Yes, Joe, but if *I* write it in Perl, it will be crap code. :) I'm working on a Python stub application for this session handler idea. We can use it as a basis and build on it, if you guys like it. What Andrew and I were talking about doing is actually quite different than what Scott Wheeler's original Perl script did. I'm much more interested in the session handler idea, but I'm sure there's a way to combine them. I personally don't think it makes much difference what language they two are written in as long as they play nice together. Mike On Sat, Jun 12, 2010 at 10:29 PM, Joe McMahon wrote:

...

2010/6/12 mike clemow :

...
I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. Okay, well, I'll take a look at the Perl version; let's see what we can come up with.

By the way: good programmers enforce legible code, not languages. :) Programming languages can help out, but it's possible to write crap code in any language. Having written both, I think that writing good Perl does indeed require more discipline, but the power advantages (especially CPAN) help a lot. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

mike clemow

5:58 p.m.

Okay folks, It's hacky and slow, but it does technically work (on my Mac with Snow Leopard...) how to: 1) make sure chuck is installed ;) 2) unzip the archive, open a terminal window 3) cd /path/to/chuck-session-handler_v01 4) python csh-v1r0.py - notice that the script starts chuck and adds the setup.ck and mylib.ck files 5) open another terminal window 6) in that terminal window cd /path/to/chuck-session-handler_v01 7) chuck + test.ck 8) verify that the output (in the first window) prints "5 :(int)" 9) killall chuck 10) notice that the script reboots chuck and adds the setup.ck and mylib.ckfiles 11) chuck + test.ck 12) verify that the output (in the first window) prints "5 :(int)" 13) rinse, repeat... Questions, comments, concerns? I think that something like this could be very interesting as part of an incremental programming system that would keep track of the classes that were written and add them to the list of classes that are included in setup.ck. I think that this would be interesting for building and maintaining libraries for live-coding. Anyway, it's a start... of something. Best, Mike On Tue, Jun 15, 2010 at 2:57 PM, mike clemow wrote:

...

...
By the way: good programmers enforce legible code, not languages. :)

Yes, Joe, but if *I* write it in Perl, it will be crap code. :)

I'm working on a Python stub application for this session handler idea. We can use it as a basis and build on it, if you guys like it. What Andrew and I were talking about doing is actually quite different than what Scott Wheeler's original Perl script did. I'm much more interested in the session handler idea, but I'm sure there's a way to combine them. I personally don't think it makes much difference what language they two are written in as long as they play nice together.

Mike

On Sat, Jun 12, 2010 at 10:29 PM, Joe McMahon wrote:

...
2010/6/12 mike clemow :

...
I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. Okay, well, I'll take a look at the Perl version; let's see what we can come up with.

By the way: good programmers enforce legible code, not languages. :) Programming languages can help out, but it's possible to write crap code in any language. Having written both, I think that writing good Perl does indeed require more discipline, but the power advantages (especially CPAN) help a lot. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

-- http://michaelclemow.com http://semiotech.org

Andrew C. Smith

7:05 p.m.

Oh yes, love it. This may actually do all I need. In particular, I like how "killall chuck" restarting the libraries will make it so much quicker to try out public classes. I mean, even though it's kind of slow, at least with a scripting language like Python it'll run on other computers. One improvement I can think of is to figure out what chuck kicks back when it's fully loaded, and use that rather than time.sleep(1). It could just run into some problems depending one any kind of lags in the load time. And, considering this is totally based on crashing chuck, it should assume that not everything will work properly. Maybe kick back a warning if chuck doesn't start after 5 seconds or so. I don't know, just more ideas. And finally, maybe just have setupfile set to an optional argument. That would allow multiple chuck handles to run at once using different libraries (if, for example, you want different chucks on different osc ports). For the record, I've also got a Mac with Snow Leopard, so we've deduced nothing so far about compatibility. Great work, though--let me know if I can help. -Andrew On Jun 15, 2010, at 5:58 PM, mike clemow wrote:

...

Okay folks,

It's hacky and slow, but it does technically work (on my Mac with Snow Leopard...)

how to:

1) make sure chuck is installed ;) 2) unzip the archive, open a terminal window 3) cd /path/to/chuck-session-handler_v01 4) python csh-v1r0.py - notice that the script starts chuck and adds the setup.ck and mylib.ck files 5) open another terminal window 6) in that terminal window cd /path/to/chuck-session-handler_v01 7) chuck + test.ck 8) verify that the output (in the first window) prints "5 :(int)" 9) killall chuck 10) notice that the script reboots chuck and adds the setup.ck and mylib.ck files 11) chuck + test.ck 12) verify that the output (in the first window) prints "5 :(int)" 13) rinse, repeat...

Questions, comments, concerns? I think that something like this could be very interesting as part of an incremental programming system that would keep track of the classes that were written and add them to the list of classes that are included in setup.ck. I think that this would be interesting for building and maintaining libraries for live-coding.

Anyway, it's a start... of something.

Best, Mike

On Tue, Jun 15, 2010 at 2:57 PM, mike clemow wrote:

...
By the way: good programmers enforce legible code, not languages. :)

Yes, Joe, but if *I* write it in Perl, it will be crap code. :)

I'm working on a Python stub application for this session handler idea. We can use it as a basis and build on it, if you guys like it. What Andrew and I were talking about doing is actually quite different than what Scott Wheeler's original Perl script did. I'm much more interested in the session handler idea, but I'm sure there's a way to combine them. I personally don't think it makes much difference what language they two are written in as long as they play nice together.

Mike

On Sat, Jun 12, 2010 at 10:29 PM, Joe McMahon wrote: 2010/6/12 mike clemow :

...
I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. Okay, well, I'll take a look at the Perl version; let's see what we can come up with.

By the way: good programmers enforce legible code, not languages. :) Programming languages can help out, but it's possible to write crap code in any language. Having written both, I think that writing good Perl does indeed require more discipline, but the power advantages (especially CPAN) help a lot. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

-- http://michaelclemow.com http://semiotech.org

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

mike clemow

16 Jun 16 Jun

11:51 a.m.

Hi, 2010/6/15 Andrew C. Smith

...

Oh yes, love it. This may actually do all I need.

I was thinking that it was a pretty simple solution to something that was bugging me about the system too! But I think that means we're on the right track rather than "done."

...

In particular, I like how "killall chuck" restarting the libraries will make it so much quicker to try out public classes. I mean, even though it's kind of slow, at least with a scripting language like Python it'll run on other computers.

yeah, with Python, it's about as cross platform as Chuck itself.

...

One improvement I can think of is to figure out what chuck kicks back when it's fully loaded, and use that rather than time.sleep(1). It could just run into some problems depending one any kind of lags in the load time. And, considering this is totally based on crashing chuck, it should assume that not everything will work properly.

Totally. That's the hackiest part of it. Chuck needs time to load up and be running. It's a much better idea to have some sort of handshaking going on there. Even if we just add a file that prints something out that we can grab from stdout would be better than just waiting. I've noticed with files that do a lot of Machine.add("etc.ck"); certain systems required a some::time => now; in between the add statements because they took too long... it was an older Linux machine. Anyway, it would be much better to get feed back from the VM, you're right. Maybe kick back a warning if chuck doesn't start after 5 seconds or so. I

...

don't know, just more ideas. And finally, maybe just have setupfile set to an optional argument. That would allow multiple chuck handles to run at once using different libraries (if, for example, you want different chucks on different osc ports).

Yeah, we should add a bunch of arguments to the session handler so that it can run OSC on different ports and all that jazz. Different setup files is also a good idea. I can also see this working on a network and keeping a VM running on a different machine than the one you're coding from. Maybe the session handler itself could receive OSC commands...

...

For the record, I've also got a Mac with Snow Leopard, so we've deduced nothing so far about compatibility. Great work, though--let me know if I can help.

You are helping! :) I'm going to keep working at this. Maybe I'll add it to github... Mike

...

-Andrew

On Jun 15, 2010, at 5:58 PM, mike clemow wrote:

Okay folks,

It's hacky and slow, but it does technically work (on my Mac with Snow Leopard...)

how to:

1) make sure chuck is installed ;) 2) unzip the archive, open a terminal window 3) cd /path/to/chuck-session-handler_v01 4) python csh-v1r0.py - notice that the script starts chuck and adds the setup.ck and mylib.ck files 5) open another terminal window 6) in that terminal window cd /path/to/chuck-session-handler_v01 7) chuck + test.ck 8) verify that the output (in the first window) prints "5 :(int)" 9) killall chuck 10) notice that the script reboots chuck and adds the setup.ck and mylib.ck files 11) chuck + test.ck 12) verify that the output (in the first window) prints "5 :(int)" 13) rinse, repeat...

Questions, comments, concerns? I think that something like this could be very interesting as part of an incremental programming system that would keep track of the classes that were written and add them to the list of classes that are included in setup.ck. I think that this would be interesting for building and maintaining libraries for live-coding.

Anyway, it's a start... of something.

Best, Mike

On Tue, Jun 15, 2010 at 2:57 PM, mike clemow wrote:

...
...
By the way: good programmers enforce legible code, not languages. :)

Yes, Joe, but if *I* write it in Perl, it will be crap code. :)

I'm working on a Python stub application for this session handler idea. We can use it as a basis and build on it, if you guys like it. What Andrew and I were talking about doing is actually quite different than what Scott Wheeler's original Perl script did. I'm much more interested in the session handler idea, but I'm sure there's a way to combine them. I personally don't think it makes much difference what language they two are written in as long as they play nice together.

Mike

On Sat, Jun 12, 2010 at 10:29 PM, Joe McMahon wrote:

...
2010/6/12 mike clemow :

...
I would be happy to help make something too, although I would say we should use Python for two reasons: 1) I know Python much better than Perl. 2) Python enforces much more legible code. Okay, well, I'll take a look at the Perl version; let's see what we can come up with.

By the way: good programmers enforce legible code, not languages. :) Programming languages can help out, but it's possible to write crap code in any language. Having written both, I think that writing good Perl does indeed require more discipline, but the power advantages (especially CPAN) help a lot. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

-- http://michaelclemow.com http://semiotech.org

_______________________________________________

chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

Brendan Asselstine

11 Jun 11 Jun

9 a.m.

Machine.add( "foo.ck" ); - as defined here http://chuck.cs.princeton.edu/doc/language/spork.html or just pass your library filename (e.g. "foo,ck") to chuck *before* your main program. Like this: chuck library.ck usage.ck On Fri, Jun 11, 2010 at 7:34 AM, Thomas Girod wrote:

...

Hi there.

I'm currently working on a chuck project that is progressively increasing in size. Some parts of this project are already quite generic, and I will probably use them in other projects later (namely, an interface to communicate with the novation's monome ripoff).

So I start to wonder: how can I organize my code for easy reuse ? What are the options / good practices to write less monolithic chuck code ? Is it possible to write something that could behave as a library ?

Thanks for your attention

Tom

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Michael Heuer

9:53 a.m.

Thomas Girod wrote:

...

I'm currently working on a chuck project that is progressively increasing in size. Some parts of this project are already quite generic, and I will probably use them in other projects later (namely, an interface to communicate with the novation's monome ripoff).

So I start to wonder: how can I organize my code for easy reuse ? What are the options / good practices to write less monolithic chuck code ? Is it possible to write something that could behave as a library ?

LiCK is such a library http://github.com/heuermh/lick The import mechanism is not ideal though, there is an import.ck script that imports all the other classes with Machine.add calls in the right order. $ chuck --loop & $ chuck + import.ck $ chuck + myChuckScript.ck michael

5134

Age (days ago)

5139

Last active (days ago)

List overview

Download

18 comments

8 participants

participants (8)

Andrew C. Smith
Brendan Asselstine
Daniel Trueman
Joe McMahon
Kassen
Michael Heuer
mike clemow
Thomas Girod