Closed theGreatWhiteShark closed 11 months ago
While the crash of #1852 does not occur on my machine anymore, there is still something off.
nReleasesFrames
passed to ADSR::applyADSR
because pSelectedLayerInfo->SamplePosition
is already ahead of the note length before the ADSR is applied. This doesn't sound rightBut right now only the length of the note itself is scaled, not the sample position (the point till which the sample was already rendered). This means when we have a note which is 55% rendered and tempo is increased dramatically effectively cutting the note length in half, the next time the Sampler
tries to render this note it will false assume it is fully rendered. After all the untouched sample position is beyond the freshly updated end of the note.
I will have a look at these in another PR. Depending on how much and which code needs to be touched I might also put the fix in 1.3. only.
Ooft yes, as soon as the note's played it should no longer care about the tempo I guess. Since it's still possible in the meantime, I've added #1870 to make the ADSR tolerant to the possibility by issuing a warning and moving directly to Release phase. Better than trampling past the buffer!
Ooft yes, as soon as the note's played it should no longer care about the tempo I guess.
This could lead to audible glitches and odd behavior when changing tempo or toggling the timeline. E.g. playing two notes with the same user-defined length in a row and manually increasing tempo by a margin might result in the second note to finish before the first one.
But this is just required for tempo changes done using the BPM widget, OSC/MIDI actions, or adding of Tempo Marker. All changes applied through the (fixed) timeline are known in advanced and are covered within computeFrameFromTick
.
there was a bug in the calculation of user defined note length in the
Sampler
. The delay introduced due to humanization, like lead lag, is given in frames but was mixed with variables given in ticks. This resulted in absurdly large delays and negative note lengths.Fixes #1852