a little study of incoming MIDI data

[adeptio]

My previous post was about installing a VST MIDI monitor tool on the Receptor.
I felt I needed it, because some plugins just continue to confuse me regarding MIDI implementation. That combined with the Receptor implementations of plugins and Receptor build in MIDI mapping, can often be a challenging walk in the dark. Here is the link to the MIDI monitor tool.

http://www.rs-met.com/freebies.html

So, let's see what we can quickly learn with this tool:

Let's pick a good plugin, the VB3 from our Italian friend Guido
http://www.genuinesoundware.com/?a=showproduct&b=24

It's a B3-organ with many control features and three separate "tonewheels" tone-generators that each listens to different MIDI channels. In order for you to assign three different keyboard manuals for each "instrument" (upper, lower and pedals). So to make it work, you have to setup the MIDI mapping in Receptor channels like this for the VB3:
Listen to MIDI channels "ALL"
Play plug MIDI Channel "THRU"

Set the MIDI monitor tool to do exactly the same on its Receptor channel.

For reference here, look up Receptor Manual chapter 17 and release notes 1.7 page 28.

Lets turn OFF Receptor SETUP parameter "route midi CC to source plugin".
The "common sense" understanding of this setting should be:

"Receptor will not send any of the incoming MIDI CC to the plugin". And
"you need to use the NRPN instead of CC from your controller to control the plugin"

WRONG!

Here is the list of the 17 CC commands that IS still routed to the plugin EVEN if non of the plugin parameters are "assigned" to the first 16 "front panel parameters" (page 112-115, 193 in manual) :
CC # 1,2,3,4,33,34,35,36,37,64,65,66,67,68,69,70,71

So, watch out! You think you have a setup that filters away MIDI CC to the plugin, but all the "standard" controllers like MOD Wheel, Pedals etc are still passed through.

And if you in addition assign some of the plugin parameters to CC 16-31 (course) and CC 48-63 (fine) as explained in page 193, the phrase 'turn OFF Receptor SETUP parameter "route midi CC to source plugin" ' makes no sense anymore. Because in theory it can and will still send 17 + 32 = 49 CC parameters to the plugin!

I think the VB3 is a typical example that MAY be confused by such implementation. Because you can actually control the same parameter by EITHER Midi CC OR NPRN from your controller. E.g you have setup the B-5/1/3" organ drawbar in the VB3 to CC 33 (default in VB3). A CC 33 according to the above "discovery" will obviously go directly from your midi controller to the plugin (but not CC32 and below). BUT - if you have accidently assigned a "midi learn" in the VST Learn Mode - e.g. CC 16 to the same parameter, then both CC 33 and 16 will control the same drawbar! In addition this drawbar is ALSO controlled by NPRN lsb-15 (which you cannot change because this is done automatically by Receptor). While the "route midi CC to plugin" is TURNED OFF!

So, if you use the graphical "faceless mode" to edit the plugin parameters, these CC will change parameters which are ONLY visible in the "VST mode" displaying the plugin graphics. However not visible looking in the "faceless mode" parameters sliders (page 111). Because the sliders in the Faceless Mode will only react upon NRPN and not CC when the "route midi to CC" is turned off! (You hear but don't see the change).

Try this with the VB3 and see how easy it is to get totally confused. Luckily this plugin allows for easy CC assignment "midi-learn" for every parameter.

But if you want to CC control the Receptor's mixer as explained in chapter 15, you can only do this by CC and not NPRN. Too bad, because then CC could be reserved for editing the plugin. Muse Research: Can you pls change this? I want to be able to use CC for the plugin and NPRN for the Receptor Mixer, NOT the other way around. This feature would be so easy to implement!

To control the mixer you must turn OFF Receptor SETUP parameter "route midi CC to source plugin". So the CC is sent to the Receptor Mixer and not the plugin (except for the ones mentioned above)


Hope I did not get all of you confused.

[looneytunes]

Hello Eystein,

This is a very interesting study -- Thank you for doing it. After 3 times reading thru this post, I'm still trying to grasp all of the implications of what you have found. I hope someone at Muse can comment on the internals, because I think this conversation is healthy, and brings some transparency to the implementation. If there is some behavior that purely looks like a bug (not just an idiosyncratic design decision), I would recommend filing a bug through the normal Muse Research support channels.

In any case - thanks again for sharing your findings!

Regards,
Kevin L

[adeptio]

Hi Kevin,
yes, it's only a little study. And it might be me that is not grasping all of the the possibilities. I did not intend to report a bug. There might be good reasons to let the *standard* modulation CC pass through the filter which is supposed to stop them. These CCs are by far the most used ones. But it just doesn't match a feature that implies that non of the CCs will be passed to the plugin! I mean, there is room for a help feature in Receptor GUI that could explain things like this better, e.g. pointing out that some CC will indeed be passed on. (I miss a little help pop up window that can be activated by a link in the GUI)

I have to say we all should understand the reason why the Receptor midi/plugin implementation must use NPRN for the plugin control. I mean, there are literally thousands of control possibilities that cannot be solved by Midi CC alone.

The way Receptor automatically maps up an NPRN for all available control parameters for every VST is pure genious.

example: try to use CC directly to control all parameters in Ivory without this feature. Impossible. If you lookup up Ivory manual, there is no midi mapping of all its parameters. Synthogy did not even intend people to control them remotedly. Receptor nevertheless has a beautiful fix for lazy manufactureres of plugins that doesn't care about midi control. Except maybe for notes and pedal (and maybe volume, that's it)

Controlling the Receptor mixer is very much wanted live. But then you are forced to use midi CC, and you no longer can pass all the CC to plugins, just a few ones that might not fit your controller and purpose.

Or is t me that have missed something? Because if the mixer could have its own set of NPRN freenig up CC, we have a solution.

//Eystein

[gregh1]

Just wanted to add a "thank you" to adeptio for the research. We can all benefit from this!