This was a long time ago, and I am not sure of the status of the
feature. I assume I'd find the quality of the code embarrassing if I
read it today.

My patch was made by reverse engineering the output of some sliders
set to produce nrpn, and I would not be surprised if the behavior
misses big parts of the spec. I do hazily recall that at one point I
was able to use nrpn inputs despite the drum param error messages, but
it's been long enough that I'm unsure.

I'd be happy to answer specific questions about the patch, and it
would be great to get nrpn input that actually followed the spec
instead of just happening to work with my workflow.

On Sun, Mar 10, 2019 at 5:54 PM Pete Goodeve  wrote:
>
> On Sun, Mar 10, 2019 at 11:57:44PM +0000, Victor Lazzarini wrote:
> > I did not know Csound could handle these, and so I googled it, getting this
> >
> > http://csound.1045644.n5.nabble.com/patches-for-NRPN-input-td3413369.html
> >
> > not sure if this ever made it to the sources. I can't check it right now. My hunch is that
> > it didn't. There does not seem to be
> > anything in the manual about it, beyond
> > the capability of sending nrpns out.
>
> Thanks for the link.  It's a bit hard to figure out, because the
> patch doesn't include any file names.  AND it seems to be
> reversed!  The *result* of the patch would be the current
> code, but obviously his intent was to add an 'nrpnin' opcode
> and so on, which are not there.
>
> It looks as his code was pretty specialized.  It doesn't seem
> to take account of the common RPNs either.
>
> I'll have to try to stir myself to be able to compile Csound
> again.  If I do, I can have a go at sorting it out.
>
> Thanks,
>
>         -- Pete --
>
> 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

https://csound.com/docs/manual/midiin.html ?

On 11/03/19 11:42, Ed Cashin wrote:
> Would it be too crazy to just go fully general and have a rawmidiin
> opcode that returns an array of bytes?
>
> On Mon, Mar 11, 2019 at 2:32 AM  > wrote:
>
>     Thanks for picking up, Justin.
>
>     It looks like your patch was fairly device speciific, and it still
>     didin't handle
>     the regular RPNs I'm interested in.  If we do anything I figure it
>     should be
>     as general as possible, giving the user all the info neded and
>     letting them
>     decide on action.  I strongly believe that the current controller
>     opcodes
>     should respond for all controller numbers, and not arbitrarily block
>     some.
>
>     Currently, for instance, all CCs above 111 (I think) are blocked.
>     Long ago
>     I wanted to respond to "All Sounds Off" (CC120), but it never worked.
>     Just recently I discovered that Csound *will* respond to "All Notes
>     Off" (123)
>     but my software just sends CC120 which I always thought was more
>     logical!
>     123 is the only one special cased, and it acts directly, rather than
>     being
>     passed to the user.   Similarly, the RPN and NRPN controllers
>     (98...101 and 6)
>     are blocked.
>
>     In addition to revising things so that ctrl7 and so on handle all
>     controllers,
>     how about something like this?
>
>     Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
>     respond to particular codes, let them return everything relevant -- the
>     selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
>     value (controller 6).  e.g.:
>
>             kmsb, klsb, kval rpnin
>
>     or maybe:
>
>             kval rpnin kmsb, klsb
>
>     Not sure which format would be more useful, but how does the general
>     idea sound?
>
>     Cheers,
>
>             -- Pete --
>
>
>     On Sun, Mar 10, 2019 at 06:54:21PM -0700, Justin Smith wrote:
>     > This was a long time ago, and I am not sure of the status of the
>     > feature. I assume I'd find the quality of the code embarrassing if I
>     > read it today.
>     >
>     > My patch was made by reverse engineering the output of some sliders
>     > set to produce nrpn, and I would not be surprised if the behavior
>     > misses big parts of the spec. I do hazily recall that at one point I
>     > was able to use nrpn inputs despite the drum param error messages, but
>     > it's been long enough that I'm unsure.
>     >
>     > I'd be happy to answer specific questions about the patch, and it
>     > would be great to get nrpn input that actually followed the spec
>     > instead of just happening to work with my workflow.
>     >
>     > On Sun, Mar 10, 2019 at 5:54 PM Pete Goodeve
>     > wrote:
>     > >
>     > > On Sun, Mar 10, 2019 at 11:57:44PM +0000, Victor Lazzarini wrote:
>     > > > I did not know Csound could handle these, and so I googled it,
>     getting this
>     > > >
>     > > >
>     http://csound.1045644.n5.nabble.com/patches-for-NRPN-input-td3413369.html
>     > > >
>     > > > not sure if this ever made it to the sources. I can't check it
>     right now. My hunch is that
>     > > > it didn't. There does not seem to be
>     > > > anything in the manual about it, beyond
>     > > > the capability of sending nrpns out.
>     > >
>     > > Thanks for the link.  It's a bit hard to figure out, because the
>     > > patch doesn't include any file names.  AND it seems to be
>     > > reversed!  The *result* of the patch would be the current
>     > > code, but obviously his intent was to add an 'nrpnin' opcode
>     > > and so on, which are not there.
>     > >
>     > > It looks as his code was pretty specialized.  It doesn't seem
>     > > to take account of the common RPNs either.
>     > >
>     > > I'll have to try to stir myself to be able to compile Csound
>     > > again.  If I do, I can have a go at sorting it out.
>     > >
>     > > Thanks,
>     > >
>     > >         -- Pete --
>     > >
>     > > 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
>
>     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
>
> --
>   Ed Cashin >
> 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

