Receiving OSC messsages from TotalMix


Anyone familiar with TotalMix and OSC?

I just want to map a couple volume faders from the Input and Output busses of TM. You have to set the bus state


first before sending /1/volume1 to set the correct volume for track 1. This works.

Receiving the OSC from TM the other hand using

On OSCMessageReceived (m : OSCMessage) Matching "/1/volume1"

matches both Input track 1 and Output track 1 volumes without discerning between which is which.

Any ideas how to figure this out?

First of all you need to use parameter 1.0 to change the bus state and send one of the following:

  • /bus/Input 1.0
  • /bus/Output 1.0
  • /bus/Playback 1.0

When you send one bus select OSC command, TM FX send you back the current bus with a 1.0 value and the other buses with a 0.0 value.
e.g. If you send /bus/Input 1.0, then TM FX will send back:

  • /bus/Input 1.0
  • /bus/Output 0.0
  • /bus/Playback 0.0

If you want to act differently depending on the current selected bus, you will have to use a variable to remember the bus states. If you are the only one who can select the active bus, simply the bus states in variables. If somebody else can change the bus states, the use an OSC callbacks to instantiate the bus state variables.

This bus states variables can then be used in the ‘volume’ callback using a Select statement:

  busInput == 1.0 Do something()
  busOutput == 1.0 Do somethingElse()
  busPlayback  == 1.0 Do somethingDifferent()

Ok… this makes sense. TM will send page data (volume in this case) on the last set I/O bus only.

Another question… How do I get TM to send both Input 1 and Output 1 volume data if only one bus state can be active at a time? (moving faders inside TM)

E.G. If the last bus I set via GP is /1/busInput 1.0, GP only receives TM input 1 fader volume data. And if /1/busOutput 1.0 is set, only GP only receives TM output volume data… never both. This means changing TM faders will cause TM and GP to go out of sync.

That’s right.

You cannot do it at the same time. In GP I only use the 8+1 faders of my control surface mapped to GP slider widgets. I follow what RME do on TouchOSC or Lemur. You can switch to one of the bus and can switch banks and tracks to go over the 8 channels limitation and that’s it.

It is not my advice to do so, but I am working on a TouchOSC mk2 template to go over the present RME limitation and use therefore time multiplexing. My template is very very experimental, for the moment it is not robust at all and depends from both the way RME send OSC informations and from the way Touch OSC processes it. My next step will be to further analyze how to optimize the OSC bus cycling I do in TouchOSC with regard to the TM FX incoming OSC flow. Not sure at all it will ever work properly, even if I am very close from my goal.

Please, tell us what you will be able to achieve. :wink:

I’ve found a way to have TM send on both bus channels at the same time. :slight_smile:

  1. Set up TM to receive on data a second OSC port.
  2. Set up GP OSC targets to use both TM ports.
  3. Set i/o bus on each TM target.
   OSC_SendDoubleSpecific ("/1/busOutput", 1.0, TotalMixIP, TotalMixOutputPort)  
   OSC_SendDoubleSpecific ("/1/busInput", 1.0, TotalMixIP, TotalMixInputPort)

Now, TM sends both Input and Output data… except they are coming through different ports.

One problem with this, in GP I need to know which port receives a message. For example.

On OSCMessageReceived (m : OSCMessage) Matching "/1/volume1"

If TotalMixOutputPort received the message then I know Analog Output 1 fader was changed.

Is there a way to know which GP OSC target send the message?

Yes you are partially right, I forgot about the fact that you can have up to 4 TM FX remote controls and that you can thus use several simultaneously to adresse directly 3 different buses. (I already requested to RME to have more, because it would possible to have up to 8 remote controls). But the issue with this approach is that you will be able to use several OSC output port to reach the different TM FX remotes, but regarding the incoming OSC messages, there is currently only one reception port in GP, so you won’t have a straightforward solution to deal with 3 remotes sending to a unique port. I wouldn’t do that. But you could imagine using 3 GP instances with different reception port, and bridge two of them to the first one. It should work, but it would be a very complicated solution.

Ok. So it’s not possible for GP to know the who sends data to the single port GP exposes.

The problem is OSC messages aren’t necessarily unique. Two clients sending messages to GP can send the same message and a GP user won’t know which is which. Another example could be /play. A common scenario possibly.

Workaround would be to create intermediary OSC host which catches and relays the message with additional identifying info. In your last example of using GP instances, simply catch the busInput /1/Volume1 and resend it to the main GP instance and call it /busInput/1/volume1 or whatever. Very easy to implement but not very elegant having multiple instances. If GP ever adds the ability to get client info, I’ll revisit this.

Thanks again for your insight,


Your analysis is true.

GP won’t we able to do this as the OSC “standard” is not designed for that. You can identify the sender because it uses a particular UDP port. Perhaps, that GP could be able to deal with more incoming port in the future, but for now, you have to find workarounds.