rncbc / qtractor

Qtractor - An Audio/MIDI multi-track sequencer
https://qtractor.org
GNU General Public License v2.0
495 stars 86 forks source link

MIDI rounding error, note not played #371

Closed suedwestlicht closed 6 months ago

suedwestlicht commented 1 year ago

commit 49dd246bd9bd9e1a1537e5eb087cfd3a4d3988b8 (I don't know when the issue showed up first)

1

The left window is the original clip, the right window is the copied/linked clip. It's used for a kick drum in drumkv1. As you see the durations are not exactly equal. Some durations are 240 and then the 2nd note on the marked two notes in the right window is not played (or the note off comes too quick).

2

Wenn I shorten the first of the two notes in the right window then the 2nd note is played correctly.

When I change the track's type to drums then the 2nd note is played, probably because of the suppression of the note-off.

This happens on other tracks with synth plugins as well, so some notes are not audible.

Further investigation shows that not only copied/linked clips are effected. Even perfectly quantized clips have some different durations.

rncbc commented 1 year ago

can you share one and just one of the original MIDI files (.mid) that shows these rounding errors? maybe "schwerelos-Kick-7.mid" ?)

QUICK FIX: for all the clips (or files) you find that there's a probable rounding error, mainly due to internal MIDI internal resolution been terribly increased in recent release (v0.9.30), you may try for a manual fix: quantize durations (and durations only) to a minimum like Beat/8 (or even lower if you have any same notes in a straight short sequence than that -- supposedly, this will only matter for the case of note events that are on the very same line, and in immediate sequence, back to back, so that a note-off won't get ever scheduled immediately or short after a note-on which won't have a chance to make a noticeable sound ever!

of course, you may also workaround the issue interely, by turning off in drumkv1 this parameter: DEF > Note-Off; but that unfortunately won't work at all on many other synths--unless the ones that can be set discretely to free "one-shot" samples (ie. ignore MIDI note-off's.).

HNY!

suedwestlicht commented 1 year ago

This is a nasty heisenbug, a few hours later the notes aren't cancelled anymore in the kick clip.

Existing old session: Quantizing duration re-introduces the error sometimes, sometimes in a copy on another location in the same track. Even drawing a new clip eg. with beat/4 snap shows that problem. Copying an existing clip doesn't make the copy "linked". same_session_new_clip

Completely new session: Drawing a new clip works ok. No cancelled notes. Copying a clip makes the copy "linked" as it should be, even after save/reload.

But duration is 0.0.479 after loading and 0.0.480 after quantizing. Saving, restarting Qtractor and loading shows 0.0.479 again. Maybe no real issue but a bit strange anyway. new_session_after_loading new_session_after_quantizing

I am getting confused. I am not sure if I nailed the problem correctly. I guess I have to workaround the problematic clips in my session by using drums-mode where possible and editing the notes' ending manually.

rncbc commented 1 year ago

may you try this from develop branch? https://github.com/rncbc/qtractor/commit/a96e4bb

suedwestlicht commented 1 year ago

Thx, this fixes "But duration is 0.0.479 after loading and 0.0.480 after quantizing. Saving, restarting Qtractor and loading shows 0.0.479 again. Maybe no real issue but a bit strange anyway."

It doesn't fix the strange quantizing issue (some .479, some .480, some cancelled notes when quantizing) with schwerelos-Synth_Bass-5.mid.zip

rncbc commented 1 year ago

and now this one may you try this from develop branch? https://github.com/rncbc/qtractor/commit/b15d0a4 (you'll prolly need to git reset --hard origin/develop before that, sorry)

suedwestlicht commented 1 year ago

Nearly.

Quantizing makes all durations to .480 and no note is cancelled.

But saving/restarting Qtractor/reloading shows some .479 and some cancelled notes.

WAIT! 2nd loading makes it better.

suedwestlicht commented 1 year ago

Still a bit strange.

Making all notes a bit shorter than .479 Save clip & song Restart Qtractor Reload song Quantize duration to /8 All durations are .480 Save clip & song Restart Qtractor Load song All durations are .480 No cancelled notes Copy clip Copied clip is not linked Some durations in copied clip are .479 Some cancelled notes in copied clip

suedwestlicht commented 1 year ago

A MIDI clip imported into a new session makes no trouble. It can be quantized, works properly and copied clips are recognized as "linked".

Both sessions have the same time properties.

What could possibly make the difference?

rncbc commented 1 year ago

please tell which runtime is you working out and collecting eveidence: whether v0.9.30 or v0.9.30.1 (develop) ?

i guess MIDI clips that were modified and saved under v0.9.30 might get this subtle rounding issues: which might occur only on same note and strictly contiguous (back-to-back) MIDI note sequences--note-off times being incidentally rounded to after the next note-on onset time...

ps. pondering about a hot-fix release (v0.9.31)...?

suedwestlicht commented 1 year ago

As always on my old Xubuntu 16.04.

