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 <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
