I just did a quick test putting 1::samp all over the place :), but so far no joy. But this is interesting, I'll explore it properly when I have a bit more time. If I can locate where most of the time gets used, I can focus on that. Thanks! Gonzalo On 16.08.18 01:36, Jack Atherton wrote:

Hi!

Shreds block when you don’t advance time. If you don’t advance time, then ChucK assumes you need all the current computation for the next audio sample. Is there a place during your long computation where you could wait one sample every so often (1::samp => now;)? For example, in the body of a loop.

Jack

On Wed, Aug 15, 2018 at 3:38 AM Gonzalo mailto:gonzalo@dense13.com> wrote:

Hi,

I'm working on a big project (www.whole-play.com http://www.whole-play.com), tons of classes, tons of calculations happening at various points. My problem is that some of these calculations take too long, up to a few seconds. I thought if I run them in their own shred, the main shred would be unaffected, but it's not the case, and the music stops during those processes. Maybe I'm doing something wrong. I can't post sample code because it's many classes interacting, but I thought maybe someone has ideas on how to tackle this issue?

Thanks! Gonzalo

-- http://dense13.com http://www.whole-play.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto: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://dense13.com http://www.whole-play.com

That might be the way to go. I'm going to explore what Jack suggested (I'm curious anyway), possibly also try to pin down where exactly the problem is. But ultimately your approach would ensure the right timing, I'm likely to end up doing that for the analytical parts of the application where timing is not so crucial. Thanks heaps! Gonzalo On 16.08.18 10:28, mike clemow wrote:

Hey!

Been a long time since I posted here. In the spirit of doing things the "wrong" way (which is what we're all about, right? ;) You _might_ consider architecting your app using two (or more) concurrent instances of ChucK; one with your synthesis stuff, and one doing your heavy computation. The one doing the math could be set up to have a local OSC API for sending the parameters in and your other code could just wait on the response (advancing time in the main chuck instance, while the calculations are being done elsewhere). You would have to have some structure around the communications, but there are ways to make that easier with functors (paging Michael Heuer).

The good thing about this is that you get to take advantage of your computer's multiple processors, since Chuck is single-threaded (last I checked). Besides, if your calculations are that intense, what's another couple of milliseconds for OSC communication? Plus, your calculations might run faster this way... maybe.

Or don't consider that because it's crazy. ;)  Fwiw, I've definitely run into applications that required multiple Chuck instances talking to each other, although usually I'm trying to use multiple sound cards simultaneously. I've also abused named pipes in service of inter-application communications, although I really don't recommend that.

Best, Mike

-- Michael Clemow he/him/his Artist/Composer/Sound Designer http://michaelclemow.com http://michaelclemow.com/

On Wed, Aug 15, 2018 at 7:39 PM Gonzalo mailto:gonzalo@dense13.com> wrote:

I just did a quick test putting 1::samp all over the place :), but so far no joy. But this is interesting, I'll explore it properly when I have a bit more time. If I can locate where most of the time gets used, I can focus on that. Thanks!

Gonzalo

On 16.08.18 01:36, Jack Atherton wrote: > Hi! > > Shreds block when you don’t advance time. If you don’t advance time, > then ChucK assumes you need all the current computation for the next > audio sample. Is there a place during your long computation where you > could wait one sample every so often (1::samp => now;)? For example, in > the body of a loop. > > Jack > > On Wed, Aug 15, 2018 at 3:38 AM Gonzalo mailto:gonzalo@dense13.com > mailto:gonzalo@dense13.com>> wrote: > >     Hi, > >     I'm working on a big project (www.whole-play.com http://www.whole-play.com >     http://www.whole-play.com), tons of classes, tons >     of calculations happening at various points. My problem is that some of >     these calculations take too long, up to a few seconds. I thought if I >     run them in their own shred, the main shred would be unaffected, but >     it's not the case, and the music stops during those processes. Maybe >     I'm >     doing something wrong. I can't post sample code because it's many >     classes interacting, but I thought maybe someone has ideas on how to >     tackle this issue? > >     Thanks! >     Gonzalo > > >     -- > http://dense13.com > http://www.whole-play.com >     _______________________________________________ >     chuck-users mailing list > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

