1 (edited by mxa 2014-01-12 17:53:04)

Topic: anatomy of the OSC messages

I have found the OSC chart https://archiv.rme-audio.de/download/os … talmix.zip. There is a little explanation in the Excel document on the spreadsheet-page with the name "comments".

I want to change the EQ Frequency of the middle (second/green) value on the analog outs 1/2.

In the Excel document the corresponding line reads:

Name    internal ID        ScaleType         ScaleTypeVal       Channel
eqFreq2    kPEQ_Freq2    kOSCScaleFreq    kOSCScalePrintVal    0

I can successfully change the Mic 1 level from the Hardware inputs like this:

/1/volume1 0.5

The format appears to be

/{Pagename}/{Name} {Value}

Pagename is the name of the page in the Excel document. There is "none paged" where this value is ommited completely, then there is ""Page1", "Page2" and "Page3" which correspond to Pagename /1, /2 or /3
Name is the name of the controller as listed in the Excel document.
Value ist the value of the controller to set it to, but normalized 0.0 to 1.0 (you must define the type as a float otherwhise if you send a 1, 1.0 or anything above, the fader will jump back to -oo)

When the volume is changed like this, TotalMix is responding through the OSC connecton (default: port 9001) like this:

/1/volume1Val -12.1 dB

It seems TotalMix's controls can't be adressed by absolute OSC messages (yet – I read here it's in the works). Rather it is expected awkwardly to "navigate" to different controls by sending selection messages. That seems geared towards the App TouchOSC but is generally neither intuitive, nor does it make clever use of the powerful message nesting OSC provides.
A nice OSC implementation would work similar like this:

/HardwareInputs/1/Volume -21

there is no need to normalize the values to a 0-0.999 range in OSC.

/HardwareInputs/Volume -21

could set all Hardware Inputs to -21dB at once.

I found out that in order to change the EQ Frequency I have to do this:

/1/busOutput 1.0
/setBankStart 0.0
/2/eqEnable 0.51
/2/eqFreq2 0.5

Sending /2/eqEnable 0.51 again will toggle the EQ off. Strangly enough you can't just switch it on or off explicitly by sending /2/eqEnable 0.0 and /2/eqEnable 1.0 but you have to survey and parse what TotalMix sends back over OSC to know the current status of the EQ and go from there (who made this up??).

When using Pure Data (Pd) with [mrpeach/packOSC] you have to send

[slider 0-1]
|
[sendtyped /2/eqFreq2 f $1(      // not send, but sendtyped!
|
[mrpeach/packOSC]
|
[mrpeach/udpsend]


If you want to crash TotalMix, then just send it an untyped

/2/eqFreq2 -50

And by the way: I like the new GUI. Nice work.

Re: anatomy of the OSC messages

Hi all,

sorry for digging this topic out..

First of all THANKS @mxa for providing more information on OSC in combination with TM than the official RME excel file is providing (sad but true).

mxa wrote:

............
It seems TotalMix's controls can't be adressed by absolute OSC messages (yet – I read here it's in the works). Rather it is expected awkwardly to "navigate" to different controls by sending selection messages. That seems geared towards the App TouchOSC but is generally neither intuitive, nor does it make clever use of the powerful message nesting OSC provides.
A nice OSC implementation would work similar like this:

/HardwareInputs/1/Volume -21

..........

I totally agree with you on this part. Actually I would even go one step further:
A nice OSC implementation would make it possible to adress all the channels WITHIN SUBMIXES!
So for example, if I would like to control my main mic (input channel 9 on my FF UFX) volume just on my inear-mix (output channel 9/10)...
right now I would have to "navigate" to my output channel (as you already mentioned) and then I would have to navigate to my input channel. Now I could control my volume. This makes it not only very inconvenient but also impossible to control different things on different submixes simultaneously.

mxa wrote:

Sending /2/eqEnable 0.51 again will toggle the EQ off. Strangly enough you can't just switch it on or off explicitly by sending /2/eqEnable 0.0 and /2/eqEnable 1.0 but you have to survey and parse what TotalMix sends back over OSC to know the current status of the EQ and go from there (who made this up??).

THAT's the question smile "Who made this up?" ... this eq TOGGELING behaviour totally fits into the rest of the OSC implementation....

That's a topic RME should be thinking about again, for sure!

Don't get me wrong: i LOVE my FF UFX... it's a perfect tool with a perfect sound, I'm not missing anything EXCEPT some decent controlling possibilities.

Thanks RME for NOT IGNORING our suggestions which would really improve your awesome products cool

3 (edited by Burtan 2014-01-12 13:33:09)

Re: anatomy of the OSC messages

mxa wrote:

there is no ned to normalize the values to a 0-0.999 range in OSC.

There is an advantage for sending normalized values instead of absolute values and showing the absolute values by receiving them from TFMX. Not any parameter of TMFX is scaled linearly, thus by normalizing values, the scaling is done by TMFX. Otherwise the client app would have to do this. Although some clients support scaling (like OSC-Commander ;-)), you still don't know the math behind any parameter.

OSCAR for Android and iOS with TotalMixFX templates: http://www.oscar-app.de

Re: anatomy of the OSC messages

Thanks for ben26 and Burtan for reviving this old post. As I am predominantly under Linux nowadays, I would like to bring up another big design drawback of the current implementation: Ideally I would send OSC messages to the device, not the software on the host computer connected to the device. In other words: I would like to control the Fireface, not TotalMix. TotalMix then can visualize the changes in the values if it is connected. That would open up another world of possibilities.

5 (edited by ebulb 2014-01-13 11:59:16)

Re: anatomy of the OSC messages

ben26 wrote:

I totally agree with you on this part. Actually I would even go one step further:
A nice OSC implementation would make it possible to adress all the channels WITHIN SUBMIXES!
So for example, if I would like to control my main mic (input channel 9 on my FF UFX) volume just on my inear-mix (output channel 9/10)...
right now I would have to "navigate" to my output channel (as you already mentioned) and then I would have to navigate to my input channel. Now I could control my volume. This makes it not only very inconvenient but also impossible to control different things on different submixes simultaneously.

I agree....

mxa wrote:

Thanks for ben26 and Burtan for reviving this old post. As I am predominantly under Linux nowadays, I would like to bring up another big design drawback of the current implementation: Ideally I would send OSC messages to the device, not the software on the host computer connected to the device. In other words: I would like to control the Fireface, not TotalMix. TotalMix then can visualize the changes in the values if it is connected. That would open up another world of possibilities.


How would you communicate OSC directly with UFX and bypass totalmix ? My understanding is OSC data would still need to be recieved by a computer and then a software routine to convert and allow UFX to recieve the commands ?? If a software process on the computer is absolutely necessary then isnt this what totalmix effectively is ? Im curious as to how the process could be any different without UFX having a network port.. 

Having said that I saw a video on youtube yesterday where a guy plugged his DSLR directly into a USB router and used a tablet to control the camera through USB without any computer..

http://www.youtube.com/watch?v=xnlYzt6zcpw

Is it feasable something like this router could connect UFX through USB port and then wifi to a tablet for direct OSC control or the totalmix ipad app ? It looks like that router is made for 4G modems but has a hacked firmware to become a wifi dongle for DSLR.. My guess is no way it would work UFX but it would be cool if CC drivers or some basic operation could work with a device like this over wifi.

Aside from that what advantages do you see from UFX receiving OSC directly instead of through totalmix ?