Robin Schmidt

oh - wait - you mean, because in my code comment i say: `// compute, by how much we must shift x1 to match x2 at the given match level:`...

hmmm - here is what i am getting:  with the following settings: ``` RAPT::rsExponentialEnvelopeMatcher em; em.setMatchLevel(-50); em.setInitialIgnoreSection1(60000); em.setInitialIgnoreSection2( 6000); em.setIgnoreThreshold1(-70); em.setIgnoreThreshold2(-70); ``` i used large "initial ignore sections", especially...

...wait! i just found a stupid bug....

> i just found a stupid bug the user specified the ignore-levels in dB and i was checking against linear amplitudes without converting (rendering the ignore-threshold settings ineffective) - this...

this is what happens now (with the same settings) with the other tail section that doesn't come from the original full signal: 

> Match level should be dictated by the "short" signal which needs a tail wait - so far, the short signal *was* the tail and the long signal was the...

> I'm getting 90% bad results. what about the other 10%? can you identify signal features that they have in common which the bad 90% don't have?

yes - that code looks right. that was my stupid bug hmm...well...i could sanity-check and clip the results - but that wouldn't solve the underlying problem (but maybe it's a...

which are the ones where you get this 31 sec shift?

with this pair: ``` testEnvelopeMatching( "MutedMallets/(0042)DPan_MutedMalletsNorth`n=D2`tail=3", "MutedMallets/(0034)DPan_MutedMalletsNorth`n=D2`tail=1"); ``` i get this result (using the exact same settings as i said above)  ...which looks quite good. did i pick the...