mirror of
https://github.com/juce-framework/JUCE.git
synced 2026-01-10 23:44:24 +00:00
Whitespace corrections
This commit is contained in:
Tom Poole
parent
824840e8b4
commit
964638f6d1
1 changed files with 66 additions and 52 deletions
|
|
@ -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
|
||||
---------------
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue