Closed suedwestlicht closed 6 months 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!
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".
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.
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.
may you try this from develop branch? https://github.com/rncbc/qtractor/commit/a96e4bb
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
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)
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.
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
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?
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)...?
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)
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.
good catch. are those figures in frames?
They are from the qtr file (clip -> properties -> length), probably ticks.
nope. in the .qtr file all clip-lengths are in frames.
ok, then the clip-lengths are in frames.
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.
can you please provide the minimal session file with those 3 midi clips only? thanks
Saved with 0.9.29.19git.4b550a.dirty and added .zip extension because github doesn't accept qtz: schwerelos.1.qtz.zip
This has fixed:
It has not yet fixed:
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 .
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.
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.
b06c9f4dbc5e7661acd7c70b3cf6100cde075549 was ok.
c9c9790dc06896cfc6f3245c83b09a8245b65fe4 introduced the new bug.
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.
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
Thank you Rui. It's fixed.
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.
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 ! ;)
Didn't find other issues when loading/saving other songs. Looks good and backward compatible.
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. ;))
Yep, the minor flaws in the event window are fixed. I can't find any other issues.
Thanks, Rui.
keep an eye on it, for a while though ;) wholly thanks, a lot
commit 49dd246bd9bd9e1a1537e5eb087cfd3a4d3988b8 (I don't know when the issue showed up first)
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).
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.