audacity
audacity copied to clipboard
audacity
An audible "tail" can be heard when switching an effect off and then back on
- [x] AudioUnit (e. g. AUMatrixReverb)
- [x] Ladspa (e.g. GVerb from swh plug-ins)
- [ ] LV2 (e.g. any of the Dragonfly reverbs)
- [ ] VST (not yet testable)
- [ ] VST3 (not yet testable)
@Paul-Licameli When the effect is turned off during the playback, it leaves some "residual" tail of audio. It can be properly observed on a DTMF tones track where signal and silence are alternating. So the trick is to start playback having the effect turned on and then turn it off in the middle of the playback of the tone:
https://user-images.githubusercontent.com/70063970/174297861-4c81bcc0-4d38-423c-b22a-c96fb186e8c7.mp4
And then, when clicking the toggle again during the silence part, you can hear an audible "tail" while there should be silence.
Originally posted by @dozzzzer in https://github.com/audacity/audacity/issues/3060#issuecomment-1158821687
FWIW, I was able to reproduce as described above as well on recent master build on MacOS Monterey 12.3.1.
@crsib apparently yes, but not only the built-in reverb, I observed the exact same issue with the pre-installed Apple AUReverb2 and AUMatrixReverb on MacOS.
The above-mentioned issue can still be observed when using the built-in Reverb plugin.
The above-mentioned issue can still be observed when using the built-in Reverb plugin.
Reverb will not be available in the side bar this release. Please check the boxes in the description for the effect families for which you can demonstrate the fix.
@Paul-Licameli For an LV2 family (e.g. Dragonfly Reverb) the issue still remains:
https://user-images.githubusercontent.com/70063970/185418379-73709b36-f00e-4ed6-9710-243648b6b66e.mp4
@dozzzzer yes, I observe that with Dragonfly Plate, but also observe that Dragonfly Hall now works as expected after my fix.
I think you should check off the box if you can demonstrate that at least one effect of the family was not clearing the tail before my fix, but now, it does. That means our host side gets its part of the protocol right. But if it fails still with some individual effects -- then I think we can blame those effets for not being correctly implemented.
@Paul-Licameli re-testing on macOS against the most recent release branch build shows that at least some LV2 effects still have this issue (dRowAudio: Reverb, TAL Reverb), and some Audio Units also show the same undesired behavior (DX Reverb Light can be used for reproduction)
@Paul-Licameli re-testing on macOS against the most recent release branch build shows that at least some LV2 effects still have this issue (dRowAudio: Reverb, TAL Reverb), and some Audio Units also show the same undesired behavior (DX Reverb Light can be used for reproduction)
If at least one reverb effect of each family can be shown to behave correctly -- then I think I have done what I can on the host side of the program, improving it over what it was before my merge, and blame is on the plug-ins for not responding as they should to messages from the host.