I made a very simple pedalboard where I have a switchbox plugin to route the flow between two chains of plugin.
I then bound the switchbox channel parameter to one of the Duo footswitches.
The plugin works perfectly, but the led light on the dup is always green, and so it’s difficult to see at a glance the state of the pedalboard.
Is it supposed to work this way or is it a bug?
Green color is used for trigger controls, or if the parameter is a list.
So this is working as intended, though in this case indeed it is not optimal.
Not optimal is an understatement. I find it nearly unusable.
The problem here is the lack of a clear visual feedback of the footswitch state in this case. The label reposts the number of the selected channel, but it’s absolutely non readable in live stage standing situation. The only way of knowing what channel are you going through is strumming, and that’s a no-no.
All in all it’s an interface issue. Like I have pointed out other times, the Duo interface is not suited for a live standing user. It shows you the current state of the active knob parameter, which is not of much use while you’re playing, and you can’t see basic info like the pedalboard name or snapshot.
Do you think it would be difficult to have the parameter area of a screen briefly showing the state of the parameter bound to a footswitch when it’s pressed? this would be a reasonable workaround.
An alternative (or additional feature) could be to have “short list” parameters (those with a boolean parameter ranging 0 to 1) to behave both as list plugins and on/off plugins.
I mean, when it’s on 0 the led would be lit green, and when on 1 the led would be lit up red.
Technically, if it’s not too much work, even the CV switchboxes 1-3 could be handled this way, assuming the led can be lit ochre or some other color.
I’m sorry if I repeat myself so much, but I can not stress enough how much clear, luminous and bold visual feedback is paramount in stage situations.
While I can understand why a long and/or verbose list, such as the tonestack model in a cabinet simulator can not be expected to be bound to a footswitch in a meaningful way, we must find a way to make these “toggle like” kind of plugins usable on stage, because as they work now they are nearly useless.
…or, more simply, 1-3 could simply be green|red|off.
Well, yes sure, why not?
I’m not interested in eye candy, whatever works is good for me. A third color would be more effective since it conveys the meaning that the plugin is always on, but, really, I don’t care that much.
We hear you, and have been discussing this in the team.
We agree that being only green does not make a lot of sense, but how to “fix” it is the big question.
There are no decisions at this point, but surely something we will act upon.
Maybe something we can push for v1.10 too
Thank you very much for the kind answer.
I’d like to point out that if I’m very vocal and maybe even pushy regarding some issues is only because I care for the device, the concept under it and the community. And I like to toss idea around, and I really appreciate when the devs take note of the requests and feedback me and the other owners provide.
Another idea on the top of my head. What about short pulses of green depending on the parameter value? 1 pulse for channel 1, 2 for channel 2 and so on? could work for small lists.
Well, on the 2 chain switch what happens when the pedal is “off?” No sound output? It would totally fix @Tarrasque73’s issue if the sound just passed thru channel 1 when off (no light) and channel 2 when on (any color LED).
Unfortunately when the plugin is set to off it seems to output on both output channels.
Now that I think of the easiest solution could be, in case of the simple 2 way switchbox, to create a new plugin where the toggle is operated by an on/off switch “the usual way”.
I would do it myself if I had the slightest knowledge in plugin creation.
More complex routing setups will be better handled when we have a more robust pedalboard snapshot switching implementation, and with this I mean at least being able to rearrange the saved snapshots and being able to directly recall any one of them with a footswitch.
With those features implemented you can just chain switchboxes as you like and save the channel settings in the snapshot. Routing heaven.
As a workaround, until we improve the functionality of the devices, you can use the following technique using the x42 stereo X-fade plugin:
By doing this, you can use the bypass button of the stereo x-fade plugin to achieve the same result as toggling between channel 1-2 on the switchbox.
//Jesse
Great tip! Thank you! I’ll surely use this workaround.
In the meantime I’d also try and help and make a version of the SwitchBox that works as a toggle and not as a list. I have no experience of audio or plugin programming but i’m a developer and by looking at the git code the Switchbox plugin seems very simple. It seems just a matter of chenging the type of the controls “interfaces” to something else (probably boolean) and changing some lines of code.
I think that I might be able to give a shot at it by jus looking at the code of some other plugin myself and maybe relieve some unnecessary work off the shoulders of the Mod team.
I just need some help to set up as fast as possible the compiling environment. Unfortunately I have very little free time at the moment and I can’t afford to waste it by reading lots of docs just to set up the compilers and tool chain.
I’m on Ubuntu 20.04. If somebody would be so kind to paste me some quick and dirty shell lines to apt-get or download or otherwise set up the whole SDK I’d be really appreciated.
The place to start for building plugins is https://github.com/moddevices/mod-plugin-builder
Assuming you have enough disk space, just run bootstrap, wait a few hours, and you will have a cross-toolchain environment that matches the MOD OS stuff.
for local development, you can “source” the local.env file there to have it adjust CC, CXX and other environment variables so building code should cross-compile by default.
Thanks. how much disk space do I need approximatively?
Can I “bootstrap” on a place different from my home directory (I don’t think i have enough space on that partition)?
Nevermind the second question, I just read about the WORKDIR variable
Just checked my modduo folder here, it is 9.5Gb in size 
But you can use the hidden “.clean-install.sh” to clear up space after bootstrap finishes. EDIT be careful running it as it unconditionally deletes a lot of stuff
I cloned the repository, no problem at all. I get unautorized errors, though, when updating submodules.
Hi. Can anybody please help me with the issue I posted?
right, sorry, I fixed that a couple of days ago already but just forgot to reply here
just clone again and all should be fine.
you dont need to submodules to build stuff for yourself though.
