Stop reverb tail when hitting Bypass in Logic [SOLVED]

[iamdannywyatt]

I’m not a developer myself, but I’m trying to find an answer for this if someone can share it. I use the TAL REVERB free plugin and I noticed that the tail doesn’t stop when I hit Bypass and then un-Bypass, meaning, when I hit bypass it stops the tail, of course, but when I click it again to enable it, the tail is still there. This is more noticeable when the tail is long, of course.

I sent an email to the developer and he wasn’t able to figure it out yet. He mentioned that the plugin needs to “clear the buffer” (whatever that means…) when the the plugin is bypassed.

I wanted to find an answer that could maybe help him solve this.

I found these two topics that I already sent him as well, but I have no idea if that’s related, because as I said, I’m not a developer:

My own Logic Pro X bypass flag

Hello, as I know Logic Pro X doesn’t support processBlockBypassed() so we can’t perform any action when Logic Pro bypass is clicked. But I wonder if is following idea well or not: I found out that when I click in Logic Pro bypass, it stops my processBlock. So I think there must be some way to check if processBlock is running or not (is there anything like that?). If it’s true. I could just set the timer in my plugin, and in timerCallback always check if processorBlock() is running. And if it…

AudioProcessorPlayer and suspendProcessing

I didn’t pay attention to that. Allright then, thank you!

If someone knows anything about this and don’t mind sharing, I appreciate it!
Thank you all!

[kerfuffle]

The problem is that Logic doesn’t tell the plug-in it’s being bypassed, it just stops sending the plug-in any audio, and so the plug-in is essentially “frozen”. When the bypass is turned off, the plug-in is “unfrozen” and resumes what it was doing.

Many plug-ins implement their own bypass option to handle the bypass a bit better, but that doesn’t solve the problem when the user clicks Logic’s bypass button.

One thing the plug-in could do is keep track of the current system time. If the next time processBlock() is called and the system time is further in the future than expected, the plug-in must have been bypassed in the mean time. (However, not sure if getting the system time is safe from the audio thread.)

[Verbonaut]

Overload AudioProcessor::reset and clear the buffers in there.

[kunz]

@Verbonaut

AudioProcessor::reset

Thanks, this worked!

[iamdannywyatt]

Thank you for clarifying. It seems that @kunz was able to fix it (he’s the plugin’s developer) by using @Verbonaut 's solution.

[iamdannywyatt]

Thank you so much! The plugin is now working as expected
@kunz is the plugin developer, by the way.

[Verbonaut]

Glad that helped. Good luck with your 365 challenge.

[iamdannywyatt]

@Verbonaut

Good luck with your 365 challenge

Thank you so much!