Processor.reset() is not called - Example travel & time continuity check here

In my processor reset() is not called, not in logic nor reaper, in auv3
now I dont understand the world anymore, it must be something really bloody obvious, but I don’t see it.
Isn’t reset() not allways called when the host repostions the playhead or hits start?

void reset() override
    // all my stuff is here that needs to stop trailling verb and delay and stuff..

relevant info: “The default implementation does nothing, but a host may call this to tell the plugin that it should stop any tails or sounds that have been left running.”

1 Like

In the juce example i took as starting point for my app, the reset() call was described as a standard in the comments there. So that was a bit of half-truth there…
Is a custom ocntinutiy check the only option?

I don’t have direct knowledge, and was only pointing out the wording of the documentation. Hopefully others with experience can help you find a solution.

ok, this is a complete continuity check for travel and time.
-The travelcheck is quiet straightforward
-The timecheck is done very forgivingly, because I’m afraid to be too narrow there.
if you catch an error or have improvements: please share! I’m eager to learn.
This function should be in JUCE allready imho, and I dont expect this to be the best implementation.

int64_t oldTimeSamples=0;
int64_t nextTimeSamples=0;
double predictTime=0;
template <typename FloatType>
void process (AudioBuffer<FloatType>& buffer, MidiBuffer& midiMessagesIn)
// =======================================================
    // t r a v e l  &  t i m e  c o n t i n u i t y   c h e c k
    bool allreadyReset=false;
    if (int64_t newTimeSamples = *getPlayHead()->getPosition()->getTimeInSamples())
    {   // First do travel continutiy
        if( oldTimeSamples==newTimeSamples)
            // pausing, we let it reverberate/echo
            if( nextTimeSamples - newTimeSamples != 0 )
                reset(); // there was a jump
        int64_t myProgress = buffer.getNumSamples();
        oldTimeSamples = newTimeSamples;
        nextTimeSamples = newTimeSamples + myProgress;
        // Next: time continutiy
        // I assume that that bypassing takes longer than 50mS, that keeps me out of the jittery decision zone
        // time is read folded, that way there can be no overflow anomaly
        double thisTime = fmod( juce::Time::getMillisecondCounterHiRes() , 1000000);
        if(( fabs(thisTime - predictTime) > 50 ) && !allreadyReset) reset();
        predictTime = thisTime + ((float)buffer.getNumSamples()/SR)*1000;
  1. The folding of time is not perfect: there is small chance that you toggle off the bypass between 1000 secs and 1000.050 secs, where the function will think the time passed is less than 50 mS, due to the folding.
  2. I am unsure about non-realtime rendering issues: e.g. if the offline rendering goes slower than realtime, the time function here is not good.