The direct-midi branch of https://github.com/milkymist/flickernoise contains the development version of my improved MIDI support for Flickernoise. Among its features are:
-the number of MIDI controls is only limited by available PFPU registers, - MIDI messages can come from any channel, - device description is separated from the functions the patch expects, with automatic translation of (some) semantics, - user-assigned names instead of hard to remember midi1, midi2, ... A variant of Tornado Rain Dance that uses the new MIDI style is here: https://github.com/milkymist/flickernoise/blob/direct-midi/experimental/T.fnp And here's a draft of a description of how it all works: http://downloads.qi-hardware.com/people/werner/m1/tmp/midi-draft-20120215.pdf Open issues: - there are currently keywords like "fader" and "pot" for control elements that are basically identical as far as Flickernoise is concerned. This may change when a GUI is added in the future, where fader and pot could be represented by different symbols. However, I'm not sure this is really how we want to convey such information. An alternative would be to just call all these things "range" (like the function - see the manual for this terminology) and then have some GUI-specific parameters or qualifiers that define the visual representation. - I'd also welcome feedback on the names I've picked, particularly "range". - while I hint at a naming convention for control elements in the manual, I haven't really come up with one yet. Ideas welcome. Good names should make it easy to write patches that work with a large set of devices. And of course there's still more to do: - generalize to keyboard events, DMX, IR, etc. The documentation also meanders between being MIDI-specific and trying to use more general language. - generalize to other actions than changing patch variables. E.g., events should also be able to switch patches, etc. - separate the device database from the patch file. Ideally, a patch should not have to carry any device database information. I think it makes sense to allow a patch to optionally provide a device database, though. - add the ability to identify MIDI devices and use this to constrain element selection. This is the biggest missing feature. Right now, Flickernoise simply assumes that any declared device is really available. (And ignores the device designator.) - retire the old MIDI system once the new one covers all its functionality. Anyway, I think the new MIDI system is useful in its present state. So if nobody objects, I'd merge it into the master branch and return to working on the remaining bits in a few weeks, after tackling a few other items on my to do list. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
