MIDI-REMOTE API changes v12.0.50

HI,

Version 12.0.50 is just out and i noticed lot of changes in the midi_remote_api_v1.d.ts file though there’s no mention of it in the patch notes from Steinberg.

So i’ll list new function here: will test them later.

It seems that full control over inserts and channel strip have been implemented. It looks promising.

But I didn’t see any sign of touch sensitive controls.


/**
 * @class MR_HostPluginParameterBankZoneAction
 * @augments MR_HostAction
 */

/**
 * @class MR_HostInsertEffectViewerAction
 * @augments MR_HostAction
 */

/**
 * @callback OnActivateMappingPage
 * @param {MR_ActiveDevice} activeDevice
 * @param {MR_ActiveMapping} activeMapping

/**
 * @callback OnDeactivateMappingPage
 * @param {MR_ActiveDevice} activeDevice
 * @param {MR_ActiveMapping} activeMapping

/**
 * @class MR_HostObjectUndefined
 * @augments MR_HostObject
 */

/**
 * @class MR_HostPluginParameterBankZone
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotFolder
 * @augments MR_HostObject
 */

/**
 * @class MR_HostInstrumentPluginSlot
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotGate
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotCompressor
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotLimiter
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotSaturator
 * @augments MR_HostObject
 */

/**
 * @class MR_HostStripEffectSlotTools
 * @augments MR_HostObject
 */

/**
 * @class MR_HostInsertEffectViewer
 * @augments MR_HostObject
 */

/**
 * @class MR_HostInsertAndStripEffects
 * @augments MR_HostObject
 */

Also callback MonProcessValueChange takes one more parameter called “diff”

MR_FactoryMappingPage has a new method “.mCustom”

MR_HostTransport has a new method “mTimeDisplay” and 2 new callbacks functions “mOnTitleChange” and mOnColorChange"

MR_QuickControls have 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_FocusQuickControls have 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_SendSlotFolder have 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_ControlRoomCueSendSlotFolder have 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_MixerBankChannel have 2 new methods “mInsertAndStripEffects” and “mInstrumentPluginSlot” and 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_SelectedTrackChannel have 2 new methods “mInsertAndStripEffects” and “mInstrumentPluginSlot” and 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_HostMouseCursor have 2 new callbacks “mOntitleChange” and “mOnColorChange”

MR_HostControlRoomChannelMain have 2 new callbacks “mOntitleChange” and “mOnColorChange”

Basically a lot of functions have those 2 callbacks added

MR_HostValue has “Increment” and “Decrement” methods added as well as child classes

MR_CommandBinding has new method “makeRepeating”
Not Implemented according to @Jochen_Trappe

MR_ActionBinding has new method “makeRepeating”
Not Implemented according to @Jochen_Trappe

MR_SubPage callbacks “mOnActivate” and “mOnDeactivate” take one more argument

MR_DeviceDetectionUnit method “detectSingleOutput” has been removed

3 Likes

Sorry, these are not implemented. they accidently slipped into the API-def. My fault :triumph:

2 Likes

Ahah! :smile:

Good to know, and thanks for your feedback!

Do you have any hint on how to bind to plug-ins and strips parameters? I didn’t spend much time yet but was unable to find the right syntax for these.

All MixerChannel-like HostObjects now have a new subsection called “InsertAndStripEffects”. There you have the “InsertEffectViewer” which is similar to the Focus Quick Controls, as it automatically focuses on selected plugin windows (if they are part of the same track/mixer channel). And additionally all ChannelStrip-Effects do have a representation inside “InsertAndStripEffects” as well. They all follow the Parameter-Bank concept to be able to access ALL plugin parameters. And they follow your custom parameter lists if working with the “Remote Control Editor”.

3 Likes

Ok, i think i found the right syntax (I was missing an empty parenthesis at the end of the line)


pageHolder.mainPage.makeValueBinding(fader8.mSurfaceValue, pageHolder.mainPage.mHostAccess.mTrackSelection.mMixerChannel.mInsertAndStripEffects.mStripEffects.mCompressor.mParameterBankZone.makeParameterValue())

