tracker data
what you need to know to receive tracker data via OSC in various formats
Three different formats can be used to send the tracker data to your application.
All of these formats are OSC based, and organized in OSC bundles. Each bundle represents all the data tracked at a given moment in time, and is tagged with a time-stamp. Note however, that this time-stamp is calculated at the moment the data arrives in the QVicon2OSC-application, which is not necessarily the same instant in time as the data is actually generated by tarsus.
You can specify, to which host and port you want the OSC bundle to be sent in the "OSC Server" area.
plain OSC
This is the most basic format which can be used to connect to any generic OSC-server.
Each channel (consisting of one or several subchannels) is represented by one OSC message within the bundle.
The 1st part of the OSC address can be defined by the user as "Prefix". The default is /prefix
.
The 2nd part of this address is derived from the channel name as given by Vicon.
- g. the vicon channels
body3:rfoot <T-X>
,body3:rfoot <T-Y>
ANDbody3:rfoot <T-Z>
, are grouped together into one channel/body3/rfoot/T
with 3 subchannels (x, y, z).
Example:
Two channels "/body3/rfoot/T" and "/body3/lfoot/T" are selected; the prefix is "/tracker". Each OSC bundle will consist of 2 messages. The 1st message consists of an address /tracker/body3/rfoot/T', followed by a list of 3 floating point elements, representing x, y and z. The 2nd message consists of an address /tracker/body3/lfoot/T', again followed by a list of 3 floating point elements, representing x, y and z.
SC3 client
This OSC message is specially formatted for use with a SuperCollider3 client (the sclang unit).
Each OSC bundle consists of one single message.
This message is sent to the OSC address "/client".
The 1st data element in the message is a OSC symbol denoting a command to be called on the sclang unit with the rest of the data as an argument. The default command "ViconTrackerData" can be changed.
The rest of the message is a list of floating point values, which is formed by linearily appending the channel values.
Example:
Two channels "/body3/rfoot/T" and "/body3/lfoot/T" are selected; the command is "TrackerData". The single OSC message in the bundle has an address "/client", which is followed by a list of 7 items. The first item is the symbol "TrackerData", the next 3 items are floating point values representing x, y and z (of /body3/rfoot/T), the last 3 items are floating point values representing "body3:lfoot <T-X>", "body3:lfoot <T-Y>", and "body3:lfoot <T-Z>".
As you can see, in this format the order of the data depends on the selection. Selecting "/body3/rfoot/T" and "/body3/lfoot/T" will generate an OSC-message that is structurally identical to the message generated by selecting "/body3/head/r" and "/body2/thorax/A". However, the meaning of the data will be different (e.g. the last element of the list, will be the z-position of the left foot of body3 in the first case, but in the second case it will be the rotation around the z-axis of the thorax of body2.)
Therefore it is important to have a way to query which channels are selected (and in which order the data will appear). See the section about gathering information to learn how to do this.
SC3 server
This OSC message is specially formatted for use with a SuperCollider3 server (the scsynth unit).
The channel values will made be available as data-busses within the scsynth. These data-busses are allocated in one block, starting at a choosable base index.
Like with the SC3 client format, each OSC bundle consists of one single message.
This message is sent to the OSC address "/c_setn". The first two arguments, denote the base index and the number of busses to write. The rest of the message is a list of floating point values, which is formed by linearily appending the channel values.
Example:
Two channels "/body3/rfoot/T" and "/body3/lfoot/T" are selected; the base index is "128". Therefore, busses 128-131 will hold the x, y and z values of "/body3/rfoot/T", whereas busses 132-135 will hold x, y and z of "/body3/lfoot/T".