PLUG_VERSION_HEX not interpreted correctly in DAWs?

This may be old news but I have discovered that many DAWs do not display the correct plugin version number for VST2 plugins.

I believe that number comes from this line in config.h:

#define PLUG_VERSION_HEX 0x00010203

The VST3 version number seems to come from the next line:

#define PLUG_VERSION_STR "1.2.3"

These two should match but when I check the plugin info in DAWs like Cubase and Studio One 5 the VST3 version shows correctly “1.2.3” but the VST2 plugin version shows up as “1.0.2.0”.

The instruction for PLUG_VERSION_HEX from iPlug_include_in_plug_hdr.h says,

"The hexadecimal version number in the form 0xVVVVRRMM: V = version, R = revision, M = minor revision."

and that is what I believe I am doing. Oddly, this only seems to support 3 decimal places but VST2 version numbers have 4 decimal places (i.e., “1.0.2.0”, etc.).

I’ve fiddled around with all different combinations in PLUG_VERSION_HEX including using actual hex numbers (like 7B) but still can’t get it to display properly in DAWs plugin info. Other plugins seem to be doing it right (VST and VST3 show same version) so what is wrong here? Is this a known issue in iPlug or am I doing something wrong?

Doesn’t look like you are doing anything wrong.

Are any hosts displaying this correctly for you? Can you set a breakpoint in GetDecimalVersion() and see if it is being used in hosts that do/don’t display correctly?

It seems unlikely that this very historical code on versions is totally incorrect, but the use (or not) of GetDecimalVersion() seems like a possible source of issue. It’s also possible that the versioning has been incorrectly implemented since iplug1, but that seems a little unlikely.

OK - It looks like mEffect.version is set incorrectly using GetDecimalVersion(), which doesn’t match the expected format given the SDK. There may also be issues with effGetVendorVersion which returns the same number.

Please make an issue on Github for this and I’ll discuss with Oli. Changing GetDecimalVersion() is trivial, but I’m not yet sure of any knockon effects.

No.

I have looked back and my older iPlug1 plugins and they display correctly so I think this may have been a migration error in iPlug2. The instructions in iPlug1 are a bit different (but still don’t work right in iPlug2):

// Format 0xMAJR.MN.BG - in HEX! so version 10.1.5 would be 0x000A0105

I’ve searched the entire project in MSVS and it doesn’t find mEffect.version or GetDecimalVersion() anywhere - where are those functions/values?

I will post this on GitHub. Thank you.

Can you tell me the last version of iplug1 you were using (and where I can find the source)?

As far as I could see looking earlier the last version of WDL-OL I was using was identical to the current code (albeit in different files). I also looked at Oli’s first commit of WDL-OL (2012) and the code looks functionally identical so I can’t see how this could have worked in iplug1 but not work now…

I was just about to edit my post above. I just checked and it did not work properly in iPlug1 either. So it seems to be a very old, unreported error. Please check some of your own plugins to verify.

I don’t seem to have a host to hand that displays this info.

I’m using the demo version of Studio One but paid versions of others. Do you have a link to demos of your plugins that I could test?

This is an old bug in IPLUG2. Possible fix could be

/** /todo

  • @param version /todo
  • @return int /todo */
    static inline int GetDecimalVersion(int version)
    {
    int ver, rmaj, rmin;
    GetVersionParts(version, ver, rmaj, rmin);
    return 1000 * ver + 100 * rmaj + 10 * rmin; // FIX VST2 version number
    }
2 Likes

@TBProAudio - Yes, that seems to fix it (as tested in Cubase and Studio One). I will add this info to the GitHub report I posted. Thank you.

Now - to be safe - is this just a display issue or could making this change affect folks who are using plugin version numbers in their serialized data of controls, etc.?

Good question. We do not use version checks in serialized data :frowning:
Maybe this was the reason why Oli never touched this?