You are not logged in. Please login or register.
RME User Forum → TotalMix FX → Global OSC – TotalMix FX Alpha available
Please note a small update of the protocol description table. TM FX and the protocol zip now include version 260614, with this change:
- fixed wrong format of mix-message in table
Just wanted to say really appreciate working with this alpha so far. Hoping for snapshot save to be implemented soon and maybe even workspace saving. For my usecase it would mean I basically can build tooling that writes all it's state to one snapshot - to keep it working across power cycling and such.
Side note, TM remembers and stores last state, so power cycling should already work without changing TM.
But yes, the savig snapshot/workspace could be handy here and there....
I really like the Global OSC and can't wait to have it implemented in the official version of TM.
Would it be possible to implement OSC adresses to activate/show interface panels like EQ or Dynamics? For example it would be great if I could send an OSC message to simultaniously open the EQ panel of channel 1 when I enable the EQ on channel 1.
Regards
Florian
I see something unexpected here:
- with send-all-data-on-start turned ON (GlobalOSCSettings & 2) I get an incomplete dump when TM launches (mostly missing room EQ)
- with send-all-data-on-start turned OFF there is an even more incomplete dump sent anyway (about 50% of it)
In both cases, an app watching for TM to launch (like a StreamDeck plugin) needs to wait a few hundred ms before issuing a /sendall request to get the complete dump, send it too early and it will be ignored it seems.
LMK if you want a bash repro script showing this with nc.
This is with TM FX 2.1 alpha 7, with a UFX III on macOS 26.5
Did you try to lower the bandwidth for OSC?
prspn:
- with send all... OFF you currently get a complete random set of data at start (perhaps the send-request flags should be cleared in this case to send absolute nothing instead)
- for a StreamDeck PlugIn using "sendall" is not a good idea, because it triggers a large amount of mixer data, better use "sendchan" (I think about a function "sendactivenode" to reduce it to effictive mixer nodes, necessary also for MCP)
- tests with TotalMix-to-TotalMix connection showed typical limitations of UDP transfers (you can compare the new message counter in Help-Menu), but in best setup (Mac to Mac with Ethernet) even with unlimited bandwith all data arrived
Any chance we could get the track color-information as well via OSC?
I'm building a headphone mixer so clients can control their phones output directly.
Works beautifully incl. channel visibility and user set names - color would be the cherry on top!
Thanks for this!
Frank
Sorry, didn't get an email notification from the forum, so I didn't see your replies until now.
Did you try to lower the bandwidth for OSC?
Yes, I tried both BW cap settings + off, no difference.
This is over localhost by the way, but same result for ethernet as well.
But I don't think this is a BW issue.
prspn:
- with send all... OFF you currently get a complete random set of data at start (perhaps the send-request flags should be cleared in this case to send absolute nothing instead)
- for a StreamDeck PlugIn using "sendall" is not a good idea, because it triggers a large amount of mixer data, better use "sendchan" (I think about a function "sendactivenode" to reduce it to effictive mixer nodes, necessary also for MCP)
- tests with TotalMix-to-TotalMix connection showed typical limitations of UDP transfers (you can compare the new message counter in Help-Menu), but in best setup (Mac to Mac with Ethernet) even with unlimited bandwith all data arrived
To be clear, a manual "sendall" works perfectly here every time, I get back what I requested, nothing is dropped, full dump.
The problem I see here is that on launch, TM auto sends what looks like an incomplete version of what a normal "sendall" returns.
So I currently have to handle and ignore that first unrequested dump, and send my own request a little later.
If I don't wait ~500ms then TM ignores my manual request.
That does not seem right, and it also means using "sendchan" as a workaround would not help in this case, it gets ignored as well.
And yes with send all set to off I'd expect it to not send anything at all on launch, but that seems like a separate issue.
So the issue for me is that small window at the start where TM will silently ignore OSC requests, while at the same time sending an incomplete dump. I can work around it now that I know, but this is alpha so if it can be fixed, even better? 
Post 1 has links for the latest 2.1 Alpha 8 and the respective, updated protocol document
From the updated protocol document:
26.06.26, Alpha 8
- added "snapshot load" send function to enable simple snapshot-keys with on/off signalling
- added command /sendmix, /sendsubmix with option to send only active nodes
- added color in channel-setting (send only)
- added /showwindow, multiple new parameters to control room
- added re-send options (use carefully, can trigger ping-pong transmissions and lag of faders and dials)
- fixed: starting with option "send all data on start" off triggered undefined set of send data (now no data should be sent)
- reduced count of level messages due to improved change detection
The binaries are from 4 July and include a few more smaller fixes and improvements that do not affect the protocol document. Also the later plugged ARC USB should now be detected correctly (Windows, see former post on first page).
Awesome, thanks for the colors!
Thanks MC for the snapshot-load send function in Alpha 8 — snapshot keys now show their real on/off state, no more workarounds. Great to see a user request land in the software. Much appreciated!
- fixed: starting with option "send all data on start" off triggered undefined set of send data (now no data should be sent)
Awesome, Alpha 8 seems to have fixed both my issues, very nice!
Thank you so much for adding GlobalOSC!
I finally have some time to dive in. It’s been a while since my last OSC edits, and the faders seem to work differently from the earlier OSC implementation.
/mix/in/0/0/faderlin works beautifully from TouchOSC to TMFX.
However, TMFX sends out /mix/in/0/0/fader (FLOAT -300 to 6) values instead of faderlin 0 to 1.
I’m probably overlooking something simple, but I’d appreciate your help with getting the fader curve working correctly.
(/fader works both ways when values are set to -65 and 6, but the movement curve is different from the TMFX fader, so I’d like to use /faderlin both ways.)
Thanks for any help!
Thank you so much for adding GlobalOSC!
I finally have some time to dive in. It’s been a while since my last OSC edits, and the faders seem to work differently from the earlier OSC implementation.
/mix/in/0/0/faderlin works beautifully from TouchOSC to TMFX.
However, TMFX sends out /mix/in/0/0/fader (FLOAT -300 to 6) values instead of faderlin 0 to 1.I’m probably overlooking something simple, but I’d appreciate your help with getting the fader curve working correctly.
(/fader works both ways when values are set to -65 and 6, but the movement curve is different from the TMFX fader, so I’d like to use /faderlin both ways.)Thanks for any help!
You must select "Send faders in linear scale" in the Global OSC Detailed Settings menu and receive on /mix/in/0/0/faderlin. I had the same confusion!
You must select "Send faders in linear scale" in the Global OSC Detailed Settings menu and receive on /mix/in/0/0/faderlin. I had the same confusion!
Ah, perfect, that was it! I was in that menu multiple times, but somehow still managed to overlook that setting.
Thank you!
RME User Forum → TotalMix FX → Global OSC – TotalMix FX Alpha available
Powered by PunBB, supported by Informer Technologies, Inc.