Random Manufacturer Code - Projucer Change Request

Hi folks,

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!

Cheers,

Joaquin Saavedra

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.

3 Likes

Exact! It would be great if Projucer force the user to enter a 4 char code.

What I don’t see is the point of giving the chance of setting it to less than 4 chars, I did it because I didn’t know and caused a problem.

For reference, the random bits come from

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.

3 Likes

Thanks!

I opened an issue on GitHub, not sure if that’s correct.

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.

1 Like

Hi,

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.

Cheers,
Steve.

You can define JucePlugin_AAXManufacturerCode or JucePlugin_ManufacturerCode in the “Preprocessor Definitions” project setting.

1 Like

Thanks for the tip!

I’ve updated the newest version of the Projucer so that shorter manufacturer/plugin codes will produce a warning rather than a hard error:

That’s great - many thanks!