ParameterQuality change in 2.3.0

Will do, thanks Paul :+1:

Damn. Now I am worried about my next Venom release, where I am taking advantage of the new 2.2.3 feature of custom port context menus (Options to take absolute value and/or invert). The change log does not list it as an API change. But I don’t see how it could be anything but.

I really like the custom port menus, but I certainly don’t want an updated Venom plugin to cease working on Rack installations that are not up-to-date.

This is a bit off topic, but it is certainly a related issue.

Custom port context menus aren’t an API change; they are a missing call in the portWidget to appendContextMenu which was already in the api. This was the bug if you are curious.


Thanks! That is a relief.

Thanks Don. This is not great…

Yes, the g++ ... -lRack link has extra symbols inside it, and the “compatible” one has new filtered behaviour.

To update those participating in the discussion just above with @cosinekitty @DaveVenom @baconpaul , I got a quick response from VCV support: it is indeed expected behavior that if we use new methods, then our plugins will not work with older Rack versions, and so it is recommended that users always use the latest version of Rack. This means that we can roll out the fix required for Dave’s issue.

I also got a helpful suggestion to the effect that we should not call ParamQuantity methods from the DSP, and we should preferrably use APP->engine->setParamValue() instead. I’m not knowledgeable enough to elaborate on any of this, just passing on the info in case it can help others.

1 Like

This is not going to be a good user experience. Lots of users are going to see the red dot on the Library, reflexively update their plugins, and all their MindMeld modules are going to vanish from their patches. There won’t be any explanation of why they are gone.

I think this is one of those cures that’s worse than the disease. If it were my plugin, I wouldn’t submit this change, but that’s your call of course.


Thanks, after discussing it more with @steve we came to the same conclusion, and we have instead opted for the less disruptive method of posting post 2.3.0 builds on our github, for those encountering Dave’s issue. When Rack 2.3.0 is installed by more users, we will update the library.


After more thought, if we find the way to use that instead of any of the new methods in ParamQuantity, perhaps then the change can work in all versions of Rack…

Is there a Rack Version string accessible to the plugin? I see in the API docs that there are various Version() methods, but I’m not sure if one of them returns the currently running Rack version.

Operators are defined to compare versions to see if one is >= another. So would it be possible to query the running Rack version and call the appropriate method? If >= 2.3.0 use the new method, else fallback to the old? I’m hoping that as long as the non-existent new method is never called, it never causes a problem, even if there is a reference to it that isn’t called.

Unfortunately, the problem happens before you even get a chance to decide at runtime whether you want to call the new function. As soon as the older version of VCV Rack tries to load the plugin, dynamic linking fails because it can’t find the new symbol ParamQuantity::setImmediateValue. So your plugin never gets a chance to run, let alone look at version strings.

1 Like

Ugh that’s not great indeed. It also means I can’t fix surge easily I think.

I suppose you could dlsym the mangled fn dynamically and branch rather than resolve in the linker but that’s pretty painful. Or make a dll pair in resources with 22 and 23 with a stub and dlopen them. All clumsy though

Why not make the update require a specific version to install? this would be something done on the cloud server side, but I have implemented something like this before so I know it is doable.

As a simple example, say there is a new plugin that makes use of new APIs from the start. It will only work on 2.3.0, never anything below. On the server side we could just have it so that only users with >= 2.3 see it as option to install/update.

The case for plugin updates requiring new APIs is a little weird and unusual, but worst case the server can keep old builds frozen while adding new ones for >= 2.3 users.


Yes - I can see how that should be possible, and I think there is a keen need for implementation!

A thought which I don’t have time to test but to share

setImmefiateValue is a five line function

Rather than calling pq->set immediate copy that function to take a pq* that and use that-> in the 6 lines and then call that

It should in theory work in 2.2 and 2.3 identically then and you are exposed only to compile Time errors with future apis not runtime ones for this particular function


I’ll ponder this, thanks Paul :slight_smile:

A little late to the game here, but it sounds like VCV introduced a breaking change on a point revision? Have they commented on this issue? Sounds really odd - not the kind of thing I would expect from VCV.

I’m not sure it’s a break change. It could be a bug fix. In terms of smooth audio, it shouldn’t affect anything noticeably. Likely it will prevent a lot of MinBLEP requirements. I had to fix some things myself, but yes it was a discreet state that needed ConfigSwitch() instead of smoothly drifting between states. The .json load will work the same.

So what breaks? Pokes into machine state assumed to have constant implementation?

EDIT: Out of pedantic design, assume someone makes a polymorphic map of enum to port, and pokes cable objects to fix a patch load. Then any outer reference would not know which became which routing control. So who is to blame on a “my rack is malfunctioning”, “please dedicate time to read my paid for log servicing”, “that’s bad, I’ll tell everybody now”, “what you mean you haven’t done a subtract one module (then n) for an auto load without sequencing choice autofix?”

“He says I’ve got to learn C and understand the source.” … It needs a “METAMODULE” tag … expectations of where the breaks lie?

From the description above it seems like the ability to put a plugin into the library breaks. But maybe I’m mis-reading it.