Rendering issues of notes with user-defined lengths

[theGreatWhiteShark]

When toying with user-defined note lengths and samples provided in #1852 I came across a couple of rendering issues:

• [x] Manual tempo changes are not reflected in notes which are currently rendered (e.g. using the BPM widget to increase speed from 60 to 360) (an edge case. I admit it :D )
• [x] When manually adjusting the length of a note, the note just sounds bad. The waveform is just cut at the end and a click/crack/distortion follows each and every note. Since we already have code for handling ADSR, how about a quick release phase at the end of such notes?
• [x] When activating filtering (clicking the BYP button in the Instrument Editor), all custom note lengths are discarded and the entire sample is played back. We could of course argue that activating the filtering and setting a non-zero resonance shouldn't be discarded either. But then the original sample should only be played back till the user-defined length and everything that follows is the result of resonance filtering.
• [x] Creating a note with user defined length and reducing the length of the pattern to be smaller than the length of the note -> note will ring beyond end of the pattern.

[cme]

Agree with this reasoning ADSR: changing the length of the note should effectively move the Release point, and also filtering.

I guess I would recommend that before doing anything much else in renderNote*, it would probably be wise to just entirely remove renderNoteNoResample to avoid duplication of effort. It's slower than the NoResample variant, but not that much slower. Optimisation without duplication can be a later activity (which I plan to do!)

[theGreatWhiteShark]

I guess I would recommend that before doing anything much else in renderNote*, it would probably be wise to just entirely remove renderNoteNoResample to avoid duplication of effort.

Any volunteer? 😄 But you are right, of course. Just hoped I could implement the drumkit map stuff without large detours. But sample rendering is too important to postpone it till 1.3.0.

I would start by checking/adding some unit tests. They should step on our toes if just a single frame of rendered audio is different. So we can at least check for unintended side effects while refactoring.

[theGreatWhiteShark]

There is another issue with the notes having custom lengths:

Defining a length

and shrinking the pattern so it ends prior to the note

leaves the note length unaffected. It will ring on.

I think it would feel more natural if the custom note length is truncated at the end of the pattern.