Re: [LAD] [LAU] Ardour MIDI tracer

On Sat, 16 Aug 2014, Tim E. Real wrote:

>> 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.

That is the limitation with the mackie standard. However, with midi over
ethernet, it is not that hard to send two midi ports... on the other hand
a standard that allows 40 faders or more where the fader number is one
byte would be advantageous.

> You would just have to reserve some channels, or even a whole interface.
>
> Yay Mackie! And others doing this.

That is the way my project is set up. (well the config file I am using
right now)

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

They could... we could probably fake it... after touch and program change
are the two odd events with only two bytes instead of three. Soft/firmware
probably has to look for them...

>> 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".

Yes, nrpn is actually a take off on them. It uses one of those pairs with
two othe data bytes in front
>
>> 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.

It is actually a double event and so should be passed as two events in
ALSA. I have seen one controller that sends them as five byte events
assuming running status. (9 byte for nrpn) However, in reading the
jackmidi docs "Clients must not write more than data_size bytes into this
buffer. Clients must write normalised MIDI data to the port - no running
status and no (1-byte) realtime messages interspersed with other messages
(realtime messages are fine when they occur on their own, like other
messages)."

I had thought this meant I could not stuff two events together like that.
But rereading it, I am thinking it means an "event" in jack is one status
byte followed by any number of data bytes. That would be fine for sending,
but what happens after that? does it get split into separate events in
jack? Does jack take separate events and remove status where possible?
Jack adds time to every event, so running status would only make sense for
two events with the same time stamp.

>> 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

> 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)?

The docs are here:
http://www.allen-heath.com/media/Qu-MIDI-Protocol-V1.5.pdf
http://www.allen-heath.com/media/iLive-MIDI-Protocol-V1.91.pdf
http://www.allen-heath.com/media/GLD-MIDI-and-TCPIP-Protocol-V1.4_2.pdf

The qu shows the nrpn as two values but the faders and other level
controls only use MSB, the only time LSB is used is for sub data... for
example the pan control uses this to set the channels routing to sub bus.
The iLive only sends three bytes for the same functions and the GLD does
the same.

A quick thought on fineness of control. It is true that 127 levels tends
to "zipper". However, 127 levels is more than enough for static levels.
Ardour (and I assume other DAWs) uses some kind of smoothing to avoid the
zipper with fast fader moves. I would expect that A&H would do the same.
That is, effectively build in a "slew rate". Think:
- fader has moved up
- start ramping level
- at 10 (or whatever) fine ticks check if new level reached
- either stop or continue ramping

Really, there are a lot of controllers out there that use CC (0 to 127)
for all their levels, so if a DAW wants not to have bug reports about
"that zipper noise", they will add smoothing anyway. The second benefit,
is that there would be less MIDI traffic. Not just with one byte less per
event, but also 127 less events per tick. My old "MIDI and SoundBook for
the Atari ST" talks about sequencers having trouble being swamped by pitch
control data and ways of dealing with it. I think that is why the original
MIDI spec only had one PB per channel. I would suggest it was found that
we can hear tuning differences much more than level differences.

> 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?

I think it would have to be HW. Most Midi port are USB today and one does
not know what processing happens inside. Those interfaces that use midi
over tcp/ip could be sniffed with a normal net sniffer.

>> 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.

Yup, Here are a few lines from the Yamaha doc...
- (1) If the assigned parameter has fewer than 128 steps
- (2) If the assigned parameter has 128 or more but less than 16,384 steps
- (3) If the assigned parameter has 16,384 or more but less than 2,097,152
steps

I didn't mention the three byte stuff before because I could not find
anywhere in the document where it is actually used or how it is
implemented. It merely says that in any case where more than one byte is
used a change that involves less than all the bytes need only send the
byte(s) that changed.

>> 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.

It does do some checking. I have not played with it though.

> 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.

While this is true, you cannot control what comes in the door. I may be
able to send running status 5 byte messages, but it looks like the jack
API does some filtering. I would like to know more about this. It would be
wonderful if jack dealt with NRPNs as one event, recognizing them,
collecting them and stripping all status bytes but one. They _should_ all
get sent as the same time slot, and if not (external slow physical MIDI
line) the whole message should be timeed to either the time of the first
status byte or the last. (the first makes more sense) This should be the
same as double event high precision CC events.

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

This what I am finding. In my case I am on the sending end which is
easier. I do get updates from the DAW as well (bank switches for example)
and have to deal with those. I do not have motorized faders, but rather a
local copy of the fader value for the same effect. I need to trouble shoot
this still. I can use the mouse to change the fader level and my program
catches that ok, but when I change banks, it doesn't. I can see that the
fader info goes out... but I don't seem to be catching it.

One more thought on control surfaces and DAWs: Reading what the control
surface is supposed to do in some of the DAW manuals and what the
controler puts out. I can see that most of the fancy functions are left up
to the DAW. There must be a large chunk of code in the DAW just for the
control surface. For example, the mackie control surface has buttons to
assign the "v-pots" (encoders) to various functions. This switching is
left up to the DAW. I get the idea most DAWs are more like the Harris
Mixbus where the channel strip is more or less predefined and this is
easier. For example a send may be pre or post, in Ardour this would make
it two different plugins for remote control as they all go in order. In a
Mixbus channel strip, the send could remain in the same place and just
have a pre/post parameter. I do not know what the deal between Ardour and
Harris is (and I don't have to know, and I am not grumpy whatever it is),
but it may preclude the inclusion in Ardour of a full strip or the ability
to swap out the fader/meter. I would be happy to buy Mixbus if I could use
the channel/bus strips in Ardour3. Ardour3 has a much improved remote
control interface.

--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev