First of all, thank you for a wonderful product and all the awesome updates, LOVE the mod duo! The only thing that’s keeping me from using it full time is the lack of two-way midi parity. I use the Midi Fighter Twister to control my amp, pedals, and EQ. Unfortunately, when I switch pedalboards or presets, the Twister controls no longer accurately represent the new knob positions within the Mod. Could the mod please broadcast it’s updated midi positions on preset changes? Pretty please
Any insight where this falls on the dev team’s priority list? I really don’t want to switch to a kemper
Thanks again for the great work, love love love my Mod Duo!
This has not been considered before, I believe.
You might be the first one asking for such feature (though I can be wrong of course)
There is a sorta technical issue here, where we do not have a way to specify which MIDI ports to broadcast this information to.
Would it be okay to send this information to all connected MIDI devices (that can receive data) ?
Maybe there could be a global setting to disable midi broadcast if that behavior isn’t desired in some setups–though midi parity is the norm when mapping midi controls in DAWs and other contexts so it’s probably not a real concern.
We are not completely pairing in&outs at the moment though. Internally, things are still a bit separated, legacy from the days when the MIDI devices only sent data but did not care to receive anything
Preamble.
We all know that controlling MIDI with CC (or PC for that matter) is a sort of a one-way street. Here’s what I mean: if I have an external MIDI controller configured to swithch a plugin (say, a stomp box) on MOD Dwarf with a CC message (e.g. CC20 127 for “on” and CC20 0 for “off”), for the MIDI controller there’s no way of knowing in which state that stomp box is when Dwarf loads up a snapsot, so there’s a 50% chance that I have to press a footswitch twice(!) on the MIDI controller for the stomp box to change its state (the stomp box was ‘on’, the controller sent an ‘on’ message → nothing happened, upon a second stomp of the footswithc the controller sends an ‘off’ message → the stomp box switches off).
It’s even worse if you try to map a potentiometer and/or an encoder to a CC to control a knob on a plugin - the MIDI controller would never know what is the current position, or value, of the knob, and will send either the current physical - electrical - position of a pot, or an arbitrary value of an encoder, thus causing unpredictable step change of the knob’s value of the plugin.
Not an ideal situation. Unless there’s a workaround that I’m not familiar of. End of preamble.
So here’s an idea.
Why don’t we make MOD Dwarf mirror the values of those controls that are assigned to MIDI with the correspoding CC/PC messages through its MIDI OUT?
When a pedalboard or a snapshot is loaded, Dwarf could dump loaded initial states of all its assigned MIDI controls to MIDI OUT, and when an idnividual control changed its value via user interaction with the web GUI or via the external MIDI controller itself, that individual vaue would be sent out too.
This way, the external MIDI controller could pick those messages up, translate them into visual information for the user - on an LCD screen or via coloured LEDs, and control Dwarf in a smart way, sending ‘on’ messages for the plugins that are ‘off’ and vice versa.
This behaviour could be made optional (switch this ‘MIDI feedback’ on and off in a web GUI), and such MIDI feedback could be send via a specific (selectable) MIDI channel in order not to mess up communication of the rest of the MIDI devices in the chain.
P.S. Apologies for a lengthy post, I hope I got the idea across.
P.P.S. I know that MOD Audio has ControlChain for these kinds of affairs, and I even have built a CC controller which works well, it works ok, but the CC protocol is still pretty raw and unstable, and its develpment had been put on hold for far too long (for obvios reasons - insolvency, focus on the core product etc.). MIDI, on the other hand, works very smooth, lacking ony this kind of feedback.
This is not a device-specific feature, but is a software implementation that applies to all MOD units.
So I merged your new topic with the original one so that we don’t fragment discussions and requests over many topics.
hope you understand it is just 1 single person taking care of kernel + OS updates and maintenance, performance tuning, fixing software things in general, managing new plugin releases and updates, maintaining cloud infrastructure, plus support through these user forums and sometimes even helping in product fulfilment.
so time is always short, making hard to prioritize tasks.
while your work is very appreciated, the truth is that it is just not a matter of merging and being happy about it. we need to handle documentation for new features (which we are already not doing such a good job at…), then also giving support for any new features we introduce.
this means I need to understand the feature well enough to be able to find potential problems and explain it to users requiring support. as I have never used these MIDI devices that can receive feedback, it is something that I would still need to study and understand first.
(we already had the case of accepting changes from a 3rd party, that we now need to maintain ourselves without fully understanding it, so we are much more careful about such things)
anyhow even with the very thin focus within the company on the last couple of months, it was still not enough.
still hope to revisit this one day, but hard to say when that really happens, sorry.
It is indeed bad news that such a nice project is only maintained by 1 person… Resources should be focused on development of new features and making things as stable as possible, because that’s the main reason to buy these devices vs others…
If only I did not have already 3 jobs… I would be willing to help. I have made some minor changes to some plugins, maybe I will send some PR’s soon
@falkTX I wish you luck and better times soon. Cheers!
Yeah I understand, as I have said in another thread. You are totally overworked.
I didn’t want to keep merging Mod changes into my branch to keep everything updated without any indication of it would ever be used which is why I closed the PR.
