mod-role="input-control-port" silently fails for plugins using patch:writable parameters

[bwanab]

When writing a modgui skin for an LV2 plugin that exposes its parameters via patch:writable (the atom/patch protocol) rather than traditional lv2:ControlPort ports, using the documented mod-role="input-control-port" in icon.html causes knobs to render correctly but not respond to interaction. There is no error or warning — the knobs simply do nothing when dragged.

Root cause

In modgui.js, assignControlFunctionality populates self.controls from effect.ports.control.input:

self.controls = self.makePortIndexes(effect.ports.control.input)

For patch:writable plugins this list is empty (only internal ports like enabled and freeWheeling appear there, both with
pprop:notOnGUI). The binding code then looks up the knob's mod-port-symbol in self.controls, finds nothing, and silently skips the entire binding:

var port = self.controls[symbol]
if (port) {
// bind the knob — never reached for patch:writable plugins
}

Affected plugins

Any LV2 plugin built with JUCE uses patch:writable exclusively for all parameters. This includes the entire Surge XT effect suite and any other plugin exported via JUCE's LV2 support. The pattern is increasingly common.

Workaround

Use mod-role="input-parameter" with mod-parameter-uri set to the full parameter URI instead:

This is undocumented in the SDK and not mentioned anywhere in the modgui skin examples or wiki. A developer following the standard
examples will produce broken skins for this class of plugin with no indication of what went wrong.

Suggested fix

Either of these would resolve the issue:

1. When input-control-port + mod-port-symbol finds no match in effect.ports.control.input, emit a console.warn identifying the
   unresolved symbol. This costs nothing and would immediately surface the problem.
2. As a deeper fix, fall back to checking effect.parameters for a parameter whose URI ends with :symbol. If found, bind using the
   lv2PatchSet path. This would make input-control-port work transparently for both parameter types.

[bwanab]

Additional symptom: MIDI CC / OSC parameter binding is completely unavailable

Beyond the modgui knob-interaction failure described above, the same root cause produces a second showstopper: no parameter on a patch:writable plugin can be mapped to MIDI CC or OSC in the MODEP settings panel.

For traditional lv2:ControlPort plugins, each parameter in the settings panel shows a small mixer icon in the lower-right corner. Clicking it opens the MIDI CC / OSC assignment menu. For any patch:writable plugin — which means any plugin built with JUCE's LV2 backend — that icon is absent for every parameter. The parameters are visible in the panel but are entirely unassignable to MIDI or OSC.

The cause is the same effect.ports.control.input emptiness described in the issue body: the MODEP UI populates MIDI/OSC binding controls from that list, and for patch:writable plugins the list contains only enabled and freeWheeling (both marked pprop:notOnGUI), so it is effectively empty.

Why this is a showstopper for JUCE-based plugins

JUCE's LV2 exporter uses patch:writable for all user-facing parameters — there is no option to emit lv2:ControlPort instead. This covers:

• The entire Surge XT effect suite
• DISTRHO-based plugins
• Any other plugin built with JUCE targeting LV2

MIDI CC control is not a convenience feature on MODEP — it is the primary mechanism for real-time parameter control via expression pedals, MIDI controllers, and automation. Without it, a plugin's parameters are static for the lifetime of a pedalboard session. This makes JUCE-based LV2 plugins unsuitable for live use on MODEP, regardless of how well their modgui skin is crafted.

The modgui knob workaround (mod-role="input-parameter" + mod-parameter-uri) fixes the visual interaction in the icon, but there is no equivalent workaround for MIDI/OSC binding — that is entirely server-side and modgui has no influence over it.

A fix at the effect.ports.control.input population layer (falling back to effect.parameters for patch:writable plugins) would resolve both symptoms simultaneously.