Custom MIDI-NRPN Mapping for every DAW-Action

[Smokehead]

Hi,

i'd like to see a freely assignable/configurable MIDI-NRPN messages for every event/action in Reaper including options on plugin-parameters like ReaEQ changes.

It would be really nice to have a functionality like this if you want to sync your DAW with an digital mixing console and/or multiple controllers with custom MIDI-protocols.

I'm thinking of syncing for example an Allen & Heath QU-Series digital mixer with Reaper. The Allen & Heath protocol is based on MIDI-NRPNs for each console-action. It would be nice if Reaper would have some possibility to sync things like channel states, panning, (if enabled) compressor, peq, etc. in a specific setup without using the DAW-Control mode on the console which doesn't have eq or comp functionality. Maybe there would be a way to make the MIDI-Learn feature capable of MIDI-NRPN messages, even if the user would have to configure them manually.

Thanks for reading.

Cheers,

Smokehead

[azslow3]

"Generic" DM solution is too tricky to make build-in. That is csurf extensions task.

For A&H:
1) while they use NRPN for transferring the information, they use it tricky way (from 14bit value, 7bit is an extra parameter ID, in addition to 14bit address)
2) A&H mixers do not inform throw MIDI about currently visible on the device parameters (logical, there can be iPad(s) applications which control something different at the same time). That means for EQ/Comp syncing, ALL EQ/Comps should be always sync. That can be rather "heavy" for the DAW and the device, so requires special tuning for the update rates.
3) the picture of build-in effects will mismatch with the picture on the plug-in. F.e. while EQ frequency with a bit of luck can match, EQ Q/width/band type have little chance to be the same
4) in not DAW mode, using controls on Qu will influence the sound of DM. That means it is impossible to use it for live and DAW controlling at the same time.

So, can be done. But tricky, not generic and not without consequences (I have done that for Sonar with Qu, including EQs)

[Smokehead]

Actually i don't want to use it this way when using the console live. I want to use the QU as DAW-Control with extended features.

But yes i think it's hard for the QU-Series in example. But it would open new worlds for custom controllers. It could open new ways on custom build controllers with open-hardware/open-source designs as well as new ways for controlling reaper without the need of OSC (which is restricted as well).

I've started working on an Control-Panel for the QU-16 for PC (Linux first) which i'd like to work like the app. I'm just experimenting with MIDI via USB and MIDI via network (i'd like the USB-approach much more). If it works i would split the control- and receive-part as a shared library which can be used in other applications, maybe a QU-Series -> DAW translator.

If REAPER would allow custom configurable NRPN messages with variable/configurable length it would make the use of something like this simpler.

[azslow3]

Beringer has not published Xctl specification, but from my test it is just raw MIDI transfered throw the network pipe.
All parameters are in 0-127 range, the same for A&H.
I mean for what (N)RPN is good? Yes, it allows more parameters to be specified (CC is limited by 128x16), so some use NRPN other SysEx. Note that both are extremely slow in transfer (f.e. NRPN is 4 messages per parameter), when physical carrier is normal MIDI (~1ms pro message).

OSC has no limitations in this respect. Its design say nothing about syncing, but for controlling purpose that is normally not required (till someone try to use it for automated operations, there are such threads there).

The fastest approach is adopting OSCII-bot. Proper approach will be dedicated csurf (here proper value mapping can be implemented, to match particular DM FXes with particular VST FXes). But both is hard, long and not payed work... so no one has done it so far

[mschnell]

Originally Posted by azslow3

Beringer has not published Xctl specification, but from my test it is just raw MIDI transfered throw the network pipe.

Which X-Control ?

I have the "Compact" and same can be set to either of "native" and "MC" (Mackie) mode.

With native mode any controller can be assigned to an arbitrary CC message. But no high resolution / NRPN or SysEX.

In MC mode it uses the weired (non standard) Midi messages dictated by Mackie compatibility.

-Michael

[Steviebone]

I use ReaLearn to assign NRPN's to Reaper DAW actions. Works great. Not sure if this is what you are referring to...

[azslow3]

Originally Posted by mschnell

Which X-Control ?

At least big X-Touch (with displays) can control XAir mixers. That also works throw network, but it is not using OSC. In the Internet people mention the protocol as "Xctl".

The only interesting thing about it is display color support. It seems like that is not possible in any other X-Touch mode, but works fine with XCtl (I have tested remotely).

In MC mode it uses the weired (non standard) Midi messages dictzated by Mackie compatibility.
-Michael

I will say in MC mode it use standard Mackie messages. But unlike HUI, MCU has only 8 encoders. So they have fancy assignments for right encoders in MC mode.

For me, the weakest part of Compact is ignoring other layer messages and not informing the DAW when layers are switched.
I mean when A and B are used, LEDs/rungs/faders have to be manually resynced on every switch.

Also I have asked in forums several time, but I still have no answer. Are big X-Touch faders have high resolution? Compact version has low resolution faders (7 bit). Original MCU has 10bit resolution faders.

