Midiremote API and NRPN

IMHO these live consoles have the potential to make fabulous DAW controllers and the second hand market for them (e.g. GLD / QU) puts a 20 channel surface in the same ballpark cost, or lower, than the cost of many 8 fader DAW controllers. I’ve used A&H desks for years in live sound engineering so looking at how to bring the same intuitive UI and flexibility to the studio with a decently large channel count at lower cost after being somewhat disappointed with the range of 8 nd 16 fader DAW surfaces on the market.

Here’s an interesting explanation of NRPN for those interested, it seems the three and four byte NRPN implementations are not as uncommon as I first thought but so far it looks like the way each byte’s data segment is used is widely open to manufacturer interpretation (as expected in Non Registered…)

1 Like

Thanks - and for sharing the article re NRPN. For me the issue is that it was working in 12 but isn’t in 13 on Mac, although seems to be on Windows. Hopefully someone from Steinberg will clarify their intentions.

1 Like

Thanks @m.c for your help earlier, I’ve done some midi translatiion using Bome as an interim work around and the faders, scribblestrips and mutes are all working with 20 physical faders across 2 layers giving me 40 channels in Cubase. Did hit one issue though, where my pan knobs seem to be controlling fader channels. I’ve bound the faders and pans as follows but suspect I’ve misunderstood how the params are used by Cubase (i.e. how the second param to .bindToControlChange() is mapped as a CC to Cubase faders and pans):

IMG_4948

From what I can understand you have some overlap between the faders and knobs MIDI CCs. I see you’re setting up your faders starting from MIDI CC 32 (0x20), and your knobs from 48 (0x30). This means that if you have, say, 24 channels, I would expect the CCs for knobs to start from an upper point, for example, 56. But since all this is done using remapping, I would suggest that you check the rules you’ve placed for knobs inside BMT.

Thanks, checked this and it’s definitely happening in my midi remote code. Is there a reference that states the specific CC numbers that each of Cubase’s controls (fader, pan, etc) map to?

My fader bind works fine on its own and the pan bind does connect to the right pan in Cubase (found by trial and error) but since that pan cc number is also generated by my faders (ch 16 onwards) the fader bind is picking up the pan message as well.

I’ve obviously not got the right cc numbers to avoid overlap between the faders and pans.

Then please share the code either here or by private message and I will surely have a look :slight_smile:
At the same time, I’d like to have a look at your BMT template.

thanks @m.c will do…

Thanks @m.c and forum for your help with this, I’m indebted.

The console works brilliantly and my workflow in Cubase is massively improved. My next job then is to replace the BMT app with a dedicated Swift code Mac app that does the midi translations I need and also look at an integration between the Cubase Control Room and the desk signal routing (also midi controlled) for my monitors and maybe some quick controls and 31 band graphic EQ mapped to faders on a spare layer.

I do think a better native handling of NRPN would be great to have on the Steinberg backlog as a lot of gear uses this message type.

1 Like

I 100% agree and I’m sure this will eventually be addressed.