On 22/04/2008, <b class="gmail_sendername">mike clemow</b> <<a href="mailto:gelfmuse@gmail.com">gelfmuse@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes, of course. So, a while back (and I had promised to send video<br> and school took over my life instead) I worked on a project building a<br> trash-sculpture with two bands, who graciously donated audio samples<br> to the project. </blockquote>
<div><br>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!<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> And then, also you can listen to two events at once, so if you wanted<br> to also send "/sndbuf/buf/gain" you'd have to set up a new shred...<br> but that also necessarily means a new receiver, a new port, and a new<br>
event. The sender will have to know that to send "/sndbuf/buf/gain,"<br> they have to send to a different destination. So, what's the point in<br> the hierarchy, right? Everything is flat and everything is it's own<br>
net address.</blockquote><div><br>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.<br><br>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.<br>
<br>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.<br>
<br>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)<br>--------------------------------------------<br>
Event some_event;<br> <br>for (0 => int i; i < 1000; i++)<br> {<br> spork ~my_shred();<br> me.yield();<br> }<br>minute => now;<br>//clean it all up<br>some_event.broadcast();<br><br>fun void my_shred()<br>
{<br> //no functionality at all here<br> some_event => now;<br> }<br>----------------------------------------------<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> Anyway, I'm done ranting for now. I have to admit that I'm a bit<br> obsessed with OSC in general.</blockquote><div><br>If that's "ranting" I'd love to hear about your more serious concerns! :¬)<br>
<br>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.<br>
</div><br><br>Thanks for "ranting"!<br>Kas.<br></div>