Two-way Midi Mapping

Hi Mod Devs!

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 :slight_smile:

Any insight where this falls on the dev team’s priority list? I really don’t want to switch to a kemper :moneybag:

Thanks again for the great work, love love love my Mod Duo!

-Mark

My setup:

And my midi fighter twister mappings:

6 Likes

Not really what we’re looking for:
https://forum.moddevices.com/t/display-updated-values-on-my-midi-controller/

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) ?

2 Likes

Absolutely, that would be perfect.

2 Likes

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

1 Like

I’m currently trying to get some interaction with the Roland FC-300 (see 2. at https://forum.moddevices.com/t/mod-duo-roland-fc-300-midi-foot-controller/).
If a solution is going to be invented, maybe it makes sense to make the feedback somehow mappable to specific MIDI commands.

2 Likes

Ok, this has been asked for before on this forum, only for MOD Duo.
So please consider this as a feature request for MOD Dwarf.

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.

7 Likes

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.

Whatever, as long as it gets implemented.

It looks like this feature request, no ?

There is even a code solution in there

I also asked for this kind of feature here : Send Midi CC after Change Program or Snapshot - #2 by Rom

2 Likes

I did have a fully working solution and a PR put in, as nothing was done about I removed the PR as it would go stale.

Sorry.

2 Likes

I don’t understand this practice. Having the PR visible is much more useful than randomly closing things, no?

1 Like

Just while it is closed didn’t mean it isn’t visible any-more.

Really impressive work, by the way.

4 Likes

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.

6 Likes

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 :smiley:

@falkTX I wish you luck and better times soon. Cheers!

2 Likes

@falkTX

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.

2 Likes