[chuck-users] Shred blocking main shred

Gonzalo gonzalo at dense13.com
Tue Aug 28 19:25:38 EDT 2018


I implemented those. They basically turn all attributes to string, then 
chain them separated by spaces. There's a couple of tricky bits, like 
time and dur, and the problem of strings with spaces in them, but all 
solvable.

Not sure how extensible this is though. I.e. I have a Note class with 10 
attributes, which end up being a longish string. Then a Chord class 
which has a number of notes, that becomes an even longer string. If I 
had a Progression class with a series of chords, I might end up having 
very long strings up and down OSC. Not sure if that might become a 
problem, so far so good. :)


On 29.08.18 03:08, mike clemow wrote:
> Haha! MPI is an old C library for doing threaded applications. I've 
> never had to use it and it sounds complicated. ;)
> 
> Interesting! I have to admit to not using Chuck in a while; are 
> .stringify() and .destringify() built in or did you implement those? 
> What does the string version of a complex data type actually look like?
> 
> If it works for you, it's a working solution. I tend to favor getting 
> things working before trying to optimize.
> 
> -mike
> 
> On Mon, Aug 27, 2018 at 19:13 Gonzalo <gonzalo at dense13.com 
> <mailto:gonzalo at dense13.com>> wrote:
> 
>     I didn't know what MPI was, just had a quick check (only got the
>     gist of
>     it). I'm learning a lot of things through Chuck. :) I think it would be
>     interesting, but might be a bit tricky to implement with chuck? I don't
>     know enough though, just wondering.
> 
>     My approach might have been a bit clumsy. I had two situations to solve:
> 
>     - Sending an array of primitives of an unknown length. This is
>     relatively easy to solve, adding all the args to the OscMessage in a
>     loop.
> 
>     - Sending a complex type that includes mixed primitive types. This
>     was a
>     bit trickier, and some conversion needs to happen anyway when using
>     time
>     or dur.
> 
>     My (probably a bit inefficient) solution was to .stringify and
>     .destringify my objects (using Tokenizer), and then just sending a
>     string over OSC. It's a bit delicate/error prone, but it works, and
>     once
>     I've added those methods to a class, it becomes quite easy to use, for
>     the actual communication. For instance, to transfer myObject would look
>     something like this:
> 
>     // The sender. Sets up an OscOut, then:
>     oscOut.start("my/adress/pattern");
>     oscOut.add(myObject.stringify());
>     oscOut.send();
> 
> 
>     // The receiver. Gets an OscMsg, then:
>     if (oscMsg.address == "...") {
>         oscMsg.getString(0) => string stringifiedVersion;
>         MyClass.destringify(stringifiedVersion) @=> MyClass myObject;
>     }
> 
>     I've also encapsulated the sender part into a method to be able to
>     simply write:
> 
>     this.response("my/adress/pattern", myObject);
> 
>     Is this a decent approach? The type conversion to/from string can be a
>     bit fiddly, but it seems to work. One thing I like is that complex
>     types
>     composed of other complex types are easy to (de)stringify, calling
>     their
>     children's methods.
> 
>     In the spirit of doing things the "wrong" way... ;) (I like that!)
>     Gz
> 
> 
> 
>     On 28.08.18 07:31, mike clemow wrote:
>      > 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 <http://michaelclemow.com/>
>      >
>      >
>      >
>      > On Mon, Aug 27, 2018 at 5:03 AM Gonzalo <gonzalo at dense13.com
>     <mailto:gonzalo at dense13.com>
>      > <mailto:gonzalo at dense13.com <mailto:gonzalo at 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
>     <gonzalo at dense13.com <mailto:gonzalo at dense13.com>
>      >     <mailto:gonzalo at dense13.com <mailto:gonzalo at dense13.com>>
>      >      > <mailto:gonzalo at dense13.com <mailto:gonzalo at dense13.com>
>     <mailto: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>>
>      >      >     <mailto:gonzalo at dense13.com
>     <mailto:gonzalo at dense13.com> <mailto:gonzalo at dense13.com
>     <mailto:gonzalo at dense13.com>>>
>      >      >      > <mailto:gonzalo at dense13.com
>     <mailto:gonzalo at dense13.com> <mailto:gonzalo at dense13.com
>     <mailto:gonzalo at dense13.com>>
>      >     <mailto: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>
>      >      >     <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>>
>      >      >     <mailto: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>>>
>      >      >      >     <mailto: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>>
>      >      >     <mailto: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>
>      >     <mailto: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>
>      >     <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
>      >      >      >
>      >      >
>      >      >     --
>      >      > 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>>
>      >      >     <mailto: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>
>      >     <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
>      >      >
>      >
>      >     --
>      > 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
> 
> -- 
> Michael Clemow
> Artist/Composer/Sound Designer
> http://michaelclemow.com
> 
> 
> _______________________________________________
> 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


More information about the chuck-users mailing list