Open unfa opened 1 year ago
Likely an ardour bug.
I'll have to test. I think I did encounter a similar issue in the past with a different plug-in. Maybe it's about a plug-in changing it's reported latency mid-playback? But if that's the case - why would changing gain and threshold have the same effect?
In Ardour's plugin GUI, top-left you edit a plugin's latency
Or Ardour > Preferences > Appearance > Toolbar > Display Latency Compensation Info -- the toolbar widget has a toggle to disable Plugin Delay Compensation
I think this might not have anything to do with x42-dpl or latency compensation. I just got the same result attempting to automate CHOW Tape Model's Mix factor:
Or maybe it does... because at 0% wet CHOW probably engages an internal Bypass mode...
It froze on the 2nd automation point, not the first one...
Now I got an identical freeze on a track Mute automation point. I think this project is just going haywire. It's been created in 2018 and I think living through so many versions of Ardour may accumulate some strange issues that are not going to come up in any other situation. I'm now retrying in a recent nightly build of Ardour 7.2 again, maybe it'll work this time. Even if it will, that doesn't mean it'll work the next day, so once I manage to get it out, I'll just export all stems and bounce all tracks as backup...
It seems than whenever x42-dpl encounters an automation change, Ardour's transport is stalled and can't move. The only solution I found is to manually grab and move the automation point back or forward - then sometimes Ardour will resume. Sometimes this stalling also results in Ardour freezing and crashing with a segfault.
Removing the automation data for the x42-dpl instance removes the issue completely.
First I only automated the "Enable" parameter to bypass the effect. Then I tried to imitate the same result automating Gain and Threshold controls to identical effect; Ardour playhead gets stuck on the first automation point that has anything to do with x42-dpl.