Recently updated plugins that don't update correctly

EDIT: This is with the 2.1. 1 preview

image The Nysthi alwas shows up in the “Updates” list because I download a version not yet in library.

The log file isn’t very interesting. It shows the plugins being unpacked:

[0.235 info src/plugin.cpp:260 extractPackages] Extracting package E:/Documents.Kent/Rack2/plugins/squinkylabs-plug1-2.1.5-win.vcvplugin
[0.281 info src/plugin.cpp:260 extractPackages] Extracting package E:/Documents.Kent/Rack2/plugins/StellareModular-CreativeSuite-2.0.0-win.vcvplugin

But they show up as still having outstanding updates.

I saw this too, it’s with VCV 2.1.1 I downgraded back to 2.0.6 and all is well again. Only Squinky Labs was “off”.

I’ve seen it with:

  • Squinky Labs
  • Quantum Multiverse from ML

I haven’t licensed “Stellare Modular CreativeSuite”

VCV support knows.


Mee too. In 2.1.1 I get an update-loop for those two, whereas 2.1.0 did not want to update them.


I suspect it might have to do with this commit, but that’s just speculation.

Oh good, I was just about to write them :slight_smile:

I’ve always said those squinky labs modules are un-polished and unprofessional!

1 Like

Only this VERSION

1 Like

You’re mistaken. It’s simply that 2.1.1 likes them so much it can’t get enough of them, over and over again :smile:


According to VCV Rack support, a change between 2.1.0 and 2.1.1 caused this to happen, but they’re asking the plugin vendors in question to change their plugins to avoid this.

1 Like

I have provided an update for Squinky labs earlier today.



@robert.kock LOL

Welcome to beautiful VERSION. Of course it will take it a bit to get through the library process.


I built from source and the 2.1.6 plugin loads properly!

1 Like

Why did you need to kick the version number to 2.6? It didn’t look like there was anything wrong with 2.5.

Code updates were needed to accommodate changes in module load behavior in Rack 2.1.1.

Ah, cool. Tx!

To sum up that change that Andrew made in v2.1.1:

  • Before 2.1.1 the init() method of the plugin was called first and after that the plugin’s manifest was loaded.
  • That is reversed in 2.1.1 so now the plugin’s manifest is loaded first and then its init() method is called afterwards, which seems like the logically right thing to do.

That behaviour change bit the Squinky plugin (and others) that was using this behaviour for… something, probably some version-dependent feature detection logic, in the absence of the plugin version being available at init, because the manifest was only loaded later, which has now been corrected.

1 Like