I am - honestly speaking - a little bit concerned. Why?
Well - it is a great idea to create a midi remote API. But: Will that lead us into a situation where lack of working remote controllers will lead to Steinberg telling us that it is now the fault of the providers of the midi-controllers that the integration does not work -because they do not program the necessary software that uses the remote API?
What I am trying to say: Please, Steinberg - dont forget to include a well designed GENERIC REMOTE CONTROLLER EDITOR that allows us users to set up controllers nicely. THe API alone is not sufficient - for it will lead to a situation where you, steinberg, will delegate responsibility to the controller suppliers.
A GENERIC REMOTE CONTROLLER EDITOR - if well thought and designed - could also Replace the Midi device editor (these two things could easily be put in one single thing).
Another fear that I have: Continue to neglect EUCON integration (there is no relevant improvement made in C11 concerning EUCON. All the bugs and flaws still exisit - see mixer visibility. This is a shame!) - and tell us that there are now much better alternatives via the MIDI API.
I was wondering yesterday, while messing with quick controls, if we could have a means in the future to link two or more parameters to a single hardware knob, modify incoming values of linked parameters in any way (be it inversion of values so that one parameter goes up the other goes down or trigonometric equations so that if we consider a quick control’s range 2π, a linear increase in one parameter would cause the linked parameter to go through 0, max, 0, -max at 0, π/2, π, 3π/2 respectively.)
To be honest, I don’t think I quite understand what the MIDI Remote Controller API will encompass, and how my life as an end-user will be affected (if at all). Also, I don’t know if this has anything to do with Cubase (as a feature-set) at all, or if it’s something completely different semantically, a low-level infrastructure if you will that as an end-user I won’t have much to do with it, but will serve Cubase under the hood.
Yep, more informations about it would be welcomed. Honestly, I would like it to solve mainly the broken recognition of the NRPN messages in Generic Remote definitions, as well as clearing the situation between the latter, the RCE and Track/VST quick controls. After piling all these up through the years, we have ended up with a mess : when use rather each or other of them and how to set these accordingly to the created projects content ?
After this, API stands for Application Programming Interface : so - and in a logical way, I think - I’m wondering if there isn’t something related to an eventual LUA programming interface as it is already axisting in the full Halion 6.x version. No problem, as soon as we can get an UNIQUE interface to solve all the MIDI/remote controllers behavior quirks in Cubase…
They’re broken for so long that I had forgotten about them.
I expect all of these little quirks to be fixed, and even if the segregation of remotes cannot be solved, I hope that we eventually get a way to make our own ways (albeit straighter this time) around them.
Yep. FWIW and long ago, I’ve finally found this more or less clumsy workaround to be able to use the endless knobs of my MPD32 controller. Actually, it has served me well for several years and still do, but well, it’s far from an ideal…
Just hit a problem with current remote editor too, it would be nice if you could map a jog/endless encoder (which has a single CC address) to trigger one command going clockwise and another going anti-clockwise. i.e. such as mapping to value up/down or cursor/navigation movement.
Here is my present Generic Remote Definition for my MPD32, which has 8 endless knobs (actually 24, as these can be set differently in 3 ‘control banks’). The main aspects of it :
It is set to be used with the second MIDI port of my Fireface UCX, so this probably will need to be adapted.
The endless knobs of my unit, when set as INC/DEC, are sending NRPN messages in accordance to the MIDI 1.0 specifications, in the following way :
Setting an unique MIDI channel to an endless knob on your hardware remote device.
Creating two lines in the GR definition, in both panes (one for increment messages, the other for decrement ones)
Setting all the lines related to the endless knobs as ‘Controller’ in the Midi status column (upper pane)
Choose the involved couple commands in the lower pane, such as ‘Nudge +1’ both ‘Nudge-1’.
As an example, and using Steinberg MIDI Monitor plug-in (which perfectly recognizes such messages, by the way, contrarily to the Generic Remote implementation… ), here is what I get after recording both NRPN ‘incr’ and ‘decr’ message, using my sixth endless knob (MIDI channel 6) :
After this, it all depends to which extent the remote device is able to transmit standard NRPN messages. In my case, and as they are only 16 MIDI channels, I can only use two banks among the three that I have available.
Hope it will be useful, somehow, with a minimal adaptation…
To be honest, and in a perfect egocentric way, it’s interesting, as I am considering the MPD232 to replace the one I have, which is something like 9 years old and begins to show its age…
232’s looking good! I don’t see how it can go wrong, the downloadable editor allows for complete remapping of the device. I expect it to be even more robust for 232 since it’s more expensive than the 218.
Ah, my controller is just plain Relative Midi CC, So sends value 1 clockwise, and value 127 anticlockwise. And there’s absolutely no way of splitting them as separate entities on the generic editor as it’s the same CC#.
I want to play too!! haha… I hope they put this into the new mapping system.
Yep, and I’m keeping an eye on it (even downloaded its userguide…). Not sure that I like the step buttons implementation (I’ll never use it), but well… As soon as I retrieve its main features and the same NRPN messages transfer process.
What is your controller and, most important, is it able to transmit NRPN massages which are compliant to the MIDI 1.0 specifications ?
Well… It’s a bit of an oddball, but one of my workflow gems!
It’s an Ableton Push controller, running a script called PXT General. The display and knobs are basically MCU functions, so i get all the plugin parameters and page control at the top displayed on the screen as per MCU. That’s setup as MCU device in Cubase.
Then the Pads go out on their own port to the piano roll, and can be set to different scale modes etc.
But separate to that, I can set any of the buttons and rotaries as Relative or Absolute MIDI CC and route through it’s own Generic Remote Device entry - So, sadly no NRPN options exist as part of the PXT General script.
If there were more than 1 or 2 knobs that i wanted to route like this, then i’d create a virtual port and split them off based on turns - but it’s going to be really overkill to do that. Also PXT General isn’t in active development anymore either.
I’m not big on step sequencers either, but seeing those buttons so neatly arranged in a row, and assuming they are re-mappable, I would make them into Visibility Agents, Track Filters or Arranger Chain Triggers, or workspace 1-16 or something of that nature. If we had access to Quick Control Presets via keycommand, I’d have them do just that and I wouldn’t even bother to change banks from the AKAI. But I don’t know of a way to do that currently.
That’s what I’m wondering, if the new API will mean better access to the innards of Cubase. Allow us to do meaningful things with relatively cheap/simple controllers. That kind of thing.
OK. So, I have looked a little more about the Push controller and indeed, it seems that NRPN messages aren’t among its features. So, my workaround is rather useless in this case…
Sadly, it doesn’t seem that they are re-mappable, from what I see in the MPD232 user guide…
Yep, and possibly avoid any redundancy between the available remote control features : RCE, VST quick control, and blurry distinction between these and the track ones, essentially. I would much prefer 16 simple QC with the same features and usage, up to the users to decide what they want to do with them in an UNIQUE interface, and increase the number of the latters : difficult to create a drawbar organ setup with only 8 VST QC - the usage of the track QC is more or less mandatory, in this case, so what’s the point of the distinction between the two ?
They’re broken for so long that I had forgotten about them. 
), here is what I get after recording both NRPN ‘incr’ and ‘decr’ message, using my sixth endless knob (MIDI channel 6) :
