my idea of the workflow is to keep it exactly the same as current implementation (all midi devices are immediately available for midi learn) but provide a way to connect plugins’ midi outs to the mod-host:midi_in port. There is still potential for user confusion because they might think that they must connect the hardware midi it to that port for midi learn (even though that connection is already made in the background).
This also will cause difficulty because when the user sends say CC#5 through a filter which converts to CC#20 which then goes to the host midi_in port, clicking midi learn and turning the knob will recieve both CCs, one from the HW and 1 period later the one from the plugin.
this causes a major deviation from the current midi learn implementation because all HW midi are connected to the same input port of the host which controls the midi learn for all the plugins. We’d have to break it out into separate, per-plugin ports for that to work. So while it would seem about the same to the user which is nice, the backend would need a lot of change.
Perhaps a meet in the middle option would be to add a button that produces a midi learn port on a plugin which will make the host disconnect “global” midi learn to that plugin and produce a new jack midi-in port specific to that plugin that the host treats separately to the “global” midi in. The UI would have to add that port when its selected and it adds quite a bit of complexity to the host. So that could possibly be the most work of all of the suggestions, but perhaps could cause the least user confusion? It also would allow for 1 midi CC to control several parameters (since the host would be going through the event ports separately).
I think its a good idea to flesh out what the best workflow is before anybody does any work on it. Better to wait until we can do it right than a shoddy implementation that never gets fixed.