[mschnell]

Originally Posted by azslow3

At least big X-Touch (with displays) can control XAir mixers. That also works throw network, but it is not using OSC.

I doubt that this is true. I do have an XR18 and I control it by OSCIIBot via OSC over WLAN.

-Michael

[mschnell]

Originally Posted by azslow3

I mean when A and B are used, LEDs/rungs/faders have to be manually resynced on every switch.

Same mess with the "Compact": it does not send anything over Midi when the layer switches are pressed, and the inactive layer is not able to receive any midi messages . (in MC mode4 the layer switches are used for other purpose).

-Michael

[azslow3]

Originally Posted by mschnell

I doubt that this is true. I do have an XR18 and I control it by OSCIIBot via OSC over WLAN.
-Michael

I am not sure what exactly you doubt in my statement:
* the fact X-Touch can control XAir?
* that can work throw the network?
* that way is not using OSC?

For the first two: http://behringerwiki.music-group.com..._X-Touch_Setup

And for the last: XTouch is not an OSC controller

I repeat, my goal was to control the color of XTouch displays, so make them (more or less... they are not full RGB) match corresponding DAW strip color.
My tests was successful, I mean I was able to change these colors. But only when XTouch think it is connected to XAir, throw Ethernet or MIDI (no luck with USB).

[mschnell]

I doubt that way is not using OSC.

OSC is just a container for any kind of content. You always need an implementation card for a dedicated device. Same might be "Xctl".

Originally Posted by azslow3

And for the last: XTouch is not an OSC controller

AFAIU, if it can control an XAir directly via a network (no USB/Midi involved), it is.

-Michael

[azslow3]

I do not want put direct link to RE protocol here...
Google for "XCtl Behringer" and download the first link (pdf).

So they use MIDI based communications between XAir and XTouch. When using the network, they just pack these messages into network packets "as is" (without wrapping into OSC or other containers).

It is common to have some "open" channel to control devices but have full functionality in some "closed/proprietary" channel in addition. Behringer (OSC/XCtl), A&H (MIDI/iPAD), Presonus (MIDI/something used by S1 with own interfaces), RME(MIDI/TouchOSC/own app).

PS. When I guess, I always write explicitly that is a guess/IMHO. My statements without such marks means I have personally checked that is true before...

[LugNut]

Hi,
Sorry to ask here...but how do I ignore a user?
Man.......

[azslow3]

Originally Posted by LugNut

Hi,
Sorry to ask here...but how do I ignore a user?
Man.......

"User CP" (in menu toward the top of the page)
"Edit ignore list"
Enter the nick (I guess my, so "azslow3" ) and click "Okay".

You will still see threads created by me, but there are not many...

[LugNut]

Hi,
Thank you azlow3!
And I love your posts. Always learn something.
And I know abit about various control surface protocols:-)
I have a guess on the resolution of faders on the big x touch. Even though I know you don't guess:-) .... If its fully MCU compatable then 10 bit at least. Same with the hui I believe.
BTW do you have the hui docs from TheAgeman?
Took me years to find them. He's a programmer who reverse engineered the whole deal. I mean deep:-) if you want them I'll dig em up.

[azslow3]

Originally Posted by LugNut

Hi,
Thank you azlow3!
And I love your posts. Always learn something.

Thanks.

I have a guess on the resolution of faders on the big x touch. Even though I know you don't guess:-) .... If its fully MCU compatable then 10 bit at least. Same with the hui I believe.

That is easy to check, just record one fader slow movement as MIDI and in the Event List check the smallest difference in the value. For 7bit it will be 128.

When X-Touch products was introduced, I have also guessed they use 10bits. But then I have checked Compact and it was 7bit.

BTW do you have the hui docs from TheAgeman?
Took me years to find them. He's a programmer who reverse engineered the whole deal. I mean deep:-)

I think everyone who implement HUI protocol use the same RE docs
In practice, when someone has the device (or any other MIDI device) recording the protocol is an easy job. Nothing really "deep" (in comparison with Firewire/USB RE people do to make Linux drivers).

[mschnell]

Originally Posted by azslow3

That is easy to check, just record one fader slow movement as MIDI and in the Event List check the smallest difference in the value. For 7bit it will be 128.

In "native" mode the Compact uses standard CC midi messages, hence it only can do 7 bit.

In MC mode, the protocol is not documented, but bound to use the weird MCU protocol. The MCU protocol defines non-standard midi messages to transfer more than 7 bit values.

