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.

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

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.

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

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”
My Gear: Bontempi Magic light Keyboard

6

Re: Global OSC controller

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

Regards
Matthias Carstens
RME

Re: Global OSC controller

Sure - absolutely right. should improve my English

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

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

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

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”
My Gear: Bontempi Magic light Keyboard

10 (edited by bsfreq 2023-08-12 16:44:43)

Re: Global OSC controller

Please, any news on Global OSC support for TMFX?

I just spent more than 100 hours, again, during the last couple of weeks, trying to rebuild my controller layout for the TMFX.
It really is a pain in the ass without the global OSC support and direct addresses to all faders in all submixes.

No matter what I do and which software I use, it’s always a compromise with the current limitations of TMFX’s OSC implementation.


Now that Lemur is currently not available, I’ve switched to using TouchOSC on my iPads. It works really reliably and fast for linking faders between submixes, but for my use, it right away takes three of the four available OSC controller connections in TMFX for just one single iPad, and I would need at least four iPads + a couple of hardware controllers.
With global, direct OSC addresses I could link all the necessary faders in needed submixes with just a single OSC connection to TMFX.

I’m able to link two iPads to TMFX using direct connections between the iPads in TouchOSC. However adding more than two introduces problems, and I run out of available connections in both TouchOSC and TMFX. (TMFX is not the only app I need to be able to control).


I also had to get rid of my motor fader controller as it was using midi to OSC translation via OSCulator, and I ran out of available OSC ports in TMFX. 

(For some reason OSCulator introduces considerable amount of latency even with simple fader linkings, and is unable to keep the fader movements smooth even when running it locally on the same Mac as TMFX. (This hasn’t been the case always, but ever since I updated to Bug Sur, which was a good while ago, I haven’t been able to make OSCulator run as smoothly. An iPad running TouchOSC via wifi runs much smoother for some reason.)

Also, I would like to request a non toggle type OSC command for the Trim-mode, so that it can be forced on regardless of the current state. I remember someone else was asking for this earlier, and perhaps I did as well.
There's a midi command for this, so currently I’m using midi alongside OSC, but midi and OSC are not transmitted at the same speed, as midi takes a different route of course.


I see OSC related requests and inquiries pop up here pretty much weekly.
Some are related to global OSC and most, if not all, would at least be solvable with global OSC. So the need is there.

I’m really frustrated by the amount of time I’ve had to spend on building something that always ends up being skecthy and unreliable, and could be done reliably in a day or two with global OSC. Something RME talked about adding more than 10 years ago. This is really holding me back, as I’ve planned everything in my setup on top of RME gear and TMFX.

So please, please add global OSC soon.

I would like to express my sincere gratitude for any efforts you can contribute towards making this happen.

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic

Re: Global OSC controller

@bsfreq
roll

Hi my (old) friend ;-),

Please do not misunderstand my post. I really like your inspirations (like the OSCulator thing f.ex).
But it seems you mix a lot of weird stuff.

If you want to get tipps for your environment, maybe you should try to provide a network-diagram or sth for your environment and needs. So it would be more clear...

WTF, why do you need 3 different connections for each of your 4 iPads??
You know about the OSC Handling in TouchOSC?
I mean, you can assign each single OSC Message from the Totalmix-TouchOSC Layout on every device. And map it to the connection it should be used for.
ATM it seems that you use at minimum 4x3=12 connections at the same time, which logically spam your Mac (and network)...

In my case OSCulator has no latency lags. If i arrange the whole (yes, OSCulator is complicated) setup right.
You tell, that you just moved to BigSur. In 2023? hey, BS was released in 2020. Maybe your Mac lacks due to Hardware Limitations? Or why not ventura?

Did you try to analyze what is going on in your network? In wireshark you can enable the osc_udp Protocol and filter all the stuff. So you can see what is going in detail on there. Sure, its not a 5 Minute thing. But your environment seems to be really special, which efforts of special knowledge to identify the lags.

Once again: Global OSC - Buzzword.
No one here ever described some technical details, how it could be realized in detail to fit all the needs you expect.

And think about all the side effects which surely come up. Not mentioning all the platforms, OSX, iOS, Win, etc... 

- You want to use your Host, 4 iPads and some other controllers...
- I want to use 1 Host, 3 TMFX-Remote sessions, 2 iPads. And if the Host is offline, 3 other total independant MIDI Devices connected via RTP-MIDI on a Raspberry, which is wired via HW Midi to the RME-Unit should also work...


regards, maggie

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

12 (edited by bsfreq 2023-08-14 15:26:38)

Re: Global OSC controller

Ahh, maggie, long time nosy. wink (pun intended, with all the love)

maggie33 wrote:

