Any news about the time "gap" when change pedalboards?

Hi #treelemon.

The MOD is REALLY a great equipament. With an unquestionable hardware quality
and, all of us knew, that is in constant development of the softwares and plugins.

This issue, of the mentioned “gap”, has´s been discussed to find the best solutions.
Unfortunately, at this moment, this issue turns to very complicated to use it in live performances or reharsals (when sometimes you need to change an entire pedalboard). Even when you load a very simple pedalboard (ex. only chorus and gain plug ins), even if this plugins are “desativated” at the moment of load, the gap is unnaceptable !! And the worst thing is, this gap causes a mute moment !! If just take a long to apply the effect, it would be more acceptable, but it mutes all the chain.

Let´s wait for the team (and help, of course), to find a better solution for this gap.

And I guarantee you, the MOD is REALY AWSOME !!!

Thanks Again.

1 Like

What others have been calling of “scenes” is in the works already.
Basically allows you to save the current state of parameters into a pedalboard preset.
You can map the preset list into a knob or footswitch.

We’re still doing tests regarding this though, so don’t want to report too much on something that is still in progress.
(also the name too, “pedalboard presets” can be confused with regular plugin presets. “scenes” is not so bad…)


Sorry… I was the one who started calling it “scenes”… It’s what TC-Helicon calls it on their Voicelive 3… I used to have one…

I agree that the delay is unacceptable. Like everyone else, I love the Mod Duo and find it very impressive, but in a live setting, I can only use it in an effects loop due to 2 reasons: 1) the delay between switching pedal boards, and 2) the lack of trails between switching. So basically I use my Mod Duo as an ambient pedal and as a tube screamer. What I do is plug it into the effects loop of my Kemper, and then turn the loop on and off as I need the effect. Unfortunately when I turn off the effect loop, the Mod just cuts out entirely, so going for an ambient tone to my usual sounds abrupt. Also, if I go from my ambient sound to a different pedalboard sound the gap is just too unreliable, so I’m forced to use my effect loop. Anyway, I would love to see this resolved, but I’m afraid it’s more of an issue of processing power more than a software update. Anyway, one can hope.

1 Like

I figured out a solution! I used the new ToggleSwitch4 (utility) and assigned 2 sets of effects to the toggleswitch that I can easily bypass. I ran a stereo signal through the other 2 toggleswitch channels that are always on so that there was a constant dry signal going through. Then, I just assigned the footswitches to bypass each of the 2 effects. Now, I just leave my pedalboard on all the time and just bypass the effects as I need them.

So for example, footswitch 1 turns my ambient sound on and off and then footswitch 2 turns my tube screamer on and off. So, it’s an amazing setup I’ve got now - all because of the 4 way toggleswitch! And, I added the toggleswitch to the beginning of the signal chain so that my ambient tails/trails wouldn’t be cut off when I bypass the ambient sound! It’s amazing!


Note that the v1.3 release supports pedalboard presets.
Also pedalboards load slightly faster there.

EDIT: It’s out now! Release 1.3.0


btw, you can do other tricks with an analog A/B switch in front of the device into inputs 1 and 2 - you can do things like have an always-on distortion channel through input 2, and two other effects mapped to the toggles through input 1 and just have them both routed to output 1 (you could potentially even do tricks with another A/B switch and signal chain out to channel 2 but it’d be getting into some tricky management territory there).

the new stuff falk has added for plugins should enable trails in some plugins pretty soon - just gotta wait for support to catch up.

Here’s my pedalboard that solved the issues I was having. I opted for a pedal that allowed my original signal as always on, but then allowed me to activate a pad or a boost (or BOTH!) that I could toggle on and off that would retain the trail of the pad. Such a great solution!

@falkTX, I am developing PluginsManager, a python library for manages lv2 plugins with mod-host.

In my implementation, I also noticed a “gap” between pedalboard changes.

Some steps I took to minimize these were:

Something I did not and I suggest, but I do not know if it’s computationally worth implementing:

  • Try to reuse plugins with the maximum of equal parameters
  • Try to reuse plugins and connections between plugins.

Nice work on PluginsManager - I was literally just writing a part of an article about how community contributions could make the Duo something special. Lower-level / CLI tools for direct and programmatic access to the core functionality will be a nice complement to the shiny web interface.

I wonder if a flame graph would turn up anything about the delays

1 Like

I’ll just comment that at least part of the delays are simply because plugins tend to have heavy instatiation functions. In order to keep the realtime DSP as light on CPU as possible many plugins pre-compute as much as they can, sometimes large tables of data, which takes quite some time. I think most plugin developers don’t consider instatiation time a priority when writing a performant realtime audio effect. I know I don’t.

Nonetheless, can’t hurt to look, maybe there is some low-hanging fruit there that will make it easy to speed up the switching.

