Oh, cool. To be clear, there's nothing like a mixer here, right? But if I plug in a splitter it's safe to use either one of [left audio channel 3.3V range] or [left modular channel 5V range]?
I'll try this, I think I might need to add some debouncing but it should be enough for now. But, it seems like it would be better if the OpenWare layer handled this, because if I did it this way wouldn't the parameter get "stuck" if you turned it all the way to the 0 or 1 limits? OpenWare "knows" that the rotary encoders are rotary encoders but my patch does not, my patch only knows it's looking at a value between 0 and 1.
Well, I wasn't thinking of the little "all inputs" thing at the bottom, I was mostly thinking of the separate "big" bar right above it. There's the grid of bars at the bottom, but above that there's a label for the last parameter turned and a bar for just that last parameter. OpenWare knows which parameter is being displayed there at any one time, but I don't. If I knew what parameter it was displaying I could erase the bar and draw in text of my own.
(I find an onEncoderChanged in patch.h, which could potentially solve two of my problems above because I could (1) get a raw encoder delta out of it and (2) use it to track which knob was last turned, but in both cases I don't know how to find out which parameter the menu interface has currently mapped to which knob.
By the way, what does the "samples" parameter on encoderChanged and buttonChanged mean?)