[chuck-users] Shred blocking main shred

mike clemow michaelclemow at gmail.com
Wed Aug 15 20:28:04 EDT 2018


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 <gonzalo at 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 <gonzalo at dense13.com
> > <mailto:gonzalo at 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 at lists.cs.princeton.edu
> >     <mailto:chuck-users at lists.cs.princeton.edu>
> >     https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >
> >
> >
> >
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20180815/82d9f074/attachment.html>


More information about the chuck-users mailing list