The direct-midi branch of flickernoise.git now contains experimental support for directly assigning MIDI controls to variables from within a patch:
https://github.com/milkymist/flickernoise/commits/direct-midi This mechanism bypasses the MIDI settings. Instead, the patch has to know the channel and controller number(s). The channel number can be chosen freely and the number of MIDI controls is only limited by the number of registers. Here is a variant of Tornado Rain Dance that uses the new mechanism for the Faderfox LV3: http://downloads.qi-hardware.com/people/werner/tmp/T.fnp There are 16 MIDI controls: "whirl" through "sensitivity" and "red" through "change" are the same as before, just with names instead of midiN. They're assigned to the eight faders. "twist" is on the first encoder and allows fine-tuning of the rotation speed. Note that this control is bounded, so it will stop at 0 or 1 even though the encoder can be turned beyond the limit. This can be improved in the future. "theta" changes the angle at which the wave is drawn. At slow rotation, this changes the place where the "cloud" begind. At fast rotation, it changes the angle of the pattern, similar to "twist", but without affecting the curvature. It's on the second encoder and is cyclic, making its use a bit more intuitive than "twist". I've also assigned the two joysticks to sx/sy and dx/dy, but the results don't look very interesting so far. The joysticks are disabled by default and can be enabled by pressing the grey button in the respective FXn group. So what does all this provide at the end of the day ? - removes the restriction to one channel at a time. Devices like the LV3 use multiple channels. - removes the 8 MIDI controls limit - allocates registers for MIDI dynamically - supports different translations of controller input, according to how the controller works and what the patch needs. Note that the old midiN mechanism still exists in parallel and one could even mix the two in the same patch. What still needs doing: - more translations, e.g., for unbounded linear mappings, - cleanup, such a range checking for channel and controller, and a few changes to implementation details like internal APIs, - see if we can do with a bit less copying, - check that we don't have any nasty performance regressions, - add a device-specific abstraction layer so that we don't need to hard-code controller numbers in patches. This still needs more thought. I'll probably also make more changes to the syntax. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