WTF, why do you need 3 different connections for each of your 4 iPads??
You know about the OSC Handling in TouchOSC? 
I mean, you can assign each single OSC Message from the Totalmix-TouchOSC Layout on every device. And map it to the connection it should be used for.

I do know how the OSC handling works. But currently, as we don’t have global OSC and thus don’t get direct, submix independent feedback (feedback simultaneously from multiple submixes), and as some aspects of my controller layout need to be ’static’ (locked to specific submixes), I’m forced to make it this way.

Let’s just take this one part of my layout as an example. I have faders linked between 6 submixes (TouchsOSC sends out submix switch commands with the fader positions etc.), but solo states need to sync between only 3 of those submixes. I get the solo states from one TMFX window to TouchOSC. If I change the  state of a solo button, either from within TMFX or TouchOSC, my TouchOSC mappings then quickly jump through those 3 submixes and change the states in all of them.

Without locking one TMFX window / OSC controller for this, I’d have weird / wrong things happen if I (or any other player) simultaneously adjust a fader with similar kind of submix-jumping actions (or even without) in any of those submixes. Wrong solo states in wrong submixes, wrong fader positions in submixes etc.
I understand this might be doable with a single iPad and a whole lot of scripting. (I mean, I already had OSCulator layout and mappings change according to currently selected submix) However if I want to have multiple iPads and the option to adjust more than one parameter at a time from different places while also keeping the correct links between submixes, I’d need unique addresses to all faders in all submixes, otherwise things will overlap and collide.

I don’t get why this concept of direct addresses for all the faders and buttons in every submix is so hard to grasp.

maggie33 wrote:


In my case OSCulator has no latency lags. If i arrange the whole (yes, OSCulator is complicated) setup right.
You tell, that you just moved to BigSur. In 2023? hey, BS was released in 2020. Maybe your Mac lacks due to Hardware Limitations? Or why not ventura?

I didn't say I just moved to Big Sur, but a good while ago. More than a year ago, don't remember exactly. But I’ve read of more problems with Ventura than with Big Sur. My audio works perfectly with Big Sur, so no reason to update. I’m quite sure it will not fix my OSCulator latency problems..

I'm running a 15" Macbook Pro from 2019, with 2,3Ghz 8-core Intel, 32bg of ram. Definately not the newest Mac, but should be enough for what I'm trying to do.

maggie33 wrote:

Did you try to analyze what is going on in your network? In wireshark you can enable the osc_udp Protocol and filter all the stuff. So you can see what is going in detail on there. Sure, its not a 5 Minute thing. But your environment seems to be really special, which efforts of special knowledge to identify the lags.

I didn’t. Perhaps I should do that at some point. But I tested with a simple one fader link and closed TouchOSC and other OSC-related apps. Also tried adjusting the tracking speed in OSCulator settings, but that didn’t help. I do have Ableton Live sending out all it’s clips state data and beats and bars via OSC. However, even that m4L-device wasn’t running the last time I tested my OSCulator mappings.

maggie33 wrote:

Once again: Global OSC - Buzzword. 
No one here ever described some technical details, how it could be realized in detail to fit all the needs you expect.

How is it a buzzword, if the functionality without it is not there? Can you perhaps think of a better word for it then? Or can you please explain how to adjust and get feedback from multiple submixes simultaneously with the current implementation when the fader and button addresses are not unique to each submix?

And what technical details do you think is needed for this request:

-Unique addresses for faders and buttons in each submix, so that we can adjust and get feedback from all submixes without switching between submixes and the current OSC layout.

maggie33 wrote:

And think about all the side effects which surely come up. Not mentioning all the platforms, OSX, iOS, Win, etc... 

What side effects? Surely changing the OSC addresses would mess with the current mappings, but I don’t see that as a problem. Not too much work to change them accordingly. I think it might be even possible to keep the current OSC mappings and simply add the direct addresses.

And by mentioning the platforms do you mean that it would work on all those platforms? Yes, would be good.

Best regards,

bsfreq

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic

Re: Global OSC controller

Technical details? Just grabbed one single sentence of your complains:

-Unique addresses for faders and buttons in each submix, so that we can adjust and get feedback from all submixes without switching between submixes and the current OSC layout.

Unique addresses faders and buttons for each submix...
clear.

Did i get it right? That means you want this?

For example - just to be able to do a basic network-relative calculation:

Lets imagine its a UFX III (dont know exactly atm) i assume - maybe 128 Channels per row?
For Input, Playback, Output = 128 x 3 = 384 "Channels". (each Row)

so that we can adjust and get feedback from all submixes without switching between submixes

