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