Sequential Prophet VS - ability to reverse NRPN order?

Question

MIDI Target Manufacturer(s): Sequential Circuits

Hello all,

I am working on creating a Layout for the Sequential Circuits Prophet VS. However, I ran into a bit of a snag.

Symptom: When I go to edit LFO 1 shape using MDP sent to the VS, it also causes LFO 1 rate (on the unit itself) to change to a number that matches the original location of the knob I am moving. This is true whether I send continuous movement or have it send on release only. This issue happens with MANY settings, not just LFO 1 shape/rate (i.e., it happens for both LFOs and ADSR time and levels, etc). I'm just simplifying here.

MIDI settings: I am using the 7-bit NRPN (which is required). For LFO 1 shape, the manual states using MSB: 00, LSB: 0F (which is 15). So my setting is Channel - MSB - LSB or 1 - 0 - 15. 

Question for the group: From someone who knows about a bug related to the synth, they stated this:

Your symptom sounds like the reversed MIDI NRPN packet problem in the original VS OSes. Most controllers will act that way with VS OS 1.0-1.2 unless they give you the option to flip the NRPN order.

Is this possible to reverse the order? Or is there another solution to this that might work? I do not see a way to do this in the unit. I could also conceivably have a knob that sequences LSB first then MSB and just use regular CCs for this, though I'm not sure that's possible unless I have two knobs and knob 1 controls LSB and knob 2 controls MSB and I send them together... but then I have to make two controls for each parameter, which does not sound great.

Any thoughts?

Answer 1

SB output rule can reverse the order of MSB/LSB for NRPNs

There is not setting in MD to reverse the order of MSB and LSB for NRPNs.  The order of LSB and MSB is not indicated in the MIDI spec, and devices should not care which order they are received.

But, you have found a device that does care.

You can manually build the NRPNs from the individual Cc messages.

Or, we are going to use StreamByter to simply delay the MSB.

I first tried a simple SB 1 rule - BX 63 = xx +D100 (delay CC 63 messages by 100 msec).  But, when we use this, something weird happens in our output - we only see the MSB message, we never get the LSB or the data values.

There is a quirk in MD - Dan treats NRPNs as a single message, not three separate messages, and this is incompatible with the shorthand SB I code.

So, we need a few more lines of SB II output code to reverse the order of LSB and MSB for NRPN messages.  Again, remember this is non standard - we have to treat the three (or four for 14 bit data) messages as a single message.  But this actually makes things easier - so this is a good anomaly.

// Edit - updated to handle the 14 bit case //

If MT == B0 # message type Cc, any channel
  If M1 == 63 # cc 63h, NRPN MSB
    SND M3 M4 M5
    SND M0 M1 M2
    SND M6 M7 M8
    IF ML > 9 # Data LSB present
      SND M9 M0A M0B
    END
    BLOCK # stop the original, unordered message
  END
END

And sorry for the delayed response - got away from checking for a few days.

Answer 2

SB output rule can reverse the order of MSB/LSB for NRPNs

There is not setting in MD to reverse the order of MSB and LSB for NRPNs.  The order of LSB and MSB is not indicated in the MIDI spec, and devices should not care which order they are received.

But, you have found a device that does care.

You can manually build the NRPNs from the individual Cc messages.

Or, we are going to use StreamByter to simply delay the MSB.

I first tried a simple SB 1 rule - BX 63 = xx +D100 (delay CC 63 messages by 100 msec).  But, when we use this, something weird happens in our output - we only see the MSB message, we never get the LSB or the data values.

There is a quirk in MD - Dan treats NRPNs as a single message, not three separate messages, and this is incompatible with the shorthand SB I code.

So, we need a few more lines of SB II output code to reverse the order of LSB and MSB for NRPN messages.  Again, remember this is non standard - we have to treat the three (or four for 14 bit data) messages as a single message.  But this actually makes things easier - so this is a good anomaly.

// Edit - updated to handle the 14 bit case //

If MT == B0 # message type Cc, any channel
  If M1 == 63 # cc 63h, NRPN MSB
    SND M3 M4 M5
    SND M0 M1 M2
    SND M6 M7 M8
    IF ML > 9 # Data LSB present
      SND M9 M0A M0B
    END
    BLOCK # stop the original, unordered message
  END
END

And sorry for the delayed response - got away from checking for a few days.