FluidPatcher Power Up

I was poking around in the Fluidsynth code as a result of trying to figure out a slick way to monitor MIDI messages and realized I could get FS to call my own custom python function to handle MIDI events, and do whatever I want to them and pass them on to the synth as needed. What does this mean? It means I can expand router rules to translate from one type of message to another, so if I want to make aftertouch affect a control change like filter cutoff, no problem! It also means I can throw midi events at my own callback to handle things like changing patches, tweaking reverb/effect settings, etc. – so I don’t have to rely on messily keeping track of CCLinks and polling CC values constantly.

I’m not noticing any increase in latency whatsoever with my python callback function – so I think this is going in the next update. This will be a bit of a breaking change, since the cclinks keyword in bank files will go away. Router rules will now have an optional target parameter, which can be another Fluidsynth rule type, or fluidsetting, effect, or some arbitrary name that gets handled by the specific patcher implementation, plus an arbitrary number of extra parameters that get passed as needed. If I’m a good boy and can figure out a way to do it cleanly, I’ll add a hack that translates cclinks keywords into the appropriate router rule.

This site uses Akismet to reduce spam. Learn how your comment data is processed.