Using auwrapper, where can we reset internal buffers?

[Headless_Bassman]

Back in the old VST2 days, we had the suspend/resume functions where we could reset our internal buffers. This was needed in cases such as jumping backward of forward from the middle of audible audio to a new location in the timeline, in order to not continue processing the audio from the previous location. I’m not sure what would replace that functionality, but possibly setProcessing(true/false)?

The problem I am having is with the auwrapper, though. It does not appear to call setProcessing except at initialization and cleanup times, not in cases such as jumping to a new location in the timeline. (Or simply starting or stopping the transport.)

How cab our auwrapper-based plug-ins reset their internal buffers in a case like this? What function do we have to implement (using the SingleComponentEffect, if it matters).

Thanks,
Howard

[ray3]

Hi Howard,

that’s where IComponent::setActive(bool) comes into play. It’s called from AUWrapper::Initialize() / ::Cleanup().

I had the same problem in the AAXWrapper and had to add suspend(); resume() call to the VSTWrapper in AAXWrapper::ResetFieldData()…I hope they add a proper fix soon.

[Arne_Scheffler]

There’s no suspend/resume (when talking in VST2 terms) when starting or stopping the transport (not in VST2, VST3 or AU), at least not in any host I have seen in my life.
What you need to look at is the ProcessContext structure in the ProcessData structure you get in your process call. It has a state member you have to observe for transport changes. Or if you want to know if you have a cycle jump, you have to observe the projectTimeSamples member.

Cheers
Arne

[Headless_Bassman]

Thanks, Arne. I’m not sure if resetting buffers during Render is a good place for that kind of work, but if it’s the only place we can do it, then ok. Is that what most delay effects do in the case of a transport jump or loop? Or do they just keep outputting the data that was there in the delay buffers?

[Headless_Bassman]

Seems to work fine, resetting our buffers if the new position is not equal to the previous position plus the previous frame size. (We give it a little slack on either side of that number, though, just in case.)
Thanks!

[ray3]

@Arne Scheffler

There’s no suspend/resume (when talking in VST2 terms) when starting or stopping the transport (not in VST2, VST3 or AU), at least not in any host I have seen in my life.
What you need to look at is the ProcessContext structure in the ProcessData structure you get in your process call. It has a state member you have to observe for transport changes. Or if you want to know if you have a cycle jump, you have to observe the projectTimeSamples member.

Cheers
Arne

That raises the question how to handle IAudioProcessor::setActive() as a plug-in programmer though? The ADelay example implies that this is the place to reset buffers. However, setActive() is never called through the VST2Wrappers suspend()/resume() in the AAXWrapper and thus ADelay wouldn’t work properly when wrapped to AAX.

[Arne_Scheffler]

@ray

However, setActive() is never called through the VST2Wrappers suspend()/resume() in the AAXWrapper and thus ADelay wouldn’t work properly when wrapped to AAX.

If this is the case, then it is a bug in the AAXWrapper.

Cheers
Arne

[ray3]

@Arne Scheffler

@ray

However, setActive() is never called through the VST2Wrappers suspend()/resume() in the AAXWrapper and thus ADelay wouldn’t work properly when wrapped to AAX.

If this is the case, then it is a bug in the AAXWrapper.

Cheers
Arne

Hi Arne,

yes, I have already reported this and several others in this thread: https://sdk.steinberg.net/viewtopic.php?f=4&t=364 …still waiting for feedback from Yvan, however.

[Molder1]

@howaredantares

Thanks, Arne. I’m not sure if resetting buffers during Render is a good place for that kind of work, but if it’s the only place we can do it, then ok. Is that what most delay effects of vigrx plus do in the case of a transport jump or loop? Or do they just keep outputting the data that was there in the delay buffers?

Was this resolved yet, Ray? I’m having the same issue. Nothing I could think of worked.

[ray3]

@Molder

Was this resolved yet, Ray? I’m having the same issue. Nothing I could think of worked.

Nope, I’m still waiting for an answer by Yvan. However, you can check my following post under https://sdk.steinberg.net/viewtopic.php?f=4&t=364#p1273 and there is a suggestion for a simple fix in AAXWrapper::ResetFieldData().

Hope this helps.