And it works!

Thanks @Jochen_Trappe

Now… Can we have the same thing for the MultiPanner? :innocent:

Anyway, thumbs up and keep on with the good work! This is definitely the right direction.

Thomas

2 Likes

@thomas_martin
Your Topic is related to my post - I cannot get Nuendo to Open JavaScript - any guidance there would be appreciated. It has a code filter for
*.midiremote not *.js files.
Thanks

When having multiple plug-in windows open, on the same track, is there a way to have the plug-in window receiving the parameters come to front? Or is this irrelevant to the MIDI Remote?

Hi @ggmanestraki, it should be (re)focusing to the latest plugin window in front (if part of the same track/channel).

1 Like

Is there any documentation on commandbinding?

You do an action that is sending one argument. But how does the argument apply? For some commands some internal state is changed. Can this be read or reset to an absolute value?

Command bindings are one way messages, so the MIDI Remote doesn’t know if the state is changed to one thing or the other.
It’s basically the exact same as doing a key stroke, in terms of data flow.

I would personally love to see that we could have more control and not just toggle commands, especially for automation stuff in Nuendo and for the various panels that can be opened and closed.

1 Like

So the argument sent is not used at all? It is not like “0” is release and !0 is press?
The command it self have different behaviour when bound to key-press so it is non trivial to know that in the driver.

And it is very much needed to be bi-directional if cubendo are ever going to be compatible with midi-2.0.

You can only read the states of value bindings (makeValueBinding), command bindings are basically just key presses, and action bindings do carry a sent value, but cannot be read. (I think I have that right) :slight_smile:

So check if there’s a value bind you can use instead. (Check out the included readme via the scripting tools menu)

MIDI Remote isn’t finished, so it’s probably worth you showing some examples of what states you’d like to read and hope they’re added as value bindings. The pessimist in me thinks this is going to take years to evolve, and I’d scrub out all hopes of embracing the full extent of MIDI 2.0 implementation.

It seems to me that I can not control if I press or release the key, nor can I read if it pressed or not. It just toggle what ever it was.

I seriously dont understand, why we need to take care about (button) states and need to build state-machines. Why the hack, Cubase cant do the same like it does for MCU?
If you have a Mackie device enabled in Cubase, Cubase will send out all the states at LAUNCH of Cubase (no project loaded) and sends out updated states, once a project is loaded.
These states problem is so dumb and annoying. Even simple lamps on hardware, can become a real problem. Also states need a lot of code, for something that should not be a problem at all.

Exactly. Dumb, i know. The easiest way, would be to use the MCU states that are send out by Cubase at start, like i said before. But for this to work, you would need a enabled Mackie device in the Studio setup, which we dont want.

MCU does not have the state I need to know. It does not know about shuttle speed nor if constraint delay compensation is on or off. It is a generic problem and should have generic solution. Other people have other needs.

What i tried to say is, Cubase should follow the same principle, like it did for MCU. In our case, it should send ALL possible states once to the API at launch of Cubase and problem would be solved.

My thought is that the MIDI Remote is just a bolt on top of the generic remote with some added extras like the graphical interface and focused quick controls. And they’re now having to backtrack to add MCU style controls in.

Because of this approach, It was a flawed project from the start, and should’ve been a complete rewrite on how objects and plugins parameters can be read and controlled and that includes the modulation of VST parameters vs using the ridiculous method of mapping a MIDI insert and mapping to a plugin via MIDI CC values.

I’d imagine it was approached from the concept of adding a graphic interface to the generic remotes and grew from that initial idea. Hence why we’re at this point.

I mean, it’s a hell of a lot better for a lot of tasks, but it’s clearly a mess under the hood and my biggest fear is how long focus remains on improving it. Just seems like something that is going to age dreadfully as it’s just not a clean implementation.

Sending the state at one point wont work. You have different channels that can change the state. So it will need to be update when that happen. But at least all states that have GUI component in mixer or project view should have that functionality.

Why? It is not just “one point”, it is at LAUNCH. To my understanding that would be enough.