[Csnd] NRPNs

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).

Prof. Victor Lazzarini
Maynooth University
Ireland
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

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.

  -- Pete --

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

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.

Best wishes,

Jeanette

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

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:

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

Aug 21 2021, Victor Lazzarini has written:
...

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.

...
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. :slight_smile:
...

Best wishes,

Jeanette

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.

  -- Pete --

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

Well, in any case, it is true that unlike other normal channel messages, one byte is not sufficient. Three or four as you said, to characterise it.

Prof. Victor Lazzarini
Maynooth University
Ireland

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.

all best
Øyvind

lør. 21. aug. 2021 kl. 21:21 skrev Jeanette C. <julien@mail.upb.de>:

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.

Best wishes,

Jeanette

Loneliness up ahead, emptiness behind <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C56eecdf9b8cf40ff1cd408d964cf68d3%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637651664266331735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6OeH2W0jdYxMN2jRHJCszEt%2BgVnVQ8rz%2B0MU5%2BpU3rQ%3D&reserved=0
Send bugs reports to
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C56eecdf9b8cf40ff1cd408d964cf68d3%7C1454f5ccbb354685bbd98621fd8055c9%7C1%7C0%7C637651664266331735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rJYbgoZQZzh7iDkmnrGTg4MsWIP92GKSDuv7qnU49KE%3D&reserved=0
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Loneliness up ahead, emptiness behind <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Good to know, thanks for this.

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!

  -- Pete --

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

Me too.

I use it routinely as:
-+raw_controller_mode=1

You are right, I should have said a single channel message. That is what I meant.

Prof. Victor Lazzarini
Maynooth University
Ireland

Maybe a note about this could be added to the man page.

Dr. Richard Boulanger
Professor
Electronic Production and Design
Berklee College of Music

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).

Looking at the code as it is today, I still find this part of the code confusing:
https://github.com/csound/csound/blob/develop/InOut/midirecv.c#L277