Midiremote API and NRPN

Hi all, I’m writing a midiremote script for an Allen & Heath GLD80 mixing desk. The faders use NRPN messages so I’m using the bindToControlChange14BitNRPN(midiChannelNumber,ccNumber) method for midibinding.

But Cubase is not picking up the messages which are of the format Bn, 63, CH - Bn, 62, 17 - Bn, 06, LV where n is midi channel, CH is mixer channel on surface, 17 is the CC# the mixer uses for faders and LV is the fader value.

Has anyone had success using bindToControlNRPN? Alternatively as this 3 part message is made up of standard CC messages (controller 62, 63 then a data message 06) is it possible to use bindToControlChange for 3 different CC# on the same surface object?

Hello, could you please tell us the Cubase version and your OS?

Running Cubase 13.0.20 build 148 on Apple Silicon

I see. Please check my answer to a relevant thread:

Thanks @m.c so probable bug in 13.0.20 not seeing / interpreting NRPN input. Included Cubase midi monitor and third party midi monitor screenshot for reference.

As a workaround I wonder if there is there any way to set up a callback to look at all input midi messages - perhaps I could put some logic in to pick out the NRPN myself?

Unfortunately no, since the messages seem to be filtered out before even going to the MIDI Remote implementation. For now, your best bet would be to either change the messages sent by the controller (if it supports this) or send the NRPN to a translator first and change them to CCs. But… Let’s wait for a while, perhaps there will be more info on this by Steinberg.

1 Like

Hmmm, to debug a little I set the wrong midi channel in bindToControlChangeNRPN and midi monitor now shows the input received from the device fader and this is showing the first two parts of the 3 byte message but not the third. The third party monitor shows three parts still so somewhere Cubase is discarding the third (fader level value) byte.

Screenshot 2024-03-16 at 13.02.46

Indeed, I see the 98-99 messages arriving now…

In your own monitor however, I don’t see the fine coarse message either, but this is another story.

By the way, why are you assigning the 0x17? In your monitor I see 0x27 msb, 0x17 lsb, thus 5015 dec.

The 0x27 is the mixing desk fader channel select so the fader value is in fact only one byte - hmmm, maybe this is where Cubase is expecting to see a 14bit fader value in the msb/lsb rather than channel / value split across them. Spec section attached…

OK, so based on the specs, we have for the faders:

image

This means that our Inputs start from 0x20 and this is why I saw the 0x27, cool!

fader.mSurfaceValue.mMidiBinding
    .setInputPort(midiInput)
    .bindToControlChange14BitNRPN(0,128*ChannelNumber+23) //23=0x17

The MSB of the value is sent using parameter 6. From what I see here, even in Cubase 12 MIDI Remote. the whole message is not recognized, exactly because the LSB (fine) parameter (38) is not sent. Now, this parameter is optional, but I guess that upon implementing the MIDI Remote there were reasons to avoid seeking for just an MSB. Perhaps, this needs a clarification. BUT, either way, in CB13 I don’t even see the MSB arriving!

As a side note, I see in the manual of this console, that it has fader strips. Maybe you should try this option? Because I see that simple 7-bit CCs are sent this way.

Thanks @m.c . Yes, there is a feature on the desk to assign faders to midi messages which are in fact, to some extent, configurable. However, the catch is that the scribble strips for these midi channels are not addressable. I’m writing the script to use the standard input channels since these do have Sysex support to update them and there are plenty of them. I can control the mixer from Cubase and if I can just get Cubase to respond to the manual fader moves it will be better integration.

Sure, I totally understand that.

Well, If I were in this position and in a hurry, I would look for external MIDI translator apps, converting these NRPN to standard CCs, but yeah, this is just a workaround…

Are you really sure the console is sending MIDI messages if you change a parameter?

I‘m pretty sure this is a bug - see my post here

Yes, I’ve monitored these coming in on a third party midi monitor and look exactly as described in the specification and also (when not binding with bindToControlChange14BitNRPN) on the Cubase midi monitor showing the first two bytes. Three byte messages are sent continuously as the fader is moved but Cubase only sees first two bytes and presumably discards the message.

Yes, helpful post, I read it thanks. My sense is based on what @m.c said and looking at the midi specification is that the Cubase interpretation of NRPN is two byte Msg 99 MSB, Msg 98 LSB only and to use the two messages to construct a 14 bit value. Allen & Heath have chosen to include a third 06 Data Entry (Course) message and encode mixer channel, fader select and 8 bit faderValue across the three messages. It would be cool if there was a callback to be able to provide custom interpretations of NRPN messages given they are open to wide industry interpretation and implementation as this will open up a huge range of Allen & Heath digital console integrations so hopeful something like this can be done.

The MIDI faders are available on QU, SQ, Avantis and dLive.
So the intended way to remote control a DAW with an A&H console is already possible.

Yes, but limited in that you can’t address the scribble strips as you can with other channel types. The dedicated midi strips are useful to control other mixers, lighting rigs etc where there is no need to update the scribble strips (done manually on connected device) - for a DAW integration you really need scribble strips to be updated.

TBH, these are live sound consoles. Not DAW controllers in the first place.

Is that really relevant to the topic at hand?