We will need to see whether all of this is supported by the underlying MIDI backends. Then we will
probably need to modify the MIDI ports/implementation. I think it only supports channel messages 
at the moment. It is probably a big job.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 13 Mar 2019, at 09:19, Anders Genell  wrote:
> 
> I would also appreciate being able to receive midi clock if that would be possible. There is already support for sending midi clock using the mclock opcode, so receiving the clock would be nicely symmetrical.
> Also, if it would be possible, perhaps the functionality of mclock could be more generalized, so that the frequency could be varied at k.-rate, and some special value (like a negative number) would make mclock send one single clock message, so that external sequencers could be stepped at varying intervals using e.g. the poisson opcode. Just a thought...
> 
> Regards,
> Anders 
> 
> On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve  wrote:
> On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
> > how about something like this?
> > 
> > Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
> > respond to particular codes, let them return everything relevant -- the
> > selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
> > value (controller 6).  e.g.:
> > 
> >       kmsb, klsb, kval rpnin
> > 
> > or maybe:
> > 
> >       kval rpnin kmsb, klsb
> 
> I wasn't thinking hard enough there.  Of course the above would need
> a channel parameter too.  And I think they should probably be
> 'rpn7' -- and 'rpn14' and so on.  And should there should be parallels to
> 'midic7' like 'midirpn7'?  (Maybe not.)
> 
> So:
> 
>         kmsb, klsb, kval rpn7 ichan
> 
> or something.
> 
> I also forgot to note that there is one RPN that it does recognize
> (and has to!)  the Pitch Bend Range, which affects 'cpsmidib' and
> similar. 
> 
>         -- Pete --
> 
> 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

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

Csound8 then? ;-)

Regards,
Anders

> 13 mars 2019 kl. 10:40 skrev Victor Lazzarini :
> 
> We will need to see whether all of this is supported by the underlying MIDI backends. Then we will
> probably need to modify the MIDI ports/implementation. I think it only supports channel messages 
> at the moment. It is probably a big job.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 13 Mar 2019, at 09:19, Anders Genell  wrote:
>> 
>> I would also appreciate being able to receive midi clock if that would be possible. There is already support for sending midi clock using the mclock opcode, so receiving the clock would be nicely symmetrical.
>> Also, if it would be possible, perhaps the functionality of mclock could be more generalized, so that the frequency could be varied at k.-rate, and some special value (like a negative number) would make mclock send one single clock message, so that external sequencers could be stepped at varying intervals using e.g. the poisson opcode. Just a thought...
>> 
>> Regards,
>> Anders 
>> 
>> On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve  wrote:
>>> On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
>>> how about something like this?
>>> 
>>> Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
>>> respond to particular codes, let them return everything relevant -- the
>>> selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
>>> value (controller 6).  e.g.:
>>> 
>>>      kmsb, klsb, kval rpnin
>>> 
>>> or maybe:
>>> 
>>>      kval rpnin kmsb, klsb
>> 
>> I wasn't thinking hard enough there.  Of course the above would need
>> a channel parameter too.  And I think they should probably be
>> 'rpn7' -- and 'rpn14' and so on.  And should there should be parallels to
>> 'midic7' like 'midirpn7'?  (Maybe not.)
>> 
>> So:
>> 
>>        kmsb, klsb, kval rpn7 ichan
>> 
>> or something.
>> 
>> I also forgot to note that there is one RPN that it does recognize
>> (and has to!)  the Pitch Bend Range, which affects 'cpsmidib' and
>> similar. 
>> 
>>        -- Pete --
>> 
>> 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
> 
> 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

