JUCE submodule PSA

[ulrik]

@Christoph-Hart So if I chose JUCE 8, will there be other "new" function methods, etc.. that doesn't exists in JUCE 6, and will the API be updated as well?

[Christoph Hart]

@ulrik no. At the moment the only real reason to use JUCE8 is if you only have a JUCE8 license that might not cover the use of JUCE6 code which HISE is built upon (there is no clear legal framework for this but the JUCE8 starter license might not allow usage of JUCE6 code so in order to remove that legal limbo I decided to spent the first days of 2026 fighting compiler errors).

I had to strip most of the interesting stuff in JUCE8 away in order to keep it consistent with JUCE6 (which will remain the default), so eg. the entire Direct2D renderer would require months of testing. Ideally people can switch to JUCE8 easily with this approach and this way we get a safe workflow of testing the new JUCE stuff - once JUCE9 arrives with CLAP support then it will get more interesting.

[ulrik]

@Christoph-Hart Ok I understand, so as I understand it, it will be no advantage to upgrade my JUCE 7 license to JUCE 8, regarding Hise

[Christoph Hart]

@Christoph-Hart said in JUCE submodule PSA:

and then we‘ll tackle Linux in a joint effort.

@David-Healey can you check if it works now? I've recompiled the Projucer in both JUCE branches and it should now compile & export, but I'm running against the funky SimdRegister error here (BTW, have you fixed that on your HISE branch?).

[David Healey]

@Christoph-Hart said in JUCE submodule PSA:

@David-Healey can you check if it works now? I've recompiled the Projucer in both JUCE branches and it should now compile & export, but I'm running against the funky SimdRegister error here (BTW, have you fixed that on your HISE branch?).

I'll give it a try.

That invalid use of incomplete type error never showed up my fork. It only happens upstream. I can't see any difference in the lines of code related to it between upstream and my fork so it's had me scratching my head. The only thing I can think is that the order that files are being included is somehow different, but I'm really not sure.

I did add this PR to fix the symptom. The error first showed up with this commit.

Edit: Interesting, I've just pulled in the latest changes and my branch has now inherited the simd error.

[David Healey]

@Christoph-Hart Apart from the SIMD error everything worked. I did have to enable the execute permission on Projucer - can't remember if I had to do that in the past.

[clevername27]

@David-Healey Does that JUCE commit exist on Remote?

[David Healey]

@clevername27 Not sure what you're asking

[David Healey]

@Christoph-Hart Some issues I've come across:

• The Linux build of Projucer doesn't have execute permission - I think this must be set on a Linux system, not sure.
• The MacOS build of Projucer has not been codesigned/notarized so it gets flagged by gatekeeper
• The export setup Wizard has not been updated so it's still looking in tools/projucer

[Christoph Hart]

The MacOS build of Projucer has not been codesigned/notarized so it gets flagged by gatekeeper

Was the previous build codesigned & notarized?

The export setup Wizard has not been updated so it's still looking in tools/projucer

Good catch!

[dannytaurus]

@Christoph-Hart said in JUCE submodule PSA:

Was the previous build codesigned & notarized?

FWIW I don't think I've ever seen a gatekeeper dialog for Projucer.

[David Healey]

@Christoph-Hart said in JUCE submodule PSA:

Was the previous build codesigned & notarized?

I just checked and no it doesn't seem that it was. I wonder why I never saw a warning.