PreenFM > preenfm2 and preenfm3

NRPN and MIDI documentation questions and issues part 3

<< < (2/2)

feijai:
Well, NRPN has always been very, very vague in the spec.  But here's the rules regarding receiving machines (see MIDI 1.0 Detailed Specification 4.2, page 17).

"4. The receiver should be able to respond accordingly if the transmitter sends only an LSB or MSB to change the parameter number.  However, since the transmitter can't know when reception was enabled on the receiver which will be waiting for both the LSB and MSB (at least initially), it is recommended that the LSB and MSB be sent each time a new parameter number is selected."

and

"5. Once a new Parameter Number is chosen, that parameter retains its old value until a new Data Entry, Data Increment, or Data Decrement is received"  [I think this is interpreted as also permitting NRPN running status -- that is, a stream of data entry values -- though it's vague]

I think that this means that receivers are asked to be able to handle single LSBs, single MSBs, and LSB+MSB pairs (it doesn't specify the order).

Given that the PreenFM2's *primary mechanism* for control is NRPN, I'd STRONGLY recommend revisiting this to get it right.  The big issue is what happens if only a CC6 (or stream of CC6) is sent -- this is a common case and makes perfect sense.  For example, if I have a BeatStep and I want to control the Preen's Operator Modulation Indices, the BeatStep can *only* send either CC6 *or* CC38.  CC6 lets me change the indexes by a significant amount, CC38 does not.  So that means I can't really use a BeatStep with the PreenFM2 over NRPN.

Also, the inability to close properly with an RPN 127/127 is going to cause problems with a number of utility devices which were written to assume this.

I'll try to suggest a protocol that might work.  But it will almost certainly involve freeing up CC100 and CC101.

Navigation

[0] Message Index

[*] Previous page