[LAD] [LAU] Ardour MIDI tracer

[Tim E. Real]

On August 15, 2014 05:24:51 PM Len Ovens wrote:
> On Fri, 15 Aug 2014, Paul Davis wrote:
> > On Wed, Aug 13, 2014 at 10:16 PM, Len Ovens <len at ovenwerks.net> wrote:
> >       Is it just me? Has anyone else looked at pitch bend events on the
> >       Ardour MIDI Tracer? Quick test:
> >       
> >       ================================================
> >        - edit->Preferences->Control surfaces.
> >        - select both enabled and feedback for generic MIDI.
> >        - double click on it and select bcf2000 with mackie protocol
> >        - open an external midi monitor (using qmidiroute here) and connect
> >       it to
> >               Ardours MIDI control out.
> >        - also open Ardours MIDI tracer window and connect it to the same
> >       output.
> >        (Now qmidiroute will be in decimal and MIDI Tracer is hex..)
> >        - use the mouse to move the gain up and down on channel one with an
> >       audio track.
> >       =================================================
> > 
> >  the trace shows MIDI messages. there are no 10 or 14 bit MIDI messages.
> > only "controllers" with 14 bit state. 14 bit state is sent as two
> > messages (when necessary). the tracer shows each individual message.
> 
> Pitch bend, which the mackie faders use, is specified in the MIDI standard
> and in the MCP spec as: Ex yy zz in one event. 

Correct. 
Pitch bend is the only truly 14-bit encapsulated message.
There is also one more, real time Song Position Pointer (F2, LSB, MSB).
I think it is 12-bit though.

One can use the pitch wheel for something other than pitch.
It is per-channel. You can have up to 16 14-bit pitch wheels 
 (or knobs/sliders/etc), per interface, each routed to whatever you want.

You would just have to reserve some channels, or even a whole interface.

Yay Mackie! And others doing this.

But do I wish MIDI had included at least one /more/ encapsulated 
 14-bit message per channel.

> WHere x = channel, yy = LSB
> (7 bits) and zz = MSB (7 bits). This is one event. This the way I send
> fader info to Ardour and It is also the way Ardour sends info back to me
> when I use a mouse to move a fader. Lets compare the output of the tracer
> with qmidiroute: (using fader5 as happens)
> 
> tracer			db	qmidiroute			midi
> ===========================================================================
> Pitch Bend chn  5 1a	-0.5	Ch  5, Pitch  4378 (111a)	e4 1a 42
> crt/alt/mousewheel down
> Pitch Bend chn  5 09	-0.5	Ch  5, Pitch  4361 (1109)	e4 09 42
> Pitch Bend chn  5 79	-0.5	Ch  5, Pitch  4345 (10f9)	e4 79 41
> There is no second midi event with the msb, this info is missing.
> 
> I am well aware that controllers are 7 bits in an event. The MIDI standard
> does double up some of them for 14 bit, 

I think you are referring to what I will call 
"14-bit aggregate 7-bit controllers", as opposed to 
"14-bit (N)RPN controllers".

> but I am not aware of anyone who
> uses them.

In my searches for products/software that use them I have seen a few. 
Good to plan for it anyway. I think ALSA can use it too - I think it is one 
 of the event types. 

> 
> Speaking of which... I was looking at the MIDI codes for some more upscale
> Control surfaces:
> Allen & Heath iLive control surfaces
> Yamaha CL series mixers
> 
> Both of these use NRPN (Non-Registered Parameter Number) for some of their
> messages. The A&H uses this because they have run out of controllers (I
> would guess) and still only get 7 bits for their faders. They use three
> events, the first one has the mixer channel (as well as the midi channel),
> the second has a code for what in the channel it controls (0x17 for fader)
> and the third is the data. 

Wow, so they just ate up 16,384 available 7-bit NRPN controllers.
That's an entire interface full.

Any 14-bit controllers at all on these AH models?

If so, do they have detailed info on exactly how it is sent, and options?
If not, do you have a way of reading what comes out of them (and when)?
NOT with ALSA sequencer or any of the 'snooper' apps I've seen. 
It must be either a true UART HW project or a low-level API for reading 
 the MIDI data. 

Does anyone out there know of a *true* sniffer application that handles 
 all 7-bit and 14-bit controller types and displays them conveniently 
 and correctly?

> Yamaha uses four events, the first two carrying
> the controller number (they have not bothered to group them the way A&H
> has) and the last two are MSB and then LSB. The wiki for NRPN says the
> controller number for the first two bytes should be 0x63 and 0x62,
> however, Yamaha has these listed backwards. As there are other typos in
> the same page, this may just be a typo too.

These are 14-bit NRPN controllers.

> I do not know if the Ardour midimap binding msg="byte byte byte" would
> handle this or not. I know Jack would consider this 4 events and probably
> not accept just the first status byte with 8 running status data bytes
> following as a single event.

I think Jack does not care. It simply passes on whatever bytes it receives.

This is a blessing for me actually. I have to make my own encoder/decoder 
 (this converts raw 7-bit midi to/from MusE controllers) but at least 
 *I* control what goes on inside there.


(I'd like to take this opportunity for a bit of an update):

It's been a year since I reported how I was attempting to finish adding true, 
 full 14-bit midi controller support to MusE (that's 7-bit controllers, 
 14-bit aggregate 7-bit controllers, 7 bit RPN and NRPN controllers, and
 14-bit RPN and NRPN controllers).

I said I found that ALSA sequencer API doesn't handle 7-bit RPN.
And wouldn'tcha know it, my keyboard sends only 7-bit.

As I say, it means I have to make my own encoder/decoder.
I think possibly the ALSA RAW API is what I want. 
But MusE uses the ALSA sequencer API, big job to switch to RAW.

Fortunately MusE also uses Jack Midi.
I said that I /could/ have taken Jack's raw midi data and fed it 
 to/from an ALSA encoder/decoder - but again, no 7-bit RPN.

So it's /all/ home-brew for me! Workin' on C++ classes all these months. 
My efforts are moving along, but slowly.
I'm trying to make it a library 'cause it seems useful for other apps,
 but right now some of it very specific to MusE.

Trust me, robust controller support needs some fairly 'acrobatic' code, 
 and user options concerning formatting. Example:

I read where one company manufactured a whole line of
 small embedded midi board products.
Only to have a user point out that they didn't do 7-bit RPN
 conventionally (they used the LOWER 7 bits of data), but the 
 company owner said there was nothing he could do until 
 next designs and he actually argued vigorously that his way
 was correct (well, he is right but the almost universal convention
 is the other way - the UPPER 7 bits).

See what I mean?
I scoured the 'net for product docs and found wide variations in 
 implementations, even though they are all 'correct'.

Cheers. Greetings Len.
Tim.