Re: 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
Matthias Carstens
RME
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! ![]()
As cherry on top of the GlobalOSC implementation: here is a 'proof-of-concept' Stream Deck plugin for anyone having a Stream Deck controller. Download:
https://www.rme-audio.de/downloads/tmfx … in_011.zip
To avoid colisions with the normal remote change ports to 7008/9008 as shown in this screenshot.
Have fun!
Awesome!!
Please excuse my ignorance.... but
If using Control Pilot for Controllers 1 & 2 (7001, 7002 & 9001, 9002)... Do I assign to Controller 3 and assign (7008 & 9008) ??
Of course you can use any of the 4 controller instances, just enter the data there and activate "in use".
Hi MC
Some wishful thinking but here goes. Is there any chance to also transmit the (0 based) channel number as a value not just in the address?
For example:
/output/28/name ADI 7/8 (string)
becomes:
/output/28/num 28 (integer)
/output/28/name ADI 7/8 (string)
Use case: when an OSC receiver is listening with OSC wildcards, and a handler function can only receive the value and data type, not the address that triggered the (wildcard) listener.
wildcards are supported by the OSC 1.0 standard:
'?' in the OSC Address Pattern matches any single character
'*' in the OSC Address Pattern matches any sequence of zero or more characters
A string of characters in square brackets (e.g., "[string]") in the OSC Address Pattern matches any character in the string. Inside square brackets, the minus sign (-) and exclamation point (!) have special meanings:
two characters separated by a minus sign indicate the range of characters between the given two in ASCII collating sequence. (A minus sign at the end of the string has no special meaning.)
An exclamation point at the beginning of a bracketed string negates the sense of the list, meaning that the list matches any character not in the list. (An exclamation point anywhere besides the first character after the open bracket has no special meaning.)
A comma-separated list of strings enclosed in curly braces (e.g., "{foo,bar}") in the OSC Address Pattern matches any of the strings in the list.
Any other character in an OSC Address Pattern can match only the same character.
-- [http://opensoundcontrol.org/]
I'm late to the party, but I just wanted to say this is incredibly useful! Last night, I implemented a very crude software bridge between TotalMix FX and my Roto-Control in Max and it worked perfectly. I hope to be able to use my M-1620 Pro with a Fireface interface to act as a standalone digital mixer when my laptop is detached, and for that I'll want to be able to target specific submixes as effects sends--now I just need to find a MIDI hardware bridge or a control surface that supports OSC.
Please continue here: https://forum.rme-audio.de/viewtopic.php?id=43485
TM FX 2.1 has left Alpha state!
Please continue here: https://forum.rme-audio.de/viewtopic.php?id=43485
TM FX 2.1 has left Alpha state!
The biggest update in 2.1 is the support for Global OSC, which already made waves throughout the community and third parties. We even went ahead and made a Global OSC based plugin for the popular Elgato Stream Deck, as proof-of-concept. Details and download here: https://forum.rme-audio.de/viewtopic.ph … 75#p252575
Hello dear Matthias Carstens,
I have a request for this. Is it possible to place the two topics 'Global OSC' and 'RME Stream Deck Plugin' separately as a standalone sticky here in the RME Forum? This would significantly improve clarity.
Personally, I am very interested in an official TotalMix FX plugin from RME for the elgato Stream Deck Controllers. I have already written a first comment on this. I am sure that the RME team can offer a mature Stream Deck plugin for the TotalMix FX. Please continue.
RME User Forum → TotalMix FX → Global OSC – TotalMix FX Alpha available
Powered by PunBB, supported by Informer Technologies, Inc.