"MIDI learn" from arbitrary point in pedalboard

it would be nice to be able to control a plugin parameter with some transformed MIDI, rather than with the MIDI as it arrives at the hardware input. so, essentially, using “MIDI learn” with the MIDI signal ~after~ some MIDI plugin which scales/re-maps/whatever.

currently, for audio plugins which have no MIDI input, there’s no way to access transformed MIDI data for control, right? or am i missing something?

I believe it is as “simple” as adding a mod-host midi output to the pedalboard so you can connect any plugin midi output to the same hidden midi input the hardware midi ports connect to for midi learn. However I haven’t yet been able to hack it to add that. If anybody else wants to work on it with/for me let me know and we can confabulate.

The problem with this is that it makes things a lot more confusing to the user.
Right now all attached midi devices can be used for CC/learn straight away.
Adding such port means the user has to:

  1. enable that port via “midi ports” dialog
  2. connect the new port to the designated midi-learn/cc one

The base idea here is nice - allowing the user to modify the raw midi device messages - but an extra port on the gui seems like a bad idea to me.

what if you could right-click on the MIDI-out port of a plugin, and have a dialog come up which allows you to check a box to designate it as available for MIDI-learn, with text-entry to name that point in your pedal board? then, once you’ve designated it that way, that port shows a star beside it or gets a different colour or something, so you can easily see which ports are sources for MIDI-learn.

then, when you ask for MIDI-learn on a plugin parameter, you get a combo-box listing all the available designated MIDI-outs, along with the usual direct hardware MIDI, and you can choose which one that parameter learns from.

…so everything could just operate the way it does now, until the user designates any ports, at which point the choosing dialog shows up when asking for MIDI learn. i.e. this just expands the current implementation…

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.

cool… thanks for the backend clarification!

whatever way it goes, personally i think it would be good to maintain the possibility of a plugin learning from BOTH the hardware MIDI in and from the MIDI out of another plugin. yes, that presents the possibility of two (or more!) sources of a given CC, but i’d say it’s the responsibility of the user who chooses to engage in such a setup to resolve conflicts intelligently.

[ OT: btw @ssj71 , i’ve used your “infamous” stuff before, and just installed “stuck” from unstable! :slight_smile: ]

I agree, but you could still connect the HW midi to the plugins’ individual midi learn/modulation ports so you still have both.

sorry for digging up such an old topic, however, this does seem unresolved… note that I am waiting for my MOD Dwarf, so I can’t test any of this yet.

I was wondering if the possibility to control MOD plugins from MIDI plugins has become a reality yet ?

Some cases I see:

  • use external MIDI events (notes, PC) and use them to trigger CC events for controlling MOD plugins
  • “fix” external CC events (in my case, I have a LPD8 MIDI controller which has sensitive pads, and when sending CC events, it would use the velocity as CC value ; however, it seems that on the MOD, to toggle on a switch in a plugin, the CC value has to be above 64, which would force me to press quite hard on the pad ‑ I would like to be able to use a MIDI plugin to fix the value from “>0” to 127, and use only “0” to toggle off)
  • use one source event to trigger multiple plugin adjustments in different ways simultaneously (change values here and there, switch on/off, etc) a bit like the snapshots but with a more focused changes and more parametric control.

It would also be nice to be able to tell the MOD from which inputs (HW MIDI interfaces or MIDI plugins) it should get MIDI learn events… the idea of an optional “MOD Host” outgoing MIDI interface could be nice, and if anything is connected to it, it would only listen to these connected events).

[actually, what I would really like is the ability to manipulate MIDI events in the way of the Midihub from Blokas, possibly as a separate “pedalboard” tab or something, but I expect this would be a major endeavour]