• Registered: 2023-05-01
  • Posts: 3

Topic: Global OSC controller

Hi,

I understand that the OSC interface of Totalmix is somewhat good enough to create alternative interactive interfaces, but it clearly is not good enough to make complete automation.

First, the commands are badly suited for automated control:

- the fact you need to change from track to track for some features (eq, for instance) means you may have to send 190 time a /2/track+ command before you can change a value. This is, to say the least, not very practical.

- the fact that you cannot set on/off values but only toggle them force you to send a command, get the answer and then resend the command if needed. Again not very practical.

- the fact that, for page 1 commands, you access the sliders by their respective number on the displayed screen, and not by their, say, MADI number makes it quite difficult, as, if the user changes the screen layout the automation cease to work correctly.

- switching from stereo to mono changes the quantity of tracks, which means you never get a secure sense of how far is one track from another.

In general, the consequence of the above remarks is that, when you implement an automated control based on OSC, you are forced to listen to the answers provided by the OSC interface at each stage. This seems normal (why would you send answers if they were not to be listened ?) but in reality those answers are sent in multiple UDP packets, and with a small delay.

This means you can control features but only in a slow manner.

If you have to change, say, 10 volumes, you have to send about 25 commands (this is an approximation, as it essentially depends of the currently selected track, and if the tracks you want to set are consecutive or not). Something like:

/2/busInput 1.0   (recieving 6 bundle packets as answer)
/2/track- 1.0     (recieving 6 bundle packets as answer)
/2/track- 1.0     (recieving 6 bundle packets as answer)
/2/track- 1.0     (recieving 6 bundle packets as answer)
/2/track- 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.0     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.1     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.2     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.3     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.4     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.5     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.6     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.7     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.8     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 0.9     (receiving 1 bundle packet as answer)
/2/track+ 1.0     (recieving 6 bundle packets as answer)
/2/volume 1.0     (receiving 1 bundle packet as answer)

So you have to recieve not less than a hundred answer packets.

It will work, but this will take easily 2-3 seconds to go, not because the software or network is slow, but mostly because the commands are designed so that at each step, you have to wait for the answers which takes each about 1/100th of a second to get back.

Comparatively, you can do this:

/1/busInput 1.0   (discarding the answers)
/1/volume1  0.0   (discarding the answers)
/1/volume2  0.1   (discarding the answers)
/1/volume3  0.2   (discarding the answers)
/1/volume4  0.3   (discarding the answers)
/1/volume5  0.4   (discarding the answers)
/1/volume6  0.5   (discarding the answers)
/1/volume7  0.6   (discarding the answers)
/1/volume8  0.7   (discarding the answers)
/1/volume9  0.8   (discarding the answers)
/1/volume10 0.9   (discarding the answers)
/1/volume11 1.0   (discarding the answers)

in less than a tenth of second (which should be fast enough in most circumstances), but it doesn't work for all settings, nor for a group of more than 24 consecutive slides.

Having a bit more cartesian OSC control would solve all those issues: something like

/<bus-name>/<madi-id>/<feature> <value>

for instance
/input/10/volume 0.5
or
/output/152/eqEnable 1.0 (which doesn't toggle the value, but sets the value to 1).

and if you want to get the values, instead of setting them, something like

/input/10/getall -1.0    (for, say, all settings of the input track 10)

possibly you could even use the value -1.0 to get a specific value, since negative values are not used anywhere

/input/10/volume -1.0    (to get the volume of track 10)

This could be implemented and yet keeping the old OSC commands (since they don't overlap).

Reading the posts of this forum, it seems that people ask for it since about 10 years, so it apparently is difficult to provide this feature for some reasons (that I personally don't understand, but it's like that).


OK, let's admit RME isn't going to do it.

Yet apparently, the Totalmix remote succeed in controling in a fast manner the Totalmix application.

I initially thought it was using OSC but some invetigations shows it's apparently not.

This may explain, by the way, why it is faster :-)

So the question is:

Is there a documentation of the messages exchanged between Totalmix remotes and Totalmix ?

This would allow to build an application that on one end would provide a "rational" OSC interface and on the other would control the Totalmix in a fast and understandable manner, allowing people who want to make automation to do so.

  • bsfreq
  • AES/EBU artist
  • Offline
  • Registered: 2011-03-02
  • Posts: 188

Re: Global OSC controller

bawumbu wrote:

OK, let's admit RME isn't going to do it.

Global OSC is said to be added, so I assume it's still just a matter of when.

Hopefully sooner than later, as I'm also hitting a brick wall here with the limitations of the current OSC implementation.

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic
  • Registered: 2023-05-01
  • Posts: 3

Re: Global OSC controller

Thanks for the reply,

yes, I read one of your preceding post, about a year ago, where a staff member of RME (do I undestood it well) "promised" to add a global OSC support as soon as they'll find time (!).

MC wrote:

    Nevertheless we hvae plans to do it, but in the last years several other topics had higher priority, and since two years we (like anyone else) had to devote all our time to be able to continue manufacturing existing products. The current crisis takes a high toll, and that will continue for some time. So don't expect any change in OSC within the next months


This was about a year ago and still not there, so yes... it indeed wasn't to be expected in the coming monthes :-))

My problem is that I cannot really wait: this is part of a studio instrument I have to deliver by the end of the month. The actual OSC system, though usable with extensive programming, causes delays (because essentially you are forced to read answers of every calls, and occasionnaly to issue a lot of commands for a single setting if the tracks aren't contiguous).

This is quite sad, as the hardware is absolutely gorgeous.

  • bsfreq
  • AES/EBU artist
  • Offline
  • Registered: 2011-03-02
  • Posts: 188

Re: Global OSC controller

bawumbu wrote:

This is quite sad, as the hardware is absolutely gorgeous.

I totally agree.

Hopefully the good people of RME can see the value in adding the global OSC control. I believe it just might bring a whole new user group to RME devices too. For the time being, there’s really no real substitute for TMFX, and it’s so close to perfection. I hope they can still raise the bar to this final level of awesome.

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 39

Re: Global OSC controller

bsfreq, i reference to your post from the 1.81 beta thread - sure. this thread is better for discuss the "Global OSC" Buzzword:
https://forum.rme-audio.de/viewtopic.ph … 54#p201854

I’m not too much into scripting, and I try not to spend another decade diving into new languages instead of spending that time making music. Absolute OSC control for TMFX would get me where I want, quickly and easily.

-> it seems that you have a special and customized environment. OK.
-> You use Oscillator - hello?? Oscullator is a very powerful tool. But you have all the possibilities, you want! Of course you have to dive into the matter if you want a perfect environment which suits your needs.
-> but have no time to spend a decade... it took about 3-4 evenings for me to understand the concept behind osculator.

However, I’ve maxed out TMFX windows and controllers, and for syncing my controllers I have locked some TMFX windows to some submixes and controllers (+MIDI-OSC controller sync)

-> fine. And what is the problem now?

Also, I need feedback from TMFX (have TMFX send the current values to my controllers when powering on my system) With global OSC I would get all the values without having to build some hideous submix-jumping script that may or may not work.

-> When powering up the system = starting the mac/pc? and TMFX comes up? Sorry - how should this be realized.. There are dozens of pssibilities which can lead to errors. In my case: When i power up the mac, the docking station (where all my controllers and the interface is connected to) comes up after a few seconds... it seems to depend which apps i had opened before shutting down.
-> maybe i misunderstood - but this has nothing to do with OSC in general (or "Global OSC")
-> you can trigger tmfx by your controllers/scripts/etc as they are ready to send the current values. there are several posibillities. That makes the most logical sense in my opinion.
-> although - if you want a setting option in tmfx - where you can define a delay and push all the states if TM gets loaded - why do you not suggest this enhancment preciise towards RME/in the forums?

Trust me, I have fiddled. big_smile  And I understand that if your setup works for you, other people’s need are not that relevant. But that’s exactly why we need global OSC. It would really work for any situation and all the needs.

-> i do not think you have really fiddled and tried out all the options you have today
-> if other peoples needs would not be relevant for me - hey, i would not spent so much time im answering and trying to understand your needs.
-> But Thank You! You inspired me what possibilities exist and to think about what would be an enhancement in my environment. And to dive deeper into this - and i learned a lot the past days :-)


Simply having more groups is unfortunately not enough for me, as groups in TMFX don’t allow opposite states of buttons which I need in my use case. Global OSC would.

OK - as i rememder, you wrote that you want independant fader groups.

- 6 completly idependant fader groups.
via osculator. routed vise versa between logic and totalmix... ok - there seems to be a small lag if you move one slider in tmfx - but it was a quick'n dirty routing - tmfx slider sends and receives its own value, and additionally receives the grouped value.
its a issue in my script...

Look at my video:
(Note: seems that it will be deleted after 6 days, where i uploaded it)

https://filebin.net/jwxb1cum9zb2rhmt/OS … talmix.mov


https://filebin.net/jwxb1cum9zb2rhmt/OSC_Fadergroups_Logic-Totalmix.mov

So, my final thoughts:
It seems that there are some people in this forum, crying for for the "Global OSC Control" Buzzword.
But i could not find any detaild description with preceise facts and bulletpoints, what you expact and maybe ideas how it could be realized.
No precise findings or or something like a cheklist what could be improved in the "Global OSC" Fanbase here...

AND: NO - I AM NOT CONVINCED IN ANY WAY WITH RME.

I am just a Hobby Musician with a little knowledge about sw development due to my job.

“Do It For Her”

6 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 23,782

Re: Global OSC controller

It seems 'convinced' should have been 'connected' or 'affiliated'.

Regards
Matthias Carstens
RME

MC's Website

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 39

Re: Global OSC controller

Sure - absolutely right. should improve my English

“Do It For Her”

8 Reply by bsfreq (edited by bsfreq 2023-05-25 13:44:38)

  • bsfreq
  • AES/EBU artist
  • Offline
  • Registered: 2011-03-02
  • Posts: 188

Re: Global OSC controller

maggie33 wrote:


-> You use Oscillator - hello?? Oscullator is a very powerful tool. But you have all the possibilities, you want! Of course you have to dive into the matter if you want a perfect environment which suits your needs. 
-> but have no time to spend a decade... it took about 3-4 evenings for me to understand the concept behind osculator.

I understand OSCulator, and I'm using it with multiple controllers (syncing OSC+MIDI too). I have multiple OSCulator windows linked and partly synced to different submixes in TMFX. I still don’t quite understand why you assume I don’t know at all how OSCulator works and what is possible already.

maggie33 wrote:

However, I’ve maxed out TMFX windows and controllers, and for syncing my controllers I have locked some TMFX windows to some submixes and controllers (+MIDI-OSC controller sync)
-> fine. And what is the problem now?

Maxed out, meaning that without global OSC, more TMFX windows and controller inputs to TMFX would be needed. However, with Global OSC the current number of TMFX windows and controllers would be more than plenty, I could actually get rid of some of those and simplify my setup a lot! As I said, the problem is syncing between different submixes (and no, not total sync that you can do with mirroring submixes) and the lack of direct addresses to all faders and buttons on all submixes. (to make syncing between them possible and simple, without switching between submixes.) BTW, your example video is showing syncing faders on a single submix (+Logic Pro). This is very simple indeed, and I have no problems with that whatsoever. 

maggie33 wrote:

-> When powering up the system = starting the mac/pc? and TMFX comes up? Sorry - how should this be realized.. There are dozens of pssibilities which can lead to errors. In my case: When i power up the mac, the docking station (where all my controllers and the interface is connected to) comes up after a few seconds... it seems to depend which apps i had opened before shutting down.
-> maybe i misunderstood - but this has nothing to do with OSC in general (or "Global OSC")

When powering up the system = When turning on my harware controllers + controller software and TMFX. Currently I do that by turning on my controllers, then disabling OSC control from TMFX settings, then turning it back on. Fader positions etc. are being sent out via OSC. Currently only the levels/positions of the visible submixes / currently selected set of faders are being sent. With global OSC I could also get fader positions to my controllers from faders not currently visible and selected in TMFX. I suggested on another related thread that if it raises the CPU usage of TMFX too much, perhaps we could have an option to enable OSC feedback per submix, or even have a table to enable only the addresses we need.

maggie33 wrote:


-> although - if you want a setting option in tmfx - where you can define a delay and push all the states if TM gets loaded - why do you not suggest this enhancment preciise towards RME/in the forums?

I actually have suggested a mappable button / control command to send out all the values. It’s buried somewhere on these forums. I know these forums are read by the RME staff.

maggie33 wrote:

-> i do not think you have really fiddled and tried out all the options you have today

That’s a bold statement that I find a bit rude too. I mean, of course I could try to dance around TMFX playing an English flute or even a triangle, but that doesn’t add the features to the core of my setup (TMFX). The shortcomings of TMFX’s OSC have been pointed out here on multiple occasions, they’ve been agreed upon, and quite frankly I don’t understand why is it you seem to insist on not having a better / more complete OSC control solution.

maggie33 wrote:


-> if other peoples needs would not be relevant for me - hey, i would not spent so much time im answering and trying to understand your needs.
-> But Thank You! You inspired me what possibilities exist and to think about what would be an enhancement in my environment. And to dive deeper into this - and i learned a lot the past days :-)

That might just be my interpretation of your written word, hard to hear the nuances here. But to me you sound a bit attacky to my asking for this ”promised” and quite obviously needed feature. But learning's good so cheers to that!

maggie33 wrote:

Simply having more groups is unfortunately not enough for me, as groups in TMFX don’t allow opposite states of buttons which I need in my use case. Global OSC would.
OK - as i rememder, you wrote that you want independant fader groups.

I basically wrote that I need global OSC, and also that I would not care to explain my whole setup here, as it would take a whole lot of time and has limited benefit for others. Point again being that global OSC would cover all my needs (and those of many others).

We’ve had enough replies from RME to very least keep the hope of global OSC alive. I’d like to believe they would have had the courtesy to say otherwise by now, if it’s not going to happen at all..

maggie33 wrote:

- 6 completly idependant fader groups.
via osculator. routed vise versa between logic and totalmix... ok - there seems to be a small lag if you move one slider in tmfx - but it was a quick'n dirty routing - tmfx slider sends and receives its own value, and additionally receives the grouped value.
its a issue in my script...
Look at my video:


Indeed, there seems to be a del.. I mean lag. Also, you’re still simply controlling things on one submix. Not between multiple, having to swich between them to be able to sync the faders on multiple submixes.

maggie33 wrote:

So, my final thoughts:
It seems that there are some people in this forum, crying for for the "Global OSC Control" Buzzword.
But i could not find any detaild description with preceise facts and bulletpoints, what you expact and maybe ideas how it could be realized.
No precise findings or or something like a cheklist what could be improved in the "Global OSC" Fanbase here...

After this long of a wait, you'd be ”crying” too.
No precise checklist needed. I believe MC knows exactly what is asked and needed, as it’s been talked here a lot. The implementation is up to RME, afterall.
Only they know how TMFX works under the hood, and how this feature can be added.

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 39

Re: Global OSC controller

Hi bsfreq,

sorry, i was not intended to attack you or sth like that.
As far as i have the time to fully understand your details, i will answer her.

“Do It For Her”