According to the VST3 spec, activateBus and setBusArrangements shall not
be called when a plugin is in the 'activated' state.
Previously, if prepareToPlay was called twice in a row on a hosted VST3
plugin, during the second call the plug-in would already be activated,
but its bus layout would still be adjusted. Now, we always ensure that
the plugin is inactive before the bus properties are adjusted.
This avoids repeating the 'fallback' values in the case that the
AudioPlayHead or PositionInfo is not available.
As a side-effect of this change, when an AudioPlayHead is available but
does not supply a valid BPM value, a fallback of 120 will be used,
instead of 0. This fixes an issue where the Microtonic sequencer failed
to play in the AudioPluginHost.
Also fixes an issue in which `numInputSamplesAvailable` was assigned
instead of `exceeded`, Github issue #1114.
Co-authored-by: Tatsuya Shiozawa <shio.tatsu99@gmail.com>
This change fixes an issue where opening multiple OpenGLContexts on
certain versions of macOS (observed on 10.13) could cause a deadlock.
The issue can be reproduced by:
- Attaching an OpenGL context to the AudioPluginDemo editor
- Opening multiple copies of the editor simultaneously in a plugin host.
I tested with Live 10.
I also observed the issue in a standalone app that opened new windows
containing OpenGLContexts on a timer.
On Windows, the OpenGL context window sometimes receives a repaint
request after moving between screens with different scale factors.
If the screen has changed size/scale since the last paint operation,
failing to invalidate the painted area may cause the screen contents
to be drawn at the wrong scale until paint is next called.
- 4.1 and 4.3 contexts can now be requested
- The requested context version is no longer ignored on Linux
- Debugging contexts are now enabled in Debug builds with GL 4.3
- Fixes a bug where glEnable(GL_TEXTURE_2D) was called in core profiles
The previous implementation would trigger assertions in
grabKeyboardFocus() when the DragImageComponent was hidden due to the
target returning false from shouldDrawDragImageWhenOver().
Hiding the image would also mean that its keyboard focus was lost. Now
focus is restored when the image becomes visible again.
