I have a problem using a Korg nanoKontrol2 with the Cubase 12 Pro new MIDI Remote.
Mapping page is set to MIXER to control the mixer. Same bug in the EQ of Selected Track and Selected Track pages. Button mode is set to Toggle
For example, on nanoKontrol2 the channels features a Solo, Mute, Record buttons and a fader.
On the first channel I Press S to activate the solo state. The button turns red.
Then I Move the fader and press S again. Here’s the bug: the solo state should turn off but remains On and the channel is still soloed in cubase. The button remains red.
I have to press S again to deactivate the solo state on the nanoKontrol2 and in Cubase.
Anyone else experiencing the same with a nanoKontrol2 ? I suspect the bug to be present using any controller.
Interesting to note that I don’t have this problem using the legacy Generic Remote feature. For sure the buttons on the nano dont lit but in Cubase the track Solo mode is triggered normally.
I have no idea what I’m doing, but on the Korg Kontrol Editor (you can download it for free) I set that “thing” (which is not a physical button) to “external” (please see screenshot) and that fixed it for me.
I’m on Monterey 12.3.1, and I’m using v 2.0.9, which is probably the latest available. You can find it here: Korg Kontrol Editor 2.0.9.
Hi Dream!
Thanks a lot for your help! I’m happy to know that it works for you. Unfortunately, I still have the same issue. I’m on Catalina (my 2012 iMac can’t run a newer macOS). I installed the Korg Kontrol Editor 2.0.9 but that didn’t solve my issue either. I try to change the LED mode to External but it goes back to Internal when I close/re-open the editor. (UPDATE: It’s ok. Now set to External but still have the issue))
I’m gonna try the same on my Macbook Pro running Big Sur a little later.
Argh! Sorry that didn’t help.
I’ve been on Mojave for ages with a rock solid stable system, but C12 wasn’t supported. Decided to do the big jump a while ago, and luckily it’s all smooth (beside the performance of C12 which isn’t as snappy as C11 yet, but workable for me).
I remember I had also tried to mess around with the “audio midi” on OS.
For a while I had to connect the nanoK only after Cubase was loaded to make all the lights work well, but after I changed to “external” now I can leave it always connected and that made the trick for me.
I tried the same on my Macbook Pro running Big Sur and still have the issue.
One thing I noticed either with my iMac (Catalina) or Macbook Pro (Big Sur) is that the Last Touched Control Value is updated correctly only if I press S twice. For example, If the value is ON, and I move the fader and then press S again, the value indicated for the Last Touched Control is still ON while it should be OFF. That’s why a second press on S is needed. However the Mute and Record values are updated correctly.
Anyway! I’ll be able to live with this “minor issue” from now on. Pressing S two times already became an habit in my workflow! After all, it’s early days for this new CB12 Midi Remote feature and there will certainly be some bugs to fix in a near future.
Steinberg should not be in a hurry to remove the legacy Generic Remote though.
Just discover it works as expected if I use a knob instead of a fader to control the volume with my nanoKontrol2. Here’s what I tried:
Created a Cubase project with just an Audio track
Created a new blank MIDI Controller Surface
Created a button and a knob
Mapped the button to Solo the channel
Mapped the knob to channel’s volume
Now the solo works as expected even after controlling the channel volume with the knob.
So maybe the bug lies somewhere around the fader control implementation in the Java Script?
The script sends the definition SysEx when loading. So there is no need to change something in the KORG editor. Actually it will be overwritten by the script anyway.
I cannot reproduce it here in my side. Are you sure you pressed the button properly? Sometimes it doesn’t send the value out.
Hi Martin. Thanks for your help. Very much appreciated!
Yes I just saw the switchDeviceToCcModeWithExternalLed function in the script. So nothing to do on this side indeed. Yeah I tried all sort of combinations. All buttons seems to work properly. My issue happens only when a movement of a channel’s fader is involved before pressing S. The same happens on all the nanoKontrol2 channel.
As stated before, I created a new blank MIDI Controller Surface and it works as expected if I use a knob instead of a fader to control the volume.
Since this is happening on two machines with two different macOS, then maybe it’s my nanoKontrol2 itself that is action wrong.
On the last Greg Undo May 3 livestream there’s a user with the same problem but he haven’t provided much infos with his issue. Anyway here’s the link: 02:31:07. The user asked “Why do I have to toggle some buttons twice using the new MIDI remote?”
Next step in my case, I presume, is to reset completely my nano.
It’s not me! I referred you to a youtube livestream where a user has the same issue as me but as I told you, he didn’t specify any details! Here’s the link again. 02:31:07.
BTW I factory reseted my nanoKontrol2 and still have the issue.
Again it’s important to follow this sequence to reproduce the issue:
On the first channel I Press S to activate the solo state. The button turns red.
Then move the fader and after I press S again. Here’s the bug: the solo state should turn off but remains On. So the channel is still soloed in cubase and the button is still red on the nano.
I have to press S again to deactivate the solo state on the nanoKontrol2 and in Cubase.
Maybe the reason why on my case works is that I’m not using the provided script but I made one.
Reason for that is that I wanted to remove the faders from the control surface so that they can be set to CC values of my choosing.
It would be great if in the future midi remote will let us assign CCs in a way that in a page we could have faders for the mixer, and on another one faders assigned to custom CCs (like modwheel, expression, master volume etc).
Yes, this feature request has been risen already. Something like bypass the assignment, so you can pass the data to the MIDI/Instrument track the common way.
Still investigating. But what I have found so far:
The issue is not linked with the Mixer functions. The very same issue is in other pages too. For example the Selected Track page. If you Enable Send 1 (Solo button), move the Send Level 1 (slider) and try to Disable Send 1, it doesn’t work neither.
It’s always linked to the same “channel”. So the Solo slot X and the slider slot X. If I do Solo 1 - slider 2 - Solo 1, then it works as expected.
I tried to print some data to the console and I can confirm in the case of Solo - Slider - Solo, the 2nd Solo doesn’t print the value to the console.
Combination Solo - Encoder - Solo works as expected.
Combination Mute - Slider - Mute works as expected.
Combination RecordEnable - Slider - RecordEnable works as expected.
In fact it’s the Slider - Solo combination. The button before the Slider doesn’t play any role.
And it’s also the Solo - Slider combination. Te very 1st value from the slider (after the Solo) is not reflected by Cubase (I can see the value in the MIDI Monitor, but the Volume Fader doesn’t move).
Result:
It’s definitely related to the fact that MIDI CC0-32, CC1-33 are kind of special combinations (MSB & LSB values of the same parameter).
I adapted the script and send the MIDI Messages from different MIDI source. It was the same bug.
I changed the Solo MIDI CC from 32 to 31 (which is not in use). So Slider sends 0 and Solos sends 31. It works.
I changed the Solo MIDI CC from 32 to 33. So Slider sends 0 and Solos sends 33. It works.
I changed the Slider MIDI CC from 0 to 1. So Slider sends 1 and Solos sends 32. It works.
I changed the Slider MIDI CC from 0 to 9 (which is not in use). So the Slider sends 9 and Solos sends 32. It works.
=> The only non-functional combinations are: 0-32, 1-33, 2-34, etc.
Btw, it seems it’s not a bug in the script, it’s bug in the API. I have created a new script from scratch, using just 2 parameters and I can reproduce it too.
