Previously, it wasn't safe to access Font instances from multiple
threads because there was a chance that they might reference the same
shared internal state. In this case, calling getTypeface() or getAscent from
two threads simultaneously would cause a race on the typeface and ascent
data members, even though the Font instances appeared to be disjoint.
With this change in place, it is now safe to use Font instances from
multiple threads simultaneously.
It is still an error to modify the same Font instance from multiple
threads without synchronization!
// Fine:
Font a;
Font b = a;
auto futureA = std::async (std::launch::async, [&a] { /* do something with a */ });
auto futureB = std::async (std::launch::async, [&b] { /* do something with b */ });
// Bad idea:
Font f;
auto futureA = std::async (std::launch::async, [&f] { /* do something with f */ });
auto futureB = std::async (std::launch::async, [&f] { /* do something with f */ });
Previously, the samplerate combo would display as a blank box in the
case that the device's actual samplerate wasn't one of the "available"
samplerates reported by the device.
By defining JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES, the iOS audio device
will always use the requested samplerates instead of querying the
current audio device for the samplerates it supports. This is useful
because certain hardware (such as the Focusrite iTrack Dock) takes a
long time to set new samplerates, which can end up freezing the main
thread for significant lengths of time.
This approach is inspired by the AUM app for iOS, which appears to
provide a fixed list of "allowed" samplerates, rather than querying the
device for its allowed samplerates.
Calling AccessibilityHandler::getChildren() or getParent() may cause an AccessibilityHandler object to be created and an InternalAccessibilityEvent::elementCreated notification to be sent. Calling AndroidAccessibilityEvent.setSource may then cause a recursive populateNodeInfo() call.
This issue could be seen when modifying the "OSC FmModSrc" parameter of
U-He Diva AU from the custom editor in the AudioPluginHost. The
parameter display in the generic parameter editor did not update
properly because the wrong parameter was marked as changed.
Previously, updating the program or bypass parameter could cause an
out-of-bounds access into the parameter value cache. This is because
AudioProcessorParameter::getParameterIndex() was used to index into the
cache, but the parameter index could be negative for parameters that
had not been added to the AudioProcessor.
We now use the appropriate index in the cache for parameters that
have not been added to the AudioProcessor.
