Topic: Global OSC controller
Hi,
I understand that the OSC interface of Totalmix is somewhat good enough to create alternative interactive interfaces, but it clearly is not good enough to make complete automation.
First, the commands are badly suited for automated control:
- the fact you need to change from track to track for some features (eq, for instance) means you may have to send 190 time a /2/track+ command before you can change a value. This is, to say the least, not very practical.
- the fact that you cannot set on/off values but only toggle them force you to send a command, get the answer and then resend the command if needed. Again not very practical.
- the fact that, for page 1 commands, you access the sliders by their respective number on the displayed screen, and not by their, say, MADI number makes it quite difficult, as, if the user changes the screen layout the automation cease to work correctly.
- switching from stereo to mono changes the quantity of tracks, which means you never get a secure sense of how far is one track from another.
In general, the consequence of the above remarks is that, when you implement an automated control based on OSC, you are forced to listen to the answers provided by the OSC interface at each stage. This seems normal (why would you send answers if they were not to be listened ?) but in reality those answers are sent in multiple UDP packets, and with a small delay.
This means you can control features but only in a slow manner.
If you have to change, say, 10 volumes, you have to send about 25 commands (this is an approximation, as it essentially depends of the currently selected track, and if the tracks you want to set are consecutive or not). Something like:
/2/busInput 1.0 (recieving 6 bundle packets as answer)
/2/track- 1.0 (recieving 6 bundle packets as answer)
/2/track- 1.0 (recieving 6 bundle packets as answer)
/2/track- 1.0 (recieving 6 bundle packets as answer)
/2/track- 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.0 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.1 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.2 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.3 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.4 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.5 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.6 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.7 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.8 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 0.9 (receiving 1 bundle packet as answer)
/2/track+ 1.0 (recieving 6 bundle packets as answer)
/2/volume 1.0 (receiving 1 bundle packet as answer)
So you have to recieve not less than a hundred answer packets.
It will work, but this will take easily 2-3 seconds to go, not because the software or network is slow, but mostly because the commands are designed so that at each step, you have to wait for the answers which takes each about 1/100th of a second to get back.
Comparatively, you can do this:
/1/busInput 1.0 (discarding the answers)
/1/volume1 0.0 (discarding the answers)
/1/volume2 0.1 (discarding the answers)
/1/volume3 0.2 (discarding the answers)
/1/volume4 0.3 (discarding the answers)
/1/volume5 0.4 (discarding the answers)
/1/volume6 0.5 (discarding the answers)
/1/volume7 0.6 (discarding the answers)
/1/volume8 0.7 (discarding the answers)
/1/volume9 0.8 (discarding the answers)
/1/volume10 0.9 (discarding the answers)
/1/volume11 1.0 (discarding the answers)
in less than a tenth of second (which should be fast enough in most circumstances), but it doesn't work for all settings, nor for a group of more than 24 consecutive slides.
Having a bit more cartesian OSC control would solve all those issues: something like
/<bus-name>/<madi-id>/<feature> <value>
for instance
/input/10/volume 0.5
or
/output/152/eqEnable 1.0 (which doesn't toggle the value, but sets the value to 1).
and if you want to get the values, instead of setting them, something like
/input/10/getall -1.0 (for, say, all settings of the input track 10)
possibly you could even use the value -1.0 to get a specific value, since negative values are not used anywhere
/input/10/volume -1.0 (to get the volume of track 10)
This could be implemented and yet keeping the old OSC commands (since they don't overlap).
Reading the posts of this forum, it seems that people ask for it since about 10 years, so it apparently is difficult to provide this feature for some reasons (that I personally don't understand, but it's like that).
OK, let's admit RME isn't going to do it.
Yet apparently, the Totalmix remote succeed in controling in a fast manner the Totalmix application.
I initially thought it was using OSC but some invetigations shows it's apparently not.
This may explain, by the way, why it is faster :-)
So the question is:
Is there a documentation of the messages exchanged between Totalmix remotes and Totalmix ?
This would allow to build an application that on one end would provide a "rational" OSC interface and on the other would control the Totalmix in a fast and understandable manner, allowing people who want to make automation to do so.