Tom Duff;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
</div>Reasonable support for TUIO has to go hand in hand with OSC support. TUIO<br>
is the killer app for OSC. Lots of extremely attractive devices use it,<br>
not just Reactivision, and being unable to exploit them without kludging<br>
around is really not good.<br>
<br>
I count this as a ChucK bug, just like nonexistant garbage collection.<br>
<font color="#888888"><br>
</font></blockquote><div><br>I largely agree with you though I think the term "bug" is a bit exaggerated, "unfinished" sounds better to me. We do need full OSC support and I'd like to see that combined with a plugin/include system. With that everyone could make their own objects that would use OSC, from TUIO to TIRP (Tom's Ice-cream Recipe Protocol).<br>
<br>As I see things OSC depends on the sender and receiver agreeing on what data is being send and what it means, that would greatly benefit from published classes and so on.<br><br>I could also imagine a version of HID that would deal with HID devices in a more raw way which coulkd then be wrapped in comunity made classes for more convenient consumption. I'm not sure the current way of dealing with HID is capable of scaling to the huge range of possible HID devices people might encounter; we can hardly expect Spencer to implement classes like "magic carpet controller" and so on just because they exist, that doesn't seem like a efficient way to use limited resources and time to me.<br>
<br>Yours,<br>Kas.<br></div></div><br>