diff --git a/BREAKING-CHANGES.txt b/BREAKING-CHANGES.txt index 7d55955b7d..beda4704b5 100644 --- a/BREAKING-CHANGES.txt +++ b/BREAKING-CHANGES.txt @@ -6,31 +6,36 @@ Develop Change ------ -JUCE's MPE classes have been updated to reflect the official specification recently approved -by the MIDI Manufacturers Association (MMA). +JUCE's MPE classes have been updated to reflect the official specification +recently approved by the MIDI Manufacturers Association (MMA). Possible Issues --------------- -The most significant changes have occured in the MPEZoneLayout classes and programs -using the higher level MPE classes such as MPEInstrument, MPESynthesiser, MPESynthesiserBase and -MPESynthesiserVoice should be unaffected. +The most significant changes have occured in the MPEZoneLayout classes and +programs using the higher level MPE classes such as MPEInstrument, +MPESynthesiser, MPESynthesiserBase and MPESynthesiserVoice should be +unaffected. -Previously, any MIDI channel from 1 - 15 could be selected to be the master channel of an MPE zone, -with a specified number of member channels ascending from the master channel + 1. However, in the -new specification this has been simplified so that a device only has a lower and/or an upper zone, -where the lower zone has master channel 1 and assigns new member channels ascending from channel 2 -and the upper zone has master channel 16 and assigns new member channels descending from channel 15. +Previously, any MIDI channel from 1 - 15 could be selected to be the master +channel of an MPE zone, with a specified number of member channels ascending +from the master channel + 1. However, in the new specification this has been +simplified so that a device only has a lower and/or an upper zone, where the +lower zone has master channel 1 and assigns new member channels ascending from +channel 2 and the upper zone has master channel 16 and assigns new member +channels descending from channel 15. Workaround ---------- -Use the MPEZoneLayout::setLowerZone() and MPEZoneLayout::setUpperZone() methods to set zone layouts. +Use the MPEZoneLayout::setLowerZone() and MPEZoneLayout::setUpperZone() methods +to set zone layouts. -Any UI that allows users to select and set zones on an MPE instrument should also -be updated to reflect the specification changes. +Any UI that allows users to select and set zones on an MPE instrument should +also be updated to reflect the specification changes. Rationale --------- -The MPE classes in JUCE are out of date and should be updated to reflect the new, official MPE standard. +The MPE classes in JUCE are out of date and should be updated to reflect the +new, official MPE standard. Version 5.2.1 @@ -39,13 +44,15 @@ Version 5.2.1 Change ------ Calling JUCEApplicationBase::quit() on Android will now really quit the app, -rather than just placing it in background. Starting with API level 21 (Android 5.0), the -app will not appear in recent apps list after calling quit(). Prior to API 21, the app will still -appear in recent app lists but when a user chooses the app, a new instance of the app will be started. +rather than just placing it in background. Starting with API level 21 (Android +5.0), the app will not appear in recent apps list after calling quit(). Prior +to API 21, the app will still appear in recent app lists but when a user +chooses the app, a new instance of the app will be started. Possible Issues --------------- -Any code calling JUCEApplicationBase::quit() to place the app in background will close the app instead. +Any code calling JUCEApplicationBase::quit() to place the app in background +will close the app instead. Workaround ---------- @@ -53,21 +60,24 @@ Use Process::hide(). Rationale --------- -The old behaviour JUCEApplicationBase::quit() was confusing JUCE code, as a new instance of JUCE -app was attempted to be created, while the older instance was still running in background. This -would result in assertions when starting a second instance. +The old behaviour JUCEApplicationBase::quit() was confusing JUCE code, as a new +instance of JUCE app was attempted to be created, while the older instance was +still running in background. This would result in assertions when starting a +second instance. Change ------ Calling JUCEApplicationBase::quit() on Android will now really quit the app, -rather than just placing it in background. Starting with API level 21 (Android 5.0), the -app will not appear in recent apps list after calling quit(). Prior to API 21, the app will still -appear in recent app lists but when a user chooses the app, a new instance of the app will be started. +rather than just placing it in background. Starting with API level 21 (Android +5.0), the app will not appear in recent apps list after calling quit(). Prior +to API 21, the app will still appear in recent app lists but when a user +chooses the app, a new instance of the app will be started. Possible Issues --------------- -Any code calling JUCEApplicationBase::quit() to place the app in background will close the app instead. +Any code calling JUCEApplicationBase::quit() to place the app in background +will close the app instead. Workaround ---------- @@ -75,9 +85,10 @@ Use Process::hide(). Rationale --------- -The old behaviour JUCEApplicationBase::quit() was confusing JUCE code, as a new instance of JUCE -app was attempted to be created, while the older instance was still running in background. This -would result in assertions when starting a second instance. +The old behaviour JUCEApplicationBase::quit() was confusing JUCE code, as a new +instance of JUCE app was attempted to be created, while the older instance was +still running in background. This would result in assertions when starting a +second instance. Change @@ -86,42 +97,45 @@ On Windows, release builds will now link to the dynamic C++ runtime by default Possible Issues --------------- -If you are creating a new .jucer project, then your plug-in will now link to the dynamic -C++ runtime by default, which means that you MUST ensure that the C++ runtime libraries -exist on your customer's computers. +If you are creating a new .jucer project, then your plug-in will now link to +the dynamic C++ runtime by default, which means that you MUST ensure that the +C++ runtime libraries exist on your customer's computers. Workaround ---------- -If you are only targeting Windows 10, then the C++ runtime is now part of the system core -components and will always exist on the computers of your customers (just like kernel332.dll, -for example). If you are targeting Windows versions between Vista and Windows 10, then you -should build your plug-in with the latest updated version of VS2015 or later, which ensures -that it's linked to the universal runtime. Universal runtime is part of the system's core -libraries on Windows 10 and on Windows versions Vista to 8.1, it will be available on your -customer's computers via Windows Update. Unfortunately, if your customer has just installed -Windows 8.1 to Vista on a fresh computer, then there is a chance that the update mechanism -for the universal runtime hasn't triggered yet and your plug-in may still fail. Your installer -should prompt the user to install all the Windows updates in this case or you can deploy the -universal runtime as a redistributable with your installer. If you are targeting earlier -versions of Windows then you should always include the runtime as a redistributable with your -plug-in's installer. Alternatively, you can change the runtime linking to static (however, -see 'Rationale' section). +If you are only targeting Windows 10, then the C++ runtime is now part of the +system core components and will always exist on the computers of your customers +(just like kernel332.dll, for example). If you are targeting Windows versions +between Vista and Windows 10, then you should build your plug-in with the +latest updated version of VS2015 or later, which ensures that it's linked to +the universal runtime. Universal runtime is part of the system's core libraries +on Windows 10 and on Windows versions Vista to 8.1, it will be available on +your customer's computers via Windows Update. Unfortunately, if your customer +has just installed Windows 8.1 to Vista on a fresh computer, then there is a +chance that the update mechanism for the universal runtime hasn't triggered yet +and your plug-in may still fail. Your installer should prompt the user to +install all the Windows updates in this case or you can deploy the universal +runtime as a redistributable with your installer. If you are targeting earlier +versions of Windows then you should always include the runtime as a +redistributable with your plug-in's installer. Alternatively, you can change +the runtime linking to static (however, see 'Rationale' section). Rationale --------- -In a recent update to Windows 10, Microsoft has limited the number of fiber local storage -(FLS) slots per process. Effectively, this limits how many plug-ins with static runtime -linkage can be loaded into a DAW. In the worst case, this limits the total number of plug-ins -to a maximum of 64 plug-ins. There is no workaround for DAW vendors and the only solution is -to push plug-in vendors to use the dynamic runtime. To help with this, JUCE has decided to make +In a recent update to Windows 10, Microsoft has limited the number of fiber +local storage (FLS) slots per process. Effectively, this limits how many +plug-ins with static runtime linkage can be loaded into a DAW. In the worst +case, this limits the total number of plug-ins to a maximum of 64 plug-ins. +There is no workaround for DAW vendors and the only solution is to push plug-in +vendors to use the dynamic runtime. To help with this, JUCE has decided to make dynamic runtime linkage the default in JUCE. Change ------ AudioProcessorGraph interface has changed in a number of ways - Node objects -are now reference counted, there are different accessor methods to iterate them, -and misc other small improvements to the API +are now reference counted, there are different accessor methods to iterate +them, and misc other small improvements to the API Possible Issues ---------------