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:
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! 
]
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:
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]
Hi @Joal_ban_Kluane, no worries at all! The forum is here to help you find a solution for your doubts and if you still have them, it’s ok to ask 
I’m also happy that you are already preparing to receive your new Dwarf 
Going through your questions:
- use external MIDI events (notes, PC) and use them to trigger CC events for controlling MOD plugins
yes, you can already do it. A plugin like this will help you.
- “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)
When you are making your assignments you have an Advance Settings stretch window that allows you to define ranges, this will help you solve these issues. Check more about it here.
- 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 more focused changes and more parametric control.
This is not possible yet. For now, an actuator on the units or on external controllers can only be assigned to a single parameter.
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).
You can configure your device to listen from All MIDI inputs simultaneously or each of your controllers independently. You select that option on the WebGUI. Check it out here.
Overall, there are a lot of MIDI plugins that allow you to manipulate your MIDI inputs or generate them in a huge variety of ways. Check the list here.
Hope that you got the answers that you were searching for
Hi @jon, thank you very much for the answer - indeed I become more and more excited for the Dwarf, I have (too?) many plans for it
Regarding the first point, indeed the plugin is nice, what I was thinking though was the ability to take the output of such a MIDI plugin, and use that as a means to control e.g. a reverb plugin (which does not have MIDI input) - not sure if I expressed properly 
Regarding the other topics, it looks like I may have to study more 
Some of it may have to wait for the Dwarf to come (and it looks like v1.10 is going to bring a lot of new nice features, this is quite interesting!)
You’re welcome
Glad that you have many plans for the Dwarf (here between us, we are all excited about it!)
The plugin is just a converter, for example, to use a note from a MIDI keyboard as a on/off toggle for an effect. I’m not completely sure if I got it, but all the plugins are suitable to assign any parameter. The plugin doesn’t really need to have a MIDI input. MIDI inputs are just necessary for generator plugins in order to “supply them” the notes.
Indeed the version 1.10 will bring important new features. Perhaps when your Dwarf arrives you will also understand better how it can answer all your needs.
Anyway, before or after it arrives you are more than welcome to post in the forum your doubts or suggestions.
Thanks. I think I should better describe the use cases:
(1) for example, I use an overdrive pedal, and I want to turn it on and off using my LPD8, but the pad in the LPD8 generate a velocity-sensitive CC, while the midilearn expect on to be CC with value ≥ 64 in order to be on: this forces me to press hard on the PAD to generate an ON event (no problem for the OFF event, which is 0 on the LPD8), therefore I need a way to change CC values 1 and above to be changed to 127 and the output of that to be used to control the pedal switch;
(2) for example, I want to be able to change the same “drive” value from both the LPD8 and the FCB1010 foot controller.
(3) for example, I want to be able to change the “drive” value from 0 to MAX, while adjusting the Tinygain after it from 60% down to 40% simultaneously (i.e. one controller to control 2 potentiometer, and more, with different scale/direction).
So far, none of this is possible with just using midilearn (at least, not with 1.8, which is what my test MODEP setup uses).
On a real MOD device, from 1.9, it looks like I would be able to do some (or all?) of these use cases by using CV: using CC to affect MIDI-to-CV plugins, manipulate then the CV signal as wanted, and getting the drive and tinygain to use the named CV output for controlling the parameter.
Is this so? How much CPU would I consume by going this way ? The original midi events might be pretty rare, but I understand the CV plugins themselves would provide a CV signal and run continuously. Also, this might mean I need to have a way to easily replicate the MIDI-to-CV setup easily from pedalboard to pedalboard.
It would therefore be nice to have the capability (if not added already in 1.9 - I couldn’t find the details whether it’s there already) to name MIDI plugin output ports, like we can name CV output ports, and when assigning to controls, telling the UI to listen to that MIDI plugin output port only.
In the meantime, when I have the time to do it (probably over Christmas), I’ll try to test another way altogether, and use the “mididings” tool, that would create in & out interfaces between which I can run arbitrary python scripts enriched with MIDI event manipulation rules… it should allow me to fulfil all the use cases.
It might be a bit cumbersome to first create the rule, and also to make sure the midilearn functionality of the MOD UI gets the right event (ie the one from the mididings output, rather than the one from the source controller), but that should be doable with getting mididings to generate the same CC event from a NoteOn event for example.
Then, of course, the big question will then be how to integrate that with the MOD dwarf when it comes (eg. would I be able to run mididings on the dwarf? or would I have to create a bit more complicated MIDI routing setup to send all my MIDI events to the Raspberry Pi and back to the dwarf once they are modified?), but that’ll wait until the MOD Dwarf comes.
Hey @Joal_ban_Kluane, I will take it by parts. Hopefully managed to understand what you need and how can I help you.
If I understood correctly you want it to work as a momentary switch (and are aware that that’s what will happen). Basically, this just switches the overdrive pedal on when you push the button.
I would take a look at the LPD8 settings and check if you can edit the velocity sensitivity there. I’m not so familiar with the LPD8, not sure if there’s some sort of MIDI editor for it (Is there something like that?)
This is theoretically not possible. By this I mean: you can’t assign two controllers directly to the same parameter.
Yet, you can get “creative” and maybe you will find a nice workaround. I suggest you to take a look into the CV plugins. Check also this tutorial.
Again, unfortunately, you can’t assign nor two actuators (from MIDI controllers or on the MOD device) to a single parameter, nor assign a single parameter to multiple parameters.
Exactly this is what I suggested. The CV plugins don’t take much CPU, they are fairly simple, so I guess you don’t need to worry much about that.
Regarding the replicate specific parts of the setup, this is something that we are taking care. Hopefully, in one of the next firmware updates, there will be a feature that allows you to create pedalboard blocks. You must wait a bit longer though.
This feature is just available with the CV plugins.
I would also suggest you to MIDI loop the output and input of your device (externally). It may help you in some way (?)
Not sure if I got it properly, put you can send them over the MIDI input of the Dwarf
Hey!
Hope you don’t mind me chipping in
I don’t actually have a MOD device (yet) to see if this would work as expected but I think something like this could get close to the same effect, even if it works in a different way.
Path A: Drive 0, tiny gain 60%
Path B: Drive MAX, tiny gain 40%
Set up the two paths in parallel.
Use a cross-fader (eg Stereo X-Fade) to blend — using one knob — between Path A and B.
I imagine there would be some trade offs, especially in the middle, but maybe these can be minimised with careful use of the settings and fade shape.
Hopefully it:
or it inspires a different solution which works better
Maybe someone with a device can let me know if this won’t work at all.
Let me know how you get on!
Edit: image for clarity
@danmh feel free to chip in as much as you want
If I got it right, your idea is possible.
As long as you are trying to simply pair one physical actuator with a single parameter on your pedalboard, it will work.
