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

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.


I really don’t agree with you there.

What the plugins should do and what they actually do are 2 completely different things.

And on some specific plugins (fluidsynth based stuff), there will never be a possibility to have them pre-loaded and using low memory at the same time. They load the entire sf2 on ram.
If the plugin only loads the sf2 in activate() rather than instantiate(), it will mean that its activate method will take quite some time. If the plugin loads the sf2 on instantiate (as they’re doing now), pre-loading it without activation will have its memory space wasted.

Personally I don’t see preloading as that great option that can magically solve this.
We basically will need to have 3 pedalboards loaded in ram (even if 2 of them only instantiate the minimum details) - the current pedalboard, the previous, and the next.
Thing is, when we change to the ‘next’ pedalboard, we not only need to load that pedalboard (from preload memory area), but then we also need to delete the old ‘previous’ pedalboard (the old ‘current’ becomes the new ‘previous’) and we will need to pre-load the next pedalboard too. I’m not confident that this is actually faster than normal operation.

The only preload that I can see being useful is instantiating a few plugins within a bank.
We will need to rate the plugins to know which ones have low memory consumption after instantiate, so that they can be safely preloaded.

That’s why I talk about a user selected pedalboard selector could do it. If, a user plan to run a gig, he/she could decide which pedalboards, and therewith plugins, he/she plan to use during the gig. Pre-load all the included plugins will allow the user to run the show smooth, and, he/she could improvising the sequence to play, or jumping from one to a other independent from the sequence in the bank.
Even, if a resource hungry plug like fluid is involved, it isn’t a waste of memory, when the plug didn’t run the hole time, but run, when it should run.
Truly all this can’t go above the mem available, but, using the available mem to extend (keep a small amount for . . ) isn’t waste in my view. So, when a user select the pedalboards to use, a indicator could show how much mem still is available, and simply refuse to load more then possible.
All this could be, for example, “Live Mode”.

This is an interesting discussion, in part because it appears to highlight some differences between user expectations and the design philosophies of the device (mod_host).

I’m only a hobbyist, but I enjoyed the experience of how Apple Mainstage works and lets you organize your patches in a hierarchy of (roughly) Set -> Song -> Instrument/Track, with the ability to hardware map around the hierarchy (next song, next patch, next patch for set, etc). It’s a fantastic piece of software for the price, but I prefer OSS, cross-platform tools.

I’ve envisioned similar use cases for the Duo where I could select a Bank and then use hardware controllers to flip between different Pedalboards, each of which may have a “SwitchTrigger” style pedal (for example).

What the plugins should do and what they actually do are 2 completely different things.

That doesn’t need to preclude:

  • having a productive discussion about what challenges might exist today because of current implementations
  • assessing whether existing plugins can meet the technical requirements of pre-load / fast-switching
  • forming a roadmap for raising awareness and improving capability of plugins w.r.t. to these use cases

And on some specific plugins (fluidsynth based stuff), there will never be a possibility to have them pre-loaded and using low memory at the same time. They load the entire sf2 on ram.

Speaking for myself, I don’t see the need to support every plugin in existence under this mode. For me, I see it simply as ‘use the tools that are right for this job’. I have a garage full of tools but I don’t get them all out every time I sweep the patio. Some tools I only use occasionally, and they do take extra preparation and caution to use. I don’t think there needs to be an expectation that every plugin would operate seamlessly in this mode (or at all). That said, I do understand as a software developer that there would be a non-trivial amount of UX work and plugin benchmarking work to avoid having users creating bad experiences for themselves.

This sounds extremely complicated to “get right”, UI-wise, segregates plugins and will create many discussions about specific effects people need for their live performances.

Perhaps more aggressive compiler options could alleviate this?

1 Like

sounds extremely complicated to “get right”, UI-wise, segregates plugins and will create many discussions about specific effects people need for their live performances

I don’t disagree, but it seems like any of this type of functionality is far down a Duo team product roadmap and this is all conjecture at this point. We have a handful of interested people with knowledge and ideas, and the source code to all the important parts. I don’t see as much harm in the community discussion and experimentation with different modes of operation. I haven’t seen any indication that the Duo team is going to pursue anything that’s been discussed here, and wouldn’t expect them to adopt architectural changes to mod_host or ’mod-ui without first vetting a functional version with the proposed changes in place.

I think good first steps that hacker/users interested in this could pursue:

  • do some benchmarking on the set of plugins, measure init times and resource usage, determine how much disparity between plugins
  • fork and hack on mod_host to better support/optimize ‘live mode’ use cases as described above

I think this is a good idea, but be sure to report it upstream to the plugin devs. The mod team has done a lot of work to curate a set of plugins, but almost none of the plugins are actually developed or maintained by the mod team. So we could actually offload some work from the mod developer if we can get more of the actual plugin developers interested/active in supporting the mod platform. I don’t expect that to be easy but if we get some enthusiastic users working toward it, it will sure be a step forward.


Some preliminary steps I’ve taken:

Here’s the raw data from running lv2bench -n 0 (process zero audio frames, output here) and lv2bench -n 48000 (process 48000 audio frames output here). I need to learn more to confirm that the zero frame test is a good measure of plugin startup time. The numbers could suggest that this is fast across the board for the current stock of plugins, which would be a good start. I wouldn’t put too much hope into this information without more research and qualification. We still need to measure memory and CPU

