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 &quot;bug&quot; is a bit exaggerated, &quot;unfinished&quot;  sounds better to me. We do need full OSC support and I&#39;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&#39;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&#39;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 &quot;magic carpet controller&quot; and so on just because they exist, that doesn&#39;t seem like a efficient way to use limited resources and time to me.<br>
<br>Yours,<br>Kas.<br></div></div><br>