Re: [chuck-users] Shred blocking main shred

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 On Wed, Aug 15, 2018 at 7:39 PM Gonzalo 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> 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 _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users