LED display with switchbox

Contribute Feature Requests
#1

When I assign the channel parameter of SwitchBox2 to a footswitch, it would be helpful if the LED toggled between off and (say) red. This is much easier to see than a small number 1 or 2 in the display.

5 Likes
Effect Loop with blend knob Plugin?
#2

This is working like this because the parameter is not an on/off switch, but a list / enumeration instead.
a mixed mode of list + toggle is worth implementing though, we added to our feature backlog. thanks

1 Like
#3

Personally I don’t like the idea to use “led off” and “led on” to represent items of a list. This can be easily confused with other functions which already use these representation.

#4

I’m not proposing to do that in general. But when the “list” is simply two numbers “1” and “2” then semantically it’s not a normal list but simply a toggle between two options, and in that context it’s barely any different from an on/off switch.

Also, I don’t see much risk of confusion, because the existing display on the LCD screen would not change from how it is now, so it would still be equally clear what the footswitch is controlling.

1 Like
#5

Any update on this? I still use 2-way switchboxes on gigs and it makes performances a lot harder when I can’t immediately see which route is being selected due to the LED being permanently green. Thanks.

#6

I looked into the source for this and found where the input switch is defined as an lv2:integer:

Why was it done this way? Wouldn’t it have been more logical to define it as an lv2:toggled property, like the HardwareBypass plugin does?

I’ve never hacked on MOD plugins, but I’m guessing that switching the parameter type would be enough to fix the LED display issue described in this thread.

1 Like
#7

I suspect its line 46, the enabled designation that makes it behave differently. You could try tweaking it and installing your updated version to check.
I agree it would be nice to have some way to get visual feedback on the state.

1 Like
#8

Nope, the line 46 you are looking at is in a completely different plugin (HardwareBypass), which I quoted as an existing example of a plugin which successfully uses lv2:portProperty lv2:toggled. In that case, IIUC the lv2:designation is designating the port as being the parameter which controls whether the plugin is enabled or not.

I suspect it should be enough to switch the lv2:enumeration to lv2:toggled, and then make the corresponding changes elsewhere in the code to match.

Sure - but before trying that, I was hoping for an answer on whether there’s any good reason why it wasn’t done as a toggle in the first place. I’d like to avoid the risk of burning a bunch of time on a pointless exercise :wink: Especially since I haven’t set up the MOD plugin SDK at all yet and that alone will take some time.

#9

I did realize that. I didn’t think though that there are plenty of toggle ports that aren’t bypass ports that you can map the footswitch to to test. Its not something I’ve tried.

I suspect because they wanted to keep open the idea of using the same code for a switchbox 3, switchbox 4, 8 etc. I can’t speak for them though.

Actually to the code an enumeration with just 1,0 will appear the same as a toggle, so you should be able to just ssh in and edit the file to test without recompiling.

#10

Ah yeah, good point - that would make sense.

Oh wow OK, thanks a lot - I’ll try this!

2 Likes
#12

I need too

#13

I use xfade stéréo, clean sound on left oupout and fx on right output, signal to B and assign ON/OFF to the toggle switch. The led is off and the signal go through exit A, when I active the switch , led turn red and the signal go to out B :