Latest Release causing massive lag in the web interface?



The web interface has been getting slower and slower, sometimes hanging til I have to reboot, adding some pedals causes massive lag, changing parameters on the Duo itself while it’s hooked up to the web interface can take AGES for the audio to catch up (like 45seconds to a minute). Without a laptop hooked up, the Duo is faster than ever - changing between boards has got a lot faster with the latest release, but editing boards has become hugely hit and miss and laborious. And loading the pedalboard library and plug in store take a very long time too…

Anyone else experiencing this?

How to reproduce

  1. Connect Duo to Lapto
  2. Try to do literally anything
  3. Wait ages for anything to happe

Expected/suggested solution

just be faster and more consistent!

Additional information

Open the controller menu (hold left knob down), navigate to Info > Versions and write down here the versions.

  • release: v 1.6.0
  • controller: (this is blank)

Also provide some information about your system if possible.

  • Operating system: Windows
  • System version: Windows 10, on a Dell i7 laptop.


Hi @solobasssteve

Are you connecting via Bluetooth or usb cable?


USB, and I tried swapping cable and port to see if that was a problem. It wasn’t :slight_smile:


i would agree, steve. although i’m not seeing the delay in audio that you report, it does seem like the browser UI is generally way more laggy. i’d say it’s especially slow when loading the pedalboard representation in the browser window - it just takes a really long time to build the graphics, and sometimes i have to reboot the MOD to get it to work.

perhaps the increase in xruns on pedalboards with CPU loads around 65 or 70% (which i’ve reported elsewhere) is related. they seem to be ok when running untethered, but i see an xrun every couple of minutes when connected to the GUI. of course, without an xrun counter on the MOD, it’s hard to be sure how they’re behaving on the untethered MOD…


I’ve experienced some instability and seemingly degraded performance too. I’ve discussed some things in other threads but for me:

  • I see a large amount of xruns with the web interface (several per minute) on some boards.
  • Slow initial loading of the web interface
  • Slow to load library and banks
  • Using search / filters in the store can lead to unresponsive UI

I also feel like the device is taking longer to boot and init than usual. The device will be on the splash screen for what seems like longer than normal, then the screens will come up as if there is a default pedalboard loaded (nothing mapped, default control labels), then after another 10 - 20 seconds the displays will show the expected current pedalboard mappings.

I wonder if this has to do with license checking for the commercial plugins. Maybe some new logic to sync with the commercial store has unintended consequences. I think they also introduced a new tool for capturing screenshots? I can’t think of anything else that changed between 1.5 - 1.6.


yeah, i’d agree also that it seems the device boot/init time is longer.

my general impression of all this has been: hmmmm, it feels like the software load on this thing is too much for the current hardware. i’m sure the proposed CPU upgrade will help immensely, but we should also keep the software as light, clean, and efficient as possible!


My unit it´s taking about 20 seconds to boot and load a pedalboard that has a DSP load of around 70%.
Connected via Bluetooth (Windows 10) the web interface takes another 20 seconds to be ready.
I did not mess around with any of the MOD settings and I don´t have any footswitch connected to the unit.


I’ve noticed poor performance in the web UI with recent updates also. I mainly notice it while dragging pedals around the canvas — the pedal lags behind the pointer by a second or more.


From 1.5 to 1.6 the biggest changes are related to the addition of the plugin store. There’s very little we implemented that justifies a big change in performance.

There are however a few scenarios where I noticed some UI performance issues:

  • When you turn on ‘beta plugins’ in the Plugin Store the UI at this points gets a bit overloaded with “too many objects” to handle. I consider that a corner case scenario for most users and beta plugins are off by default.
  • When loading the mod-ui there are a few extra requests being issued to retrieve commercial plugin data. Depending on your internet speed or wifi signal it’s possible to notice some delays in loading content. Nothing major, but noticeable.

I have tested recently some of the things you mentioned (dragging plugins, loading PB, etc.) and in my unit I see no problems whatsoever. UI feels very snappy to me (I do have a powerful desktop running the browser, which certainly helps). The UI takes about 7 seconds to load in my setup for example.

So the bad news is: we don’t have any bug (with proper steps to reproduce) waiting to be fixed
The good news is: I’m here to help :slight_smile:

The best way for us to get to the bottom of this is really to isolate the issue. If you can make one particular problem reproducible (by me), then I can fix it.

For all of you a few tips:

  • Try going back to a clean PB and checking the CPU/memory level. Do you see a performance issue at this point? Does it still take forever to load?
  • Try dropping a single plugin, what happens if you address it and change parameters? Can you also check the load on your computer?
  • Is the browser giving you crazy CPU / memory spikes?
  • Try changing the browser and tell me how it affects the issue.

For those of you a bit more technical I’ll ask you to use chrome devtool (F12) and capture the network requests statistics and send it to me (if you right click in the network tab you can save it as a HAR file).

I appreciate all the help you can give us to isolate those issues listed.

The “increase in xruns” hasn’t been really confirmed to be an issue with 1.6. There are so many factors involved, it’s hard to make this correlation (not that I don’t believe you, we just need to keep our minds open about the source of the problem). In order to confirm it’s a 1.6, you’d have to go back to 1.5 and do whatever steps you do to produce xruns and conclusively show that in 1.6 they happen at least 20-30% more frequently.