I haven't messed around that much with OSC either, my experience is limited to the monome. The monome doesn't need more than one event listener (definitely not 64), because the only osc message that the monome ever sends looks like this:

/prefix/press x y state (e.g. /256/press 13 7 1 - the prefix is configurable)

which means that only have to listen for "press" and then you do whatever you want. Comparing to another similar protocol (I've worked with something called "Tib/Rendezvous" which has similarities with OSC - both are UDP based), I think that this isn't a bad way to work with incoming UDP messages. If there are two different OSC commands that do different things, it makes sense that you have two seperate entry points in the ChucK code that waits for them. Especially if they can happen simultaneously (gain and buf are sent at the same time). Even if the shred concept isn't exactly mappable to the thread concept, I think it makes sense to keep handling of each asynchronous event in its own shred (like you'd do in a thread based solution).

What could make sense would be to listen to something like /sndbuf/buf/* or /sndbuf/buf, but then you have the problem of finding out what the full name of the incoming event is (../gain or ../rate).

I have occasionally wished for a possibility to wait on multiple events as well (mixing timing events with message events), but I usually find that I'd have to check which event was triggered anyway, which will lead to an if-statement that means that it's not that much harder to do a solution using two shreds.

/Stefan

On Tue, Apr 22, 2008 at 9:57 PM, Kassen <signal.automatique@gmail.com> wrote:
On 22/04/2008, mike clemow <gelfmuse@gmail.com> wrote:
Yes, of course.  So, a while back (and I had promised to send video
and school took over my life instead) I worked on a project building a
trash-sculpture with two bands, who graciously donated audio samples
to the project.  

Did your life take over from making the video or just from sending it? If just the sending then please know I would be very interested in seeing this, this sounds great!

 

And then, also you can listen to two events at once, so if you wanted
to also send "/sndbuf/buf/gain" you'd have to set up a new shred...
but that also necessarily means a new receiver, a new port, and a new
event.  The sender will have to know that to send "/sndbuf/buf/gain,"
they have to send to a different destination.  So, what's the point in
the hierarchy, right?  Everything is flat and everything is it's own
net address.

Yes, I see, and for large amounts of events this would get quite expensive before anything even gets done at all, not to mention spectacularly ugly and hard to edit, I imagine.

I should probably confess that I haven't done that much with OSC yet. I'm greatly in favour of OSC as I find MIDI quite unpleasant but I simply haven't had a situation yet where I had a OSC sender and receiver that would solve some problem I had... but this doesn't look that good to me.

Anyway, yes, I agree this is less then clean. Parsing that hierarchy would depend on string parsing though and we can build strings but ATM we can't pull them apart. I'd also say that this way of dealing with OSC doesn't alleviate some of the practical issues with the native GUI elements at all.

Illustration1; Example of shreds waiting for events taking up CPU. It's not *that* bad but they aren't free either. (see "Taskmanager" or "top" or similar OS tool)
--------------------------------------------
Event some_event;
   
for (0 => int i; i < 1000; i++)
    {
    spork ~my_shred();
    me.yield();
    }
minute => now;
//clean it all up
some_event.broadcast();

fun void my_shred()
    {
    //no functionality at all here
    some_event => now;
    }
----------------------------------------------
 

Anyway, I'm done ranting for now.  I have to admit that I'm a bit
obsessed with OSC in general.

If that's "ranting" I'd love to hear about your more serious concerns! :¬)

On some level I think your concerns with OSC here are quite similar to  some of the concerns about the MAUI. There ought to be a more powerful and compact way of structuring these things. There have been proposals for shreds waiting for multiple events and I agree that could be a good idea but for even just 64 events (I'm thinking about the Monome here) that would already be a lot of boring monotonous code. I feel we need something compact that would have a single event and more elaborate parsing of it's members. You make it sound like MIDI parsing is more elegant then OSC and considering the MIDI spec I think that means there is a issue... I like MIDI as much as anyone, it's cheap and generally available, but readability and simplicity don't seem to have been high on the list there.


Thanks for "ranting"!
Kas.

_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users




--
Release me, insect, or I will destroy the Cosmos!