Alternatively we could disable antialiasing before the fill operation
but this could cause neighbouring Components to overlap on the screen
even if their coordinates don't.
This fixes an issue where opening a FileTreeComponent could cause the UI
to hang. The call to subcontentsList->isStillLoading() in
FileListTreeItem::selectFile() would always return true because the
file-scanner TimeSliceThread wasn't started until the selectFile() call
finished.
Previously, the bus layout was considered invalid if the host provided
an unexpected number of channels on a disabled bus. Specifically,
Acoustica 7 would prepare sidechain input buses with a non-zero number
of channels, but provide a zero-channel bus during processing.
Given that the plug-in doesn't attempt to read from disabled buses, it
should be safe to process as normal in this scenario.
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
