[chuck-users] Shred blocking main shred

mike clemow michaelclemow at gmail.com
Tue Aug 28 13:08:03 EDT 2018


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> 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>> 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>>> 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>>>> 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>), 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>>>
> >      >      >
> 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
> >
> >
> >
> > _______________________________________________
> > 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
>
-- 
Michael Clemow
Artist/Composer/Sound Designer
http://michaelclemow.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20180828/f562522a/attachment-0001.html>


More information about the chuck-users mailing list