Should NPRN repeat address (CC 98/99) and NPRN Reset (if enabled) with each value?

Bug reports
1

When moving a knob (in a 4 mixer) multiple value changes are sent in quick succession. It’s possible to send less bytes by skipping the NRPN address as the value is changing … and to only send the reset once at the end once the value is no longer changing.

This assumes there is a buffer or other state that knows the controller has queued up value messages.

The current behavior is the safest, but the least efficient.

2

yes, that is the main reason behind that. At this moment each message is self-contained and does not need to know the context/state other message stream. I wish to add support for running status at some point (on the outbound side), this is basically the same thing.

1 Like
3

Hi @martin . I have encountered a MIDI device (new LPE beta firmware for the MakingSoundsMachine Plinky) that aggressively minimises the NPRN data it sends out (used for parameter value feedback) that I want E1 to handle as incoming MIDI to update / initialise mapped controls. Can the E1 automatically handle parsing such incrementally - specific NRPN messages, or does it require each NPRN message to be complete (ie 4 byte NPRN MSB+LSB, DATA MSB+LSB) ?

CC98/99 and CC6/38 form two 14bit values. When sending a 14bit value, each of the CCs in the pair need to be sent at least once. After having sent each at least once, the 14bit value can be updated by sending one of the CCs of the pair while omitting the other.

When the 14bit NRPN value changes, the 14bit DATA value is cleared. This means CC6/38 always need to both be sent at least once after a change of CC98/99.

4

You need to test out what E1 will be when it receives a stand alone CC6 of CC38. My guess it will interprete it against the latest CC99 or CC98 that was transmitted. Important though if to check which CC98 of CC99 is considered by both parties (Plinky as well as the E1) as ‘the latest’ .. Is it the one sent ? or the one received ? or either one that was last ?
That might be sensitive in case you find the interpretation by both devices is different.

You can test this with an E1 and a plinky by creating a preset in which E1 sends NRPNs and receives NRPNs and you ensure you visualise the results on the E1.

If the interpretation is different by both parties, you’ll need to intercept incoming data using midi.onControlChange(midiInput, channel, controllerNumber, value).

In that case you could for instance choose on the E1 not to make use of native NRPN parameters, but use virtual parameters.
With the function parameterMap.onChange(valueObjects, origin, midiValue)

  • you then intercept changes made to those controls on the E1 and
  • convert them to
    midi.sendNrpn(port, channel, parameterNumber, value, lsbFirst, reset)
    or a combination of 1 to 4
    midi.sendControlChange(port, channel, controllerNumber, value)

In the other direction you intercept incoming CC via midi.onControlChange(midiInput, channel, controllerNumber, value). and use custom logic (according to Plinky behaviour) to assign the resulting value to the right virtual parameter.

1 Like