Generic remote template on CMC-AI not working after restart

Cubase
#1

When adding a generic remote template for the CMC-AI or CMC-TP controller, the template is not properly loaded after restarting Cubase. A workaround to get it (temporarily) working again is to re-import it manually, re-select the midi-input and output device in the Generic Remote template configuration, or tag the ‘learn’ option in the template configuration. This somehow triggers Cubase’s awareness of the template, and then it will function until Cubase is restarted.

The reason I need a Generic Remote template for my CMC-AI controller is that I use it to assign some controls to the arrow buttons, which are otherwise unutilized outside of the browser function of the buttons. Also, I want one button on the CMC-AI controller to open a plugin window, and the integrated CMC-AI remote template doesn’t allow for this.

Reproduce:

  • Navigate to Devices -> Device Setup
  • Press + sign to add a Generic Remote template
  • Choose the CMC-AI controller as midi input and output
  • Assign any parameter to any of the F1-F4 buttons on the CMC-AI
  • Export the template and save it somewhere on your disk
  • Press Apply in the Device Setup screen and close the window
  • Test your template, it should function as expected
  • Restart Cubase (saving/not saving the project makes no difference)
  • The template no longer works

I have not been able to reproduce this issue with other midi controllers. I tried this with the NI Kore 2 controller and the Akai LPK controller, and they both worked fine. You’d think getting a Steinberg controller would function better in their own daw than some 3rd party controller… :unamused:

Cubase 6.5 (6.5.1.117) 32-bit
Windows 7 Ultimate 64-bit
CMC-AI
CMC-TP

#2

After messing about a bit, I realised that a workaround that I’d be happy with is if I could somehow assign the ‘reset’ button under Devices -> Device Manager -> Generic Remote to a midi controller via Generic Remote.

I tried messing about with the Generic Remote XML files, as this option isn’t a listed parameter for Generic Remote control, but couldn’t get a working configuration. Any Generic Remote/XML hackers out there that could be of assistance? :slight_smile:

#3

This seems to be a problem with any generic remote. I attempted to assign control room volume to a simple fader on one of my midi controllers (as the Eucon control room knob is too inaccurate), but Cubase keeps forgetting the assignment.

I even tried adding a new mapping (vs. the default VST1-8, etc), but that is lost as well. Renaming a default mapping doesn’t even work after a restart. All is fine until Cubase is restarted, then it’s gone. Have to remap it manually everytime - how in the heck can Steinberg screw up something like this that worked for years?

#4

I can’t check this on the Cubase now, but I guess, the Generic Remote is saved with the project. Isn’t it?

I mean, if you use your own settings in the project, save it and open again, you will get your settings. If you open new empty project, you will get factory Generic Remote, because there si this factory Generic Remote in the Empty Project template.

But again, I can’t check it, now. I just guess. Can you check it yourself, please?

#5

No - that’s the problem. It isn’t saved with the project. I could save it with my template if it was.

#6

A custom generic remote setup has to be exported to XML before Cubase will reload it at launch.

It makes sense, in a way.

The custom generic remote setup is a “user preset” of the generic remote device.
Like any user-created preset of any plugin, you have to save it before it will be recalled.

When you export, you also tell Cubase where to find that “preset”.
If you then move or delete the “preset”, it will load the default “preset”.

#7

Thanks - that works.

It might make sense to Steinberg, but it makes little sense in the DAW world.

If it has to reload it as a preset, then it would make more sense to just save it with the project, along with the project’s xml prefs. It shouldn’t require another complete rewrite to simply allow a user-named controller for each project (rather than a user-named xml export), and let the project save it as the default for that project. Exporting and importing custom controller configs should be an addition to this concept.

Also, there should be a way to setup a custom controller with no definitions in place, or at least delete them all at once. I have no need for all fader, pan, and send definitions when setting up a control room controller.

Perhaps, like a few other things, Steinberg is in the process of changing this, and just didn’t get past the export function.

#8

No, it doesn’t make sense to manually export a template for Cubase to be able to remember the template…it’s rather upsidedownface, actually.

You don’t manually export a midi file so Cubase can find and automatically load it the next time you open a project?! There’s just no way of justifying it. The XML should be saved automatically in the user prefs folder and loaded from there.

An addiotional feature could be to allow this XML template to be saved on a per project basis, but I don’t think many would benefit from that.

Anyway, if anyone has a solution for my inital issue, I’m all ears. For now, everytime I start Cubase and open a project, I have to open the Generic Remote config menu and press the ‘reset’ button to get it functioning…it’s not a major pita, but annoying nonetheless.

#9

Two things:
1 make sure (as mentioned above) that you save and reload the template.
2 make sure every controller entry has a unique name (very important) BEFORE you save and reload

#10
  1. Read the OP and pay particular attention to the 5th repro step.
  2. I am aware of this issue and can assure you that I have taken this into account.
#11

Considering that generic remotes don’t recall correctly (i.e. by default rather than xml auto-import), I would say it’s a bug with something in the CMC controller config that isn’t activated after a restart.

What you are seeing may actually be there with any controller, but since most are simply midi CC controls, it may not affect those - i.e., you move a cc control, and Cubase sees the assignment.

The CMC may have additional sysex or midi messaging that has to be reset before Cubase can see it’s assignments.

#12

That doesn’t make much sense to me. If the CMC conforms to the MIDI spec as any other MIDI device, at the very fundamental level, it is a generic midi controller. Case in point: After restarting Cubase, the midi signals are registered perfectly fine (as I can see in the midi activity window), but Cubase just isn’t aware of the generic remote assignments. I believe this is more likely caused by a Cubase design error where the CMC extension somehow tricks Cubase into thinking all necessary configs have been loaded and never get’s a chance to load the user defined generic remote config.

