Bug : Midi message ignored with lv2:enabled button toggled

Hi.
I made a plugin called Plujain Ramp and It seems to works well on the Mod Duo except one little thing.

source code is here :

The plugin is provided in two versions, Plujain Ramp and Plujain Ramp Live, the trouble only concerns Plujain Ramp Live. I need to explain one of its features to explain the bug.

Plujain Ramp Live provides 1 midi in/out port to synchronize multiple instances of the plugin without having a rolling transport and make very worked tremolo sounds. For this, it sends “Midi start” and “Midi Stop” messages to its midi output, of course it can also receive and treat this messages in midi_in.
The plugin contains a port named “Active” that has the property lv2:enabled, this port is needed because it prevents artefacts and plugin sends a midi message when it’s toggled (under conditions…).
On the Mod Duo only, a second instance of Plujain Ramp Live do not receive the midi message when the first one instance is actived/deactivated. I tried to change the Midi Start/Stop messages to Midi note on/off and it the same. I also seen that midi message has been well sent (tested with a fluid organ plugin).

I just tried to comment the line “lv2:designation lv2:enabled ;” of the “Active” port in the .ttl, and this way it works nice. But it’s a shame that this port doesn’t activate/deactivate the pedal button, and it will confuse the users. It also means I need to make another one version of the plugin for the mod.

Cheers.

1 Like

It’s a bit unclear to me what the problem is.
You wrote, your first instance send the midi message correctly? You wrote, "other " plugs receive the message. Just your second instance of Plujain Ramp, didn’t receive the message, or, didn’t act as expected?
So, do you expect that the second instance switch it’s own state from bypassed to enabled when receive the midi start message, or do it just set some internal used values?

I understand that it can be a bit unclear, it’s quite complex.

You wrote, your first instance send the midi message correctly? You wrote, "other " plugs receive the message.

Correct, that’s it.

Just your second instance of Plujain Ramp, didn’t receive the message, or, didn’t act as expected?

Second (or third, or more…) instance didn’t receive the message. I tried to modify the behaviour of the plugin directly at reception of message in code, but message never come. As I said, remove the lv2:enable in active port in the .ttl file fix this problem.

So, do you expect that the second instance switch it’s own state from bypassed to enabled when receive the midi start message, or do it just set some internal used values?

No, It just set some internal used values. I don’t know if a plugin can change from code its externals parameters… curiosity, is it possible ? desirable ?

No, that’s why I ask, it’s possible, but not supported by the LV2 specs and could lead to u-defined beehive.

So that sound’s indeed strange. I guess you talk about the case were the plugin (slave instance) is in enabled state. Then, indeed, it shouldn’t make a difference if a plug have defined a port with lv2:enable

So that sound’s indeed strange.

Yes I agree. It sounds like the bug would be: No midi message arrive to an instance if another instance of the same plugin has been deactivate during this buffer period.

I guess you talk about the case were the plugin (slave instance) is in enabled state.

Absolutely. Plugin has to be activated to make effect work, then midi messages decide if effect works. If plugin is deactivated, sound is bypass (except a little fade at deactivation to prevent artefacts).

That smells like a global var, didn’t it?

I just retried to see more about this bug.

That smells like a global var, didn’t it?

Humm, I really can’t see this on my side. And as I said, if “active” port has not lv2:enabled property, it works well. It would be strange to have this kind of trouble resolved by a commented line in a .ttl .
Maybe you talk about global var in mod code ?

The problem is that having not this port property means 1 more visible control port: a very useless and dirty on/off that is in front of the virtual pedal.
It’s ugly.
And this plugin works perfectly in Carla or Ardour, without this kind of troubles.

if your plugin port has lv2:enabled as designation, then it should not appear in the web-ui.
See https://github.com/moddevices/mod-ui/blob/master/html/js/modgui.js#L24

If it does appear, then something is wrong…

tinygain, fil4 and stuck plugins implement this lv2:enabled, so try and see if those are working.

Note that enabled is inverted from bypass.
So when plugin is enabled (value 1 on that port), the mod-bypass is 0.
And when mod-bypass is 1, enabled is 0.

Thanks falkTX for the interest.
But, the problem is not what you mean.
“Active” port is well hidden with lv2:enabled property and this behaviour is this one I want.
Please read the first post if you want to understand the bug, it’s quite complex.

Note that enabled is inverted from bypass.
So when plugin is enabled (value 1 on that port), the mod-bypass is 0.
And when mod-bypass is 1, enabled is 0.

It’s another thing, but I don’t understand this, by default mod offers an on/off button, not a bypass button.

the mod-bypass thing is just how it works internally.
we do not use on/off state, but rather the bypassed state.
But only important when looking at mod-host code.

anyway, I am not really sure I understand what the issue really is to be honest…
you are sending a midi message when the plugin gets enabled and disabled?

in mod-host, a plugin that is bypassed will not send or receive any MIDI events.
Have a look at the section in https://github.com/moddevices/mod-host/blob/d6f31d8e4f0fb84d72a1bcdbbdfd436b62454c61/src/effects.c#L1226
When a plugin is bypassed, MIDI output is ignored.

So this might fix things for you: https://github.com/moddevices/mod-host/commit/a2ef7a054d2072d5229e3712b9bd22691ef3de4b

I will do a test build for you and report back…

Yesss, thanks falkTX !
Seeing this, I am pretty sure it’s that !