- May 21, 2021
-
-
reuk authored
In cases where a VST3 plugin set a non-zero latency in its prepareToPlay, and then set its latency to 0 later on, the host was not notified about the latency change.
-
reuk authored
In older versions of the VST3SDK, hostContext is a raw pointer, in newer versions it's a smart pointer. If we do manual refcounting with the smart pointer, we may cause leaks.
-
reuk authored
-
ed authored
-
ed authored
Accessibility: Fixed some bugs in Windows text navigation and readouts, improved selection and focus navigation
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
ed authored
-
- May 19, 2021
- May 18, 2021
- May 17, 2021
- May 15, 2021
- May 14, 2021
- May 13, 2021
- May 12, 2021
-
-
reuk authored
-
reuk authored
-
reuk authored
-
reuk authored
The old design had us checking isActive inside our audio callbacks, and also modifying isActive from prepareToPlay(), and releaseResources(). To avoid race conditions, and to ensure that isActive actually reflects the activation state of our plugin, we need to lock in these places. If we don't lock, there's a chance that other threads will observe isActive to be true while the plugin is not actually active (for example). If you're not convinced, imagine this scenario: - The message thread calls prepareToPlay. The plugin is activated. - The audio thread starts calling processBlock, and gets as far as the isActive check. The plugin appears active, so we continue into processBlock. - At the same time, the message thread calls releaseResources(). The processBlock call is still in progress, but the message thread is simultaneously making calls to setProcessing() and setActive(), which is a race. Normally, it'd be up to the host of the AudioProcessor to ensure that prepareToPlay() isn't called at the same time as processBlock(). However, VST3 plugins can request a restart at any time from the UI thread, requiring us to call prepareToPlay() even while processBlock() is running.
-