Hi there again 
,
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 :
atmHostAccess.mTrackSelection.mMixerChannel.mChannelEQ.mBand1.mOn
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.
Ron
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:
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! 
Perhaps I need to try switching off the procrastinator in me and just getting on with things, and Steinberg knows best. haha.
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 
) 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. 
Very much needed 
. 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.
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)
{âidâ:28,âtypeâ:âUserFocusHostObjectâ,
âmembersâ:{âObjectBasePathâ:âVST Mixer\Channels\Instrument 2â,
âObjectSubPathâ:âStrips\Slot 3\297BA567D83144E1AE921DEF07B41156-4â,
âObjectClassIDâ:âEQâ,
âValueTagâ:4204,
âIsValueTagQuickControlIndexâ:false,
âFocusTypeâ:âSelectedTrackâ,âValueâ:29}},
{âidâ:29,âtypeâ:âUserFocusHostValueâ},
{âidâ:30,âtypeâ:âValueBindingâ,âmembersâ:{âScopeâ:âGlobalâ,âSurfaceValueâ:68,âHostValueâ:29,
âTypeâ:âDefaultâ,âValueTakeOverModeâ:âJumpâ}
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!! 
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.