View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006543 | ardour | bugs | public | 2015-08-25 19:04 | 2015-08-25 20:37 |
| Reporter | don3 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 4.1 | ||||
| Summary | 0006543: Nudge clock display doesn't match time entered | ||||
| Description | Ardour 4.x (last tested on 4.1.0) Steps to reproduce: 1: Right-click in nudge clock field and set display mode to Minutes:Seconds. 2: [Left-]Click in nudge clock and enter a time - for example 5 ms (0005) - and press Enter. Expected result: Display should show time entered - eg, 00:00:00.005 Actual result: Display usually shows 1 ms less than the value entered, so 00:00:00.004 in this example. Some values do get displayed as entered, but in my experience that seems to be fairly rare -- so from the outside it doesn't appear as simple as something like a round-off issue. | ||||
| Additional Information | I haven't done much experimenting with this, but from what I can see, regions get nudged by the amount displayed, not the amount entered. So I've been working around this by entering what I want + 1 ms. | ||||
| Tags | No tags attached. | ||||
|
|
The underlying unit is audio-samples and the granularity in Ardour is audio-samples (there is no sub-sample region-alignment). The displayed timecode is rounded to the nearest audio-sample. Still that would be around 0.02 ms at 48K so what you describe is odd. When it says "4" Can you switch the unit to "samples" and compare? Maybe the displayed "..:004" is not (sample-rate * 4.0 / 1000.0) but just under 5ms and truncated. I cannot reproduce this 48KSPS, no pull-up/down. Typing 5<enter> in the nudge clock I get 00:00:00:005 switching to display samples it's 240 exact. |
|
|
Ah - guess I shouldn't have been surprised that the resolution would be related to samples. So I should've mentioned that I'm using 44.1-kHz sample rate in this case, which gives a period of about 22.7 us. If my math is correct, 5 ms should be 220 or 221 samples (truncated or rounded up), and 4 ms should be 176 or 177. When I enter 5 ms, the display initially shows 00:00:00.004, but switching to samples it shows 220, which suggests that it correctly took the 5 ms I entered. I had convinced myself from previous experiments that it was using the *displayed* time value when nudging regions (hence my "work-around"), but just now I tried it with the relative clock set to samples instead, nudged a region, and I see the offset is very close to 220 samples. Hmmm. So I would say you can close this, and sorry for the noise! (I suppose allowing time to be shown with precision below 1 ms in the nudge (or main) clock might have given me a clue earlier, but for most users that would probably be overkill. Well.., now that I think of it, there have been times I've wanted to measure and/or shift things with sub-millisecond precision - corrections for mic placement errors or external device delays, for example. Now that I "get" that Ardour uses samples as its base unit, I could obviously work in samples to get the precision I'm after. Allowing the clocks to display higher precision seems more convenient, but again, maybe not worth the cost for too many others.) |