-- http://dense13.com http://www.whole-play.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto: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://dense13.com http://www.whole-play.com

Quick wrap up of this thread. I did what Mike suggested, and it works great, thanks for the pointers! It was a bit of work getting to transfer all the required data structures properly via OSC, but worth the effort. :) On 16.08.18 10:28, mike clemow wrote:

Hey!

Been a long time since I posted here. In the spirit of doing things the "wrong" way (which is what we're all about, right? ;) You _might_ consider architecting your app using two (or more) concurrent instances of ChucK; one with your synthesis stuff, and one doing your heavy computation. The one doing the math could be set up to have a local OSC API for sending the parameters in and your other code could just wait on the response (advancing time in the main chuck instance, while the calculations are being done elsewhere). You would have to have some structure around the communications, but there are ways to make that easier with functors (paging Michael Heuer).

The good thing about this is that you get to take advantage of your computer's multiple processors, since Chuck is single-threaded (last I checked). Besides, if your calculations are that intense, what's another couple of milliseconds for OSC communication? Plus, your calculations might run faster this way... maybe.

Or don't consider that because it's crazy. ;)  Fwiw, I've definitely run into applications that required multiple Chuck instances talking to each other, although usually I'm trying to use multiple sound cards simultaneously. I've also abused named pipes in service of inter-application communications, although I really don't recommend that.

Best, Mike

-- Michael Clemow he/him/his Artist/Composer/Sound Designer http://michaelclemow.com http://michaelclemow.com/

On Wed, Aug 15, 2018 at 7:39 PM Gonzalo mailto:gonzalo@dense13.com> wrote:

I just did a quick test putting 1::samp all over the place :), but so far no joy. But this is interesting, I'll explore it properly when I have a bit more time. If I can locate where most of the time gets used, I can focus on that. Thanks!

Gonzalo

On 16.08.18 01:36, Jack Atherton wrote: > Hi! > > Shreds block when you don’t advance time. If you don’t advance time, > then ChucK assumes you need all the current computation for the next > audio sample. Is there a place during your long computation where you > could wait one sample every so often (1::samp => now;)? For example, in > the body of a loop. > > Jack > > On Wed, Aug 15, 2018 at 3:38 AM Gonzalo mailto:gonzalo@dense13.com > mailto:gonzalo@dense13.com>> wrote: > >     Hi, > >     I'm working on a big project (www.whole-play.com http://www.whole-play.com >     http://www.whole-play.com), tons of classes, tons >     of calculations happening at various points. My problem is that some of >     these calculations take too long, up to a few seconds. I thought if I >     run them in their own shred, the main shred would be unaffected, but >     it's not the case, and the music stops during those processes. Maybe >     I'm >     doing something wrong. I can't post sample code because it's many >     classes interacting, but I thought maybe someone has ideas on how to >     tackle this issue? > >     Thanks! >     Gonzalo > > >     -- > http://dense13.com > http://www.whole-play.com >     _______________________________________________ >     chuck-users mailing list > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

-- http://dense13.com http://www.whole-play.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto: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://dense13.com http://www.whole-play.com

I didn't know what MPI was, just had a quick check (only got the gist of it). I'm learning a lot of things through Chuck. :) I think it would be interesting, but might be a bit tricky to implement with chuck? I don't know enough though, just wondering. My approach might have been a bit clumsy. I had two situations to solve: - Sending an array of primitives of an unknown length. This is relatively easy to solve, adding all the args to the OscMessage in a loop. - Sending a complex type that includes mixed primitive types. This was a bit trickier, and some conversion needs to happen anyway when using time or dur. My (probably a bit inefficient) solution was to .stringify and .destringify my objects (using Tokenizer), and then just sending a string over OSC. It's a bit delicate/error prone, but it works, and once I've added those methods to a class, it becomes quite easy to use, for the actual communication. For instance, to transfer myObject would look something like this: // The sender. Sets up an OscOut, then: oscOut.start("my/adress/pattern"); oscOut.add(myObject.stringify()); oscOut.send(); // The receiver. Gets an OscMsg, then: if (oscMsg.address == "...") { oscMsg.getString(0) => string stringifiedVersion; MyClass.destringify(stringifiedVersion) @=> MyClass myObject; } I've also encapsulated the sender part into a method to be able to simply write: this.response("my/adress/pattern", myObject); Is this a decent approach? The type conversion to/from string can be a bit fiddly, but it seems to work. One thing I like is that complex types composed of other complex types are easy to (de)stringify, calling their children's methods. In the spirit of doing things the "wrong" way... ;) (I like that!) Gz On 28.08.18 07:31, mike clemow wrote:

Hey that's great!

Do you think it's worth building a library and standard framework around sending/receiving those types of messages over OSC? A sort of Chuck/OSC version of Message Passing Interface. Or do you think that OSC is general enough to do the job all by itself?

Curious what your learnings were!

Congrats!

-Mike

-- Michael Clemow he/him/his Artist/Composer/Sound Designer http://michaelclemow.com http://michaelclemow.com/

On Mon, Aug 27, 2018 at 5:03 AM Gonzalo mailto:gonzalo@dense13.com> wrote:

Quick wrap up of this thread. I did what Mike suggested, and it works great, thanks for the pointers! It was a bit of work getting to transfer all the required data structures properly via OSC, but worth the effort. :)

On 16.08.18 10:28, mike clemow wrote: > Hey! > > Been a long time since I posted here. In the spirit of doing things the > "wrong" way (which is what we're all about, right? ;) You _might_ > consider architecting your app using two (or more) concurrent instances > of ChucK; one with your synthesis stuff, and one doing your heavy > computation. The one doing the math could be set up to have a local OSC > API for sending the parameters in and your other code could just wait on > the response (advancing time in the main chuck instance, while the > calculations are being done elsewhere). You would have to have some > structure around the communications, but there are ways to make that > easier with functors (paging Michael Heuer). > > The good thing about this is that you get to take advantage of your > computer's multiple processors, since Chuck is single-threaded (last I > checked). Besides, if your calculations are that intense, what's another > couple of milliseconds for OSC communication? Plus, your calculations > might run faster this way... maybe. > > Or don't consider that because it's crazy. ;)  Fwiw, I've definitely run > into applications that required multiple Chuck instances talking to each > other, although usually I'm trying to use multiple sound cards > simultaneously. I've also abused named pipes in service of > inter-application communications, although I really don't recommend that. > > Best, > Mike > > -- > Michael Clemow > he/him/his > Artist/Composer/Sound Designer > http://michaelclemow.com http://michaelclemow.com/ > > > > On Wed, Aug 15, 2018 at 7:39 PM Gonzalo mailto:gonzalo@dense13.com > mailto:gonzalo@dense13.com>> wrote: > >     I just did a quick test putting 1::samp all over the place :), but so >     far no joy. But this is interesting, I'll explore it properly when I >     have a bit more time. If I can locate where most of the time gets used, >     I can focus on that. Thanks! > >     Gonzalo > >     On 16.08.18 01:36, Jack Atherton wrote: >      > Hi! >      > >      > Shreds block when you don’t advance time. If you don’t advance time, >      > then ChucK assumes you need all the current computation for the next >      > audio sample. Is there a place during your long computation where >     you >      > could wait one sample every so often (1::samp => now;)? For >     example, in >      > the body of a loop. >      > >      > Jack >      > >      > On Wed, Aug 15, 2018 at 3:38 AM Gonzalo mailto:gonzalo@dense13.com >     mailto:gonzalo@dense13.com> >      > mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com>>> wrote: >      > >      >     Hi, >      > >      >     I'm working on a big project (www.whole-play.com http://www.whole-play.com >     http://www.whole-play.com >      >     http://www.whole-play.com), tons of classes, tons >      >     of calculations happening at various points. My problem is >     that some of >      >     these calculations take too long, up to a few seconds. I >     thought if I >      >     run them in their own shred, the main shred would be >     unaffected, but >      >     it's not the case, and the music stops during those >     processes. Maybe >      >     I'm >      >     doing something wrong. I can't post sample code because it's many >      >     classes interacting, but I thought maybe someone has ideas on >     how to >      >     tackle this issue? >      > >      >     Thanks! >      >     Gonzalo >      > >      > >      >     -- >      > http://dense13.com >      > http://www.whole-play.com >      >     _______________________________________________ >      >     chuck-users mailing list >      > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >      > > >     -- > http://dense13.com > http://www.whole-play.com >     _______________________________________________ >     chuck-users mailing list > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

-- http://dense13.com http://www.whole-play.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto: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://dense13.com http://www.whole-play.com

I implemented those. They basically turn all attributes to string, then chain them separated by spaces. There's a couple of tricky bits, like time and dur, and the problem of strings with spaces in them, but all solvable. Not sure how extensible this is though. I.e. I have a Note class with 10 attributes, which end up being a longish string. Then a Chord class which has a number of notes, that becomes an even longer string. If I had a Progression class with a series of chords, I might end up having very long strings up and down OSC. Not sure if that might become a problem, so far so good. :) On 29.08.18 03:08, mike clemow wrote:

Haha! MPI is an old C library for doing threaded applications. I've never had to use it and it sounds complicated. ;)

Interesting! I have to admit to not using Chuck in a while; are .stringify() and .destringify() built in or did you implement those? What does the string version of a complex data type actually look like?

If it works for you, it's a working solution. I tend to favor getting things working before trying to optimize.

-mike

On Mon, Aug 27, 2018 at 19:13 Gonzalo mailto:gonzalo@dense13.com> wrote:

I didn't know what MPI was, just had a quick check (only got the gist of it). I'm learning a lot of things through Chuck. :) I think it would be interesting, but might be a bit tricky to implement with chuck? I don't know enough though, just wondering.

