DISTRHO
/
JUCE
mirror of https://github.com/DISTRHO/JUCE
1
0
Fork 0
Code Releases 1 Activity
Browse Source

Altered the format of BREAKING-CHANGES.txt to display better on GitHub

tags/2021-05-28
tpoole hogliux 7 years ago
parent
7a3e412cf2
commit
ed5dc0ca3d
1 changed files with 121 additions and 35 deletions
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +121
    -35
      BREAKING-CHANGES.txt

+ 121
- 35
BREAKING-CHANGES.txt View File

@@ -6,81 +6,112 @@ Version 5.1.0

Change
------
The option to set the C++ language standard is now located in the project settings instead of the build configuration settings.
The option to set the C++ language standard is now located in the project
settings instead of the build configuration settings.

Possible Issues
---------------
Projects that had a specific verison of the C++ language standard set for exporter build configurations will instead use the default (C++11) when re-saving with the new Projucer.
Projects that had a specific verison of the C++ language standard set for
exporter build configurations will instead use the default (C++11) when
re-saving with the new Projucer.

Workaround
----------
Change the "C++ Language Standard" setting in the main project settings to the required version - the Projucer will add this value to the exported project as a compiler flag when saving exporters.
----------
Change the "C++ Language Standard" setting in the main project settings to the
required version - the Projucer will add this value to the exported project as
a compiler flag when saving exporters.

Rationale
---------
Having a different C++ language standard option for each build configuration was unnecessary and was not fully implemented for all exporters. Changing it to a per-project settings means that the preference will propagate to all exporters and only needs to be set in one place.
Having a different C++ language standard option for each build configuration
was unnecessary and was not fully implemented for all exporters. Changing it to
a per-project settings means that the preference will propagate to all
exporters and only needs to be set in one place.


Change
------
PopupMenus now scale according to the AffineTransform and scaling factor of their target components.
PopupMenus now scale according to the AffineTransform and scaling factor of
their target components.

Possible Issues
---------------
Developers who have manually scaled their PopupMenus to fit the scaling factor of the parent UI will now have the scaling applied two times in a row.
Developers who have manually scaled their PopupMenus to fit the scaling factor
of the parent UI will now have the scaling applied two times in a row.

Workaround
----------
1. Do not apply your own manual scaling to make your popups match the UI scaling
----------
1. Do not apply your own manual scaling to make your popups match the UI
scaling

or

2. Override the Look&Feel method PopupMenu::LookAndFeelMethods::shouldPopupMenuScaleWithTargetComponent and return false.
See https://github.com/WeAreROLI/JUCE/blob/c288c94c2914af20f36c03ca9c5401fcb555e4e9/modules/juce_gui_basics/menus/juce_PopupMenu.h#725
2. Override the Look&Feel method
PopupMenu::LookAndFeelMethods::shouldPopupMenuScaleWithTargetComponent and
return false. See
https://github.com/WeAreROLI/JUCE/blob/c288c94c2914af20f36c03ca9c5401fcb555e4e9/modules/juce_gui_basics/menus/juce_PopupMenu.h#725

Rationale
---------
Previously, PopupMenus would not scale if the GUI of the target component (or any of it’s parents) were scaled. The only way to scale PopupMenus was via the global scaling factor. This had several drawbacks as the global scaling factor would scale everything. This was especially problematic in plug-in editors.
Previously, PopupMenus would not scale if the GUI of the target component (or
any of it’s parents) were scaled. The only way to scale PopupMenus was via the
global scaling factor. This had several drawbacks as the global scaling factor
would scale everything. This was especially problematic in plug-in editors.


Change
------
Removed the setSecurityFlags() method from the Windows implementation of WebInputStream as it disabled HTTPS security features.
Removed the setSecurityFlags() method from the Windows implementation of
WebInputStream as it disabled HTTPS security features.

Possible Issues
---------------
Any code previously relying on connections to insecure webpages succeeding will no longer work.
Any code previously relying on connections to insecure webpages succeeding will
no longer work.

Workaround
----------
Check network connectivity on Windows and re-write any code that relied on insecure connections.
Check network connectivity on Windows and re-write any code that relied on
insecure connections.

Rationale
---------
The previous behaviour resulted in network connections on Windows having all the HTTPS security features disabled, exposing users to network attacks. HTTPS connections on Windows are now secure and will fail when connecting to an insecure web address.
The previous behaviour resulted in network connections on Windows having all
the HTTPS security features disabled, exposing users to network attacks. HTTPS
connections on Windows are now secure and will fail when connecting to an
insecure web address.


Change
------
Pointer arithmetic on a pointer will have the same result regardless if it is wrapped in JUCE's Atomic class or not.
Pointer arithmetic on a pointer will have the same result regardless if it is
wrapped in JUCE's Atomic class or not.

Possible Issues
---------------
Any code using pointer arithmetic on Atomic<T*> will now have a different result leading to undefined behaviour or crashes.
Any code using pointer arithmetic on Atomic<T*> will now have a different
result leading to undefined behaviour or crashes.

Workaround
----------
Re-write your code in a way that it does not depend on your pointer being wrapped in JUCE's Atomic or not. See rationale.
Re-write your code in a way that it does not depend on your pointer being
wrapped in JUCE's Atomic or not. See rationale.

Rationale
---------
Before this change, pointer arithmetic with JUCE's Atomic type would yield confusing results. For example, the following code would assert before this change:
Before this change, pointer arithmetic with JUCE's Atomic type would yield
confusing results. For example, the following code would assert before this
change:

int* a; Atomic<int*> b;

jassert (++a == ++b);

Pointer a in the above code would be advanced by sizeof(int) whereas the JUCE's Atomic always advances it's underlying pointer by a single byte. The same is true for operator+=/operator-= and operator--. The difference in behaviour is confusing and unintuitive. Furthermore, this aligns JUCE's Atomic type with std::atomic.
Pointer a in the above code would be advanced by sizeof(int) whereas the JUCE's
Atomic always advances it's underlying pointer by a single byte. The same is
true for operator+=/operator-= and operator--. The difference in behaviour is
confusing and unintuitive. Furthermore, this aligns JUCE's Atomic type with
std::atomic.



@@ -93,15 +124,25 @@ JUCE has changed the way native VST3/AudioUnit parameter ids are calculated.

Possible Issues
---------------
DAW projects with automation data written by an AudioUnit or VST3 plug-in built with pre JUCE 4.3.1 versions will load incorrectly when opened by an AudioUnit or VST3 built with JUCE versions 4.3.1 and later. Plug-ins using JUCE_FORCE_USE_LEGACY_IDS are not affected.
DAW projects with automation data written by an AudioUnit or VST3 plug-in built
with pre JUCE 4.3.1 versions will load incorrectly when opened by an AudioUnit
or VST3 built with JUCE versions 4.3.1 and later. Plug-ins using
JUCE_FORCE_USE_LEGACY_IDS are not affected.

Workaround
----------
Disable JUCE_USE_STUDIO_ONE_COMPATIBLE_PARAMETERS in the juce_audio_plugin_client module config page in the Projucer. For new plug-ins, be sure to use the default value for this property.
Disable JUCE_USE_STUDIO_ONE_COMPATIBLE_PARAMETERS in the
juce_audio_plugin_client module config page in the Projucer. For new plug-ins,
be sure to use the default value for this property.

Rationale
--------
JUCE needs to convert between its own JUCE parameter id format (strings) to the native parameter id formats of the various plug-in backends. For VST3 and AudioUnits, JUCE uses a hash function to generate a numeric id. However, some VST3/AudioUnit hosts (specifically Studio One) have a bug that ignore any parameters that have a negative parameter id. Therefore, the hash function for VST3/AudioUnits needed to be changed to only return positive-valued hashes.
JUCE needs to convert between its own JUCE parameter id format (strings) to the
native parameter id formats of the various plug-in backends. For VST3 and
AudioUnits, JUCE uses a hash function to generate a numeric id. However, some
VST3/AudioUnit hosts (specifically Studio One) have a bug that ignore any
parameters that have a negative parameter id. Therefore, the hash function for
VST3/AudioUnits needed to be changed to only return positive-valued hashes.



@@ -110,11 +151,15 @@ Version 4.3.0

Change
------
A revised multi-bus API was released which supersedes the previously flawed multi-bus API - JUCE versions 4.0.0 - 4.2.4 (inclusive).
A revised multi-bus API was released which supersedes the previously flawed
multi-bus API - JUCE versions 4.0.0 - 4.2.4 (inclusive).

Possible Issues
---------------
If you have developed a plug-in with JUCE versions 4.0.0 - 4.2.4 (inclusive), then you will need to update your plug-in to the new multi-bus API. Pre JUCE 4.0.0 plug-ins are not affected apart from other breaking changes listed in this document.
If you have developed a plug-in with JUCE versions 4.0.0 - 4.2.4 (inclusive),
then you will need to update your plug-in to the new multi-bus API. Pre JUCE
4.0.0 plug-ins are not affected apart from other breaking changes listed in
this document.

Woraround
---------
@@ -122,7 +167,11 @@ None.

Rationale
--------
A flawed multi-bus API was introduced with JUCE versions 4.0.0 up until version 4.2.4 (inclusive) which was not API compatible with pre JUCE 4 plug-ins. JUCE 4.3.0 releases a revised multi-bus API which restores pre JUCE 4 API compatibility. However, the new multi-bus API is not compatible with the flawed multi-bus API (JUCE version 4.0.0 - 4.2.4).
A flawed multi-bus API was introduced with JUCE versions 4.0.0 up until version
4.2.4 (inclusive) which was not API compatible with pre JUCE 4 plug-ins. JUCE
4.3.0 releases a revised multi-bus API which restores pre JUCE 4 API
compatibility. However, the new multi-bus API is not compatible with the flawed
multi-bus API (JUCE version 4.0.0 - 4.2.4).


Change
@@ -131,15 +180,32 @@ JUCE now generates the AAX plug-in bus layout configuration id independent from

Possible Issues
---------------
ProTools projects generated with a < 4.3.0 JUCE versions of your plug-in, may load the incorrect bus configuration when upgrading your plug-in to >= 4.3.0 versions of JUCE.
ProTools projects generated with a < 4.3.0 JUCE versions of your plug-in, may
load the incorrect bus configuration when upgrading your plug-in to >= 4.3.0
versions of JUCE.

Workaround
----------
Implement AudioProcessor’s getAAXPluginIDForMainBusConfig callback to manually override which AAX plug-in id is associated to a specific bus layout of your plug-in. This workaround is only necessary if you have released your plug-in built with a version previous to JUCE 4.3.0.
Implement AudioProcessor’s getAAXPluginIDForMainBusConfig callback to manually
override which AAX plug-in id is associated to a specific bus layout of your
plug-in. This workaround is only necessary if you have released your plug-in
built with a version previous to JUCE 4.3.0.

Rationale
--------
The new multi-bus API offers more features, flexibility and accuracy in specifying bus layouts which cannot be expressed by the Projucer’s legacy “Channel layout configuration” field. The native plug-in format backends use the new multi-bus callback APIs to negotiate channel layouts with the host - including the AAX plug-in ids assigned to specific bus layouts. With the callback API, there is no notion of an order in which the channel configurations appear - as was the case with the legacy “Channel layout configuration” field - and therefore cannot be used to generate the AAX plug-in id. To remain backward compatible to pre JUCE 4.0.0 plug-ins, JUCE does transparently convert the legacy “Channel layout configuration” field to the new callback based multi-bus API, but this does not take the order into account in which the channel configurations appear in the legacy “Channel layout configuration” field.
The new multi-bus API offers more features, flexibility and accuracy in
specifying bus layouts which cannot be expressed by the Projucer’s legacy
“Channel layout configuration” field. The native plug-in format backends use
the new multi-bus callback APIs to negotiate channel layouts with the host -
including the AAX plug-in ids assigned to specific bus layouts. With the
callback API, there is no notion of an order in which the channel
configurations appear - as was the case with the legacy “Channel layout
configuration” field - and therefore cannot be used to generate the AAX plug-in
id. To remain backward compatible to pre JUCE 4.0.0 plug-ins, JUCE does
transparently convert the legacy “Channel layout configuration” field to the
new callback based multi-bus API, but this does not take the order into account
in which the channel configurations appear in the legacy “Channel layout
configuration” field.



@@ -148,17 +214,37 @@ Version 4.2.1

Change
------
JUCE now uses the paramID property used in AudioProcessorParameterWithID to uniquely identify parameters to the host.
JUCE now uses the paramID property used in AudioProcessorParameterWithID to
uniquely identify parameters to the host.

Possible Issues
---------------
DAW projects with automation data written by an audio plug-in built with pre JUCE 4.2.1 will load incorrectly when opened by an audio plug-in built with JUCE 4.2.1 and later.
DAW projects with automation data written by an audio plug-in built with pre
JUCE 4.2.1 will load incorrectly when opened by an audio plug-in built with
JUCE 4.2.1 and later.

Workaround
----------
Enable JUCE_FORCE_USE_LEGACY_IDS in the juce_audio_plugin_client module config page in the Projucer. For new plug-ins, be sure to disable this property.
Enable JUCE_FORCE_USE_LEGACY_IDS in the juce_audio_plugin_client module config
page in the Projucer. For new plug-ins, be sure to disable this property.

Rationale
--------
Each parameter of the AudioProcessor has an id associated so that the plug-in’s host can uniquely identify parameters. The id has a different data-type for different plug-in types (for example VST uses integers, AAX uses string identifiers). Before 4.2.1, JUCE generated the parameter id by using the index of the parameter, i.e. the first parameter had id zero, the second parameter had id one, etc. This caused problems for certain plug-in types where JUCE needs to add internal parameters to the plug-in (for example VST3 requires the bypass control to be a parameter - so JUCE automatically creates this parameter for you in the VST3 backend). This causes subtle problems if a parameter is added to an update of an already published plug-in. The new parameter’s id would be identical to the id of the bypass parameter in old versions of your plug-in, causing seemingly random plug-in bypass behaviour when user’s upgrade their plug-in.
Most plug-in backends differentiate between a parameter’s id an index, so this distinction was adopted starting with JUCE 4.2.1 by deriving the parameter’s unique id from the paramID property of AudioProcessorParameterWithID class.
Each parameter of the AudioProcessor has an id associated so that the plug-in’s
host can uniquely identify parameters. The id has a different data-type for
different plug-in types (for example VST uses integers, AAX uses string
identifiers). Before 4.2.1, JUCE generated the parameter id by using the index
of the parameter, i.e. the first parameter had id zero, the second parameter
had id one, etc. This caused problems for certain plug-in types where JUCE
needs to add internal parameters to the plug-in (for example VST3 requires the
bypass control to be a parameter - so JUCE automatically creates this parameter
for you in the VST3 backend). This causes subtle problems if a parameter is
added to an update of an already published plug-in. The new parameter’s id
would be identical to the id of the bypass parameter in old versions of your
plug-in, causing seemingly random plug-in bypass behaviour when user’s upgrade
their plug-in.

Most plug-in backends differentiate between a parameter’s id an index, so this
distinction was adopted starting with JUCE 4.2.1 by deriving the parameter’s
unique id from the paramID property of AudioProcessorParameterWithID class.


Write Preview
Loading…
Cancel
Save