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 <gonz...@dense13.com
<mailto:gonz...@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 <gonz...@dense13.com
<mailto:gonz...@dense13.com>
> <mailto:gonz...@dense13.com <mailto:gonz...@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
<gonz...@dense13.com <mailto:gonz...@dense13.com>
> <mailto:gonz...@dense13.com <mailto:gonz...@dense13.com>>
> > <mailto:gonz...@dense13.com <mailto:gonz...@dense13.com>
<mailto: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>>
> > <mailto:gonz...@dense13.com
<mailto:gonz...@dense13.com> <mailto:gonz...@dense13.com
<mailto:gonz...@dense13.com>>>
> > > <mailto:gonz...@dense13.com
<mailto:gonz...@dense13.com> <mailto:gonz...@dense13.com
<mailto:gonz...@dense13.com>>
> <mailto: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>
> > <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>>
> > <mailto: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>>>
> > > <mailto: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>>
> > <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <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>
> <mailto: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>
> <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
--
Michael Clemow
Artist/Composer/Sound Designer
http://michaelclemow.com
_______________________________________________
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
