Generic Remote - Come on, man

I was thinking about raving about Cubase today. It’s totally awesome.

Then I lost 1 hour trying to fix a Generic Remote.

What I learned:

  1. Do NOT name 2 things the same.
    —If you have “Volume” as the name for something, don’t name another thing “Volume”. It messes up the saving of the XML file, not only if you export it yourself, but how Cubase saves it in the background. Next time you open up Cubase, you’ll have a problem with that Generic Remote. So now I have a “Main Control Room Volume”… and a “Phones Control Room Volume.” Fixed.

  2. Taking off from point 1, do not assume saving an XML files works. Look carefully at your Generic Remote XML files inside your Cubase preferences folder and see how things are named and formatted. Sometimes, you will see something off, like duplicate entries. Odd behavior.

I honestly pray someday that I will stop caring because it’s little things like this that eat up hours of my ever-declining hours left on this planet. I do not understand, I simply do not, why little stuff like this isn’t simply worked out already within Cubase. Steinberg, for the love of God, please assign some grunt the menial task of testing every last variable that has to do with formatting and saving XML files within the studio setup window. It’s NOT too much to ask, no it isn’t, for your software to have banged out the little stuff already. Sure, if I run into an issue with the new Sampler track, OK, I can cut you some slack and say to myself, “ok, this is a newer feature”… but SAVING XML FILES, causing me and others to lose hours of time? Call me sensitive. I am. I want that time back. Please fix.

3 Likes
3 Likes

Welcome to the club!

I’m many hours deep into the Generic Remote abyss. :crazy_face:

And I also hope that the re-working of the Midi Remote API will finally deliver a more complete and consistent implementation than the current Generic Remote and Quick controls. There is quite a bit of potential greatness to be had.

1 Like

What Cubase version are you running? I’m still on C10.5 and that .xml saving issue doesn’t seem to be an issue anymore. I think it got fixed somewhere along the line between C10 and C10.5 - but i’m not 100% sure.

Previously i had to export the changes as i wouldn’t trust Cubase to save them.

So yeah, it is a pain. And man, the new API is well overdue.

I setup generic controllers via MCU emulators as the MIDI Remote is just too unreliable for me, it’s too easy to accidentally move controls in the background and you’re changing instruments/effects without knowing.

The new API is rumoured to have a visual representation of your current control focused controls which will help navigation and reduce accidental parameter changes a great deal.

I’m on 11.
The specific issue I was having I’ve never run into before, probably because I never tried to do this before - have 2 hardware volume controllers for two separate volume controls in the control room. I’m guessing this is a bug.

The repro is:
Create a phones output in your control room (if you don’t already have one). Then in your generic remote, add a hardware control for both your main control room volume and for this new phones output volume. Make sure to name both of them “Volume”. Then export what you’ve created. Then import it.

I’m guessing it won’t import correctly and either one or both those hardware controllers won’t work. And this is a problem mainly because every time Cubase opens up after being shut down, it imports its own saved XML file for that generic remote. And that’s saved file is also flawed, just like the one that you exported.

The front-end editor is incredibly basic and does not tell you when you have a killer error in your configuration. Specifically in this case:

The name is the unique identifier/key that links the 2 halves of the connection:

  • external midi controller
  • internal Cubase command or control

So having multiple items with the same name confuses the Generic Remote XML parser. Whenever that parser gets confused, it just ignores stuff and loses things when saving and/or loading.

This requirement of a unique name is relatively unique in Cubase and inconsistent with much other remote control stuff that has internal identifiers or sequence numbers - although it also shows the name. – For example linking a control to the first “send” volume of the selected track will show the current name of the send target, but internally actually links by the 1st of the send slots - and automatically adjusts if the send target in slot 1 changes.


One can do a lot of really powerful things with the Generic Remote, but the learning curve is dictated by how fast you can guess the underlying design. Even for a former software developer (cough), that is a lengthy exercise more akin to reverse engineering than learning by studying the documentation.

Overall I’m really grateful for the XML based approach, which allows the more adventurous of us to do more - even if it’s not officially supported.

And imho the Generic Remote is far superior to any of the Mackie protocols. Those are badly documented and inconsistently implemented across manufacturers. I have totally given up on using them.


I’m really hoping that the phrasing used in the not-an-announcement announcement “MIDI Remote API” is deliberate as in creating an API that is usable by 3rd party developers and hopefully not too crazy complicated. If done well, that could make it much more realistic to have the best of both worlds: Hands-on physical controls much like hardware, combined with the incredible power and flexibility of software.

Making Cubase even more of a “platform” with more APIs beyond VST and ARA would allow Steinberg to concentrate even more on the stuff they consider core, and allow 3rd party developers to fill in more of the surroundings. What a wonderful world that would be … :wink:

1 Like

When you get your head around the default MCU protocol, and then how Steinberg implemented their interpretation it’s FAR better than Generic Remote. Coming from Logic i got to grips with the standard/default mapping many years ago, so getting my head around Cubase’s unique method was interesting - i actually prefer it now as there’s less clicking of v-pots to navigate.

Anyway - The main reason that MCU is better is because you don’t have to map fixed CC controls to specific Cubase elements, plus there’s visual feedback via the onboard screen (Or emulator).

