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:<br>
<br>/prefix/press x y state (e.g. /256/press 13 7 1 - the prefix is configurable)<br><br>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).<br>
<br>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).<br><br>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.<br>
<br>/Stefan<br><br><div class="gmail_quote">On Tue, Apr 22, 2008 at 9:57 PM, Kassen <<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 22/04/2008, <b class="gmail_sendername">mike clemow</b> <<a href="mailto:gelfmuse@gmail.com" target="_blank">gelfmuse@gmail.com</a>> wrote:</div><div><div class="Ih2E3d"><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><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><div class="Ih2E3d"><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><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><div class="Ih2E3d"><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><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>
<br>_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Release me, insect, or I will destroy the Cosmos!