Recently I had an issue that I would like to share with you, and I believe would be great if the behaviour of Projucer could be changed for upcoming versions.
Manufacturer codes (and also plugin codes) should be 32 bits long, in Projucer project settings we set up to 4 chars and that will be used as the 32 bits code.
But, what happens if you use less than 4 chars? Let’s say 2 chars?
I was able to see that the rest of the bits are randomly generated by Projucer, and this can cause lots of problems. (Each export will have a different manufacturer code, so DAWs won’t detect them as the same plugin)
As I see it, Projucer shouldn’t let us use Manufacturer codes shorter than 4 chars. As a second option, Projucer could fill the missing chars with a fixed char, but not random bits, please!
Let me know if I’m wrong in my understanding of how manufacturer codes work / should work!
Why use less than 4 characters? We have an old AU-wrapped VST3 plugin that needs backwards compatibility, where that code was 'VST ', so we include the trailing space to make it 4 characters. Can’t you just do that?
He surely can do that but I think his point is that it should be enforced by the Projucer. Adding random bits on each project generation to a code that is supposed to be unique is indeed a weird way of filling the missing information.
String::operator[] doesn’t do any bound check in Release builds (it does assert in Debug), so accessing fourCharCode[2] and fourCharCode[3] on a string that is only 2 char-long returns garbage/random bits.
Thanks for reporting, I’ve merged a change so that exporting projects with ill-formed plugin/manufacterer codes will fail. I’ve also introduced similar behaviour to the CMake build.
I’m porting an AAX-only project from JUCE 5 to JUCE 6.
Were were getting away with an ill-formed three character manufacturer code in JUCE 5 (and it seems that the extra bits were fortunately always set to the same value of 0x00). Now we can’t recreate this ill-formed manufacturer code in Projucer v6.1.4 (as you can’t enter an ascii code of 0x00 for the last character).
Would it be possible to have a setting to override the current Projucer error and replicate the Projucer 5 behaviour (i.e. missing trailing characters replaced by 0x00)? I accept this shouldn’t be the default behaviour but it would be nice to be able to make a new version of our Plugin in JUCE 6 without having to hack JucePluginDefines.h every time we save the .jucer session.
I’d be grateful if you could let me know if there’s a better way of working around this.
