Tom Poole
8 years ago
1 changed files with 67 additions and 53 deletions
Split View
Diff Options
-
+67 -53BREAKING-CHANGES.txt
+ 67
- 53
BREAKING-CHANGES.txt
View File
| @@ -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. | |||
| 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. | |||
| 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. | |||
| 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 | |||
| --------------- | |||