One question to clarify something about the oldest change in the breaking changes list (and if you feel this belongs in another place on the forum, feel free to move this):
If the last release of the plugin was done under these conditions:
JUCE version before 4.2.1
plugin did not make use of AudioProcessorParameter(WithID) (only using plain old setParameter/getParameter) [clarified in post edit]
only a VST 2.4 version was released (no VST 3)
then, will upgrading JUCE to the last development version and building/releasing a new VST 2.4 plugin still cause the described problems related to that bypass parameter?
And is that bypass parameter the only one, or are there others and other effects to consider/look out for?
Would be really helpful to make sure you organize proper changes between releases.[quote=“fabian, post:9, topic:20941”]
BREAKING-CHANGES.txt
JUCE now uses the paramID property used in AudioProcessorParameterWithID to uniquely identify parameters to the host
[/quote]
From what I recall (and see) this is related only to newer methods of plug-in management. but for plain addParameter it doesn’t require any change.
And about best workflow, as @KoenT suggest.
having a definition of JUCE_API with numeric value sounds to me the best resolution.
So…
JUCE_API will be generated on new Projucer project but won’t change without explicitly fiddling with it.
You (aka JUCE team), can add compiler warning when the API is older in a way you discourage the use of it or even fail to compile if feature has dependency on newer changes.
In the case I asked about above, the plugin just uses getParameter/setParameter (it doesn’t use addParameter/AudioProcessorParameter(WithID) at all). I’ve edited my post to clarify that.
So, would there be a problem when upgrading such a VST 2.4 plugin to the latest development branch then?
It’s just not entirely clear to me if that bypass parameter issue affects plugins that handle their parameters themselves (I already had my own Parameter classes).
auval will prefer your home folder components! so make true sanity against released builds by testing returned IDs of older builds.
@KoenT , VST2 wrapper doesn’t use the JUCE_FORCE_USE_LEGACY_PARAM_IDS flag. @patrickkunz and others, the main concern is for VST3 and AU. both started using hashes IDs.
so instead of getting 0…N for parameter IDs you’ll get some numeric values based on the hash function used in the wrapper.
I saw that for AAX (and RTAS?) it should do much but for AU & VST3 if you released prior to the changes AUTOMATION WILL BREAK (with the exception of Logic X from my testings).
semi OT question… but what’s the safest JUCE version today? I’m still on 3.2 and I’m very afraid to step to a newer version. I would like to use the multibus, but so far I don’t know if that’s still experimental or there’s a working version… and, if exists, the related JUCE version what will break for my existing plugins.
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.
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.
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.