I’ll have some homework to do about the best ways to do this, since running process profiling tools on the Duo is beyond my scope. I’m sure I can get the lv2* tools running on my Ubuntu box and do some data gathering, which might not be a good representation of the performance characteristics of the Duo hardware and OS.

The Full Test features of lv2bm seem useful down the road if we can compile approximate maximums per plugin, the runtime could use that info to avoid activating patches that would overload the system.

1 Like

Well said, @unbracketed! Long term, this might be a very fruitful initiative. I am just skeptical with regards to the workload for the MOD team… but if we as community can do something, even better. We had a discussion about prioritizing porting plugins here (Plugins, from LV2 project to your Duo / Plugin testers wanted) and somehow went to rating (commercial and FLOSS) plugins in the store. IMO a benchmark, like you proposed, could make a valuable criterion. No idea though if this standard will ever be followed… things don’t seem to have changed much since then.

1 Like

Thank you for linking that discussion - I think there are a few different aspects of the product and user experience as a whole that could benefit from being able to systematically evaluate and catalog performance aspects of the different plugins. I’ll think about ways that process can get going; sometimes it’s just a matter of a person or few doing a trivial first step, and then you iterate the process from there…

Let me also clarify, because it’s important, that my own interest in any of these matters is for learning and making the most of my Duo experience. I hold no expectations that any work I produce or ideas I suggest will be taken up by the team. I’ve seen in many open source communities that some people demonstrate attitudes of entitlement because they showed up to a forum or submitted a pull request and I intend to do my part to reduce those behaviors :slight_smile:

1 Like

well, they’re rather understaffed. Its basically just falktx doing the software. So they really aren’t doing much with plugins at all at this time.

I wouldn’t recommend making benchmarks some requirement just because they usually only reflect one aspect when there are many factors to a plugins performance. They can be mis-interpreted too. So I’m all for sharing info and discussing what may see overly resource intensive, but I just wouldn’t want some arbitrary threshold of whats allowed.

1 Like

Sure! … and that’s why I @unbracketed’s initiative so compelling. And while I agree that we should not judge plugins by their computational load, there seems to be a use case for lightweight plugins with low memory footprints with an application in a “gapless switch mode”. And well, to find out if a plugin would be good for this application we’d somehow have to benchmark them somehow, right?

Do you mean releasing allocated memory by calling free() in the plugin’s deactivate method?

If so, note that activate() and deactivate() are realtime functions and hence cannot do that. Realtime safty is the whole point of having that API separate activate()/deactivate() API in addition to instantiate()/cleanup(). Only the latter allow non-rt-safe function calls.

One example from DAW land are loops/locate and reverb tails or EQ/Filters with state. Plugins are re-activated on non-linear jumps. The overall audio-I/O and signal processing and does not stop.

Also note that deactivate must not reset the configuration (internal state). A host may still ask a plugin to save its state after it has been deactivated.

For further information see lv2.h

That is a nice idea and elegant.

While setting up/taking down pedalboards call pending plugins with 0 samples to process (while the mod-host just zeros the output buffer). All LV2 Plugins are expected to process “0” samples as NO-OP, and only set output ports (particularly the latency port).

I’m not sure this is true.
See the top of
Only run and connect_port as part of audio class threading.

Then see

The plugin MUST NOT use … memory management functions within its Audio class functions

There’s no restriction on having non-rt-safe code in activate and deactivate.

It’s really bad! My God!!! Impossible to play live with this fucking issue. If I could I’d like to get my money back. Hey guys, form Mod Duo, are you kidding? I have installed de 1.90 version, the last one! I Tre problem is the same.

How can we love MOD DUO with this big big problem? It’s unacceptable!!!

Many people have already performed live using a Duo.

It’s possible that some of your use cases can be satisfied with existing features like snapshots and/or routing with switchboxes. However you didn’t provide any info for anyone to help you with.

This is a friendly and helpful community. It is frustrating when your hardware doesn’t work as expected. But I think you’ll have a better experience here if you refrain from cursing the hard work of the developers and take a moment to explain what you’re trying to achieve.


When changing pedalboards, all plugin and connections are reloaded. This causes a sound interruption and cannot be avoided.

It’s usually ok if you change pedalboard between songs, but it does not suit changing tones during a song. for that you must use different strategies.

The first strategy is thinking of a Duo pedalboard as an actual physical pedalboard.

You do not disconnect and reconnect pedals while playing, do you? Same thing here. If you have to change tone during a song (solo, clean part) you must design it in order to do so. You can use switch plugin operated by the foot pedals or any other means to route your sound through different plugin chains.

The second strategy is using pedalboard shapshots like patches in physcal rack effect processors.

Snapshots are a recent feature. Basically you can save the state of all plugins settings in a pedalboard and give them a name. That list can be then assign to an actuator like a knob. Changing snapshot does not cause a sound interruption because you are not disconnecting or reloading anything, you’re only changing many settings in you pedalboard at the same time. The only great limitation of snapshots at the moment is that they can not be accessed as easily as I wanted to (they can not be reordered and you need to set a midi channel specifically for them if you want to recall them with a midi pedalboard)

So, IMHO the best thing you can do is try to make your mind in advance and see how you can fin your use cases in one of the two strategies, bearing in mind that they can also be combined, of course.

No one bars you from designing a pedalboard with different snapshot and using the footswitches to enable a volume boost and distortion for the solo for example.