I would also appreciate being able to receive midi clock if that would be possible. There is already support for sending midi clock using the mclock opcode, so receiving the clock would be nicely symmetrical.

Also, if it would be possible, perhaps the functionality of mclock could be more generalized, so that the frequency could be varied at k.-rate, and some special value (like a negative number) would make mclock send one single clock message, so that external sequencers could be stepped at varying intervals using e.g. the poisson opcode. Just a thought...

Regards,

Anders 

On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve <pete.goodeve@computer.org> wrote:

On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
> how about something like this?
>
> Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
> respond to particular codes, let them return everything relevant -- the
> selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
> value (controller 6).  e.g.:
>
>       kmsb, klsb, kval rpnin
>
> or maybe:
>
>       kval rpnin kmsb, klsb

I wasn't thinking hard enough there.  Of course the above would need
a channel parameter too.  And I think they should probably be
'rpn7' -- and 'rpn14' and so on.  And should there should be parallels to
'midic7' like 'midirpn7'?  (Maybe not.)

So:

        kmsb, klsb, kval rpn7 ichan

or something.

I also forgot to note that there is one RPN that it does recognize
(and has to!)  the Pitch Bend Range, which affects 'cpsmidib' and
similar.

        -- Pete --

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

Do we support Ableton Link.  If not, we should. That's a clock that many of my students could really use... and me too.

Dr. Richard Boulanger

Professor

Electronic Production and Design

Berklee College of Music

On Mar 13, 2019, at 5:19 AM, Anders Genell <anders.genell@gmail.com> wrote:

I would also appreciate being able to receive midi clock if that would be possible. There is already support for sending midi clock using the mclock opcode, so receiving the clock would be nicely symmetrical.

Also, if it would be possible, perhaps the functionality of mclock could be more generalized, so that the frequency could be varied at k.-rate, and some special value (like a negative number) would make mclock send one single clock message, so that external sequencers could be stepped at varying intervals using e.g. the poisson opcode. Just a thought...

Regards,

Anders 

On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve <pete.goodeve@computer.org> wrote:

On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
> how about something like this?
>
> Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
> respond to particular codes, let them return everything relevant -- the
> selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
> value (controller 6).  e.g.:
>
>       kmsb, klsb, kval rpnin
>
> or maybe:
>
>       kval rpnin kmsb, klsb

I wasn't thinking hard enough there.  Of course the above would need
a channel parameter too.  And I think they should probably be
'rpn7' -- and 'rpn14' and so on.  And should there should be parallels to
'midic7' like 'midirpn7'?  (Maybe not.)

So:

        kmsb, klsb, kval rpn7 ichan

or something.

I also forgot to note that there is one RPN that it does recognize
(and has to!)  the Pitch Bend Range, which affects 'cpsmidib' and
similar.

        -- Pete --

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

Do we support Ableton Link.  If not, we should. That's a clock that many of my students could really use... and me too.

Dr. Richard Boulanger

Professor

Electronic Production and Design

Berklee College of Music

On Mar 13, 2019, at 5:19 AM, Anders Genell <anders.genell@gmail.com> wrote:

I would also appreciate being able to receive midi clock if that would be possible. There is already support for sending midi clock using the mclock opcode, so receiving the clock would be nicely symmetrical.

Also, if it would be possible, perhaps the functionality of mclock could be more generalized, so that the frequency could be varied at k.-rate, and some special value (like a negative number) would make mclock send one single clock message, so that external sequencers could be stepped at varying intervals using e.g. the poisson opcode. Just a thought...

Regards,

Anders 

On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve <pete.goodeve@computer.org> wrote:

On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
> how about something like this?
>
> Add "rpnin" and "nrpnin" opcodes like yours, but rather than having them
> respond to particular codes, let them return everything relevant -- the
> selector numbers (from RPN:101/100 or NRPN:98/99) and the data entry
> value (controller 6).  e.g.:
>
>       kmsb, klsb, kval rpnin
>
> or maybe:
>
>       kval rpnin kmsb, klsb

I wasn't thinking hard enough there.  Of course the above would need
a channel parameter too.  And I think they should probably be
'rpn7' -- and 'rpn14' and so on.  And should there should be parallels to
'midic7' like 'midirpn7'?  (Maybe not.)

So:

        kmsb, klsb, kval rpn7 ichan

or something.

I also forgot to note that there is one RPN that it does recognize
(and has to!)  the Pitch Bend Range, which affects 'cpsmidib' and
similar.

        -- Pete --

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

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

There are sources for some ableton link opciodes in the master tree; also 
examples in the manual tree but no manual page.



On Wed, 13 Mar 2019, Dr. Richard Boulanger wrote:

> Do we support Ableton Link.  If not, we should. That's a clock that many of my
> students could really use... and me too.
> 
> Dr. Richard BoulangerProfessor
> Electronic Production and Design
> Berklee College of Music
> 
> On Mar 13, 2019, at 5:19 AM, Anders Genell  wrote:
>
>       I would also appreciate being able to receive midi clock if that
>       would be possible. There is already support for sending midi clock
>       using the mclock opcode, so receiving the clock would be nicely
>       symmetrical.Also, if it would be possible, perhaps the
>       functionality of mclock could be more generalized, so that the
>       frequency could be varied at k.-rate, and some special value (like
>       a negative number) would make mclock send one single clock
>       message, so that external sequencers could be stepped at varying
>       intervals using e.g. the poisson opcode. Just a thought...
> 
> Regards,
> Anders 
> 
> On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve
>  wrote:
>       On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
>       > how about something like this?
>       >
>       > Add "rpnin" and "nrpnin" opcodes like yours, but rather
>       than having them
>       > respond to particular codes, let them return everything
>       relevant -- the
>       > selector numbers (from RPN:101/100 or NRPN:98/99) and the
>       data entry
>       > value (controller 6).  e.g.:
>       >
>       >       kmsb, klsb, kval rpnin
>       >
>       > or maybe:
>       >
>       >       kval rpnin kmsb, klsb
>
>       I wasn't thinking hard enough there.  Of course the above
>       would need
>       a channel parameter too.  And I think they should probably
>       be
>       'rpn7' -- and 'rpn14' and so on.  And should there should be
>       parallels to
>       'midic7' like 'midirpn7'?  (Maybe not.)
>
>       So:
>
>               kmsb, klsb, kval rpn7 ichan
>
>       or something.
>
>       I also forgot to note that there is one RPN that it does
>       recognize
>       (and has to!)  the Pitch Bend Range, which affects
>       'cpsmidib' and
>       similar.
>
>               -- Pete --
>
>       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
> 
> 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

Sorry -- the bleton link opces are un the manual  -- i was wrong


On Wed, 13 Mar 2019, Dr. Richard Boulanger wrote:

> Do we support Ableton Link.  If not, we should. That's a clock that many of my
> students could really use... and me too.
> 
> Dr. Richard BoulangerProfessor
> Electronic Production and Design
> Berklee College of Music
> 
> On Mar 13, 2019, at 5:19 AM, Anders Genell  wrote:
>
>       I would also appreciate being able to receive midi clock if that
>       would be possible. There is already support for sending midi clock
>       using the mclock opcode, so receiving the clock would be nicely
>       symmetrical.Also, if it would be possible, perhaps the
>       functionality of mclock could be more generalized, so that the
>       frequency could be varied at k.-rate, and some special value (like
>       a negative number) would make mclock send one single clock
>       message, so that external sequencers could be stepped at varying
>       intervals using e.g. the poisson opcode. Just a thought...
> 
> Regards,
> Anders 
> 
> On Tue, Mar 12, 2019 at 12:51 AM Pete Goodeve
>  wrote:
>       On Sun, Mar 10, 2019 at 11:32:20PM -0700, I wrote:
>       > how about something like this?
>       >
>       > Add "rpnin" and "nrpnin" opcodes like yours, but rather
>       than having them
>       > respond to particular codes, let them return everything
>       relevant -- the
>       > selector numbers (from RPN:101/100 or NRPN:98/99) and the
>       data entry
>       > value (controller 6).  e.g.:
>       >
>       >       kmsb, klsb, kval rpnin
>       >
>       > or maybe:
>       >
>       >       kval rpnin kmsb, klsb
>
>       I wasn't thinking hard enough there.  Of course the above
>       would need
>       a channel parameter too.  And I think they should probably
>       be
>       'rpn7' -- and 'rpn14' and so on.  And should there should be
>       parallels to
>       'midic7' like 'midirpn7'?  (Maybe not.)
>
>       So:
>
>               kmsb, klsb, kval rpn7 ichan
>
>       or something.
>
>       I also forgot to note that there is one RPN that it does
>       recognize
>       (and has to!)  the Pitch Bend Range, which affects
>       'cpsmidib' and
>       similar.
>
>               -- Pete --
>
>       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
> 
> 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