Subject: Re: [linux-audio-dev] MIDI question
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: ke elo 11 1999 - 20:57:22 EDT
On Wed, 11 Aug 1999, Adam Zygmunt wrote:
> All controls except pitch bend are coarse. Control change and pitch bend
> are actually two different types of messages. Control change is of the
> form Bx (hex) y z, where x is the MIDI channel, y is the controller
> number, and z is the controller value (both 7-bit). Pitch bend is of the
> form Ex l m, where x the channel, and l and m are the least- and
> most-significant bytes, respectively. Both of these are also 7 bit, which
> is a little weird.
I understand that pitch bend is not a controller in terms of MIDI,
although I tend to agree with another poster (forgive me for not checking
up on the name) who said that such similar things should be able to be
editted in a similar manner. For that matter, aftertouch in its two forms
(note specific and channel-wide) is not considered a controller either.
What I'm referring to is that there are pairs of controller numbers for
many of the defined types of controllers. For instance, controller number
1 sets the most significant 7 bits for the mod wheel, and controller
number 0x21 sets the least significant 7 bits for the mod wheel. Older
and cheaper synthesizers will only send the first, allowing only a course
level of control, but the standard supports a full 14 bits of resolution,
spread across two messages. At least, that's what it really looks like
from the spec; I wanted to make sure what limitations there were in terms
of order and intervening messages.
> [N]RPN are actually just extensions to the controllers. As there are
> only 127 available controllers, some of the more esoteric things have been
> put here. I'm pretty sure (I'd have to double-check a manual to be
> absolutely certian) that you use [N]RPN by sending three sequential
> controller-type (Bx) messages. The first, 62 or 64 (hex), sets the RPN or
> NRPN parameter number lsb. 63 or 65 sets the msb. controller 6 would then
> set the value (coarse only). There are a couple of special controllers for
> [N]RPN - 60 (increment) and 61(decrement) which can be used instead of 6,
> though these seem a little unusual to me. To summarize, [N]RPNs are a way
> of giving MIDI devices 32,000 controllers (2^14 RPNs+2^14 NRPNs), instead
> of just 127. As they're all still fundamentally controllers, they still
> only have 7 bits of resolution, though.
This seems to coincide with the scattered documentation I found, all
except the 7 bit limit. To send a value of 1234 (0x4D2) to RPN number
5678 (0x162E), I believe the sequence would be:
/ 0xB0 controller message on channel 1
message 1 < 0x64 RPN number LSB
\ 0x2E bottom seven bits of 0x162E
/ 0xB0 controller message on channel 1
message 2 < 0x65 RPN number MSB
\ 0x2C top seven bits of 0x162E
/ 0xB0 controller message on channel 1
message 3 < 0x26 data entry LSB
\ 0x52 bottom seven bits of 0x4D2
/ 0xB0 controller message on channel 1
message 4 < 0x06 data entry MSB
\ 0x09 top seven bits of 0x4D2
Notice the 14 bits of resolution in both the RPN number and the value to
which it is being set. My questions were really:
1. Can you reverse the order of 1 and 2, likewise 3 and 4, and still have
it be valid? In other words, does MIDI really have an "endian"
preference? (Not the IFF based SMF files, which definitely do, but the
wire messages themselves?)
2. Is a sequence like 1, 2, 3, 4, 3, 4 valid, where you don't repeat the
RPN number? This seems like it should be valid, because otherwise the
data increment and decrement controllers (0x60 and 0x61 respectively)
would be pretty inefficient, but then again I'm not sure.
3. Can you leave out 4 so that the RPN number has 14 bits of resolution,
but the value to which it is set has only 7 bits, like with the "coarse"
versions of regular controllers?
This would be easy to test out if my synth actually sent or recognised
RPNs and fine-grained regular controllers, but unfortunately it is too old
for that.
Thanks for your help,
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST