How to have access to different states, that Cubase does not transmit?

Hi there again :slight_smile: ,

Can someone tell me, how we can receive the state from Cubase for different, essential functions, like Bypass EQ, Bypass Strip etc.
It seems to me, that we have no options to properly know these states, so that we could bind them to buttons. Any help here, would be nice.

@skijumptoes, @Jochen_Trappe, @oqion … anyone???
How to build a state machine for these?

5 days. I’ve been doing other things.

I assume you mean in JS. have you looked :


the thing is, what I think you want is to get a callback when it changes. That is a bit more difficult.

My experience using mOnValue change has let to significant performance issues.

Can you describe what it is you are tying to accomplish? I might be able to figure out a way to do it.
The events are not strait forward the way I think a lot of people would expect.

He’s referring to the bypass of all bands, not the individual bands. I’m already getting the callback on the individual bands with success.

As far as the overall bypass, You can toggle, assert dessassert on the selected tracks through the use of the project logical editor, but there seems to be no way to get the current state.


I would agree with that, I couldn’t find a way, so I used each band individually.

Exactly and not only EQ bypass, i miss any other bypass too (sends, strip etc.).

That is exactly my problem i have with API and the Mapping Assistant.
Why is the API so limited comparing to the Mapping Assistant?

Most of the functions that can be used with API (like 70%) are toggle switch functions. This circumstance degrades encoders to ordinary buttons, instead of controlling parameters.

The most annoying part is, that API and Mapping Assistant are working so differently. The Mapping Assistant makes excessive use of XML documents, that define the binding and the function and we dont have tools to do the same with the API. I still have the hope, that we can use both methods (API+Mapping Assistant). It is worth a try.

The Mapping Assistant has always two scripts. One that defines the surface and the other one that uses the XML files to define the “hooks” to Cubase, that can be found here:
C:\Users\username\Documents\Steinberg\Cubase\MIDI Remote\User Settings

The XML that are used are here:
C:\Program Files\Steinberg\Cubase 12\VST3\Cubase Plug-in Set.vst3\Contents\Resources\VST XMLs

But i am sure, the Mapping Assistant can use these as well:
C:\ProgramData\VST XMLs\Steinberg Media Technologies

Important would be to fully understand the Mapping Assistant script that is here:
C:\Users\username\Documents\Steinberg\Cubase\MIDI Remote\User Settings

But to be honest, i dont have the mood for this. For me the API is a crippled assistant to make feedback possible for the “better” controllers. I see the potential of it, but it is far, far, far away from what the people really wanted. The reality is, buy the cheapest nano-crap and use that, as you will have better results with that.

100% agree, I can’t believe that there’s already such a disconnect between the two.

