[chuck-users] MAUI for PC/Linux

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080422/01113b4e/attachment.html>