Midi Implementation

[SerErris]

Looking at the MIDI implementation docs and the User Guide I am scratching my head and wonder if there is something missing.

In the Manual on Page 13 there is the following statement:

NRPNs are the preferred method of parameter transmission, since they cover the
complete range of all parameters, while CCs are limited to a range of 128. For a list of
Prophet-10 CCs and NRPNs, see the Prophet-10 Support page at Sequential.com.

Okay, understood - MIDI CC is actually limited to a value range of 0-127.

Looking at the Midi Implementation, you will find that there is actually no parameter that is outside that range. Not the filter, nor any other parameter is ever using a larger range of values that would actually justify to use NRPN over CC.

The downside of using NRPN over CC is, that NRPN is actually a MIDI CC command that requires to send 4 MIDI CC messages to be transferred instead of a single MIDI CC. In Bytes that is 3 Midi Bytes vs. 12 Midi Bytes. That might sound not a big issue, but consider that you can only send about 500 MIDI Messages (as Single Midi CC for instance) per Second, and you want to control some parameters in real time (and there is nothing like concurrent in MIDI as well), you might run pretty fast into timing issues and the overhead will make it worse (only 125 NRPN Messages per second).

So any reason I should actually every use NRPN in this Synth?
Looks like they copied the section from another synth that actually has values larger then 127.

[SynthWolf]

Looking at the MIDI implementation docs and the User Guide I am scratching my head and wonder if there is something missing.

In the Manual on Page 13 there is the following statement:

NRPNs are the preferred method of parameter transmission, since they cover the
complete range of all parameters, while CCs are limited to a range of 128. For a list of
Prophet-10 CCs and NRPNs, see the Prophet-10 Support page at Sequential.com.

Okay, understood - MIDI CC is actually limited to a value range of 0-127.

Looking at the Midi Implementation, you will find that there is actually no parameter that is outside that range. Not the filter, nor any other parameter is ever using a larger range of values that would actually justify to use NRPN over CC.

The downside of using NRPN over CC is, that NRPN is actually a MIDI CC command that requires to send 4 MIDI CC messages to be transferred instead of a single MIDI CC. In Bytes that is 3 Midi Bytes vs. 12 Midi Bytes. That might sound not a big issue, but consider that you can only send about 500 MIDI Messages (as Single Midi CC for instance) per Second, and you want to control some parameters in real time (and there is nothing like concurrent in MIDI as well), you might run pretty fast into timing issues and the overhead will make it worse (only 125 NRPN Messages per second).

So any reason I should actually every use NRPN in this Synth?
Looks like they copied the section from another synth that actually has values larger then 127.

This is very interesting, I too would like to know the answer !

[AlainHubert]

Good question indeed. I suspect that internally the synth works with a much higher resolution than the controllers/potentiometers can output. For example, if there were only 128 possible values generated by the envelopes, we would hear audible stair-stepping when they're controlling a self-oscillating filter. But there are none.

But the MIDI CC is indeed limited to 128 values when trying to directly control a parameter.
Perhaps using NRPN can allow interpolating values between those 128 CC steps? I'm just speculating here.

[SynthWolf]

Good question indeed. I suspect that internally the synth works with a much higher resolution than the controllers/potentiometers can output. For example, if there were only 128 possible values generated by the envelopes, we would hear audible stair-stepping when they're controlling a self-oscillating filter. But there are none.

But the MIDI CC is indeed limited to 128 values when trying to directly control a parameter.
Perhaps using NRPN can allow interpolating values between those 128 CC steps? I'm just speculating here.

I think you’re on to something here.
What about the values of aftertouch, velocity, amp and filter ?

[Qwave]

I think you’re on to something here.
What about the values of aftertouch, velocity, amp and filter ?

Aftertouch is 7 bit (0-127) on all synths I ever encounted. It is not different on the Prophet-5/10 Rev4.

And I checked all parameters of the Prophet-5/10 Rev4: they are all 7 bit like the classic vintage Prophet-5. Except for the Pitchbend, which gives more than 7 bit or 128 different parameter values. But this parameter was always defined at 14 bit data (16384 values) in the MIDI specs. But it is not send as full 14 bit here. But actually there are not many synths sending the full 14 bit pitchbend data (never had one in all the years and 35+ different synths). After all the analog voltage generated by the pitchbend wheel pot has to be measured very very accurate to get this. And then you would have random data because of slight variations in temperature and voltage of the pot.

[kris]

I think the main reason is that Sequential thankfully uses the same software code base as for their other synths, and you can only have so many different parameters to have one CC parameter for each. E.g. with the Rev2 and it's two layers, you need 187 different parameters for each layer not even counting the step or the poly sequencer - you simply run out of CCs.

So they allow you to switch to NRPN control, which exposes each and every parameter.

There are some quirks in that e.g. if you switch to NRPN control, the Rev2 stops sending out program change messages when you switch the program, which should have nothing to do with the CC/NRPN setting IMHO.

What they could have done, and I am not sure how it really behaves because sometimes it seems the CC messages still work though you set the synth to NRPN mode, is to keep reacting to CC messages even when NRPN is turned on, but send out NRPN.

Also, isn't the speed higher on USB interfaces than with DIN MIDI? It certainly is for sysex transfers.

[SerErris]

Good question indeed. I suspect that internally the synth works with a much higher resolution than the controllers/potentiometers can output. For example, if there were only 128 possible values generated by the envelopes, we would hear audible stair-stepping when they're controlling a self-oscillating filter. But there are none.

But the MIDI CC is indeed limited to 128 values when trying to directly control a parameter.
Perhaps using NRPN can allow interpolating values between those 128 CC steps? I'm just speculating here.

There is a difference of a Control Voltage Parameter of the Envelope (what is the knob position for ADSR?) and the curve of CV for the target that is created by the Envelope. Even if you can control the envelope with very steppy CVs (128 max here) then the curve created is still smooth. So that does not tell us anything and NRPN parameters are actually not controlling that behaviour. They are just programming the CPU. How the CPU then internally transferres it throug it internal DAs is a complete different questions (slop is the keyword here).

However this section in the manual simply does not make any sense.

I would have preferred they would have created a MIDI 2.0 implementation (chooseable) instead of this NRPN, which is of no benefit. That would have given us a much broader range of controllers with better numbers. And as the synth anyhow comes with USB, that would have been no issue.

The only reason I can see here is, that there is currently nothing Midi 2.0 compliant DAW/controller awailable, that would make sense to implement it. But if hardware does not implement it at a certain point in time, no software will ever apply it.

[kris]

have preferred they would have created a MIDI 2.0 implementation (chooseable) instead of this NRPN, which is of no benefit. That would have given us a much broader range of controllers with better numbers. And as the synth anyhow comes with USB, that would have been no issue.

The only reason I can see here is, that there is currently nothing Midi 2.0 compliant DAW/controller awailable, that would make sense to implement it. But if hardware does not implement it at a certain point in time, no software will ever apply it.

As I see it - as a software developer - there is currently not even good MIDI 2.0 support in the software SDKs we are using. E.g. JUCE has no MIDI 2.0 support at the time of writing, and I think not many developers, especially not the small ones which I would classify Sequential to be, are willing to take on a rather huge task of implementing a new standard on their own.

I have worked myself through the standards documentation, and must say I am not yet convinced that this is as useful and easy as it could be. My suspicion is that we will see the first full blown implementations from the big Japanese manufacturers.