MindMeld Plugin update available on GitHub for Rack 2.3 users ONLY

Rack 2.3 introduced some API changes that unfortunately stopped the mapping in PatchMaster working correctly in some scenarios.

We can and have fixed this for Rack 2.3, but the fix relies on the new change in 2.3 API and is therefore not compatible with older versions of Rack. In previous versions the ‘fixed’ plugin won’t load at all… This means we can either offer a plugin that works properly with 2.3, or a plugin that works with older rack versions, but not both.

VCV’s take on this is that all users should just update to Rack 2.3 as it is the latest version and its free to do so. In reality we know that many users don’t do that immediately and it would be a very poor user experience for people using older versions of Rack to see the red update dot, instinctively download the updated MindMeld plugin and… promptly have all their MindMeld modules disappear from their patch without knowing why.

We’d probably get a lot of unhappy emails saying “Your MindMeld plugin broke and now I can’t play my patch!”. That wouldn’t be good…

So with that in mind, we’ve decided the best course of action is to offer an updated version of the MindMeld plugin on our GitHub page for users of Rack 2.3 and above ONLY. If you are using 2.3 or above, please go grab that version.

Meanwhile the older version of the plugin which is compatible with all versions of Rack prior to 2.3 will remain in the library for now so as to minimise disruption to users. We understand that having two different versions of the plugin is not ideal, but due to these ‘circumstances beyond our control’, it seems like the least bad option.




Technically true but… booo! Andrew definately silently changed his policy and I don’t understand what the new one is. How does backward/forward compatibility in Rack work now? Crickets… Those API changes in the 2.x series are plain wrong if you ask me, they should have just been reverted. But hey… it’s not my project.

Thanks for caring about your users guys! That’s why you’re one of the go-to’s.


Thanks for handling this awkward situation gracefully. Oof.

Breaking API changes on point releases really isn’t a tenable situation without some kind of version management in the plugin architecture (even if it’s as simple as “Sorry, can’t load, requires 2.3.”). Especially concerning because, as you point out, the support requests are going to flow downhill to the plugin authors.


Thanks! Agreed, very graceful handling in a tough spot.

1 Like

Useful information, thanks a lot Steve! :wink:

1 Like

I’m reposting Marc’s post from the other more general thread about this issue here as whilst for one module in our plugin this could be considered a ‘breaking’ API change, ours is most likely an edge case so some perspective is warranted.


Thanks, do the premium modules need an update for 2.3 also? After installing the update, I see ShapeMaster 2.2.1 and pro version 2.2.0.

ShapeMaster Pro does not require an update, and the version numbers in those two plugins are actually distinct, so they will not evolve in lock-step. Althgouh it might be weird to see SM-Pro at 2.2.0 and SM-Free at 2.2.1, it would be too messy to update the Pro each time the free plugin gets an update.

1 Like

Good news - thanks to the genius of @baconpaul it looks like there’s a workaround that let’s us have the plugin working on all versions. The Github link I posted above now includes this fix. If people could please try it out with both the latest 2.3 and earlier versions (please let us know which version you tried it with) that would be most appreciated. If all’s well we’ll submit it to the library soon. Thanks :slight_smile:


Further congratulations on and gratitude for an even better outcome (and nice work @baconpaul !!!)

Taking your point that this particular change hits a corner case, maybe it won’t be a serious ongoing issue, but I do hope that Andrew is considering some kind of version-compatibility metadata (which would also help with the more common new API case).

1 Like

FWIW, if you’re a plugin developer, and you need to specialize code based on the rack version for issues like this (in my case, I have separate code paths for versions of rack with a particular bug fix and older without), here’s a code snippet you can adapt/re-use:

    // e.g. isLaterVersion(2,3) means rack after 2.3 (non-inclusive)
    bool isLaterVersion(int maj, int min) {
        auto parts = rack::string::split(rack::APP_VERSION, "."); 
        auto i1 = std::strtol(parts[0].c_str(), nullptr, 10);
        auto i2 = std::strtol(parts[1].c_str(), nullptr, 10);
        if (i1 > maj) return true;
        if (i2 > min) return true;
        return false;


    if (isLaterVersion(2, 3)) { 
        // new behavior
    } else {
        // old behavior for 2.3 and earlier

Sorry for the OT. That’s why I gave up understanding how to develop a proper plugin for VCV.

  1. I am not a coder by any means.

  2. when I tried to do something (ver. 0.6) and I only did some blank panels I find myself in a sea of problems, including not understanding how the heck github works (too jargon everywhere and not a real tutorial for REAL noobs like me) and the “manual” for VCV was, under my ignorant point of view, laughable to say the least: if it was written in ancient aramaic it would have been the same for me.

  3. after the migrations to 1.0 and more recently to 2.something things got worst and worst. What first look like a D&D labyrinth level 100, now it look a “stresseract” labyrinth level “where’s my valium”.

Maybe it’s me that’s just scared to the bone of coding and those things that looks more like magic spells rather than tech stuff (I am way more expert in other science fields), maybe it’s something else. It’s a pity tho. I have some ideas but those ideas are destined to remain such.

Again, sorry for the little rant and for the OT.

That code might need a little tweaking, if a user is running Rack 0.6 and we call the function with ‘isLaterVersion(2, 3)’, it will return true, which is likely not what it should do?

Thanks for the noticing the bug. I’ll have to fix that :wink:

Are there any modules in existence that run in both Rack 0.6 and Rack 2.0 (not just source, but same binary)? Or for that matter, Rack 1.0 and Rack 2.0?

I doubt it, because of ABI incompatibilities, it’s very unlikely those different major versions would coexist (i.e. 1.0 plugin in Rack 2.0, or vice versa), but I thought I would mention it anyways :slight_smile: