[chuck-users] MAUI for PC/Linux

[Stefan Blixt]

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 at gmail.com>
wrote:

> On 22/04/2008, mike clemow <gelfmuse at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080423/b781726d/attachment.htm>