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. Well, wish me luck, eh? Tim. ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
