Failure of plugin set to load following latest update

Hawkeye · August 9, 2026, 9:49pm

Firmware 2.3.0 and matching latest plugin set. Did update and Unfiltered Vol 1 crashes during initialization and fails to load.

degarr · August 10, 2026, 9:20am

Dan explained in another post we have reached the limit on “loading all” plugins. Don’t load all at boot and change config to load “on demand” or “ask” for each patch is the suggested route.

danngreen · August 11, 2026, 7:58pm

Yep, exactly. Best practice now is to pre-load your favorites on boot, and then load any other plugin on demand.

The reason it happens on Unfiltered Volume1 is because that plugin requires a large temporary buffer to be loaded (~64MB IIRC), and by the time the MetaModule has loaded all the other plugins alphabetically up until that point, there is not enough memory available to load that plugin. It’s possible to play “tetris” and figure out an exact loading order that works, but I don’t recommend doing this, as there are more and more plugins getting ported and it’ll soon be impossible to have them all loaded at the same time, no matter what order you do it in. Auto-loading when you open a patch is pretty reliable and is the way to go instead of loading all plugins at startup.

gabrielroth · August 11, 2026, 8:55pm

Feels like this is going to be a recurring point of confusion. I wonder if it would be helpful to have a custom alert message that triggers when the module runs out of memory on initial plugin loading, like “You’ve got too many plugins set to load on startup. Go to the plugin menu and disable some.”

danngreen · August 11, 2026, 9:52pm

Yeah, we probably need a better warning message. There are two paths to this happening: clicking “Load All”, and pre-loading all plugins.
I debated having a pop-up warning/caution when you click “Load All”, just saying “If you get an error, try loading just the plugins you need”, and we could have a custom message if the preloader fails due to memory.

I think Unfiltered will release an update that uses less memory, so that will stave off this particular issue. But as we keep adding more plugins, it’ll just happen again with some other plugin.

danngreen · August 12, 2026, 11:18pm

Ok, I might have a solution. I just opened a PR from a branch that seems to be working well:

github.com/4ms/metamodule

Lazy populate element list for VCV plugins (#611)

main ← no-module-at-plugin-load

opened 11:15PM - 12 Aug 26 UTC

danngreen

+362 -77

This reduces memory usage when loading a plugin. Currently each module has to be… constructed one at a time in order to scan the module for jack/param/light names, ranges, scaling, etc. But if lots of plugins are loaded, there isn't always enough free memory to construct each module, so the plugin can't be loaded. What this PR does is construct the ModuleWidget with a nullptr module, like VCV Rack does when displaying the module browser. VCV plugins are already OK with a null module, so this isn't a problem. Then when the module is first loaded into a patch, its constructed and the names/ranges/etc are scanned and added to the registry.

It lazily loads the modules, so less memory is needed at plugin load time. It works and you can load all the plugins at boot now with this.