When the JUCE team introduces breaking bugs in plug-ins

Thanks @fabian. This should help!

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?

Thanks,
Koen

1 Like

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…

  1. JUCE_API will be generated on new Projucer project but won’t change without explicitly fiddling with it.

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

That way -

  • upgrading JUCE version should be a hassle.
  • I can keep pace on changes easily.

No (imho) Breaking Change: Audio Parameter ID Support - #14 by chkn

Bahhh…
Just investigated this so…

  • it BREAKS VST/AU for many hosts.
  • Logic X strangely manage to cope with this? didn’t investigate further…
  • you can use auval to see the ids returned of your plug-in before/after (seems interesting to add this to tests on build systems…)
1 Like

You mean the ids of the parameters? I am interested in this, can you elaborate?

auval -v TYPE name manu | grep -E 'Parameter ID:'

(you can do this without the grep…)

So you get details of your params.

Parameter ID:48
Parameter ID:49
Parameter ID:50
Parameter ID:51
Parameter ID:52
Parameter ID:53

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

I’m using the new parameter system and it looks like all id’s are positive:

Parameter ID:11288566 Parameter ID:28943097 Parameter ID:69879911 Parameter ID:70051149 Parameter ID:70103816 Parameter ID:95852938 Parameter ID:110364447 Parameter ID:110364453 Parameter ID:260525163 Parameter ID:351093686 Parameter ID:421446943 Parameter ID:504281783 Parameter ID:505906535 Parameter ID:505906541 Parameter ID:512381614 Parameter ID:665490880 Parameter ID:824404411 Parameter ID:1232173611 Parameter ID:1336600346 Parameter ID:1650207775 Parameter ID:1676421509 Parameter ID:2068465703

Do i still need to switch on the compatibility mode when i’m updating juce or stay the positive id’s the same?

Ok,
Some things to remember:

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

Are you managing your projects with Projucer or not?

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

That’s another workflow break: Debug Targets in XCode with ProJucer

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