On December 25, 2015 10:02:21 PM you wrote: > If I may ramble on a bit, you might find this interesting. > > Concerning keeping internal midi paths 'clean' and 'verbose' > as you mentioned: > > In my branch midi_engine_fixes I'm trying to add full support > for 14-bit midi input controllers (such as surfaces etc). > > We already fully support 14-bit controllers for /output/ but > NOT for input :-( > > > In the MusE internal midi path, 14-bit controllers are already encoded. > I mentioned I'm working on a custom controller 'encoder' class. > > For reasons I could write a book about, I have to consider > one of two options (at least for midi controllers): > > 1) > There would be /two/ internal midi paths in MusE: > One path is verbose un-encoded raw input (separate hi and lo > byte controller events) and the other path is encoded events > (14-bit controllers - our so-called "internal controller types" > found in midictrl.h). > > Or > > 2) > Unlike our current single internal path of already-encoded events, > this single path would instead be un-encoded raw, and each > 'consumer end-point' has its own instance of an encoder. > (In MusE there are several types of internal 'consumers' ranging > from recorded event lists, to graphical numerical readouts which > want to conveniently display complete encoded 14-bit values yet > it is conceivable a user might want to view them as separate.) > > > It is extremely tricky. > Chiefly because with (N)RPN 14-bit controllers, you could receive > the hi byte, the lo byte, or both intended as a single 14-bit unit, > at any time in any order. If you want smooth 14-bit encoding > where a new 14-bit value is passed through MusE /only/ when > both hi and lo byte have been deemed to have been 'received' > even if one was not, it requires a timeout timer while you wait > to see if the other byte will arrive soon. > > Some controller surfaces may have separate knobs for hi and lo byte. > Others may have a single knob for the entire 14-bit range, and > some can do 'delta' modes where it's continuous movement. > Achieving 'smooth' encoding in both these scenarios is tricky.
Also consider the complete midi 'patch' consists of up to three bytes: HBank, LBank, and program. If a controller surface can send all three as a decoded 'unit' (the user selected a patch name from a complete list), we should avoid glitches in between receiving the three messages, by waiting until all three have been received (or not) before switching a patch. > > > Well, wish me luck, eh? > Tim. ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