The old session was created at least a year ago with an older version of Qtractor.

I use at the moment v0.9.30.1 (develop)

suedwestlicht commented 1 year ago

Additional information: In the existing session a copied clip doesn't have the same length as its source.

source clip: 1607442 copy 1: 1607443 copy 2: 1607448

That might be the reason why the copies are not recognized as linked.

rncbc commented 1 year ago

good catch. are those figures in frames?

suedwestlicht commented 1 year ago

They are from the qtr file (clip -> properties -> length), probably ticks.

rncbc commented 1 year ago

nope. in the .qtr file all clip-lengths are in frames.

suedwestlicht commented 1 year ago

ok, then the clip-lengths are in frames.

suedwestlicht commented 1 year ago

I went back to 0.9.29.19git.4b550a.dirty and loaded an old session:

Everything worked as expected. After quantizing every note showed the same lenght in the event window. No cancelled notes. Copies were recognized as linked.

BUT: in the qtr file the lenghts in frames were not identical: source: 1607442 copy1: 1607443 copy2: 1607442

But this had no visible/hearable results in the session, probably because of correct rounding.

But it seems that there is an old bug buried that could lead to similar problems in very rare cases with lengths that trigger rounding in the "wrong" direction.

rncbc commented 1 year ago

can you please provide the minimal session file with those 3 midi clips only? thanks

suedwestlicht commented 1 year ago

Saved with 0.9.29.19git.4b550a.dirty and added .zip extension because github doesn't accept qtz: schwerelos.1.qtz.zip

rncbc commented 1 year ago

thanks. can you now try with the fix in v0.9.30.7git.c9c979 ?

suedwestlicht commented 1 year ago

This has fixed:

It has not yet fixed:

schwerelos.1.qtz.zip

rncbc commented 1 year ago

okay, let's see if this one nails it: v0.9.30.8git.e27789

note that the different lengths are already there in the original file, coming from v0.9.29 .

suedwestlicht commented 1 year ago

Copying a midi clip again makes the copies perfect, both lengths in the qtr/qts and in the event window. No cancelled notes. You nailed it.

But there is a new bug introduced when loading old sessions that affects midi tracks from about number 11 on: midi clips have wrong contents. I had HiHat patterns from track 10 in track 11's kick drum clips.

rncbc commented 1 year ago

But there is a new bug introduced when loading old sessions that affects midi tracks from about number 11 on: midi clips have wrong contents. I had HiHat patterns from track 10 in track 11's kick drum clips.

that's horrific! you only notice now with this v0.9.30.8 or was it already there before that? does v0.9.29 do the same? please try to find some pattern on the strange overriding behavior: specifically about file-names(.mid), track and channel numbers, anything that might collude to that wrong doing.

for example: if you isolate to only having former tracks 10 and 11 as track 1 and 2, saving it to a new session (preferably doing it on v0.9.29, supposing it loads them right in the first place) and then reload it again, what happens?

ps. also please update to v0.9.30.9git.0e9d88, thanks.

suedwestlicht commented 1 year ago

b06c9f4dbc5e7661acd7c70b3cf6100cde075549 was ok. ok

c9c9790dc06896cfc6f3245c83b09a8245b65fe4 introduced the new bug. not_ok

It happens as well with a stripped down version with only those 2 tracks. schwerelos_2_tracks.qtz.zip

e277892f6c3f6fb644a9a78d6ac48f89fe618ffe still has the new bug.

rncbc commented 1 year ago

my bad--I should spank myself in shame to have dropped that one single but important source line by mistake...

fixed now in 0.9.30.10git.523b70

thanks a lot for your patience

suedwestlicht commented 1 year ago

Thank you Rui. It's fixed.

suedwestlicht commented 1 year ago

There are still some rare rounding errors in the copied clips (in the events window) but I think that's just a minor flaw and has no effect on the basic functions. a

rncbc commented 1 year ago

yes that's true but I believe it's a nit in the conversion to text display, not the "real thing"... which is way higher in resolution than nominal ppqn...

but please, while you're still at it, please try to save to, and reload from, testing whole sessions, rinse and repeat, check if things stay stable along the ordeal, and catch anything that possibly make your eyes pop out ! ;)

suedwestlicht commented 1 year ago

Didn't find other issues when loading/saving other songs. Looks good and backward compatible.

rncbc commented 1 year ago

thanks, meanwhile I've streamlined and generalized the whole rounding business and it now seems to even get the issues you found in https://github.com/rncbc/qtractor/issues/371#issuecomment-1378567920

it maybe all fixed in this new delivery v0.9.30.15git.d2e59b

please test it thoroughly with the usual safety guards (backup, backup, etc. ;))

suedwestlicht commented 1 year ago

Yep, the minor flaws in the event window are fixed. I can't find any other issues.

Thanks, Rui.

rncbc commented 1 year ago

keep an eye on it, for a while though ;) wholly thanks, a lot