This is much more exciting than it seemed on a first look.
A fully scriptable JavaScript API for interacting with MIDI devices.
https://steinberg.help/cubase_ai/v12/en/cubase_nuendo/topics/midi_remote/midi_remote_c.html

The list of MIDI devices seem to common "dumb MIDI" controllers that do not also have a competitive product (that cares) about Cubase. I say this because I'm thinking lack of Native Instruments' dumb controller support is due to this as one example.

It was likely easier to fast-track dumb controllers to get an ecosystem started and nudge the various vendors to start submitting their own updates. Proper documentation means that any of us could, potentially, provide one too. Although possibly useful, it's not the kind of thing I'd want to distract the limited coding resources around in front of other tasks.

I've been a proponent of open-sourcing and/or enabling the community to extend the capabilities of software/hardware. This seems to fit that - so it's all good. I generally think enabling the community to code their own extensions is better for the product(s) than closing the doors. I guess we'll see who bites.

[quotePost id=114709]The list of MIDI devices seem to common "dumb MIDI" controllers that do not also have a competitive product (that cares) about Cubase. I say this because I'm thinking lack of Native Instruments' dumb controller support is due to this as one example.[/quotePost]
Those Novation controllers are marketed as being perfectly integrated with Ableton Live.

[quotePost id=114709]It was likely easier to fast-track dumb controllers to get an ecosystem started and nudge the various vendors to start submitting their own updates. Proper documentation means that any of us could, potentially, provide one too. Although possibly useful, it's not the kind of thing I'd want to distract the limited coding resources around in front of other tasks.

I've been a proponent of open-sourcing and/or enabling the community to extend the capabilities of software/hardware. This seems to fit that - so it's all good. I generally think enabling the community to code their own extensions is better for the product(s) than closing the doors. I guess we'll see who bites.
[/quotePost]
Agree with all that. And in the docs they stress that it's reasonably easy to create your own.

Still, if someone buys a MODX/Montage from today on, it's Cubase 12 (AI) that they'll get bundled. It would be nice to have some decent maps out of the box.
I do expect this to happen TBH and see those in a near future MODX Connect update.

Can't wait to find some time to test this.

There's now an official Steinberg GitHub repo for users to upload and collaborate on developing MIDI remote scripts:
https://github.com/steinbergmedia/midiremote-userscripts

Still waiting either for the upgrade to Cubase AI to show up, or for Nuendo 12 to launch (next month) so I can dive into this.

You will discover, if you have not already, that script files are incompatible with MODX CONNECT. And depending on your point of view in using synthesizers in music composition, script listings are totally out of step with what the Motion Control Synthesis Engine is introducing.

Of course, you can use whatever works for you and I wouldn’t try to change you.

But a script file (XML) is ideal for those using Single Part programs in the traditional GM-style multi-timbral workflow… where you are recalling individual instruments per MIDI Channel and are willing to accept them as programmed and stored on your script. It excels in recalling Preset Single Part sounds per each Track — and recalling them as configured at the time the script was created. As soon as you stray from the one instrument per Part, one Track paradigm of presets, a script file is less useful. I’ll resist saying ‘useless’, but leave it at ‘less useful’. As soon as you edit the selection, your script file is obsolete.

Your script listing is obsolete as soon as you load a new Bank of sounds… as soon as you have interactivity between Parts (Side Chaining, Morphing, Envelope Following, etc.) … as soon as you get into Multi Part instrument programs you start to realize that storing the upper Common functions of a MONTAGE/MODX Performance (which is essential for things like the Super Knob and the whole Assign Knob and Controller matrix) these are not handled by the script file, at all — which again served the GM-style workflow magnificently because the upper Common items were always pretty much the same, with little or no interaction between Parts, between Channels…

Your question, or rather surprise at MONTAGE and MODX not being supported is what prompted this reply. If you restrict yourself to just the Single Preset, Single User, and Single Library programs then having an old style script would be extremely useful… provided you didn’t seek to have them interact with each other.

But if morphing an acoustic piano to an electric piano, or morphing a string orchestra into a string trio or brass ensemble, or having your drum groove modify your pad sounds, or your rhythm guitar strokes gating a vocal pad, etc., etc., has any interest for you and your music, you can see how the old script listing really only saves you from typing the original program name in the DAW Track Inspector… and would really be insufficient to recall your MODX settings when next you opened the DAW project.

MODX CONNECT on the other hand, is more complete (holistic) in its approach to how it captures your Performance settings. It is like a *total recall* for your MODX for the entire project, compared to which single sound did I have on this single track.

With the massive size of User memory in the MONTAGE/MODX for customized sounds, a fixed, hard to update, listing of fixed programs, it seems like CONNECT serves the synthesizers better (imho).

If I want to use an electric piano — let’s say it is a Preset, single Part item, I use the script to recall it… but then I swap the “L,C,R Delay” Insertion Effects for the “Symphonic” Insertion Effect… how does the script file SAVE my little edit? Yikes, I need to STORE my newly edited sound as new Performance, and then create an entirely new script file or update my existing script, to include this newly edited and stored electric piano. And I’d need to do this for each and every project…
I guess it depends on how YOU like to work.

Scripts are ideal when recalling a sound from, for example, the GM program list…if I recall the E.Piano2 (DX type) - all edits to that fixed program selection must be typed into the event list using cc and Sysex messages. As you know, the MODX Performance will memorize all your edits and effects. When you recall your DAW Project, none of the custom stuff is recalled, the E.Piano2 is recalled exactly as it was when ‘scripted’.

Just fyi. MODX CONNECT captures every thing about the Performance you were using and restores it completely.

As to REMOTE CONTROL functions: on your MODX HOME screen:
Tap “REMOTE” > “Settings”
Select “Cubase” as your DAW
Set Cubase Remote using “Mackie Control” protocol via MODX-2 (Port 2)

See the MODX Supplementary Manual page 18-20 for details.

[quotePost id=115229]Just fyi. MODX CONNECT captures every thing about the Performance you were using and restores it completely.[/quotePost]
I know that and I use MODX Connect all the time. Love it.

I think however that there is a confusion and we're talking about completely different things.

[quotePost id=115229]As to REMOTE CONTROL functions: on your MODX HOME screen:
Tap “REMOTE” > “Settings”
Select “Cubase” as your DAW
Set Cubase Remote using “Mackie Control” protocol via MODX-2 (Port 2)[/quotePost]
I started this thread to discuss the NEW remote control API in the NEW Cubase 12, which is replacing the previous Generic Remote / Mackie pipeline inside Cubase / Nuendo.

Your reply seem to confirm what I thought, that unfortunately there is no communication between Steinberg and Yamaha in regards to this.

The new Remote API uses JavaScript scripts to manage the DAW Remote process. You won't use Mackie ("Track Mode") on the MODX anymore, but rather the "Plugin Mode" and interpret the MIDI data with the JavaScript API.

Someone who bought a MODX/Montage today would expect that when they activate their Cubase AI 12, there would be some included scripts so their new board can do DAW Remote control properly.

I posted two suggestions on IdeaScale in regards to this: one to have the necessary scripts in the next MODX Connect version, the other to have some updated features in the next MODX / Montage OS in order to have better integration with the API in Cubase.
https://yamahasynth.ideascale.com/c/idea/286111
https://yamahasynth.ideascale.com/c/idea/286114

To me, this looks like a desperate attempt by Cubase to stay relevant in a world in which Ableton Live is so ubiquitous that it's driving 3rd party hardware creation.

I explored a bit, since the Cubase AI 12 update showed up in my inbox.
It's clear that an OS update is required to be able to use the new functionality easily.

Right now, when one is in Track mode, communication with the DAW is done via Port 2, separate from Port 1 which is used for all music-related functions.

All the Transport functions are done thru the Mackie control protocol which uses some special kind of messages (for example, the Faders transmit PitchBend, I guess for resolution reasons and the Transport buttons are mostly Note On/Off events).

The MIDI Remote API needs CCs, and those are sent when we switch to Plugin mode.

However:
The Transport features (Transport buttons, Cursor, Data Dial) are still transmitting on Port 2 via Mackie.
Only the Faders, Knobs, Scene buttons, AS and MS buttons are CCs and they go thru Port 1 (!)
And, incidentally, the default CC numbers assigned to those are overlapping with the CC numbers transmitted by the MODX's Assignable Knobs when a Part is selected.

In short, this means that if one assigns a Cubase feature to CC18 for example, the MIDI Remote API will intercept it even if MODX is not in Remote mode and the user is adjusting some parameter in the current Part/Performance.

It also means that for Transport functions we still need to use Mackie.

So a future OS version would need to:

• have the CCs in Plugin Mode sent via Port 2, so the MIDI Remote API should listen to Port 2 and not to Port 1 where the music making is happening
• have the transport controls also send CCs so those can be integrated in the MIDI Remote API.