[chuck-users] osc listener shred woes

mike clemow gelfmuse at gmail.com
Mon Apr 28 19:54:24 EDT 2008


Well, I'm glad that this is a good example of the timing/concurrency
issues at the heart of Chuck's model.  I certainly have learned a lot
through this.  Perhaps a collection of Chuck Concurrency "Best
Practices" can come out of this.  Wiki-fodder, if nothing else.

I hold OSC very close to my heart, since a lot of my audio work is now
being done on networks of machines (an environment Chuck is rather
well primed for), but the concurrency model is throwing up a bit of a
learning curve.  I think that working through it, however, will reveal
a number of paradigms that will make my code all the better for it, so
thanks to everyone for helping me out.

Cheers,
Mike

On Mon, Apr 28, 2008 at 7:23 PM, Kassen <signal.automatique at gmail.com> wrote:
> 2008/4/28 mike clemow <gelfmuse at gmail.com>:
>
> > Kassen, I completely forgot about me.yield(), which makes me feel
> > pretty dumb.  But I guess concurrency is not as simple as Chuck leads
> > me to believe!
> >
>
> Don't.
>
> In fact I have a suspicion, looking at things like we are now, that I too
> missed it a few times in recent history. It's a specialist tool and kind of
> out of the way, syntactically.
>
> I think I pointed out before (on the forum, I think) that while ChucK is
> deterministic in timing that doesn't need to inherently mean you or me will
> be able to easily predict timing in tricky cases like this. Especially the
> event cue here is a questionable bit, at the very least the priority (order
> of execution) between OSC messages and ChucKian events while yielding is
> underdocumented as far as I can tell.
>
> I fear Ge will have to shed (shred?, seeing how he's quite bussy these
> days...) a light on this issue and IMHO it's clear that the OSC hyrarchy
> needs cleaning up as well.
>
> I realise this is a urgent question to some and in that sense a bad thing,
> but I also feel it's very good that this issue which is very much at the
> core of ChucK's way of dealing with concurency and timing is brought to
> light in such a clear and practical way now. Similar scenarios have been
> naging me for a while now but never in such a practical and clear way.
>
> Yours,
> Kas.
>
> _______________________________________________
>  chuck-users mailing list
>  chuck-users at lists.cs.princeton.edu
>  https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
http://semiotech.org


More information about the chuck-users mailing list