nope. still Introjucer.
Well, ok, itās basically the same thing: Introjucer became Projucer in ver. 4.
What I meant is whether you are managing your project yourself, or if you are relying on the tool Intro/Projucer provided by JUCE.
Since the latter is the case, I think it should be fairly easy for you to upgrade if you pull the latest āmasterā branch (which corresponds to ver. 4.3.1 with some hotfixes on it), build the Projucer in it and then use it to load and resave all your Introjucer projects.
(Disclaimer: I am not using Projucer myself, what I am saying is solely based on the experience on seeing that all projects inside the JUCE codebase are regularly updated just by loading and then resaving them).
Regarding multi-bus, Iām fairly certain that 4.3.1 is the optimal āstableā release for you now: earlier releases still had some small issues with it. Donāt know about the state of develop with respect to this.
One additional thought about this:
Recently, Steinberg released VST SDK 3.6.7, which introduced some incompatibilities with the way JUCE used earlier versions of the SDK and so an hotfix has been added to master to support ver. 3.6.7 (and not earlier).
Turns out, that SONAR has currently a bug that crashes VST3 plug-ins built with VST SDK 3.6.7.
This does not happen with JUCE plug-ins only, so it seems like a bug in SONAR, whose developers have been made aware (more on this: VST SDK 3.6.7, latest JUCE tip: VST3 crashes Sonar).
Making a long story short, if you are in possession of a VST SDK that precedes 3.6.7, then Iād suggest you to stick to it and to update to the JUCE commit on master linked below, which is the one right before the breaking changes to support 3.6.7.
If you do so, you will still have a fairly recent fully functional JUCE 4.3.1 to work with, and then when the dust settles around this problem (hopefully SONAR will fix the bug in the next monthly release), you will be free to upgrade past this.
1 Like
Concerning those ābreaking changesā flags, I understand the need to set them to the default value for new projects, but perhaps you could automatically set their values when loading old projects by checking the projucer version within .jucer file? (for instance, if jucerVersion is 4.0.0, then set the JUCE_FORCE_LEGACY_PARAM_ā¦ to true)
or for more precision the version of each juce module could also be saved within the file perhaps?
just thinking out loud, but it would be great if we could have a solution that would not need us to intentionally set up a flag to not break things.
I would prefer, if there us a breaking change, and there is a legacy flag, the programmer has to actively decide to use the old or the new behaviour, otherwise the compilation should break.
3 Likes
Are breaking changes tagged or listed anywhere for easy reference?
yes : https://github.com/WeAreROLI/JUCE/blob/develop/BREAKING-CHANGES.txt
but I agree with chkn it would be great if the compilation could break until we actively set the flags for existing projects
2 Likes
cheers