i.e. for example with MCU you can toggle between having all 8 sends for one track controllable via the vpots. Or, you can swap send mode and now have Send 1 controllable for tracks 1-8 across the vpots. The ability to control the track you’re focusing on, or all of one single send would take a huge amount of work to achieve via the Generic Remote - and even then you wouldn’t have any kind of feedback as to which ‘mode’ you’re in.

Also if you’re mapping to the channel strip with Generic Remote - if anything moves position or you change the element type, you lose the mapping. Whereas MCU will address the channel strips by slot and you can even change the types within each slot.

With MCU you can also control plugins and instruments with the ability to step through pages of parameters, rather than having to hard code a hardware control per VST control. And further be careful that a knob you’re moving isn’t controlling a plugin or instrument in the background that you’re unaware of.

For me, The main advantage of the Generic mappings is when you have a control surface with plenty of hardware controls and want fixed mapping without a paging system - i.e. each control is fixed for a single function. - but as above, even that is flawed as if the channel strip changes order you lose control. :frowning:

I think the biggest issue is not having any kind of visual feedback as to what you’re controlling. Even though Generic Remote has the page system - it’s just not shown on screen when you swap - so you need dedicated and labelled buttons that stay lit on your controller for the best experience.

1 Like

Fair enough - setting up the Generic Remote is definitely extra work.

Is this something that’s already part of Cubase? I’ve taken a cursory look at the remote control editor, and a more extensive look at the Quick controls and VST controls… And have secretly wished there were Quick or VST controls you could assign in the control room to a plug-in, controls which were fixed and didn’t change depending on what track you have selected. But despite the amount of time I’ve spent on those things, I still don’t use Quick or VST controls because I’m confused, I don’t have use for it often enough at the moment… I could use a master class dedicated to this.

I don’t think you can focus your MIDI controller on Control Room parameters with VST/Quick controls because:-

VST Quick Controls - Focus on VST instruments
Track Quick Controls - Focus on plugins within a single track

As the Control Room isn’t a track, i just don’t think they would work. Plus if it did work, it wouldn’t be a fixed control, it would change when you select a track.

Also with Mackie/MCU control you can’t access the control room parameters (That i’ve seen anyway).

However, In the Generic Remote editor, you can pick VST Control Room and Control Room assignments as an assignment, and there’s the ability to mute, dim, swap monitors etc.

There is also an inserts link, but i’ve just tried it on C10.5 and the insert parameters don’t show up in there for me (I only see ‘bypass’ as an option), not sure if it’s a bug or not as according to Martin’s post on this thread they should display parameters:-

1 Like

Ah, i see what Martin is refering to in his post now. :slight_smile:

I have usually have my inserts assigned to seperate monitors (Headphones have speaker emulation, and main outs have slight EQ correction). That’s why the inserts weren’t showing up to control.

If you assign a plugin to the main section then it does appears for mapping to a MIDI controller.

If you look at the image below, brief instructions:-

  1. Blue Circle - Click the Main section and the inserts will display (I think they’re hidden by default)
  2. Yellow Circle - Pick a plugin to assign to the Main section (Will apply to all monitor outputs)
  3. Red Circle(s) - In the Generic Remote editor you can then pick the insert parameter to map to a hardware controller

1 Like

oh, that’s good news.
It seems that I tried to run a plugin in that mains section, one that affects the actual output (like room correction) and I’m not sure I heard the effect - though I may have been listening through my phones channel at the time. I’ll give it another go.

Thanks for taking the time with the detail explanation. Much appreciated.

Actually the Track Quick Controls can also control the VSTi in an instrument track (in addition to the track’s Inserts effects and a couple of other track parameters). – And often that’s the default when you do the quick load of default Track Quick Controls.

Therefore, by using the VST Quick Controls AND the Track Quick Controls, you can get yourself 16 Quick Controls for a VST instrument without the VSTi Quick Controls paging mechanism. Unfortunately that paging mechanism can’t be remote controlled.

I meant to ask you, which midi remote device you’re using via MCU to get the Cubase Channel names displayed on the remote device ?

I use a real MCU, and also. Maschine mk2, and in the past an Ableton push running native kontrol PXT general. All display on the device itself.

But recently I’ve been running from a laptop and have setup/mapped a nanokontrol2 and NI Komplete Kontrol s49mk2 - both via an MCU emulator.

With the emulator, it places an emulated MCU screen on my desktop which can float above Cubase - I make it quite small in the bottom corner.

1 Like

@skijumptoes what is an mcu emulator? can you paste some links?
BR

Just a piece of software that allows you to route generic MIDI hardware in/out of it and provides a screen that you can float on your desktop. i.e:

So the input chain is something like this:
Generic MIDI Device → MCU Emulator → Cubase

And output chain:
Cubase → MCU Emulator → Generic MIDI Device

The new MIDI remote in Cubase 12 is a better option now (imo).

Thank you very much @skijumptoes for that info.
Not fluent on cub12 yet but I dont believe they made peoples lives easier and implemented midi learn throughout all gui knobs/sliders/switches? Like every other daw already had?
BR