JUCE submodule PSA

[Christoph Hart]

Yes the rationale is that I want to support both JUCE6 and JUCE8 and this way you can simply swap the JUCE version with a single command.

I only checked Windows so far but I‘ll do macOS today and then we‘ll tackle Linux in a joint effort.

[dannytaurus]

@Christoph-Hart Wow!

[Oli Ullmann]

@Christoph-Hart
How do I switch between JUCE6 and JUCE8, and what is the default setting?

And do I need to be aware of compatibility issues with old or ongoing projects?

Many thanks,
Oli

[Christoph Hart]

@Oli-Ullmann default is (and will be for the foreseeable future) JUCE 6. In order to switch to JUCE 8 you just change the branch of the submodule. I messed up stuff when trying to use SourceTree for it, but it's a one liner in the command line bash - once everything is ready I'll add some docs on how to do that.

The customized JUCE versions that work with HISE are in this repo:

https://github.com/christophhart/JUCE_customized/tree/juce6
https://github.com/christophhart/JUCE_customized/tree/juce8

[Oli Ullmann]

@Christoph-Hart
Sounds complicated...
Thanks for the info! I'll give it a try in the next few days...

[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.

[David Healey]

@Christoph-Hart The Projucer binary appears to be Apple Silicon only

[JulesV]

@David-Healey Sorry for the noob question,

What we need to do is to download the modules, extras & projucer folders in the submodule repository?

Then copy them to the tools/projucer folder in the latest Hise develop branch that we downloaded them from?

[David Healey]

@JulesV Remove any copies of the HISE source you already have. Then reclone the repo using this command:

git clone --branch develop --recurse-submodules https://github.com/christophhart/HISE.git

That's it, you'll be good to go.