TUIO-alternatieven

* LusidOSC: Een waardig alternatief voor TUIO dat ook als laag bovenop OSC geïmplementeerd werd. LusidOSC breidt de ideeën van TUIO uit, op een manier dat het protocol voor een breder gamma aan systemen gebruikt kan worden (dus niet specifiek gericht op multi-touch touchscreens). Vandaar de belangrijke verschillen in het protocoldesign. Een eerste groot verschil zit bij het profielgebruik. TUIO bezit een aantal voorgedefinieerde profielen (2D, 3D, ...) die gebruikt worden naargelang de noden van de trackingsysteem. Bij LusidOSC is er slechts 1 profiel dat gebruikt zal worden voor alle situaties. Op die manier is het niet langer mogelijk dat een client-applicatie slechts een implementatie biedt voor 1 bepaald profiel, m.a.w. maar 1 type van berichten (bv. van het 2D-profiel) kan parsen. Bovendien blijft het protocol zo onafhankelijk van de bestaande trackingsystemen. Andere verschillen zitten in de parameters die meegezonden worden bij LusidOSC-berichten. De set-berichten bevatten volgende parameters (9 in totaal): uniek ID (u), positie (x, y, z), rotatie (a, b, c) en parameters voor extra data (e, d). fseq (geeft aan tot welk frame een pakket hoort) heeft 3 parameters: frame-nummer (f) en de tijd (s.m), maar 1 parameter (frame-nummer) bij TUIO. Daarnaast worden bij TUIO ook nog vectoren meegezonden met info over snelheid en richting. Die informatie wordt bij TUIO typisch aan de low-level zijde, dus bij de tracker, berekend. LusidOSC daarentegen zendt de tijd mee in de fseq-berichten en schuift die berekeningen door naar de clientzijde, wat het berekenen toch wel minder efficiënt maakt. Anderzijds nemen de vectoren (64 bit per seq-bericht voor een object, 32 bit voor een cursor) wel veel plaats in in een UDP-pakket, want ze zitten vervat in elk seq-bericht. De tijd (64 bit) zit enkel in een fseq-bericht, dat per pakket 1 keer wordt gestuurd.
Een concrete vergelijking brengt aan het licht dat LusidOSC duidelijk efficiënter en performanter is als het gaat om traceren van objecten in een 3D-omgeving, nu net hetgeen waar de LusidOSC-berichten zich op focussen. Bij het traceren van 2D-cursors (lees: vingers, dus het belangrijkste voor deze thesis) is TUIO dan weer op alle vlakken beter dan LusidOSC omdat LusidOSC maar 1 type van set-berichten kent die eigenlijk speciaal gericht zijn op een 3D-omgeving. Hierbij komt nog eens het nadeel dat bij het ontvangen van een LusidOSC-bericht informatie omtrent snelheid en acceleratie nog moet berekend worden.

Dit protocol wordt gebruikt door 1 belangrijk trackingsysteem, nl. Trackmate, maar dat is vooral gericht op objecten die voorzien zijn van unieke tags, wat ook bij reacTable toegepast wordt.
LusidOSC biedt momenteel libraries aan voor volgende programmeertalen: Processing, Max/MSP en Java.
Gezien de populariteit en ondersteuning van een brede waaier aan programmeertalen is TUIO nog steeds het standaardprotocol, maar LusidOSC is aan een opmars bezig. Libraries voor Flash, Python en C++ worden momenteel ontwikkeld. Aan de trackerzijde zijn er nog maar weinig mogelijkheden, voorlopig enkel Trackmate.

* MIDI: ReacTIVision kan naast TUIO ook via MIDI communiceren, hoewel TUIO nog steeds de primaire manier van communicatie blijft. Er wordt dan een XML-file opgesteld die de mapping van positie en rotatie naar MIDI bepaalt. Zo worden x- en y-positie voorgesteld door de positie van faders, een hoek door een draaiknop en note-on/note-off geeft de aanwezigheid van een object aan. Een groot nadeel van de MIDI-berichten is de beperkte bandbreedte (31,25 kbit/s, i.e. 4 bytes per millisec). 1 MIDI-bericht van 3 bytes neemt dus 0.75 millisec in beslag, dus 3 berichten (voor xpos, ypos en hoek) versturen zou 2.25 millisec duren, wat beduidend veel trager gaat dan het verzenden van UDP-pakketten.