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.
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.
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.
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…
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:
If they are not connected to the computer, Cubase will not load them. They also cannot be added manually.
They make use of active sensing messages.
Upon Cubase startup, it sent 30 bytes of sysex data.
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)
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).
I like Shinta215’s hypothesis on this actually. Definitely makes sense and well thought out and reasoning I must add. Kudo’s for that!
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.
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!
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.
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.
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.
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.’
If there is any Function assigned already, when you make an assignment to the Key Command, Cubase informs you about this existing assignment and you have to decide, if you want to overwrite it, or keep the old one. If you didn’t see this kind of message, there were no function to the Alt+Q assigned before.
Well I am pretty new tu Cubase 8.5. Was a longtime logic user.
I setup some generic devices for controlling Lemur and some other gear.
After each reboot all my settings are gone. Means every lovely morning I gotta program those In and outputs.
Another thing that is really boring me is the VST connections. I always have to reload them.
There should be at least some kind of autoload template setup that includes these settings, I mean we don"t use for each template a complete other setup.
Other than this I love cubase and wait for a fix. If you guys have any tips I would be thankful
Unfortunately, there is an issue on lots of 3rd party, who are providing virtual MIDI Ports. During every single Cubase start, they generate a new MIDI Port unique ID. So it’s always a new (another) Device from Cubase point of view. This is why you have to set it again and again in the Generic Remote Device.
Regarding the VST Connection, I would recommend you to make a new thread on the forum. In general, the settings is stored in the project, and there are some rulers, when to load it from the project, and when to keep the last settings. There are also rulers, what settings should by applied, when a new project is created.
So I made my life a little easier by doing the following:
Downloaded and installed a little scripting program called “Autohotkey”.
Created a little script (and placed this script in Windows startup folder) that sends the following key presses in sequence:
ALT+J → R → O
In Cubase I’ve assigned ALT+J to open de ‘Device Manager/Devices’ window with the Generic Remote templates settings etc.
I’ve configured the Autohotkey script to trigger when I presss ‘ALT+Q’.
So now when I start Cubase, all I have to do is press ‘ALT+Q’, and the script will automatically press the sequence of keys which in effect opens the device manager → presses the ‘Reset button’ and presses the ‘OK’ button (which closes the Devices window).
Mind, this only works if the concerning Generic Remote template has the focus/is selected in the ‘Device Setup → Devices’ window. But, if you have more GR templates, you can get around this by programming the script with TAB and up/down arrow sequences.
Anyway, like I said, this does make life a little easier. Definitely worth the 30 mins I spent on setting this up!
you don’t need to export or import anything, or do anything else to make GR work as expected.
My problem was a mistake in an xml file itself - maybe the same controller number, action or name in different lines of code (I don’t know the exact reason why it refused to import and to save itself). Actually, I edited my exported XML, which refused to load itself back to Cubase, deleting all the lines except my own assigned ones - that saved me a lot of time programming everything from scratch.
But the best way is just to start your GR programming with an empty list, deleting all the controllers first, and adding only the ones you need, taking care of not to double the names, functions, controller numbers in different lines.
Than solved all problems with my Korg Nanokontrol2 - now everything loads and works like a charm, almost every button and fader is connected with misc Cubase functions!
Sorry for my bad English and my strong Russian accent. Cheers guys!