Whichever way, the underlying cause is irrelevant. Either Steinberg fixes this issue, or I need to use the workaround I mentioned earlier. Thanks for thinking with me here though…

#13

I just tested one of my CMC units (the CMC-CH) to see what was happening MIDI wise (using MIDI-OX).

The unit sends standard MIDI messages.
When a button is pressed, it sent a MIDI note on and off message.
The fader on the unit sent pitchbend messages.

However, there are a few things to note with the CMC units:

  1. If they are not connected to the computer, Cubase will not load them. They also cannot be added manually.
  2. They make use of active sensing messages.
  3. Upon Cubase startup, it sent 30 bytes of sysex data.
  4. Upon closing Cubase, it sent 10 bytes of sysex data.

I don’t think that’s it.
You said before that pressing the reset button made it work.
If you look at what the manual has to say about the reset button:

(Keep in mind that MIDI is a peer-to-peer connection)
You essentially have two MIDI devices sharing the same physical device.
Depending on the order of initiating the handshaking protocol (probably the CMC device first) the second device to begin the handshaking protocol may fail (because the device is still “busy” with the previous handshaking), and thus, not be initialized.
Pushing the reset button on the generic remote re-starts the handshaking protocol; and because the device is now open to return the handshake, it’ll initialize.
(Please note that this is a hypothesis)

#14

The midi spec has nothing to do with it. The app has to translate those into internal commands and mappings. There is nothing in the midi spec to define how that is done. Cubase also responds to Eucon for the same control mappings, so that has to be done with either midi or Eucon, and that means it’s translated from either control protocol into internal control commands.

I think you probably nailed the crux of the problem you are seeing though - the CMC custom config is interferring with your generic mapping, and that gets down into a problem with Steinberg’s mapping code for any controller. It’s screwed up for sure, and it’s embedded in Cubase’ assignment approach (and external xml loading), not the midi controller or midi itself.

What irritates me to no end is that this has been in Cubase for a long time, and now it is broken, and has you’ve found, their own controller is handled even worse than most. More than likely, Steinberg is rewriting a lot of core code as they go for some future reason, but this section seems to be half done (actually quite a few seem to be a work in progress).

I don’t know the CMC, but is there a Steinberg CMC driver you could uninstall and try to get it to load as a generic midi device? Might allow it to go undetected as a CMC and let you manually configure it. I’m thinking not since with USB devices, this is likely impossible, but worth a suggestion at least.

(edit) just saw the last post - handshaking is where these controllers get screwed up for general midi use - given what the previous poster is saying, obviously SB is using it’s own mapping to allow button/color feedback (similar to Akai’s APC controller with Ableton - useless for general midi assignments).

#15

I like Shinta215’s hypothesis on this actually. Definitely makes sense and well thought out and reasoning I must add. Kudo’s for that! :slight_smile:

However, I used to have a BCR2000 and had set it up as both a generic remote and a Mackie Control device at the same time…so basicly the same scenario: two midi devices sharing one physical device, and had no issues.

Perhaps the CMC series use a different (longer) handshake than the BCR2000 did, or perhaps this behaviour has changed in newer Cubase versions? Either way, it’s pretty interesting to find out what is actually causing this now. :slight_smile:

Just using the CMC’s as a generic device is no good for me either, because there are some functions I want as well that the CMC extension offers that I can’t set up via generic remote. Although I guess I could try it out for giggles to -perhaps- support Shinta215’s hypothesis. Nice thinking csd, I like your style! :sunglasses:

Thanks for the feedback guys…

#16

Just a quick update:

I tested csd’s suggestion and uninstalled the CMC extension (but left the Yamaha USB driver obviously) and the generic remote template loaded fine after a restart. Seeing the logic behind Shinta215’s hypothesis, I think it’s fair to say that indeed is the cause of the issue.

Now that Shinta215 and csd have done most of the work for them, I hope Steinberg will take it from here. :wink:

Also, just for giggles I added 50 or so generic remote devices and in the last one I loaded my template for the CMC AI. I was hoping this would give enough time in between the CMC extension handshake and my generic remote device handshake, but alas…I didn’t think it’d actually work, but it was worth a shot. :stuck_out_tongue:

#17

Bump 18 months later…still not solved. Neither in Cubase 6/7 new CMC tools…nothing nada…no response from Steinberg…nothing…Will try again in 2014…or perhaps they’ll have it fixed in 2015? Who knows.

#18

Well guess what everyone. It’s 2016 and this still isn’t solved. Seriously wtf?

#19

Same Problem Here on Cubase 7.5 since a couple of days.
Formerly It was just that cubase forgot controller inputs so I had to assign them manually after loading any project, I could live with that.
Now, i have to reassign each time I open a project some commands like quantisation categories, some other assignments for the very same controller stay in place. Can’t figure out why. It really annoyes me to repeat this process 2 times a day. I hope someone will come up with a solution soon, i would really appreciate. I’m working on Yosemite, no system changes werde made as the problem occurred. Sorry, for my bad english.

#20

Hello again.

Back in 2016 and am now running Cubase 8.5.

Still not solved, haha…

I’ve programmed myself to press ALT+Q (not sure if this was a default or custom Key Command) -> select GR template -> Press ‘Reset’ button. It’s still annoying, but atleast get’s me up-and-running quick enough.’ :wink: