JUCE breaking changes

=====================

Version 7.0.3

=============

Change

------

The default macOS and iOS deployment targets set by the Projucer have been

increased to macOS 10.13 and iOS 11 respectively.

Possible Issues

---------------

Projects using the Projucer's default minimum deployment target will have their

minimum deployment target increased.

Workaround

----------

If you need a lower minimum deployment target then you must set this in the

Projucer's Xcode build configuration settings.

Rationale

---------

Xcode 14 no longer supports deployment targets lower than macOS 10.13 and iOS

11.

Change

------

The ARA SDK expected by JUCE has been updated to version 2.2.0.

Possible Issues

---------------

Builds using earlier versions of the ARA SDK will fail to compile.

Workaround

----------

The ARA SDK configured in JUCE must be updated to version 2.2.0.

Rationale

---------

Version 2.2.0 is the latest official release of the ARA SDK.

Change

------

The Thread::startThread (int) and Thread::setPriority (int) methods have been

removed. A new Thread priority API has been introduced.

Possible Issues

---------------

Code will fail to compile.

Workaround

----------

Rather than using an integer thread priority you must instead use a value from

the Thread::Priority enum. Thread::setPriority and Thread::getPriority should

only be called from the target thread. To start a Thread with a realtime

performance profile you must call startRealtimeThread.

Rationale

---------

Operating systems are moving away from a specific thread priority and towards

more granular control over which types of cores can be used and things like

power throttling options. In particular, it is no longer possible to map a 0-10

integer to a meaningful performance range on macOS ARM using the pthread

interface. Using a more modern interface grants us access to more runtime

options, but also changes how we can work with threads. The two most

significant changes are that we cannot mix operations using the new and old

interfaces, and that changing a priority using the new interface can only be

done on the currently running thread.

Change

------

The constructor of WebBrowserComponent now requires passing in an instance of

a new Options class instead of a single option boolean. The

WindowsWebView2WebBrowserComponent class was removed.

Possible Issues

---------------

Code using the WebBrowserComponent's boolean parameter to indicate if a

webpage should be unloaded when the component is hidden, will now fail to

compile. Additionally, any code using the WindowsWebView2WebBrowserComponent

class will fail to compile. Code relying on the default value of the

WebBrowserComponent's constructor are not affected.

Workaround

----------

Instead of passing in a single boolean to the WebBrowserComponent's

constructor you should now set this option via tha

WebBrowserComponent::Options::withKeepPageLoadedWhenBrowserIsHidden method.

If you were previously using WindowsWebView2WebBrowserComponent to indicate to

JUCE that you prefer JUCE to use Windows' Webview2 browser backend, you now do

this by setting the WebBrowserComponent::Options::withBackend method. The

WebView2Preferences can now be modified with the methods in

WebBrowserComponent::Options::WinWebView2.

Rationale

---------

The old API made adding further options to the WebBrowserComponent cumbersome

especially as the WindowsWebView2WebBrowserComponent already had a parameter

very similar to the above Options class, whereas the base class did not use

such a parameter. Furthermore, using an option to specify the preferred

browser backend is more intuitive then requiring the user to derive from a

special class, especially if additional browser backends are added in the

future.

Change

------

The function AudioIODeviceCallback::audioDeviceIOCallback() was removed.

Possible Issues

---------------

Code overriding audioDeviceIOCallback() will fail to compile.

Workaround

----------

Affected classes should override the audioDeviceIOCallbackWithContext() function

instead.

Rationale

---------

The audioDeviceIOCallbackWithContext() function fulfills the same role as

audioDeviceIOCallback(), it just has an extra parameter. Hence the

audioDeviceIOCallback() function was superfluous.

Change

------

The type representing multi-channel audio data has been changed from T** to

T* const*. Affected classes are AudioIODeviceCallback, AudioBuffer and

AudioFormatReader.

Possible Issues

---------------

Code overriding the affected AudioIODeviceCallback and AudioFormatReader

functions will fail to compile. Code that interacts with the return value of

AudioBuffer::getArrayOfReadPointers() and AudioBuffer::getArrayOfWritePointers()

may fail to compile.

Workaround

----------

Functions overriding the affected AudioIODeviceCallback and AudioFormatReader

members will need to be changed to confirm to the new signature. Type

declarations related to getArrayOfReadPointers() and getArrayOfWritePointers()

of AudioBuffer may have to be adjusted.

Rationale

---------

While the previous signature permitted it, changing the channel pointers by the

previously used types was already being considered illegal. The earlier type

however prevented passing T** values to parameters with type const T**. In some

places this necessitated the usage of const_cast. The new signature can bind to

T** values and the awkward casting can be avoided.

Change

------

The minimum supported C++ standard is now C++17 and the oldest supported

compilers on Linux are now GCC 7.0 and Clang 6.0.

Possible Issues

---------------

Older compilers will no longer be able to compile JUCE.

Workaround

----------

No workaround is available.

Rationale

---------

This compiler upgrade will allow the use of C++17 within the framework.

Change

------

Resource forks are no longer generated for Audio Unit plug-ins.

Possible Issues

---------------

New builds of JUCE Audio Units may no longer load in old hosts that use the

Component Manager to discover plug-ins.

Workaround

----------

No workaround is available.

Rationale

---------

The Component Manager is deprecated in macOS 10.8 and later, so the majority of

hosts have now implemented support for the new plist-based discovery mechanism.

The new AudioUnitSDK (https://github.com/apple/AudioUnitSDK) provided by Apple

to replace the old Core Audio Utility Classes no longer includes the files

required to generate resource forks.

Change

------

Previously, the AudioProcessorGraph would call processBlockBypassed on any

processor for which setBypassed had previously been called. Now, the

AudioProcessorGraph will now only call processBlockBypassed if those processors

do not have dedicated bypass parameters.

Possible Issues

---------------

Processors with non-functional bypass parameters may not bypass in the same way

as before.

Workaround

----------

For each AudioProcessor owned by a Graph, ensure that either: the processor has

a working bypass parameter that correctly affects the output of processBlock();

or, the processor has no bypass parameter, in which case processBlockBypassed()

will be called as before.

Rationale

---------

The documentation for AudioProcessor::getBypassParameter() states that if this

function returns non-null, then processBlockBypassed() should never be called,

but the AudioProcessorGraph was breaking this rule. Calling

processBlockBypassed() on AudioProcessors with bypass parameters is likely to

result in incorrect or unexpected output if this function is not overridden.

The new behaviour obeys the contract set out in the AudioProcessor

documentation.

Version 7.0.2

=============

Change

------

The Matrix3D (Vector3D<Type> vector) constructor has been replaced with an

explicit static Matrix3D fromTranslation (Vector3D<Type> vector) function, and a

bug in the behaviour of the multipication operator that reversed the order of

operations has been addressed.

Possible Issues

---------------

Code using the old constructor will not compile. Code that relied upon the order

of multiplication operations will return different results.

Workaround

----------

Code that was using the old constructor must use the new static function. Code

that relied on the order of multiplication operations will need to have the

order of the arguments reversed. With the old code A * B was returning BA rather

than AB.

Rationale

---------

Previously a matrix multipled by a vector would return a matrix, rather than a

vector, as the multiplied-by vector would be automatically converted into a

matrix during the operation. Removing the converting constructor makes

everything much more explicit and there is no confusion about dimensionality.

The current multiplication routine also included a bug where A * B resulted in

BA rather than AB, which needed to be addressed.

Version 7.0.0

=============

Change

------

AudioProcessor::getHostTimeNs() and AudioProcessor::setHostTimeNanos() have

been removed.

Possible Issues

---------------

Code that used these functions will no longer compile.

Workaround

----------

Set and get the system time corresponding to the current audio callback using

the new functions AudioPlayHead::PositionInfo::getHostTimeNs() and

AudioPlayHead::PositionInfo::setHostTimeNs().

Rationale

---------

This change consolidates callback-related timing information into the

PositionInfo type, improving the consistency of the AudioProcessor and

AudioPlayHead APIs.

Change

------

AudioPlayHead::getCurrentPosition() has been deprecated and replaced with

AudioPlayHead::getPosition().

Possible Issues

---------------

Hosts that implemented custom playhead types may no longer compile. Plugins

that used host-provided timing information may trigger deprecation warnings

when building.

Workaround

----------

Classes that derive from AudioPlayHead must now override getPosition() instead

of getCurrentPosition(). Code that used to use the playhead's

CurrentPositionInfo must switch to using the new PositionInfo type.

Rationale

---------

Not all hosts and plugin formats are capable of providing the full complement

of timing information contained in the old CurrentPositionInfo class.

Previously, in the case that some information could not be provided, fallback

values would be used instead, but it was not possible for clients to distinguish

between "real" values set explicitly by the host, and "fallback" values set by

a plugin wrapper. The new PositionInfo type keeps track of which members have

been explicitly set, so clients can implement their own fallback behaviour.

The new PositionInfo type also includes a new "barCount" member, which is

currently only used by the LV2 host and client.

Change

------

The optional JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS preprocessor

flag will now use a new Metal layer renderer when running on macOS 10.14 or

later. The minimum requirements for building macOS and iOS software are now

macOS 10.13.6 and Xcode 10.1.

Possible Issues

---------------

Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS had no

negative effect on performance. Now it may slow rendering down.

Workaround

----------

Disable JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.

Rationale

---------

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS has been ineffective when

running on macOS 10.13 or later. Enabling this flag, and hence using the new

Metal layer renderer when running on macOS 10.14, restores the previous

behaviour and fixes problems where Core Graphics will render much larger

regions than necessary. However, the new renderer will may be slower than the

recently introduced default of asynchronous Core Graphics rendering, depending

on the regions that Core Graphcis is redrawing. Whether

JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS improves or degrades

performance is specific to an application.

Change

------

The optional JUCE_COREGRAPHICS_DRAW_ASYNC preprocessor flag has been removed

and asynchronous Core Graphics rendering is now the default. The helper

function setComponentAsyncLayerBackedViewDisabled has also been removed.

Possible Issues

---------------

Components that were previously using setComponentAsyncLayerBackedViewDisabled

to conditionally opt out of asynchronous Core Graphics rendering will no longer

be able to do so.

Workaround

----------

To opt out of asynchronous Core Graphics rendering the

windowRequiresSynchronousCoreGraphicsRendering ComponentPeer style flag can be

used when adding a component to the desktop.

Rationale

---------

Asynchronous Core Graphics rendering provides a substantial performance

benefit. Asynchronous rendering is a property of a Peer, rather than a

Component, so a Peer style flag to conditionally opt out of asynchronous

rendering is more appropriate.

Change

------

Constructors of AudioParameterBool, AudioParameterChoice, AudioParameterFloat,

AudioParameterInt, and AudioProcessorParameterWithID have been deprecated and

replaced with new constructors taking an 'Attributes' argument.

Possible Issues

---------------

The compiler may issue a deprecation warning upon encountering usages of the

old constructors.

Workaround

----------

Update code to pass an 'Attributes' instance instead. Example usages of the new

constructors are given in the constructor documentation, and in the plugin

example projects.

Rationale

---------

Parameter types have many different properties. Setting a non-default property

using the old constructors required explicitly setting other normally-defaulted

properties, which was redundant. The new Attributes types allow non-default

properties to be set in isolation.

Version 6.1.6

=============

Change

------

Unhandled mouse wheel and magnify events will now be passed to the closest

enclosing enabled ancestor component.

Possible Issues

---------------

Components that previously blocked mouse wheel events when in a disabled state

may no longer block the events as expected.

Workaround

----------

If a component should explicitly prevent events from propagating when disabled,

it should override mouseWheelMove() and mouseMagnify() to do nothing when the

component is disabled.

Rationale

---------

Previously, unhandled wheel events would be passed to the parent component,

but only if the parent was enabled. This meant that scrolling on a component

nested inside a disabled component would have no effect by default. This

behaviour was not intuitive.

Change

------

The invalidPressure, invalidOrientation, invalidRotation, invalidTiltX and

invalidTiltY members of MouseInputSource have been deprecated.

Possible Issues

---------------

Deprecation warnings will be seen when compiling code which uses these members

and eventually builds will fail when they are later removed from the API.

Workaround

----------

Use the equivalent defaultPressure, defaultOrientation, defaultRotation,

defaultTiltX and defaultTiltY members of MouseInputSource.

Rationale

---------

The deprecated members represent valid values and the isPressureValid() etc.

functions return true when using them. This could be a source of confusion and

may be inviting programming errors. The new names are in line with the ongoing

practice of using these values to provide a neutral default in the absence of

actual OS provided values.

Change

------

Plugin wrappers will no longer call processBlockBypassed() if the wrapped

AudioProcessor returns a parameter from getBypassParameter().

Possible Issues

---------------

Plugins that used to depend on processBlockBypassed() being called may no

longer correctly enter a bypassed state.

Workaround

----------

AudioProcessors that implement getBypassParameter() must check the current

value of the bypass parameter on each call to processBlock(), and bypass

processing as appropriate. When switching between bypassed and non-bypassed

states, the plugin must use some sort of ramping or smoothing to avoid

discontinuities in the output. If the plugin introduces latency when not

bypassed, the plugin must delay its output when in bypassed mode so that the

overall latency does not change when enabling/disabling bypass.

Rationale

---------

The documentation for AudioProcessor::getBypassParameter() says

> if this method returns a non-null value, you should never call

processBlockBypassed but use the returned parameter to control the bypass

state instead.

Some plugin wrappers were not following this rule. After this change, the

behaviour of all plugin wrappers is consistent with the documented behaviour.

Change

------

The ComponentPeer::getFrameSize() function has been deprecated on Linux.

Possible Issues

---------------

Deprecation warnings will be seen when compiling code which uses this function

and eventually builds will fail when it is later removed from the API.

Workaround

----------

Use the ComponentPeer::getFrameSizeIfPresent() function. The new function returns

an OptionalBorderSize object. Use operator bool() to determine if the border size

is valid, then access the value using operator*() only if it is.

Rationale

---------

The XWindow system cannot return a valid border size immediately after window

creation. ComponentPeer::getFrameSize() returns a default constructed

BorderSize<int> instance in such cases that corresponds to a frame size of

zero. That however can be a valid value, and needs to be treated differently

from the situation when the frame size is not yet available.

Change

------

The return type of XWindowSystem::getBorderSize() was changed to

ComponentPeer::OptionalBorderSize.

Possible Issues

---------------

User code that uses XWindowSystem::getBorderSize() will fail to build.

Workaround

----------

Use operator bool() to determine the validity of the new return value and

access the contained value using operator*().

Rationale

---------

The XWindow system cannot immediately report the correct border size after

window creation. The underlying X11 calls will signal whether querying the

border size was successful, but there was no way to forward this information

through XWindowSystem::getBorderSize() until this change.

Version 6.1.5

=============

Change

------

XWindowSystemUtilities::XSettings now has a private constructor.

Possible Issues

---------------

User code that uses XSettings::XSettings() will fail to build.

Workaround

----------

Use the XSettings::createXSettings() factory function.

Rationale

---------

The XSETTINGS facility is not available on all Linux distributions and the old

constructor would fail on such systems, potentially crashing the application.

The factory function will return nullptr in such situations instead.

Version 6.1.3

=============

Change

------

The format specific structs of ExtensionsVisitor now return pointers to forward

declared types instead of `void*`. For this purpose the `struct AEffect;`

forward declaration was placed inside the global namespace.

Possible Issues

---------------

User code that includes the VST headers inside a namespace may fail to build,

because the forward declared type can collide with the contents of `aeffect.h`.

Workaround

----------

The collision can be avoided by placing a `struct AEffect;` forward declaration

in the same namespace where the VST headers are included. The forward

declaration must come before the inclusion.

Rationale

---------

Using the forward declared types eliminates the need for error prone casting

at the site where the ExtensionsVisitor facility is used.

Change

------

ListBox::createSnapshotOfRows now returns ScaledImage instead of Image.

Possible Issues

---------------

User code that overrides this function will fail to build.

Workaround

----------

To emulate the old behaviour, simply wrap the Image that was previous returned

into a ScaledImage and return that instead.

Rationale

---------

Returning a ScaledImage allows the overriding function to specify the scale

at which the image should be drawn. Returning an oversampled image will provide

smoother-looking results on high resolution displays.

Change

------

AudioFrameRate::frameRate is now a class type instead of an enum.

Possible Issues

---------------

Code that read the old enum value will not compile.

Workaround

----------

Call frameRate.getType() to fetch the old enum type. Alternatively, use the new

getBaseRate(), isDrop(), isPullDown(), and getEffectiveRate() functions. The

new functions provide a more accurate description of the host's frame rate.

Rationale

---------

The old enum-based interface was not flexible enough to describe all the frame

rates that might be reported by a plugin host.

Change

------

FlexItem::alignSelf now defaults to "autoAlign" rather than "stretch".

Possible Issues

---------------

FlexBox layouts will be different in cases where FlexBox::alignItems is set to

a value other than "stretch". This is because each FlexItem will now default

to using the FlexBox's alignItems value. Layouts that explicitly set

FlexItem::alignSelf on each item will not be affected.

Workaround

----------

To restore the previous layout behaviour, set FlexItem::alignSelf to "stretch"

on all FlexItems that would otherwise use the default value for alignSelf.

Rationale

---------

The new behaviour more closely matches the behaviour of CSS FlexBox

implementations. In CSS, "align-self" has an initial value of "auto", which

computes to the parent's "align-items" value.

Change

------

Functions on AudioPluginInstance that can add parameters have been made

private.

Possible Issues

---------------

Code implementing custom plugin formats may stop building if it calls these

functions.

Workaround

----------

When implementing custom plugin formats, ensure that the plugin parameters

derive from AudioPluginInstance::HostedParameter and then use

addHostedParameter, addHostedParameterGroup or setHostedParameterTree to add

the parameters to the plugin instance.

Rationale

---------

In a plugin host, it is very important to be able to uniquely identify

parameters across different versions of the same plugin. To make this possible,

we needed to introduce a way of retrieving a unique ID for each parameter,

which is now possible using the HostedParameter class. However, we also needed

to enforce that all AudioPluginInstances can only have parameters which are of

the type HostedParameter, which required hiding the old functions.

Version 6.1.0

=============

Change

------

juce::gl::loadFunctions() no longer loads extension functions.

Possible Issues

---------------

Code that depended on extension functions being loaded automatically may cease

to function correctly.

Workaround

----------

Extension functions can now be loaded using juce::gl::loadExtensions().

Rationale

---------

There are a great number of extension functions, and on some systems these can

be slow to load (i.e. a second or so). Projects that do not require these

extension functions should not have to pay for this unnecessary overhead. Now,

only core functions will be loaded by default, and extensions can be loaded

explicitly in projects that require such functionality.

Change

------

Thread::setPriority() will no longer set a realtime scheduling policy for all

threads with non-zero priorities on POSIX systems.

Possible Issues

---------------

Threads that implicitly relied on using a realtime policy will no longer

request a realtime policy if their priority is 7 or lower.

Workaround

----------

For threads that require a realtime policy on POSIX systems, request a priority

of 8 or higher by calling Thread::setPriority() or

Thread::setCurrentThreadPriority().

Rationale

---------

By default, new Thread instances have a priority of 5. Previously, non-zero

priorities corresponded to realtime scheduling policies, meaning that new

Threads would use the realtime scheduling policy unless they explicitly

requested a priority of 0. However, most threads do not and should not require

realtime scheduling. Setting a realtime policy on all newly-created threads may

degrade performance, as multiple realtime threads will end up fighting for

limited resources.

Change

------

The JUCE_GLSL_VERSION preprocessor definition has been removed.

Possible Issues

---------------

Code which used this definition will no longer compile.

Workaround

----------

Use OpenGLHelpers::getGLSLVersionString to retrieve a version string which is

consistent with the capabilities of the current OpenGL context.

Rationale

---------

A compile-time version string is not very useful, as OpenGL versions and

capabilities can change at runtime. Replacing this macro with a function allows

querying the capabilities of the current context at runtime.

Change

------

The minimum support CMake version is now 3.15.

Possible Issues

---------------

It will no longer be possible to configure JUCE projects with CMake versions

between 3.12 and 3.14 inclusive.

Workaround

----------

No workaround is available.

Rationale

---------

Moving to 3.15 allows us to use target_link_directories and

target_link_options, which were introduced in 3.13, which in turn allows us to

provide support for bundled precompiled libraries in modules. Plugins already

required CMake 3.15, so this change just brings other target types in line with

the requirements for plugins.

Change

------

The default value of JUCE_MODAL_LOOPS_PERMITTED has been changed from 1 to 0.

Possible Issues

---------------

With JUCE_MODAL_LOOPS_PERMITTED set to 0 code that previously relied upon modal

loops will need to be rewritten to use asynchronous versions of the modal

functions. There is no non-modal alternative to

AlterWindow::showNativeDialogBox and the previously modal behaviour of the

MultiDocumentPanel destructor has changed.

Workaround

----------

Set JUCE_MODAL_LOOPS_PERMITTED back to 1.

Rationale

---------

Modal operations are a frequent source of problems, particularly when used in

plug-ins. On Android modal loops are not possible, so people wanting to target

Android often have an unwelcome surprise when then have to rewrite what they

assumed to be platform independent code. Changing the default addresses these

problems.

Change

------

The minimum supported C++ standard is now C++14 and the oldest supported

compilers on macOS and Linux are now Xcode 9.2, GCC 5.0 and Clang 3.4.

Possible Issues

---------------

Older compilers will no longer be able to compile JUCE. People using Xcode 8.5

on OS X 10.11 will need to update the operating system to OS X 10.12 to be able

to use Xcode 9.2.

Workaround

----------

No workaround is available.

Rationale

---------

This compiler upgrade will allow the use of C++14 within the framework.

Change

------

Platform GL headers are no longer included in juce_opengl.h

Possible Issues

---------------

Projects depending on symbols declared in these headers may fail to build.

Workaround

----------

The old platform-supplied headers have been replaced with a new juce_gl.h

header which is generated using the XML registry files supplied by Khronos.

This custom header declares GL symbols in the juce::gl namespace. If your code

only needs to be JUCE-compatible, you can explicitly qualify each name with

`juce::gl::`. If you need your code to build with different extension-loader

libraries (GLEW, GL3W etc.) you can make all GL symbols visible without

additional qualification with `using namespace juce::gl`.

Rationale

---------

Using our own GL headers allows us to generate platform-independent headers

which include symbols for all specified OpenGL versions and extensions. Note

that although the function signatures exist, they may not resolve to a function

at runtime. If your code uses commands from an extension or recent GL version,

you should check each function pointer against `nullptr` before attempting to

use it. To avoid repeatedly checking, you could query a subset of functions

after calling gl::loadFunctions() and cache the results. Supplying custom GL

headers also allows us to use C++ techniques (namespaces, references), making

the headers safer than the platform-defined headers. Platform headers are

generally written in C, and export a significant portion of their symbols as

preprocessor definitions.

Change

------

The functions `getComponentAsyncLayerBackedViewDisabled`

and `setComponentAsyncLayerBackedViewDisabled` were moved into the juce

namespace.

Possible Issues

---------------

Code that declares these functions may fail to link.

Workaround

----------

Move declarations of these functions into the juce namespace.

Rationale

---------

Although the names of these functions are unlikely to collide with functions

from other libraries, we can make such collisions much more unlikely by keeping

JUCE code in the juce namespace.

Change

------

The `juce_blocks_basics` module was removed.

Possible Issues

---------------

Projects depending on `juce_blocks_basics` will not build.

Workaround

----------

The BLOCKS API is now located in a separate repository:

https://github.com/WeAreROLI/roli_blocks_basics

Projects which used to depend on `juce_blocks_basics` can use

`roli_blocks_basics` instead.

Rationale

---------

ROLI is no longer involved with the development of JUCE. Therefore, development

on the BLOCKS API has been moved out of the JUCE repository, and to a new

repository managed by ROLI.

Change

------

The live build functionality of the Projucer has been removed.

Possible Issues

---------------

You will no longer be able to use live build in the Projucer.

Workaround

----------

None.

Rationale

---------

Keeping the live build compatible with the latest compilers on all our

supported platforms is a very substantial maintenance burden, but very few

people are using this feature of the Projucer. Removing the live build will

simplify the code and our release process.

Change

------

`Component::createFocusTraverser()` has been renamed to

`Component::createKeyboardFocusTraverser()` and now returns a `std::unique_ptr`

instead of a raw pointer. `Component::createFocusTraverser()` is a new method

for controlling basic focus traversal and not keyboard focus traversal.

Possible Issues

---------------

Derived Components that override the old method will no longer compile.

Workaround

----------

Override the new method. Be careful to override

`createKeyboardFocusTraverser()` and not `createFocusTraverser()` to ensure

that the behaviour is the same.

Rationale

---------

The ownership of this method is now clearer as the previous code relied on the

caller deleting the object. The name has changed to accommodate the new

`Component::createFocusTraverser()` method that returns an object for

determining basic focus traversal, of which keyboard focus is generally a

subset.

Change

------

PluginDescription::uid has been deprecated and replaced with a new 'uniqueId'

data member.

Possible Issues

---------------

Code using the old data member will need to be updated in order to compile.

Workaround

----------

Code that used to use 'uid' to identify plugins should switch to using

'uniqueId', with some caveats - see "Rationale" for details.

Rationale

---------

The 'uniqueId' member has the benefit of being consistent for

a given VST3 across Windows, macOS, and Linux. However, the value of the

uniqueId may differ from the value of the old uid on some platforms. The value

of the old 'uid' member can now be found in the 'deprecatedUid' member, which

should allow clients to implement logic such as checking a saved uid against

the new uniqueId, and falling back to the deprecatedUid. This should allow

hosts to gracefully upgrade from the old uid values to the new values.

Version 6.0.8

=============

Change

------

Calling AudioProcessorEditor::setResizeLimits() will no longer implicitly add a

ResizableCornerComponent to the editor if it has not already been set as

resizable.

Possible Issues

---------------

Code which previously relied on calling this method to set up the corner

resizer will no longer work.

Workaround

----------

Explicitly call AudioProcessorEditor::setResizable() with the second argument

set to true to enable the corner resizer.

Rationale

---------

The previous behaviour was undocumented and potentially confusing. There is now

a single method to control the behaviour of the editor's corner resizer to

avoid any ambiguity.

Change

------

The implementations of `getValue` and `setValue` in `AUInstanceParameter` now

properly take the ranges of discrete parameters into account.

Possible Issues

---------------

This issue affects JUCE Audio Unit hosts. Automation data previously saved for

a discrete parameter with a non-zero minimum value may not set the parameter to

the same values as previous JUCE versions. Note that previously, `getValue` on

a hosted discrete parameter may have returned out-of-range values, and

`setValue` may have only mapped to a portion of the parameter range. As a

result, automation recorded for affected parameters was likely already behaving

unexpectedly.

Workaround

----------

There is no workaround.

Rationale

---------

The old behaviour was incorrect, and was causing issues in plugin validators

and other hosts. Hosts expect `getValue` to return a normalised parameter

value. If this function returns an out-of-range value (including Inf and NaN)

this is likely to break assumptions made by the host, leading to crashes,

corrupted project data, or other defects.