Greetings.
How do I receive changes to Registered Parameters?
There are:
midichannelaftertouch midicontrolchange
midinoteonoct midipitchbend midipolyaftertouch
midiprogramchange etc.
but no midiregisteredparam :-(
and yet there must be a registeredparam mechanism in csound, because if I send it a cc100, then a subsequent cc6 is not seen by midicontrolchange 6 ! so the cc100 command must have triggered some registeredparam code somewhere...
(I'm using csound 5.12 on debian squeeze)
Peter Billam
www.pjb.com.au
All undocumented!
Hello Peter. So -- we meet again... [insert villainous laugh] (:-)) I left it for a while in hopes someone would respond, but as you remarked elsewhere it's pretty much of a desert around here.
Meanwhile anyway, you got me digging around in the sources, and I found that it's pretty much an undocumented ad hoc hack (undocadhack?) In the first place, the code doesn't distinguish between RPNs and NRPNs! It lumps the MSBs and LSBs of the two together, and then decodes only certain ones -- pitchbend range, and a few GS NRPNs that I knew nothing about. The PB-range apparently gets plugged straight in to those opcodes that know about bending. Some of the NRPNs get stored in controllers 128+ (above the MIDI range), and others are for a "Drum Map" that is not in my ken.
So it seems if you want general access to (N)RPN values, you're out of luck. If you don't use CC 99-101, it looks as if CC 6 is passed like any other controller, but otherwise it'll be used as a data-entry value and not passed. At least Csound5 is better than 4! In 4, "unused" CC3 is used as the data-enable flag, and the handled NRPNs are put in "unused" CC109+!! Completely screwed up someone's program I was looking at that wanted to input CC1..CC8! (And of course the cause was totally obscure until I started researching your question.)
It's a bit shameful that none of this is documented anywhere. Not even the source code has much in the way of comments, but at least you can see what's happening. Probably time to push for some cleaning up. I don't think it would hurt, actually, to simply pass all the CCs, including 6 and 99-101, through to instruments that wanted to use them (in addition to keeping the special handling that exists now).
-- Pete --
Oh -- one more thing... (:-))
Of course the moment I log off, I find one little item that escaped my notice...
There is a command-line flag:
-+raw_controller_mode=yes
that apparently inhibits all the stuff I was talking about above. CC0-127 then all get passed without other messing about. With luck it will let you do what you want to. Of course that includes things like sustain, so it might complicate other desires.
I found it in
http://www.csounds.com/resources/Csound5_02_0_ChangeLog.txt
searching for "RPN"
Not quite that easy...
Pete wrote: I don't think it would hurt, actually, to simply pass all the CCs, including 6 and 99-101, through to instruments that wanted to use them
I'm not so sure :-( For example, to change the Pitch Bend Sensitivity, you'd send a sequence like this:
cc101=0, cc100=0, cc6=0..24 semitones, cc38=0,
cc101=127, cc100=127
and that would be over in a fraction of a millisecond. Then my csound program checks if cc100 has changed, and it hasn't, because it's been reset to 127 already. Therefore if cc6 has changed, is that supposed to mean Modulation Depth Range, or what? This typical sequence of cc's is too fast to be intercepted by the script, at the k-rate level. Surely it has to be handled in the code...
Peter :-)
Yeah...
I still claim it wouldn't hurt... (:-))
(because I wasn't suggesting dropping the old scheme), but I guess you're right -- it wouldn't work either.
Csound's MIDI handling is obviously rather defective when capturing a strict sequence of events is critical. As I sort of said earlier, it's perhaps time to do some rethinking. It's a pity that the current major (Csound) players don't seem to drop in here often if at all. I checked the Csound mailing list a little while ago, and it seems to be quite active, but I have an aversion to joining mailing lists. I'm on just one at the moment, and probably spend half-an-hour or so each day checking it -- and occasionally posting.
Back to improving MIDI handling: my quickie suggestion would be an optional Controller-event Queue for an instrument. A new opcode could set up the queue, and then even current opcodes like midic7 could read from the queue once each k-time. Though maybe it would be better to add new queue-reading codes too, and let the current ones continue to read static controller state.
At some point I might work on this myself, but I'm more concerned at the moment with helping to get the Haiku OS to a point where I can use it for audio stuff.