shells-dw
commented
3 years ago Hey there. Glad that plugin could help you.
I found RME's OSC implementation quite... unique, let's say that. I'm sure you figured that out yourself during your own scripting. And, to be frank, I wrote that thing 10 months ago and despite some half-assed moving code around I haven't touched it since, so I'm not really in the topic anymore, apologies if I get something slightly wrong - but off the top of my head, without digging in my code, there were the following issues I had: I have a listener for the OSC responses (setting the inital mute/solo states with that, for example), however this is getting slower the more updates it needs to process if I recall correctly, at some point it's just a lot of text being sent by the box - made quite some efforts to get it more responsive (is probably why it works faster than it does for you), but at some point it's a waiting game. I guess I could read the volume information during initialization and then have add/substract input fields allowing you to change dB relative to it's initial value. Never really thought about that usage way, would need to look into that, doesn't sound too complex, but that is something I thought about most things I implemented (or failed to here ;-)). Despite that there is one issue I was just not getting around: how RME does the channel assignment in OSC (edit: which probably makes sense for their ARC box, which has just one channel, so you just go "one channel up or down" and don't address specific channels, at least I would think that is why they did it that way). If you have a stereo channel, say AN1/2, you have 1 channel that is controlled via OSC. One volume control. If you put that channel to mono, you got 2 channels. So far so good, so far so logical, however that means that on your, say, 8 channel interface you can have anything from 8 to 16 channels (so channel 3 might be AN5/6 or it might be AN3, or AN3/4 and the higher that goes the more possibilities are there) and, despite quite a number of hours, I was unable to figure out a way how to reliably know, assign and dynamically display and be able to interact with that so that it was useful from a usability point of view as well. Thinking about switching snapshots, you probably have 6 snapshots with 6 different channel strips, so... that was getting too complex for me and getting out of hand for a nice christmas break coding, especially, as there are no axis - so even having the real time info was not really having much use for me other than for a display, so I cancelled that approach then, was not worth it. I doubt a lot of people have a fixed channel strip every time but if you have to set up the StreamDeck buttons first, not sure how much benefit there really is then in the end. It's just not dynamic enough, or maybe I was just not getting the right idea how to make it dynamic.
So long story short: I would rather get the actual values when the deck is loaded (or the button is pressed, is probably more useful) and work from there. Not a fan of messing around with config files for that, adding levels of complexity if you have user editable config files. However I promised to look into something some months ago but never really finished it. Soooooo, let's see if I can get myself going there. Not really promising anything though, but it sounds interesting, maybe I get around looking into it in the next weeks ;-)
Other than that, if need be, I control TotalMix via MIDI with a PreSonos Faderport thing I use mainly for the DAW, but it also works with TotalMix (not quite at the same time, but that are different usage scenarios anyways for me I won't have at the same time) just fine, despite I rarely do that at the moment - it works even with the motorized faders and the displays showing the channels. Other than that you can assign every MDI axis you got, I believe. Works even with the knobs of my keyboard (tried that just for the lulz), that is just not very beautiful. I've seen bigger RME devices than my Fireface UC at home working with full blown consoles, as long as you have something that has an axis and speaks MIDI (probably programmable helps) you should be fine on the haptic front. RME have their own hardware thingy (RME ARC USB) which obviously works best (seems they have their own protocol for that thing) and is kinda nicely built, but comes at a price I wasn't really willing to pay for it, had no real benefit for me personally. Personally, to conclude that wall of text, call it TL;DR: For any axis I rather have an actual hardware axis, which is just a thing the StreamDeck can't do.
ThreepE0
Hello, first let me say thanks for writing the excellent plugin! I've been limping along with my own home-cooked scripts for a while, and it's worked alright, but I've noticed that your plugin responds a whole lot quicker than my scripts, and there is much more functionality with yours than I got around to writing.
One thing I miss is the ability to change (not explicitly set) the volume. I had a json settings file where I was storing current volumes, and a script that would take a change in volume and add or subtract a given change from the "current" value stored in the settings file. Is this something that you might be able to add? I know it could get tricky, as you might end up out of sync. I'm not sure if you have a listener for the return OSC messages that can listen for changes made in TotalMix to keep everything in sync if that makes sense. But even if it does get out of sync, it'd still be useful I think.
At the end of the day I guess I am trying to get around the fact that the StreamDeck only has buttons. I'd kill for a slider or encoder on the thing. And I'm trying to take up only two buttons (plus and minus volume) instead of a button for each volume level that I might want.
With that in mind, do you have any suggestions for other small/medium control surfaces I could dedicate to controlling the RME interface?