AU component version is always 0 in exported plugins (Xcode exporter misses versionAsHex)

[dannytaurus]

@Lindon It appears to be specific to @Christoph-Hart's customised JUCE fork.

Revised (more detailed) cause from Claude:

Cause

JUCE/extras/Build/juce_build_tools/utils/juce_PlistOptions.h in JUCE_customized carries the pre-6.1 API, where versionAsHex is a member each exporter has to fill in.

jucer_ProjectExport_Xcode.h writeInfoPlistFile() sets options.version but never options.versionAsHex, so it keeps its default of 0 and juce_PlistOptions.cpp writes that straight into the AudioComponents dict.

juceaide and jucer_ProjectExport_MacMake.h both set it, so only the Xcode path - the one HISE uses for macOS export - is affected.

Upstream JUCE is not affected either way: 6.0.8 has the same member and its Xcode exporter does set it, and 6.1.0 removed the member altogether, computing the value inside the plist writer (getAUVersionAsHexInteger at juce_PlistOptions.cpp:315 in 6.1.3).

So this looks like an assignment lost while carrying the older plist code onto a 6.1.3 base.

Fix: one line next to the existing options.version assignment, matching what upstream 6.0.8 had:

options.versionAsHex = owner.project.getVersionAsHexInteger();

Since HISE 5 ships a prebuilt Projucer in the JUCE submodule, this needs a Projucer rebuild to reach users, not just the source change.

[dannytaurus]

Ha. A fix from @DanH is already sitting in a PR in the custom JUCE repo sine June 16th: https://github.com/christophhart/JUCE_customized/pull/3

[DanH]

@dannytaurus nearly all my PRs get ignored

[ustk]

I stopped trying to push PRs because a lot of us are cross fixing the same stuff over and over before having a chance to see them reviewed and merged, unfortunately...

[Christoph Hart]

Sorry guys I‘m currently completely submersed in a theatre project, so this month will still be slow but then I‘ll pick up the work and review / merge all the PRs - just keep them coming they are not ignored but sit around waiting to be reviewed.

[David Healey]

@dannytaurus I just had a user on Tahoe report this issue

Logic Pro's plug-in manager says Libre wave > Rhapsody is compatible but the version is invalid.

Is that related to what you've described here?

[dannytaurus]

@David-Healey Yep. Below shows 'invalid' value from current HISE build, a post-export fixed one and a non-HISE version number.

[David Healey]

@dannytaurus wonder why the issue is only showing up for this one use though.

At least it's a simple fix

[dannytaurus]

@David-Healey

issue is only showing up for this one use

What do you mean? As far as I know all AU plugins exported from HISE since Dec 2021 have had this 'invalid' version in Logic. VST3 is unaffected.

[David Healey]

@dannytaurus It's the first time a user has reported that Rhapsody won't load because of this version issue. Or possibly the user just saw invalid and didn't try and load it on a track - I shall ask.

[dannytaurus]

@David-Healey The AU with an invalid version works fine. It just shows 'invalid' in the plug-in manager.

[David Healey]

Yeah the fix works

[dannytaurus]

@David-Healey Nice. Did you do the JUCE fix? Or the post-export manual fix?

[David Healey]

@dannytaurus I pulled in Dan's PR and rebuilt Projucer

[ustk]

In PluginDoctor it's saying v0.0.0 (before the fix) so it kinda stands for "invalid". I'll report to DDMF so it shows a "invalid" string of some sort as well...

[dannytaurus]

@ustk Yeah, good idea. I asked Claude if the version reports as an invalid number, or just as 0.0.0.

• The AU plist has AudioComponents.version = 0.
• Pluginval decoded that as v0.0.0.
• JUCE’s decoder explicitly formats the packed integer 0 as 0.0.0.

0.0.0 is valid as a semantic version, but AU metadata uses a packed UInt32, not a SemVer string.

In practice, hosts treat raw value 0 as “version unset.” Logic therefore labels it invalid, while pluginval merely displays the decoded value.

For 0.0.30, the AU field should contain integer 30. The bundle’s separate CFBundleVersion can remain the string 0.0.30.