Maybe, when using a Midi bus, those can be recoded and analyzed (I did not do so, as I intend to use the "native" mode with Geoff's CSI Reaper extension).

But here we were told that he uses a non-Midi network interface. So the data stream can't be recorded as Midi.

I (still) suppose OSCIIBot should be able to show them, as I doubt that the XAIR speaks anything but OSC.

-Michael

[LugNut]

Hi,

@azlow...I understand about the syntax in the hui spec itself not being deep, but he figured out the whole system...zones etc. The overall systematic approach taken by the original "authors".
I'll dig em up. It was extremely difficult to get the hui spec. Mackie nor digidesign was not forthcoming. Years it took me.:-)

Isn't the compact not MCU compatable? Actually I should say MCP comparable. Mackie Control Protocol. MCU actually stands for Mackie control universal because the hardware can do MCP, hui, and logic control protocols.

Sorry for the ot.

[azslow3]

With all respect Michael...

Originally Posted by mschnell

In MC mode, the protocol is not documented, but bound to use the weird MCU protocol. The MCU protocol defines non-standard midi messages to transfer more than 7 bit values.

It IS documented by Mackie: https://images.thomann.de/pics/prod/151261_manual.pdf (chapter 13 "MIDI implementation"). It is still the same for MCU Pro and all "Mackie compatible" units.
In short, messages are: http://www.azslow.com/files/mcu.png

The success of LC/MCP protocol comes from the fact it is well defined, use minimal length messages for all control and it does not break general MIDI rules (unlike f.e. HUI, which kind of fail on all 3 categories)

Faders are sending normal PitchBend MIDI messages on channels 1-9. You can switch your compact in MC mode, enable in REAPER and record touching/moving/turning all controls. Then check what they are sending in the Event View.

I (still) suppose OSCIIBot should be able to show them, as I doubt that the XAIR speaks anything but OSC.

Theoretically I can give you my test utility, which can stay between X-Touch (tested with Big only!) and XAIR, so you can see what they send to each other. But I have already gave you the link to the RE which describe the protocol (the utility just confirm it is working), so I doubt you stop doubting no matter what I write...

[azslow3]

Originally Posted by LugNut

Hi,
@azlow...I understand about the syntax in the hui spec itself not being deep, but he figured out the whole system...zones etc. The overall systematic approach taken by the original "authors".
I'll dig em up. It was extremely difficult to get the hui spec. Mackie nor digidesign was not forthcoming. Years it took me.:-)

As I have written before, if you stay "in between" (easy with MIDI), it is possible to see any communications. And they are simple, one message per control (sometimes extra "keep alive" and "handshake").

All Mackie units are dumb:
* each control always sends the same message(s), no "configurable hardware layouts" nor live switchable "banks" as in most controllers (targeting live manipulating synthes).
* the feedback (except displays, since they are not controls) is exactly the same messages the control sends (unlike f.e. Faderport)
* there is no local feedback, like LEDs under AKAI pads, which looks "nice" when you play it but tricky to steer correctly when the pad light should be synced with the DAW track mute...

Isn't the compact not MCU compatable? Actually I should say MCP comparable. Mackie Control Protocol. MCU actually stands for Mackie control universal because the hardware can do MCP, hui, and logic control protocols.

Compact follow MCP (as in links above) when in MC mode. Handshake is not (at least was not in firmware I tested) implemented (the same for Motör), unlike in the big X-Touch.

HUI use significantly different messages from MCP. What is the difference between MCP and LCP (Logic) I do not know.

[LugNut]

https://forum.cockos.com/showthread....found+the+HUIi,

I'm aware of the details in hui and MCP protocols. I took a hui speaking mixing console and used bomes midi translator pro to convert all messages bidirectionaly to/from MCP. Works great.

Above is a links to the hui docs....post 4 has a vital correction also.

@smoke head....sorry again for all the ot. Although bomes miditranslatorpro combined with ,say, klinkes csurf could do what you want. Also check out the control surface integration thread in the general forum.

Guido

Edit..for clarity
I no longer use the "strategy" indicated in the linked posts. It wasnt till After I found the hui docs that I really understood what I was seeing coming out the "hui".
With my latest bomes project its a 1:1 conversion. I also added multiple custom layers switchable from the board. Relatively straightforward using bomes.

[mschnell]

Originally Posted by azslow3

The success of LC/MCP protocol comes from the fact it is well defined, use minimal length messages for all control and it does not break general MIDI rules (unlike f.e. HUI, which kind of fail on all 3 categories)

The size/count of the messages is completely irrelevant when using Midi over USB.
The MCU protocol uses the Midi channel as an extension for the data bits. That breaks the ability to do a Midi bus. But supposedly in most cases this does not matter.

-Michael

[mschnell]

Originally Posted by azslow3

Theoretically I can give you my test utility, ...

We are just talking about wording, not about technology, so it's really not relevant.

OSC defines just a very thin layer within UD. You can package close to anything within OSC. The device needs to come with a description what it's dedicated "protocol within OSC" is supposed to look like (I do have this for XAir, and successfully implemented it using OSCIIbot).

-Michael

[mschnell]

Originally Posted by LugNut

Isn't the compact not MCU compatable?

Partly (when set in a dedicated mode), but it does not have scribble strips and features different numbers of controls than any other MCU "compatible" device. So compatibility is questionable.

-Michael