Bugzilla – Bug 449
Click Track tempo is (slightly) inaccurate
Last modified: 2018-08-20 11:51:49 UTC
The length of each measure may be inaccurate depending on the track sample rate and the BPM setting. Revised version posted to the forum (see link). The changes have turned out to be quite extensive so this will need testing before being committed.
Created attachment 200 [details] Steve Daulton's patch to improve length accuracy Added as a patch in case any developers want to study it more quickly
(In reply to comment #1) I've updated the link to point to the new topic on the forum about this issue. I'm taking this opportunity to do a general tidy of the code and fix a couple of other minor issues. I'll post the new revised version here when complete.
Created attachment 201 [details] updated clicktrack.ny file
Comment on attachment 201 [details] updated clicktrack.ny file .ny plug-in
Attached the updated clicktrack.ny file. The name of the plug-in has been (temporarily) changed to "Click Track 2..." to allow it to be installed alongside the original version.
Created attachment 210 [details] Updated Click Track plug-in Updated patch with correct file name, correct plug-in name and code spacing corrected.
Since I reviewed the operation of the patch a few weeks ago, and there have been some testers on the forum, I committed this new file.
Thanks, Steve. Only tested on Win 7. I presume we are not aiming for (what may be perceived as) total accuracy? For example in 1.3.14 Beta, Generate > Click Track at 120 BPM, 1 beat per measure, 120 measures produces 1 min, 0 secs and 1200 samples. In 1.3.15 alpha with the committed patch it is much more accurate - 0 min, 59 secs and 44099 samples. This seems to cause bug 459 or similar to fire as the length of the track is wrongly reported as 59.000 secs in Selection Toolbar.
(In reply to comment #8) > I presume we are not aiming for (what may > be perceived as) total accuracy? For example in 1.3.14 Beta, Generate > Click > Track at 120 BPM, 1 beat per measure, 120 measures produces 1 min, 0 secs and > 1200 samples. In 1.3.15 alpha with the committed patch it is much more accurate > - 0 min, 59 secs and 44099 samples. The onset of each tick is accurate, but there was another bug in the original click-track that I missed. The function "click" uses pwl to add 5ms fade-in and fade-out to the click. However, by default pwl is calculated at a low sample rate [the control rate], so as in bug 441 the shaped click is a fraction shorter than it should be. It can be fixed by calculating the 5 ms fade at the sample rate. That is to change line 228 from: (mult (pwl 0.005 amp 0.995 amp 1) to: (mult (control-srate-abs *sound-srate* (pwl 0.005 amp 0.995 amp 1)) Should I create a patch for this or just post an updated clicktrack.ny file? > This seems to cause bug 459 or similar to > fire as the length of the track is wrongly reported as 59.000 secs in Selection > Toolbar. Confirmed. At 44.1 kHz, when extending a selection from 2645977 samples to 2645978 samples, if hh:mm:ss + milliseconds are selected, the End (or Length) displayed on the Selection Toolbar rolls over from 59.999 to 59.000
(In reply to comment #9) > Confirmed. > At 44.1 kHz, when extending a selection from 2645977 samples to 2645978 > samples, if hh:mm:ss + milliseconds are selected, the End (or Length) displayed > on the Selection Toolbar rolls over from 59.999 to 59.000 To be clear, this is unrelated to clicktrack.ny (bug 449). The same thing happens with an empty track.
(In reply to comment #9) > To be clear, this is unrelated to clicktrack.ny (bug 449). The same thing > happens with an empty track. Absolutely. "Fixing" 449 won't fix 459. > Should I create a patch for this or just post an updated clicktrack.ny file? I guess a patch would be better, if you think this is worth fixing. On that assumption I've reopened the bug.
Created attachment 219 [details] updated clicktrack.ny Fixes incorrect length of clicks. Click track should now be accurate to within 1 sample for all settings. also set value for "len" so that the progress bar now works. Tested on Linux, Windows and Mac.
Created attachment 220 [details] patch file against svn revision 11382
(In reply to comment #13) Committed most recent patch. Martyn
441000 Hz, 120 BPM, 1 beat per measure, 120 measures produces 1 min, 0 secs 00000 samples. Steps to repro (130 BPM, 4 beats per measure, 130 measures) produces 4 min 0 secs 00001 samples (but at 200 Hz, 8000 Hz or 392000 Hz is accurate). Width of click or offset doesn't affect accuracy. So please move it to RESOLVED - FIXED if you are happy, Steve.
(In reply to comment #15) > 130 BPM, 4 beats per measure, 130 measures) produces 4 > min 0 secs 00001 samples I would expect some combinations of tempo, beats per bar and sample rate to give a small rounding error, but I think the discrepancy is now negligible so I've marked this as fixed.
(In reply to comment #16) The remaining "error" is because the final beat duration is calculated to the closest sample, rather than calculating the final bar length to the closest sample. This could be "corrected" by: making "mtime" global and changing line 295 from: (s-rest(- beatlen ticklen)))) ;trailing silence to (s-rest(- (+ mtime (* sig beatlen))(/ (snd-length clicktrack ny:all) *sound-srate*))))) ;trailing silence but it would look a bit odd if one bar was created and the final beat duration was 1 sample shorter than every other beat. The choice is to either have the final beat length duration to the closest sample, or the final bar length (hence the overall click track duration) to the closest sample. Either way I don't think the discrepancy should ever be more than 1 sample. The first option (as per the current version) is neater and the code more transparent so I'd go with the current version, but if anyone disagrees, I can change it.
(In reply to comment #17) I think it's OK now and arguable either way. The only case I could possibly see for calculating the final bar length to the closest sample would be if someone was using click track sequences for loops and repeating them. Would a code comment about this be appropriate?
(In reply to comment #18) > Would a code comment about this be appropriate? Considering how long it took for anyone to notice that the old version was inaccurate and how much more accurate the current version is, I'm happy to leave it as it is.
