This is awesome.

Thanks a million! I can't wait to try it out once I’m home.

127.0.0.1 is a local loopback address. Not a useable addressable ip address.

How should this work, as 127.0.0.1 is an ipv4 address?
You cannot send/receive between ipv6/ipv4 addresses (at least without (complicated) v6tov4 translation stuff).
Thats the reason for your issue. Fix it in your router/network settings.
So, its rather a network misconfiguration on your side than a Totalmix(or OSC) issue in general.
Tip: Use network priority order in macOS‘ network settings…

...and exactly this works here:
Sending from 3rd party sw to TM's 127.0.0.1:PortX
Receiving from TM's Remote Controller Address 127.0.0.1:PortY on 3rd party sw.

Just did a quick query test. Looks quite solid and looking forward to building some fun interfaces on top.

Hello! i know this thread is not a tutorial, but i struggle to control channels related stuff.
No problem for exemple to control /controlroom/dim
but for channels and mix i think i don't understand the syntax well.
If someone could be kind enough to provide the syntax, for exemple, to juste mute input 1 or output 1/2, that would be awesome!
thanks!

The protocol is largely symmetrical. So you can simply analyse receive data from TotalMix. But:

/input/11/mute (1.0f) mutes input 11 (Mic 12 on UFXIII)
/input/11/mute (0.0f) to turn off mute
/mix/in/11/0/fader (-37.0f) means node input 11 (Mic 12 on UFXIII) and submix 0 (output channel AN1/2) set to -37dB.

Sometimes I struggle myself with turned-off Global OSC after starting an older version of TotalMix between...

Sounds like a fix to the infuriating channel counting problems that made it a pain to control anything with OSC. Very Good

Maybe I was quite unclear.
From my personal point of view...
- The /status/* messages are sent almost immediately (at least ~1 sec max - according the docs) after/or if sth changes in TM. And thats absolutely ok(!)
- Only when nothing happens, the information inside the ~every 12-15 secs bundle seems redundant/useless
- I would even say, it is sufficient if TM would only send a new /status/* message if sth related changes inside the /status/* path (like /status/dsp, /status/connection, etc) as the client knows the initial state (by sending a /sendall or if configured in the TM settings on startup...)

In my opinion and use case its irrelevant if its enabled or not by default, as long as I can configure it at all.

I think with "heartbeat" you mean that a client has the possibility to determine/know if a certain controller on the host's (=TM) side is currently active/alive/listening, right? Afaik, "sending pings via OSC" is a quite legacy technique (although still used by several professional studio consoles).

The actual common way is described in the osc 1.1 spec (from 2009). Which, although it has never been officiallly released, its used by de facto more modern standard DAWs/Apps like TouchOSC, Logic, Ableton, Reaper, etc.. Basically, the principle is to serve an DNS-SD _osc._udp entry as long as the hosts endpoint (or TMs controller) is alive. It would make sense if it could contain the active Controller Number 1-4, the Unit name (incl its unique serial), etc. in the TXT records. See: https://ccrma.stanford.edu/groups/osc/f … SC-1.1.pdf
To mention, TM seems to implement this already basically. But the dns-sd entry is only active as long as the Mixer Settings Dialog is opened (if you hit OK, the entry disappears - which is not according the common DNS-SD principle/philosophy at all). 

PS: I made a workaround script/LaunchAgent which polls for open UDP Ports towards a TM process on mac and if found, it manages this all... But, of course it would be much more elegant if this would be handled by the host (=TM) at all..
However, let me know if you're interested. Then I'll open a github repo...

Fixed in Alpha 4, link see first post. Also added: status and time messages for DURec.

A little thing I've just noticed regarding Mackie Control support.

Using record arm buttons on MCU (SSL Nucleus) we can select an output bus to send signals to. I have UFX 3 MADI connected to ADI 648. I have 32 analog channels connected in either 1x or 2x sample rates.

When I use this in 1x sample rate I can select any output bus all the way up to my last 8 channels (MADI 48-56) (4 stereo pairs). If I do the same thing when in 2x sample rate I can't select the last 4 output pairs at all (MADI 25-32) from Mackie control. If I press one of those when in 2x the channel selected is always MADI 23/24. If I select with a mouse the correct select then lights up on the control surface also.

I tried this on TMFX 1.99, 2.0 and 2.1 Alpha. The behaviour is the same for all.

Kind regards

Fixed in the just released v 2.01. Please try.

Yes I saw this earlier Mathias. You guys are amazing! Thank you very much. I’ll install tomorrow….

Any chance of fixing TM problem with refresh rate ?

When TM window is active if you have black background it flickers all the time when you move the mouse in TM on OLED screen. It's really annoying watching it messing with my eyes.

First post has been updated with Alpha 5. It includes all the fixes and improvements of current release 2.01, but also improves on GlobalOSC. Please use the updated protocol document and note the change of the input names - see bottom on page 1:

- sendchan bus names changed to (fully written out) input, playback, output       
- added loadpreset, sendsettings