This is intended to fix two issues:
- In REAPER, setting automation recording to 'Latch', recording some
automation, saving and reloading the project, then starting playback causes
automation data to be overwritten. This appears to be because REAPER
interprets parameter change messages sent during state restoration as
originating from the user.
- In Ableton Live, automation lanes are sometimes disabled when loading
projects. This also seems to be because the setStateInformation call
may send parameter change messages back to the host.
According to the docs for kAudioUnitProperty_ClassInfo, the host is
required to notify all parameter listeners that the parameter values may
have changed, implying that the plugin need not send its own parameter
change notifications during state restoration.
Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.
Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.
Previously, preparing an AudioProcessorGraph containing hosted LV2
plugins would recreate the plugins and then set their state. For plugins
without threadsafe restore, setting the state would take the
callbackLock to avoid races with processBlock. This meant that
- During prepare, the graph would take the processorLock, then the
processor would take its own callbackLock.
- During playback, the graph would take the processor's callbackLock,
and then would take the node's processorLock.
This is probably benign (prepare shouldn't be called concurrently with
processBlock at all), but to be on the safe side we now avoid taking the
callbackLock when setting new plugin state during prepareToPlay.