Robin Schmidt

i just had another idea: as it stands, the algorithm will be based purely on the envelope - maybe that's good enough, but maybe you also want the phase of...

ah - it's now clear to me, why the non-matching decays are shifted the way they are: the algorithm contains a user adjustable parameter, the "match-level", which gives the level...

if the envelope is plotted in the db domain, the exponential decays become lines. if the decay times are the same, the lines have the same slope and the algorithm...

> ...that's the only thing you can do with a shift with two that aren't parallel,... assuming, shifting is the only thing, we can do. of course, we *could* also...

here is a more realistic scenario where the two decays are not too wildly different: 

so, this is meant as a time saver for recording sessions? and/or as a space saver for sample based instruments - as in splicing together a single full decay sample...

nice! i like the idea of sample-based instruments that don't eat up gigabytes of data. i'm actually also quite fond of the idea of combining attack transient samples with a...

ok - there's a new class in rapt, called `rsExponentialEnvelopeMatcher`. it's not yet finished, though. i'm planning to incorporate a few more user parameters that let you set it up...

> i'm planning to incorporate a few more user parameters that let you set it up such that it may ignore the initial and final portion done. i've also included...

> You put the "shorter" signal in the first argument, right? you mean, here? ``` T getMatchOffset( const T* referenceEnv, int referenceNumSamples, const T* shifteeEnv, int shifteeNumSamples); ``` well, no...