I think I figured out that RCE is limited to 8 parameters per page
No. You can control more than 8 parameters per page with it. Here’s a video about it:
But there are problems (bugs) with it.#
I’ve opened a thread about it.
You can easily assign all of this to user 1, which would essentially circumvent the limitation of only 8 potentiometers for the quick controls. However, the problem here is that you can’t name the potentiometers correctly, and you don’t have the color coding either. And the bug I described in the other thread is also too annoying. (Switching between plugins doesn’t work properly.)
Yes, I tried setting the RCE up with 12 controls but it was just too buggy.
I set up user 2 for quick controls with the bottom switches set up to:
1: insert back
2: insert forward
3: on/off insert
4: open insert (to put into focus)
Works well
Can you tell me what errors you encountered?
But if you’ve assigned 1-4 like that, then you can also do it with the 16 keys, right?
I would like it if it worked, because then you wouldn’t have to select the slot first and then open the plugin. Instead, you could open the plugin with the mouse, and CS12 would map it immediately.
I’m not sure exactly what happened when I tried to assign 12 parameters with the remote control editor, but it didn’t work anyway. I have programmed the bottom four switches as I said, and only the eight top encoders work for quick controls. That said it works pretty well although the generic CS 12 insert control works well as well.
It’s kind of nice to not have to use the mouse…
978 / 5.000
I’m currently in the process of assigning my plugin assignment via the user2 page. The problem that’s cropping up here is the following. If you load a plugin where all 12 pots are occupied and then switch to a plugin where, for example, 4 pots are unoccupied, meaning no assignments have been made to 4 pots, the values of the previously displayed plugin will continue to be displayed on the 4 pots. This is obviously unpleasant, because then you don’t know which parameters actually belong to the loaded plugin. Currently, I’m getting around this by assigning the bypass function, for example, to the 4 pots and giving them a period (.) as the name. Because unfortunately, you have to give the parameter a name. Then the 4 pots always display “off,” which is also inconvenient, but better than having parameters from the previous plugin displayed. Have you noticed this too, or do you have a better idea? I don’t know if this is due to Cubase or CS12. Regards
Sounds like VS12 to me and should be reported as a bug.
Unless someone thinks that could be considered a feature in different scenarios?!? Anyone?
I already let @Tim_Chandler know 
This is the way I use the CS-12 now as well. It would be FANTASTIC if we didn’t have to have the plugin (or abbreviated name) name before the parameter. I love this way of working because I can have a channel strip plugin on every track and when I switch tracks it updates in CS-12 without having to select the insert (providing there’s only one insert). Much more direct and quicker!
… and that change would be on Steinberg side or on Nektar side?
I’m hoping the Nektar side, otherwise I doubt it would happen…
It’s surely doable on the CS12 side. I guess that @Tim_Chandler could provide a config file (if not already having this, sorry, I don’t know) for setting up such preferences.
Cool, I hope you’re right!
I can’t connect CS12.
I tried different USB cables and ports, but the device still shimmers with colors, and the connection icon is gray. And Cubase says that the device is connected. How to Factory reset?
Win 11, Cubase 14.0.30
Reinstall all Cs12 software. And then deactivate and activate control core.
Didn’t help. Reinstall and deactivate/activate.
I heard from Nektar and because the User 1 and 2 are not part of their code, it isn’t possible, it would have to be up to Steinberg to implement it. It’s a shame because, depending on the length of the plugin name, there are no characters left to show data on a controller!
Then create a ticket with Nektar.they can help you or write to @Tim_Chandler
Hi, since I don’t own this device to test it, I have to guess that these pages are for users to make their custom assignments.
When we have custom assignments and the values of them are changed while in Cubendo, some events are getting triggered.
Depending on the approach used, we can have the
mOnTitleChange, mOnDisplayValueChange, or if we’re working with the direct access approach (seems to me that Nektar chose this way) we can use the functions getObjectTitle, getParameterTitle and getParameterDisplayValue, when the events mOnObjectChange and/or mOnParameterChange are triggered.
Anyway, when using the events earlier mentioned (NOT the direct access ones, just the initial MR API functions), in the case of plugins, the mOnTitle responds with two strings, the plugin name and the parameter name. The mOnDisplayValueChange responds with the display value of the parameter (for e.g. On/Off etc) and the unit used by this parameter.
Here’s a log from a session here, where I have an insert fx in the slot 1 of a track, and I’ve assigned using the mapping assistant the very first knob of a pseudo controller to the very first param of the insert slot 1 of the selected track object:
As we can see, Cubendo responds in the same event with the plugin name separately by the parameter name. This means that we can have total control of what to send to our displays.
Now, I didn’t have time to have a deep look into Nektar’s script (at the end of the day I don’t like messing with other friends’ scripts), but here’s a line of code that may be responsible for the addition of the plugin name and the parameter name:
this.longLabel=objectTitle+" "+title;
The test snippet used for the above screenshot:
var midiremote_api = require('midiremote_api_v1')
var deviceDriver = midiremote_api.makeDeviceDriver("Test","Custom Assignments","m.c")
var midiInput = deviceDriver.mPorts.makeMidiInput("anInput")
var midiOutput = deviceDriver.mPorts.makeMidiOutput("anOutput")
var detectionUnit=deviceDriver.makeDetectionUnit()
detectionUnit.detectPortPair(midiInput, midiOutput)
.expectInputNameEquals("An Input Port")
.expectOutputNameEquals("An Output Port")
var surface=deviceDriver.mSurface
var mapping=deviceDriver.mMapping
var page=mapping.makePage("A custom page")
var aHostVar=page.mCustom.makeHostValueVariable("aHostVar")
for(var i=0;i<8;i++){
var knob=surface.makeKnob(i,0,1,1)
knob.mSurfaceValue.mMidiBinding
.setInputPort(midiInput)
.bindToControlChange(0,24+i)
page.makeValueBinding(knob.mSurfaceValue,aHostVar)
knob.mSurfaceValue.mOnTitleChange=function(activeDevice,title,subTitle){
console.log("knob "+this.i+" title="+title+" subTitle="+subTitle)
}.bind({i})
knob.mSurfaceValue.mOnDisplayValueChange=function(activeDevice,displayValue,unit){
console.log("knob "+this.i+" dispVal="+displayValue+" unit="+unit)
}.bind({i})
}
Thanks for this (although I can’t say I really understand the script stuff). Just to mention, with Nektar’s editor (Nektarine), I can change a lot of names, it’s just when using the User 1 and 2 that the plugin names can’t be changed and there’s nothing Nektar can do about this. However, for some reason the focus quick controls DON’T assume the plugin name, only the parameter name assigned in the RCE.