Global OSC – TotalMix FX Alpha available (outdated thread) (Page 2 of 2)

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 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

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

Sorry, didn't get an email notification from the forum, so I didn't see your replies until now.

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.

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?

Awesome, thanks for the colors!

Awesome, Alpha 8 seems to have fixed both my issues, very nice!

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!

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) ??

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:
  

  1. 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.)

  2. 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/]

Please continue here: https://forum.rme-audio.de/viewtopic.php?id=43485

TM FX 2.1 has left Alpha state!

I think, its not something TotalMix itself needs to change for. You can get this today with a some lines in shell using some code and libs which are solid an lightweight (like liblo f. ex)

Well, as I personally play a lot with OSC, too, I made osctool (open source OSC test/relay tool) for my own testing and dev stuff. Which grew a little over time..
Just cleaned my repo up and pushed it to github (in case it might be useful for you - feel free - prebuilt static linked bins are also there).

https://github.com/huddx01/osctools

So, a small pipeline using osctool and jq does what you need... It listens for TotalMix's OSC output, and for every /input/N/name or /output/N/name it sees, it forwards that message unchanged and additionally sends a companion /input/N/num (or /output/N/num, same for playback) message with the channel index as an integer.
So your wildcard handler might be happy as it gets the number as a value, not just embedded in the address...

osctool -l 9001 -m -j -q --no-discover --no-rc | \
  jq --unbuffered -r '
    select(.path | test("^/(input|output|playback)/[0-9]+/name$")) |
    (.path | capture("^/(?<kind>input|output)/(?<n>[0-9]+)/name$")) as $c |
    "send \(.path) s \(.args[0] | @json)",
    "send /\($c.kind)/\($c.n)/num i \($c.n)"
  ' | \
  osctool -l none -t <your-receiver-ip>:<port> --no-rc --no-discover -f -

Copy/paste the above into terminal and adjust -l 9001 to whatever port TotalMix's OSC output is set to  and -t to wherever your actual OSC-consumig app listens. Requires jq 1.7+ (for --unbuffered. without it, output gets stuck in a buffer and never arrives).

Just made a quick live test against TotalMix. Renaming a channel produces exactly this on stdout:
  /output/3/name s "an 4"
  /output/3/num i 3

Alternatively, if your OSC library gives you the matched address in the wildcard callback (most do), parsing the channel number out of the path directly in your handler avoids needing this pipeline at all. This would be a more elegant solution for this...

Dear Matthias Carstens,

is there any news about RME TotalMix Stream-Deck plugin? I really hope that RME will soon be able to offer a mature stream deck plugin for the TotalMix. Possibly even with ready-made profiles for the respective stream deck models. That would look very good on a renowned company like RME. Furthermore, I had asked if it is possible to mark this post separately as 'sticky', so that this topic will not get lost in the middle of nowhere and hardly anyone will take notice of it. That would be a great pity.

For some reason it starts to happening again. When I open TM refresh rate drops and background (if it's black or gray) flickers.

I get a 404 error when I try to download the win alpha 8 zip
What am I doing wrong?