My approach might have been a bit clumsy. I had two situations to solve:

- Sending an array of primitives of an unknown length. This is relatively easy to solve, adding all the args to the OscMessage in a loop.

- Sending a complex type that includes mixed primitive types. This was a bit trickier, and some conversion needs to happen anyway when using time or dur.

My (probably a bit inefficient) solution was to .stringify and .destringify my objects (using Tokenizer), and then just sending a string over OSC. It's a bit delicate/error prone, but it works, and once I've added those methods to a class, it becomes quite easy to use, for the actual communication. For instance, to transfer myObject would look something like this:

// The sender. Sets up an OscOut, then: oscOut.start("my/adress/pattern"); oscOut.add(myObject.stringify()); oscOut.send();

// The receiver. Gets an OscMsg, then: if (oscMsg.address == "...") {    oscMsg.getString(0) => string stringifiedVersion;    MyClass.destringify(stringifiedVersion) @=> MyClass myObject; }

I've also encapsulated the sender part into a method to be able to simply write:

this.response("my/adress/pattern", myObject);

Is this a decent approach? The type conversion to/from string can be a bit fiddly, but it seems to work. One thing I like is that complex types composed of other complex types are easy to (de)stringify, calling their children's methods.

In the spirit of doing things the "wrong" way... ;) (I like that!) Gz

On 28.08.18 07:31, mike clemow wrote: > Hey that's great! > > Do you think it's worth building a library and standard framework around > sending/receiving those types of messages over OSC? A sort of Chuck/OSC > version of Message Passing Interface. Or do you think that OSC is > general enough to do the job all by itself? > > Curious what your learnings were! > > Congrats! > > -Mike > > -- > Michael Clemow > he/him/his > Artist/Composer/Sound Designer > http://michaelclemow.com http://michaelclemow.com/ > > > > On Mon, Aug 27, 2018 at 5:03 AM Gonzalo mailto:gonzalo@dense13.com > mailto:gonzalo@dense13.com>> wrote: > >     Quick wrap up of this thread. I did what Mike suggested, and it works >     great, thanks for the pointers! It was a bit of work getting to >     transfer >     all the required data structures properly via OSC, but worth the >     effort. :) > > >     On 16.08.18 10:28, mike clemow wrote: >      > Hey! >      > >      > Been a long time since I posted here. In the spirit of doing >     things the >      > "wrong" way (which is what we're all about, right? ;) You _might_ >      > consider architecting your app using two (or more) concurrent >     instances >      > of ChucK; one with your synthesis stuff, and one doing your heavy >      > computation. The one doing the math could be set up to have a >     local OSC >      > API for sending the parameters in and your other code could just >     wait on >      > the response (advancing time in the main chuck instance, while the >      > calculations are being done elsewhere). You would have to have some >      > structure around the communications, but there are ways to make that >      > easier with functors (paging Michael Heuer). >      > >      > The good thing about this is that you get to take advantage of your >      > computer's multiple processors, since Chuck is single-threaded >     (last I >      > checked). Besides, if your calculations are that intense, what's >     another >      > couple of milliseconds for OSC communication? Plus, your >     calculations >      > might run faster this way... maybe. >      > >      > Or don't consider that because it's crazy. ;)  Fwiw, I've >     definitely run >      > into applications that required multiple Chuck instances talking >     to each >      > other, although usually I'm trying to use multiple sound cards >      > simultaneously. I've also abused named pipes in service of >      > inter-application communications, although I really don't >     recommend that. >      > >      > Best, >      > Mike >      > >      > -- >      > Michael Clemow >      > he/him/his >      > Artist/Composer/Sound Designer >      > http://michaelclemow.com http://michaelclemow.com/ >      > >      > >      > >      > On Wed, Aug 15, 2018 at 7:39 PM Gonzalo mailto:gonzalo@dense13.com >     mailto:gonzalo@dense13.com> >      > mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com>>> wrote: >      > >      >     I just did a quick test putting 1::samp all over the place >     :), but so >      >     far no joy. But this is interesting, I'll explore it properly >     when I >      >     have a bit more time. If I can locate where most of the time >     gets used, >      >     I can focus on that. Thanks! >      > >      >     Gonzalo >      > >      >     On 16.08.18 01:36, Jack Atherton wrote: >      >      > Hi! >      >      > >      >      > Shreds block when you don’t advance time. If you don’t >     advance time, >      >      > then ChucK assumes you need all the current computation >     for the next >      >      > audio sample. Is there a place during your long >     computation where >      >     you >      >      > could wait one sample every so often (1::samp => now;)? For >      >     example, in >      >      > the body of a loop. >      >      > >      >      > Jack >      >      > >      >      > On Wed, Aug 15, 2018 at 3:38 AM Gonzalo >     mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com> >      >     mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com>> >      >      > mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com> >     mailto:gonzalo@dense13.com mailto:gonzalo@dense13.com>>>> wrote: >      >      > >      >      >     Hi, >      >      > >      >      >     I'm working on a big project (www.whole-play.com http://www.whole-play.com >     http://www.whole-play.com >      >     http://www.whole-play.com >      >      >     http://www.whole-play.com), tons of classes, tons >      >      >     of calculations happening at various points. My problem is >      >     that some of >      >      >     these calculations take too long, up to a few seconds. I >      >     thought if I >      >      >     run them in their own shred, the main shred would be >      >     unaffected, but >      >      >     it's not the case, and the music stops during those >      >     processes. Maybe >      >      >     I'm >      >      >     doing something wrong. I can't post sample code >     because it's many >      >      >     classes interacting, but I thought maybe someone has >     ideas on >      >     how to >      >      >     tackle this issue? >      >      > >      >      >     Thanks! >      >      >     Gonzalo >      >      > >      >      > >      >      >     -- >      >      > http://dense13.com >      >      > http://www.whole-play.com >      >      >     _______________________________________________ >      >      >     chuck-users mailing list >      >      > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu>> >      >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu>> >      >      > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >      >      > >      > >      >     -- >      > http://dense13.com >      > http://www.whole-play.com >      >     _______________________________________________ >      >     chuck-users mailing list >      > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      >     mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu >     mailto:chuck-users@lists.cs.princeton.edu> >      > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >      > > >     -- > http://dense13.com > http://www.whole-play.com >     _______________________________________________ >     chuck-users mailing list > chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu >     mailto: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 mailto:chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

-- http://dense13.com http://www.whole-play.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu mailto:chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Michael Clemow Artist/Composer/Sound Designer http://michaelclemow.com

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

-- http://dense13.com http://www.whole-play.com