On Fri, 13 Dec 2013, rpcfender@... wrote: >> "So the knob would emit: B8 63 00 B8 62 val" > > Did you see if the ESQ-1 would accept a single B8 63 00 message on a > button and then B8 62 xx B8 06 val with a different value of xx for > each encoder? No...but the only reason I didn't try that is because most of the delay is created by the ESQ-1 updating its display every time a NRPN is received to make it select a parameter, switching to a whole different screen if necessary, and trying to repaint the screen several times a second if the NRPN's come in rapidly. If I was to put any part of the NRPN on the same encoder that's sending the data entry slider CC's, that NRPN would get resent for every change of value as the knob turns and you'd have the same problem (the display goes bonkers and the ESQ-1 can't keep up). It doesn't matter because it seems to need a whole MSB/LSB pair anyway, but if it worked with LSB alone, it'd still end up repainting the display, just with fewer Midi bytes to get it done. What would be needed is a feature I don't think the BCR has (BC Manager seems to have implemented everything it can do, and I don't see this feature anywhere in it): It would be nice if the BCR let you setup a string of custom bytes *as a header*, to be sent once at the beginning of a knob rotation, and not repeated again until the knob stops turning. That would let you have your cake and eat it too... You could have lots of knobs that each spit out a single NRPN message (or whatever you wanted) when you start turning them, but then they be quiet about the NRPN and just send their main code for as long as you keep turning. If you grab a different knob, it sends the header code for that knob, and then does the same thing sending that other knob's regular code only instead of putting the NRPN code into every single value change. That's what you'd really need to do this. I think Behringer doesn't allow that because it would create the situation where the user would need to be warned that if you setup your controller this way, there will be no turning two knobs at once for that synth. You can't blend together two simultaneous tweaks unless every single parameter change that gets sent is also paired with a NRPN parameter select that lets the target device know what that particular parameter change is supposed to be an adjustment of. It makes every parameter change effectively end up being nine bytes long of course, but at least then you can grab two knobs at once and tweak yourself silly (on a modern synth that can keep up with it, and isn't trying to repaint its screen every time it gets a NRPN). And you can even turn two knobs at the same time. By not supporting a header feature like this, Behringer's tech support doesn't have to explain anything because it can't do it anyway. Considering that Behringer won't even fix BCEdit to make it as nice as BC Manager is, I think they're basically at the point where they'd like to just make money on the BCR and BCF and not really make any more improvements, so we're probably not going to see any "header code" feature added (or anything else) now. > Can you change encoders with out having to send another B8 63 00? I did try that... It needs a full MSB/LSB pair to select a parameter on the ESQ-1, even though the MSB is always zero. So you send "B8 63 00 B8 62 val" to select something, and the ESQ-1 updates its display, but anything less doesn't do anything at all. > When you output B8 63 00 B8 62 val with an encoder I would think the > ESQ might prepare by changing the screen and wait for the value > message to follow. So with your method it is frantically changing > pages for parameters you are not interested in changing as you scroll > through??? Yes, but at least the way I've set it up now, I have it broken up into two different knobs, and only the parameter selection knob does that. Once you find your parameter, the other knob just sends data entry, and it has no problem with that. Also I've setup the first knob to have only 20 values per rotation in BC Manager, so it keeps me from flipping through parameters too fast. -- + Brent A. Busby + "We've all heard that a million monkeys + Sr. UNIX Systems Admin + banging on a million typewriters will + University of Chicago + eventually reproduce the entire works of + James Franck Institute + Shakespeare. Now, thanks to the Internet, + Materials Research Ctr + we know this is not true." -Robert Wilensky
Message
Re: [bc2000] RE: BC Manager gurus
2013-12-14 by Brent Busby
Attachments
- No local attachments were found for this message.