You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There has been a mismatch between many plugin formats (VST3, AU, CLAP) vs. AAP (and LV2) that sampleRate is required only at setting up a plugin instance (prepareToPlay() in JUCE, setupProcessing() in VST3, activate in CLAP) - or - it is required at instantiation(instantiate in LV2_Descriptor).
AAP had to follow the LV2 way otherwise it will have to populate plugin instance which is quite annoying otherwise, but this eager sampleRate setup also makes it impossible to configure sample rate after instantiating the plugins, which brings in general UX problem - for example, you will have to restructure the entire audio plugin graphs if you want to change the sample rate.
Probably we should make it follow the majority for better UX and rather implement "re-instantiation" in aap-lv2. It seems what JUCE LV2 support does too.
The text was updated successfully, but these errors were encountered:
There has been a mismatch between many plugin formats (VST3, AU, CLAP) vs. AAP (and LV2) that
sampleRate
is required only at setting up a plugin instance (prepareToPlay()
in JUCE,setupProcessing()
in VST3,activate
in CLAP) - or - it is required at instantiation(instantiate
inLV2_Descriptor
).AAP had to follow the LV2 way otherwise it will have to populate plugin instance which is quite annoying otherwise, but this eager sampleRate setup also makes it impossible to configure sample rate after instantiating the plugins, which brings in general UX problem - for example, you will have to restructure the entire audio plugin graphs if you want to change the sample rate.
Probably we should make it follow the majority for better UX and rather implement "re-instantiation" in aap-lv2. It seems what JUCE LV2 support does too.
The text was updated successfully, but these errors were encountered: