[chuck-users] Shred blocking main shred

[Gonzalo]

I tried the 1::samp technique a bit better, but still can't get it to 
work. The computation intensive processes still affect the timing. Does 
anybody have any working example of this?

In any case, I'm going to try the multiple-instance approach, which 
looks like a bit of work. Never done that before, any pointers on where 
to look for info about setting that up?

Thanks!
Gonzalo


On 16.08.18 10:37, Gonzalo wrote:
> 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 <gonzalo at dense13.com 
>> <mailto: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>
>>      > <mailto: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>
>>      >     <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>
>>      >     <mailto: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
>>     <mailto: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
>>     <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