While responding to a ticket a few weeks ago, I noticed that Csound reserves the use of four CC numbers for NRPNs and RPNs.
It made me wonder if there's anything we could do with this functionality, and if so, in what form. Does anyone have ideas about this?
In HW synths generally there is a table of NPRNs that are responded to, but not sure what we could do within the Csound context that is not already possible with other means.
As far as I can see four CC messages are sent for each NPRN parameter change. Two identify the parameter and two carry the data value (numbers are 14bit long).
While responding to a ticket a few weeks ago, I noticed that Csound reserves the use of four CC numbers for NRPNs and RPNs.
These are standard, so probably should be there. I use the "Fine Tune" NRPN codes
myself to retune my live playing when I'm playing along with some older recordings.
It made me wonder if there's anything we could do with this functionality, and if so, in what form. Does anyone have ideas about this?
In HW synths generally there is a table of NPRNs that are responded to, but not sure what we could do within the Csound context that is not already possible with other means.
See above... :\-) Rather essential for me a lot of the time.
Actually there seem to be a number of "special actions" that I'm not sure are relevant
at all. I remember being very confused with the "Unknown Drum Parameter..." error. Can't remember exactly what I was trying to do\. If Csound itself has no special
response to these NRPNs that code should probably just be removed.
As far as I can see, there is no handling of NRPNs anywhere, but CCs 98-101 are not read as CCs but placed in a separate location. The opcodes ctl7 etc do not see messages coming in these CCs. Of course midiin does.
I can't change this because it may break some Csound code somewhere, so removing them is not an option, but I don't have an immediate idea how to offer NRPN functionality.
Maybe simply something like
kout nprn ipar
where ipar is a user given nprn in the 14-bit range, and kout is the value sent also in the same range.
Or
kout nprn imsb, ilsb
where parameter is given as an imsb ilsb pair, which may be easier in some cases.
Prof. Victor Lazzarini
Maynooth University
Ireland
Hi Victor,
Aug 20 2021, Victor Lazzarini has written:
...
It made me wonder if there's anything we could do with this functionality, and if so, in what form. Does anyone have ideas about this?
...
It would be nice if there was a secondary version of midiin which would
allow for more status messages or have an additional k-rate output to
signal the arrival of NRPN/RPN parameters. I have a roughly working UDO
to parse NRPNs and RPNs, but it can get a little frisky.
AFAIK HW synth may only send part of an NRPN/RPN message, especially if
it is just a value change of the previous control. I don't know how far
this goes. The Yoshimi team looked into that. Though I haven't seen it
on any of my synths.
Since NRPN/RPN are basically CC messages bundled together, maybe a specific opcode (as we have for other messages) to receive these may be appropriate.
Prof. Victor Lazzarini
Maynooth University
Ireland
By additional status message I mean perhaps an extra k-rate parameter that can signify a standard CC, RPN or NRPN, although kstatus could also do that with higher or lower values. Yes, these parameters are constructed, but it's helpful to get them parsed.
It is also helpful to receive all CCs, RPNs and NRPNs in one opcode, since there are a few hardware synthesizers that will send CCs and RPNs/NRPNs. A simple matter of convenience.
Given that midiin outputs a single midi byte, it's not really appropriate to signal the arrival of nrpns, which use four bytes.
The best I can think so far is an opcode that outputs the value received in a user-defined nrpn. Similar to what we have for CCs (ctl7 etc). This is what I proposed in a response to Pete Goodeve yesterday.
Prof. Victor Lazzarini
Maynooth University
Ireland
where ipar is a user given nprn in the 14-bit range, and kout is the value sent also in the same range.
...
As acounterpart to ctrl7 this would work well.
The advantage of an opcode like midiin is that one can dynamically grab
all incoming data to use it as a hub or easily work based on user
supplied configurations. Whic is why my implmentations have
intelligently looked for RPN/NRPN controls and output their values in
two k-rate signals while setting some kind of status information. It's
been useful for MIDI learn features.
This is not a case against ann nrpn/rpn opcode, but a case for a more
high level opcode. Given that there are already ways around it, it
should probably go on the rainy, boring Saturday night list.
...
I'm not sure this is strictly true. The 'canonical' way is to send three or four messages:
cc99 <NRPN MSB>
cc98 <NRPN LSB>
cc6 <NRPN value MSB>
cc38 (optional) <NRPN value LSB>
but then one is supposed to "close off" the data-entry CC6/38 with:
cc101 <127>
cc100 <127>
Confusingly, it seems one should use the RPN controllers for the reset,
even for NRPN setting.
Presumably, though, this full sequence isn't necessary. If for instance
you need to set a series of NRPNs you might only need
......
cc98 <NRPN LSB>
cc6 <NRPN value MSB>
......
repeated as appropriate. Then only close off at the end.
My alwayson "Tuning" instrument (for RPN Fine Tuning) is quite simple
and works well. It simply monitors control messages and if the CC is
100 or 101 sets a local variable. If the CC is 6 and the local variables
have the correct value, it sets a global tuning variable. A more generic
"readrpn" (or "readnrpn") would be a litle more complex, but not markedly.
Without thinking too hard(!) I don't see any real difficulty in an opcode
version. Perhaps would return parameter number and value (two args)
when a CC6 is received. Might need a 14-bit version, or just ignore CC38.
Just in case it is not widely known, one can also use the flag
-+raw_controller_mode=boolean
to allow ctrl7 to receive NRPN controller data as if there was nothing special about them.
I have used this a lot, when I had a large number of different controller messages and the reserved status of the NRPNs messed up my attempts at tidy contiguous controller numbering.
By additional status message I mean perhaps an extra k-rate parameter that can
signify a standard CC, RPN or NRPN, although kstatus could also do that with
higher or lower values. Yes, these parameters are constructed, but it’s
helpful to get them parsed.
It is also helpful to receive all CCs, RPNs and NRPNs in one opcode, since
there are a few hardware synthesizers that will send CCs and RPNs/NRPNs. A
simple matter of convenience.
Best wishes,
Jeanette
Aug 21 2021, Victor Lazzarini has written:
What do you mean about “more status messages”?
Since NRPN/RPN are basically CC messages bundled together, maybe a specific opcode (as we have for other messages) to receive these may be appropriate.
Prof. Victor Lazzarini
Maynooth University
Ireland
Warning
This email originated from outside of Maynooth University’s Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
Hi Victor,
Aug 20 2021, Victor Lazzarini has written:
…
It made me wonder if there’s anything we could do with this functionality, and if so, in what form. Does anyone have ideas about this?
…
It would be nice if there was a secondary version of midiin which would
allow for more status messages or have an additional k-rate output to
signal the arrival of NRPN/RPN parameters. I have a roughly working UDO
to parse NRPNs and RPNs, but it can get a little frisky.
AFAIK HW synth may only send part of an NRPN/RPN message, especially if
it is just a value change of the previous control. I don’t know how far
this goes. The Yoshimi team looked into that. Though I haven’t seen it
on any of my synths.
Sorry to persist, but I guess for clarity it should be noted that any channel message
is at least *two* bytes, many are three, with three components: channel, function,
and value (which itself can have two parts, e.g. note and velocity). RPNs and NRPNs
are no different, and in fact if you're just setting one RPN to different values
there's no reason to use more than one (three-byte) 'data-entry' CC6 message
each time. And of course midiin handles (N)RPN sequences as well as any other.
You just need to preserve a bit of state.
I know I'm preaching to the choir here, but I thought it was worth clarifying!
I feel partly responsible for the confusing / difficult to use state of the nrpn code that exists now. Ages ago I acquired a midi controller that could use NRPN for more finely grained slider position info, and I found this useful for highly sensitive parameters like FM index.
I made a contribution to the core MIDI code that was required in order to make the NRPN usable (not knowing about the -+raw_controller_mode=1 setting if it existed at that time). Before my contribution was merged, I was unable to get NRPN bytes via midiin in some cases (which coincided or at least correlated with the “unknown drum parameter” log messages).
