Juce, Projucer and VST Version / Vendor Version


#1

Hi

currently migrating some of the older plugins to the latest tip using projucer. There is a version number in Projucer, but it seems that it’s not possible to ever update the plugin version because some hosts like cubase only load presets that mach that number.

But we have a lot of minor updates and it would be handy to manage the vendor plugin version in the projucer UI. Is there a way to do this?


How do you deal with updating your plugin when it's not backwards compatible?
#2

What we have found as one workaround is to separate the chunk version (compatibility of saved state) from the plug-in version, by adding the following in the user code section of AppConfig.h:

(using whatever the most recent JucePlugin_VersionCode was for legacy projects, or 1 for new ones)
and modifying the JuceVSTWrapper() constructor in juce_VST_Wrapper.cpp to:

#ifdef JucePlugin_VSTChunkStructureVersion
        cEffect.version = convertHexVersionToDecimal (JucePlugin_VSTChunkStructureVersion);
#else
        cEffect.version = convertHexVersionToDecimal (JucePlugin_VersionCode);
#endif

This should allow you to change plugin version numbers via the Projucer UI and only break preset compatibility when you intentionally change the JucePlugin_VSTChunkStructureVersion define in AppConfig.h.


#3

Thanks for the work around. That’s a solution that works. I would prefer one without modifying the juce source for fast updates. Especially now where we also have a developer Branch for testing.

@JUCETeam: Can we integrate something like this into the standard AppConfig and the wrapper code? I think every plugin developer runs into that issue.


#4

Sounds reasonable!


#5

Hi Fabian

Just made some more tests and it looks that at least cubase 5 accepts higher version numbers. It only avoids to load presets from a smaller version. I forgot to set the JUCE_VST_RETURN_HEX_VERSION_NUMBER_DIRECTLY flag for older migrated plugins. The version was smaller because of this. Not sure how other hosts do this. It maybe would be useful anyway for some special cases. But it’s not an issue for us anymore at the moment as most hosts ignore the version anyway.


#6

Yes, without the workaround I proposed Cubase will load VST2 presets from lower version numbers but not higher. The biggest problem is that it fails silently - the DAW doesn’t even tell the user that, say, it failed to restore the state of a particular VST2 plug while loading a session because it was saved with a newer version than is currently installed. With the workaround, it is up to the developer to create a break in compatibility by incrementing the VSTChunkStructureVersion.

Basically, without the fix you get backwards compatibility but zero forward compatibility. With it, you get both forward and backward compatibility. If your chunk format isn’t changing, the lack of forward compatibility is completely arbitrary and only a side effect of using the plugin version as the chunk version.


#7

You are right. Data loss is the worst that can happen. The user saves the arrangement and all settings are gone forever. It would be a good thing to have that option in the projucer and appconfig.


#8

I’ve added support for the JucePlugin_VSTChunkStructureVersion pre-processor macro to the develop branch. However, I did not add support for this in the Projucer as we want to add more robust version information to audio processors in future versoin of JUCE. You’ll need to add the JucePlugin_VSTChunkStructureVersion macro definition to the custom pre-processor macro field in the Projucer.