Tempo Changes: Notes Cut Off Early

[MorganEAshton]

Hello! I'm on Windows 10, 64-Bit. My current song project has multiple tempo changes, using discrete progression. When the tempo slows, any held notes in the following measure cut off early. This only occurs when playing in the song editor. Playing a single part in the piano roll works as it should.

I've tested multiple things to figure out what is causing the issue:

• Tried different instruments, both soundfonts and native plugins (All behaved the same.)
• Exported to see if the exported file behaved differently (It didn't.)
• Upgraded from 1.1.3 to 1.2.0-RC3 (No change.)
• Dragged the song section to a different measure (This revealed that the issue was connected to the measure, not the notes.)
• Imported the notes into a fresh file with no tempo changes (No issue, until the tempo changes were added.)
• EDIT: When exporting a shortened file (I tried a four-measure sample), the issue goes away. This may indicate the delay is caused by a processing issue. Maybe the instruments take a little longer to process the tempo change?

It appears that while the song as a whole changes tempo when it should, the instruments are operating on a slight delay. Thus, they end early because they're acting as if they're played at the faster tempo. So, for instance, measure 25 plays at 95 BPM, while measure 26 slows to 90 BPM. There is a whole note that plays all throughout measure 26, but it cuts off early, as if the note was played at 95 BPM.

I can manually lengthen the notes to play at the correct length, but that's messy and could cause issues if I make edits later. Does anyone have an idea of how to resolve this issue?

[D.Ipsum]

It seems to me that the content of an audio sample is not affected by the tempo or a tempo change, the information is simply read (read at the speed defined by the pitch or the note played in the case of AudioFileProcessor).

I don't know what it is for the ZynAddSubFx, but for all other synths, as long as the volume envelope is not active (AMT = 0), I have never observed the problem you evoke. Once activated, are the values of the DAHDSR parameters calculated according to the tempo? and recalculated according to the tempo changes ? (I don't know)

EDIT:

I just did a test with a sample that lasts 33 seconds loaded in the AudioFileProcessor.

In the SongEditor, via Piano-Roll, I placed a quarter note every half measure, until measure 4.

Within this range of 4 measurements, I automated a tempo change from 140 to 0.

These 4 measurements are looped.

Result: On some notes, sometimes the sample stops being played once the quarter note is finished, and sometimes it continues to be read ... This seems to occur when the end of measure 4 (thus tempo = 0) loops at the beginning of measure 1 (thus tempo = 140).

I'm lost.

[D.Ipsum]

My test : https://lmms.io/lsp/?action=show&file=11305

[musikbear]

Hello! I'm on Windows 10, 64-Bit. My current song project has multiple tempo changes, using discrete progression.

Yes, unfortunately tempo-changes are glitchy.

[MorganEAshton]

Is there anything that can actually be done about it?

[D.Ipsum]

With a bit of calculation, you can shift the notes in the Piano-Roll

[D.Ipsum]

Possibilities: for a discrete change of tempo via automation, you can place the change of value between the notes, during a silence; or at the end of a sound (to affect it as little as possible); or 1/64 before the start of a sound.

Other possibility, if a note is cut too soon due to the tempo change, you can increase its duration by automating its volume envelope (hold, sustain, decay or release).

[MorganEAshton]

With a bit of calculation, you can shift the notes in the Piano-Roll

Yeah, that's what I was trying to avoid, but I guess it won't make much of a difference in this track, since the tempos are finalized. I do hope it's something that's eventually fixed, though. I do primarily orchestral-style music, which requires a lot of tempo adjustment to sound natural. I'm still grateful for LMMS, however, and all the hard work that's gone into it. I'll do what I can with what I have. Thanks. If anyone finds a different solution, please let me know (and I will do the same if I find one)!

I went ahead and made a short file to show the way the glitch manifested in a current project, for anyone looking to fix it or for those who want to try something like this in their own songs and need to know what to expect.

Note that the glitch actually works both ways: If a tempo slows, the note cuts off early, AND if the tempo speeds up the note lasts too long. I didn't mention the latter in my original post.

https://lmms.io/lsp/?action=show&file=11326

[MorganEAshton]

Possibilities: for a discrete change of tempo via automation, you can place the change of value between the notes, during a silence; or at the end of a sound (to affect it as little as possible); or 1/64 before the start of a sound.

I had tried moving the tempo change back a little into the prior measure, and the delay still seemed to persist. I just tried it again, with the same effect. I got to about an eighth note back before I decided to try linear progression over a short space. That seems to fix it! I did a 16th note, which seems to be enough for both a 5 BPM change and a 10 BPM. I suspect it may require more space to accommodate a larger change, since there would potentially be a larger processing delay? (Edit: Just tested making the change take place over shorter intervals, and made the change bigger. With this song's settings, progressing over a 64th note still caused noticeable issue at 5 BPM. 32nd note was fine for 5 BPM, but not so much for 10, and there was an even more noticeable issue at 15. A 16th note did start showing issues at a 15 BPM change. So what I said below might not apply, unless the angle of the discrete progression was calculated based on the severity of the change.)



I also noticed while zoomed into the discrete progression that it's actually a very steep version of the linear progression fix shown above. Perhaps all it would take to prevent this issue would be to make the change just a little more gradual?