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 On Mon, Aug 27, 2018 at 5:03 AM Gonzalo <gonz...@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 <gonz...@dense13.com > > <mailto:gonz...@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 <gonz...@dense13.com > > <mailto:gonz...@dense13.com> > > > <mailto:gonz...@dense13.com <mailto:gonz...@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 > > <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 > _______________________________________________ > 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