IMHO probably not because for me at least, if the 2 pedalboards are fairly similar I’ll achieve the switch through pedalboard presets rather than a separate pedalboard. My pedalboards tend to all be very different.

end of $.02

1 Like

Thanks! PluginsManager is part of my college monography (college course completion work) that I do.

@unbracketed I believe @ssj71 has answered you: PyFlames will detect problems in the code in python, not in the initialization of the audio plugins.

What this does not mean is that this tool is not useful: With it it is possible to detect other problems, something like (is an example) the feedback given to the web GUI delays the loading of the plugins. Things we do not notice in development can be clear with it.

Thank you for this commentary. Now I can argue with my supervisor of my college monograph.

I unfortunately do not own the Mod Duo. (But it’s on my wish list: D)
So I’m not sure if they use footswitches like next / before pedalboard.

If so, some strategies could be taken, such as:

  • If MOD Duo has <50% processing and memory, it can be loaded¹:

    • some audio plugins of the current and previous pedalboard, preferably some that both have.
  • audio plugins that are present on most of the bench’s pedalboards

¹ Has anyone ever noticed if initializing an audio plugin without being connected to other plugins can cause problems in the sound - xrun?

That makes a lot of sense, thank you for the clarification. Now that there are (stronger?) use cases for optimizing the init routines (fast chain switching), are there technical reasons why the pre-computed data can’t be cached to disk or packed into the source code? Is it (almost) always dependent on the input params?

You’re right, thanks. pyflame could be useful for very minor improvements or identifying overlooked pathological cases at the GUI level. Good old ptrace and friends can still be used for profiling the plugins, but even if they clearly show where the slowdowns are there might not be much to do about it because of author design decisions to sacrifice startup speed for runtime performance.

At the least, per plugin startup time could be useful to know as one more metric to consider when constucting
:stars:The Ultimate Pedalboard :stars:

It looks like if you specify n-frames = 0 to lv2bm it will skip the run step entirely, so the run time measured should be mostly the init code. Does that sound right?

I do. But, to be honest, as well I put as much as possible in the initialization, moving as much stuff as possible out of run, just, that didn’t mean that I waste resources, or ain’t be careful with what my plugs do in init.

And I believe, most developers do so as well.

However, some of you here may know that guitarix provide smooth, gab free preset switching, and we archive that by taking all possibility’s into account. That means, we init “all” plugs on application startup, already loaded plugs will be reused. Also, guitarix is a multi-plugin host, so no jack call to register new clients is needed when change a preset (here pedalboard). That mean, changing a pedalboard in guitarix isn’t more then provide a new list of pointers to plugins.

I guess that isn’t possible for the MOD, but, maybe a new function were users could select/mark pedalboards for live use, so that the plugs which are supposed to be used for a live gig, could be pre-init/load may be of some use.
I know, it will be nearly the same as using a switchbox, just, it will allow a better organization on screen.

I see some nice ideas here.
I can add a few of my own too.

  1. stop processing when loading a pedalboard.
    mod-host was made to always be running the plugins, it has no concept of a loading session.
    as soon as you tell it to load a plugin, it does so and starts processing.
    this is a problem if we’re loading a big pedalboard. some plugins will be processing sound already while we’re still adding the last ones, making those take more time to load.
    so one thing to do is to disable plugin processing within mod-host until all plugins and connections are done.

  2. take time from RT when loading pedalboard
    the mod has a 95% time dedicated to RT tasks (default value in the linux-rt kernel)
    related to point #1, when loading a pedalboard we can not just skip plugin processing, but also bypass the audio completely. this will allow us to purposefully lower the RT dedicated time - even if xruns happen, because the audio is bypassed, the user won’t notice them.
    there’s no real sound processing happening when loading a pedalboard, so this for me sounds like a good option.
    ie, reduce RT dedicated time when starting to load a pedalboard, then when everything is done loading, restore the RT value.

preloading is also an option, to some extent.
loading the next pedalboard plugins while the current one is live has been discussed before, but sounds like a dangerous thing (will need to load things while sound is processing, which can make things even slower, not faster…)
perhaps preloading the meta-data can work, will have to do some tests later on.

optimizing the code is always an option too, of course :slight_smile:


Perhaps if there is an option to preload a whole bank of pedalboards so there is clickless switching between them then we could get a good balance. Of course that will require that each board either reuse a lot of plugins or just use very few, but then you have the option to still design pedalboards that use most of the ram and just not use a preload bank or have smaller boards that are immediately available (provided they’re in the same preloaded bank).

1 Like

That’s a pity, plugins should take care about the difference between “instantiate” and “activate” for exactly this reason. Instantiate all pointers, set all memory-low-use variables at “instantiate” and doing memory access at activate will allow you to “instantiate” a “lot” plugs, which then could switch in fast when needed. Also give memory free on “deactivate”, will give the host (application or hardware) a lot more headroom. It’s a pity when the host didn’t care about this, and that will be the first step to fix this gap.