Академический Документы
Профессиональный Документы
Культура Документы
LusidOSC v1.0
LusidOSC allows for flexibility within a single, standardized profile rather than requiring
the creation of a new profile for each type of tracking system. This design choice
enables LusidOSC libraries to remain entirely separate from the tracking system while
also enabling functionality by default with any LusidOSC-compliant application. For
example, tracking systems and applications are not required to have the same
dimensionality to function (3D positions can be used in a 2D application, and 2D
positions can be manipulated as 3D data on a surface). If, however, a large number of
applications emerge that are clearly segmented based on particular tracking technologies
or capabilities, future LusidOSC versions could support multiple profiles (as TUIO does),
but only insofar as they are necessary, thus keeping library support and application
integration as strong as possible.
Information about each sensed object is broadcast to applications via OSC (an abstract
layer on top of UDP) and provides eight components that define it in the physical world:
its uniqueID (u); position (x, y, z); rotation (a, b, c); and time (s.m). Regardless of the
sensing platform's capabilities, every object message has the same fundamental data
structure (as well as space allocated for additional platform-specific data if available),
thus allowing any LusidOSC-enabled application to function with any spatial sensing
platform.
Message Parameters
Message Formats
/lusid/1.0 fseq f s m
/lusid/1.0 set u x y z a b c e d
/lusid/1.0 alive [list of every active uniqueID]
Message Order
LusidOSC messages are encapsulated in an OSC Bundle, and the order of messages
within the bundle is important. The "fseq" message is transmitted first, as it contains
information about how to compute time-sensitive calculations for object data. After the
"fseq" message, all "set" messages are sent. Finally, the "alive" message is sent to help
manage object lists by removing messages corresponding to objects that are no longer
in use. Although redundant for sensing systems that send "set" messages for each
uniqueID every frame, the "alive" message serves well in complex systems that sense
different object types at different frame rates to maintain consistent state with their
applications.
Ports
Though the default port for LusidOSC messages is 3333 (one used by virtually all TUIO
applications), users are not limited to this choice. Trackmate allows for connectivity to a
range of ports, supporting many-to-one, one-to-many, and many-to-many [(spatial
input device)-to-(spatial application)] configurations with very little additional overhead.
Since each OSC message begins with a protocol name (such as /lusid/), ambiguity is
eliminated between multiple protocols communicating on the same port. To be fully
compliant with the LusidOSC specification, however, applications using a non-default
port should still allow the user to specify the port (3333 being one of the possible
selections) manually.
Implications
With the OSC protocol outlined in this document, any application that communicates via
LusidOSC will be able to deduce uniqueID, position, and rotation information sent from
any LusidOSC-compliant sensing or tracking system. In addition, applications that use
supplemental data specific to particular tracking systems can check the encoding string
(e) and process the corresponding data (d) accordingly.
do once at startup:
1. initialize OSC Sender to send packets to HOST, PORT.
void setupOnce(){
sender.setup(HOST, PORT); // setup the sender for a host and port.
}
void objectDataUpdated(){
OscBundle oscBundle = new OscBundle(); // create a new OSC bundle
do once at startup:
1. initialize OSC Receiver to listen for packets on PORT.
int lastFrame = 0;
int lastFrameSeconds = 0;
int lastFrameMicroSec = 0;
void setupOnce(){
receiver.setup(PORT); // setup the receiver for a host and port.
}
}
}