As i understood, you want feedback from 128 "unique" Submixes. Also, if you adjust just one param?
So our params list raises: 384 x 128 = 49152
Each "Channel" consists of - what exactly - in your mind?
I assume all eq, lc, dynamic, gain, autolevel and whatever params should also be included, too?
So our params list raises even, more.
Have fun, with 4 or even more controllers...

Maybe, i am totally wrong - i do not know how RME realizes the logic behind this.
Correct me, please - i always love to learn.

But, in my point of view - it is NOT just a dumb mapping of each unique object to a unique osc address. I can imagine, there will be side effects and stability problems otherwise. So from the point of a developer:
you have to establish a detailed flow first, when, which data makes sense to transfer and on which received data you have to act in your application.

PS: "because i have read ventura makes problems" - If i would beleive all the critical posts before doing an OS upgrade - What about backups? Anyway - i would be on Lion and Windows XP till now ;-)

Kind regards, maggie

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

Re: Global OSC controller

maggie33 wrote:

As i understood, you want feedback from 128 "unique" Submixes. Also, if you adjust just one param?
So our params list raises: 384 x 128 = 49152
Each "Channel" consists of - what exactly - in your mind?
I assume all eq, lc, dynamic, gain, autolevel and whatever params should also be included, too?

So our params list raises even, more.
Have fun, with 4 or even more controllers...

Personally I’d be fine without eq, dynamic, gain etc. options on global OSC. However, others might need those so I wouldn’t rule them out either..

As I’ve said before, I don’t know how much resources is needed for this, and this is exactly why I suggested on an earlier thread that perhaps there could an option to enable the global OSC / direct addresses option per submix, or even have a complete OSC address table to enable only the specific addresses (specific fader in a specific submix etc.) we need, to save CPU resources and keep the flow of data to a minimum.

I am by no means a programmer, never said I was, never going to be. So I really don’t know how any of the code works and how much work there is to implement something like this.

At the same time it was the good people of RME that said they would add this feature, and it would definitely bring a whole new set of possibilities to controlling our RME interfaces.
For me, it would mean the world of difference, and finally allow me to do all the things I have imagined and planned of doing with my RME gear.

It’s not like I’m suggesting something totally unreasonable here. RME said that it would come, so I feel confident it’s doable.

I’ve tried building my controller layouts over and over again, and I always hit the same limitations at some point. I get frustrated and come back here to remind RME of the importance and possibilities of this missing and missed feature.

Hopefully I’ve found the right balance between nagging about the lack of global OSC and praise of RME gear quality and current features.

maggie33 wrote:

PS: "because i have read ventura makes problems" - If i would beleive all the critical posts before doing an OS upgrade - What about backups? Anyway - i would be on Lion and Windows XP till now ;-)
Kind regards, maggie

For me, it’s ”if it works, don’t upgrade for the sake of having the newest”.
I only upgrade when it’s necessary for some new hardware or some major DAW overhaul or a feature I really need. I could of course install on a separate drive or partition, but I have a lot of paid software and licenses that I already use on two or more computers. Separate installations usually mean that I have to transfer licenses and software installation is always another pain in the ass when installing new OS’s. I try to avoid that when not necessary.

Best,

bsfreq

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic

Re: Global OSC controller

thanks, bsfreq

i saw a few days ago, that there is a new OSCultaor version inside their forum. Maybe it helps you with the lags?

regards,
maggie

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

Re: Global OSC controller

maggie33 wrote:

i saw a few days ago, that there is a new OSCultaor version inside their forum. Maybe it helps you with the lags?

Cool! Thanks for the tip!

Indeed, it was behind some bug related thread, but I found it here in case someone else is interested: https://osculator.net/forum/forum/suppo … #post12043

Fireface UFX+ | Fireface UFX | Babyface Pro | 12Mic

17 (edited by gmatters 2023-09-02 14:20:24)

Re: Global OSC controller

+1 for a direct addressing system that allows anything to be set predictably with 100% predictability without having to manage UI navigation. The open namespace of OSC is often employed to allow a layered, logical addressing. e.g.

/submix/0/input/3/volume 0.5 would set the volume of input 3 being sent to submix 0 to 0.5

/output/6/reverbReturn 1.0 should make the little green fx return fader jump up with 100% predictability

/input/0/fx/eq/enabled 1.0 would turn the eq on for the first input channel, whether it was previously on or not


TotalMixFX is quite an accomplishment, with a level of complexity appropriate to the flexibility of the hardware. Perhaps the OSC implementation makes sense as an OSC-ification of the Mackie Control Protocol, or an extension of how one might use ARC to navigate the interface while watching it. But trying to do something simple like "set a specific thing to a specific value" requires dealing with paging and banks and focus and other UI-specific concepts that should be irrelevant.