After the latest update, I can’t see how they can bring the ‘selected track’ elements from the mapping assistant into the API. Unless they expect us to manage a list of parameter ID’s and do it direct like that? (i.e. as the 'xml just shows unique ID’s for parameters and controls).

The trouble with using the API and Mapping assistant together is that the paging is generated from two sources which leads to ghost pages being left behind if you change the API. Surely it wasn’t planned to become this mess?

I could understand it more if the API was purely to develop the hardware standard and then the mapping assistant was used for all control elements - but there’s many binds in the API that you can’t do in the mapping assistant, and vice versa.

It’s shocking management really.

And therein is the focus of this MIDI Remote, it’s basically a pretty face bolt-on. Initially looks impressive, great to map elements, but as you dig it’s actually less capable, highly convoluted and reliance on already over-used nomenclature of “Quick Controls”.

Due to how it’s bolted on and worked around what is there already I just fail to see how they can turn this around.

To me, The primary focus was:

  1. Get a pretty interface for simple/quick mappings - Sell as a C12 feature
  2. Offer hardware manufacturers an easy custom look for their controllers

Both of those are very external facing, sales driven features.

I think those looking for deeper mapping, or an improvement to what was achievable with generic/mackie remotes are a secondary concern and very much sit in the “We will sort out later” bracket.

And as usual, “Will sort later” will descend into the “Not financially viable” bracket and left to rot.

My biggest issue is whether this is a big enough deal for me to change DAW’s, hand on heart I don’t know how much I need a deeply integrated controller, and even if it’s a positive effect on the music I produce. It almost feels like a hobby in itself.

In my head, I have this geek one side who loves the technical side of music and software - and he has a controller fetish and likes to procrastinate, then, on the other side lays the creative musician who probably works better when things are kept simple without any screens turned on.

As a result I’m left with one side of my mind being angry, and the other perfectly happy thinking it’s amazing! :imp:

Perhaps I need to try switching off the procrastinator in me and just getting on with things, and Steinberg knows best. haha.

1 Like

I would not have a problem with this, if it would be possible. A thing only a SB developer can tell us.
The XML provide EVERYTHING a controller would need. XML provides what to print to display, what kind of LED ring mode to use and what function (via ID) to control.

This is not exactly what i meant with using together. For me it looks, that you can use the API functions, on top (or bottom :smiley: ) of a mapping assistant script to provide the feedback for the controllers (it would be enough if the API only do that).

ALL scripts use the API, be it Mapping Assistant or your own script with API functions. It is just nowhere documented, how we can use the XML´s with our own scripts, but i am so sure, that this is possible. The easiest way to test this, is what i described above.

It is neither fish, nor flesh, nor good red herring. It is not really a mess, but it is a huge disappointment.

Which one? I dont see any… except FEEDBACK. In all other cases, the Mapping Assistant is superior.

It really is. I can only agree to this.

I feel with that too. :frowning:

Very much needed :wink: . We would not cry for years on this one.

I personally $hit on Quick Controls. Really. It is not more then a nice gimmick.
In no way are eight controllers enough, to make a VST instrument or FX feel like a real world device. If you really want to “create” NEW patches, you would still need excessive use with a stupid mouse and observe the screen.

Seriously, how can be eight controllers enough for that patch creating? They simply cant.
Thats just two Envelopes or a LFO and Filters or just Volume and some browsing etc.

Quick Controls help only those people, that have trillions presets and want some easy function, to control some essential functions, that they think is enough (IT IS NOT and we are telling this for years and years).
But myself want a control that is similar to a real world device and i have that already, just not with Cubase alone, which is the shame.

Then we need to find a way to push for it, cause I can guarantee it’s not on their list of priorities to entertain these deeper elements, as the way the remote is bolted on, it’s too much work with no increase in sales to justify it.

Whether that is via gaining access to those lists of parameter/plugin ID’s as the .xml files use I don’t know. But those who want such features, need to define what we want, and push hard for it, before it’s left to rot.

Right now, I think the only way will be to create pages and pages of hard mappings to the insert slot via the “selected track” mapping assistant binds. But no-one wants to manually swap pages to match the plugin their using - it’s pathetic expectation.

If we could get to the source of where the .xml gathers it’s parameter ID’s we could create something more dynamic in the API that detects the currently focused plugin and generates the pages required.

Or extend focused controls to use the already existing Mackie-style mappings and give us paging or more than 8 controls.

Tired of trying to do someone’s thinking for them though really, easier to just move to Studio One or REAPER where this is already achievable. …Which gets me back to wondering if these deep integrations are wholly worth it musically, or just a hobby in itself. :frowning:

I dont think the XML is gathering the parameter ID from somewhere. Each plugIn has a unique classID (in bold below). Each classID has a folder named exactly the same and in this folder are the XML´s, where you can find the ID table.

The following would be a example line from a Mapping Assistant script, that does the bypass for the whole EQ (which we dont have with API functions)

“members”:{“ObjectBasePath”:“VST Mixer\Channels\Instrument 2”,
“ObjectSubPath”:“Strips\Slot 3\297BA567D83144E1AE921DEF07B41156-4”,

The most important part, is the ValueTag. The last two digits tell us, which ID is to use from the XML and you always subtract -1 from the ValueTag (or keep that in mind). Sadly i dont know what the first two digits from ValueTag do.

Because it is the bypass for the whole EQ, you will find the XML only here:
C:\ProgramData\VST XMLs\Steinberg Media Technologies\EQ\297BA567D83144E1AE921DEF07B41156

If you open the XML, you will see:

<!-- ID=3 	-> Bypass (1) (Switch) -->

That’s only items that have been setup for devices like the Nuage, and MCU etc. via the remote editor, isn’t it?

What happens if you map a third party plugin via the mapping assistant - does it automatically create a folder and populate all the parameters within an .xml? I’ve not tried it to be honest.

I still think the API should be capable of reading the raw parameters based on the focused plugin without relying on pre-processed .xml files though. But that’s certainly an option if they’re already going down that route.

If we had the option of binding to those classid and parameter id’s via the API, the .xml should be easily parseable into an array.

Trouble is, there’s no way of unbinding, so you’re still stuck with a huge page number that grows with each plugin.

So annoying that you could do all this and have pages of parameters with the existing MCU implementation - which they’re phasing out! Arrgghhhh!! :scream:

Yes that is true, but thats what the mapping assistant is using and what the script (global mappings) will reference too. The “ObjectSubPath”: is pointing to that folder/class id.

I did not try it neither, but my biggest guess would be, they are inside of the .dll files.
Would need to test 3rd party stuff.

If they really do this, i will either stick with Cubase 11 or 12 (if once stable) or leave Steinberg entirely.
Mind you, that even with MCU implementation, you have to scroll through a long list, until you decide what VST to use.