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:
Select
busInput == 1.0 Do something()
busOutput == 1.0 Do somethingElse()
busPlayback == 1.0 Do somethingDifferent()
End
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.
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.
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.
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.
