While trying to figure out my latency/overdub sync issues I noticed that as I zoom in on a click recorded through a loopback patch cable, it seems that just before arriving at the maximum zoom (where you can see individual samples), the wave seems to jump ahead compared to the playhead. I didn’t move the playhead, I’m only using the + key to zoom in. This is kind of hard to describe. I have screenshots showing the playhead at the start of the wave at maximum zoom and after the start of the wave at an intermediate zoom level. Here they are:
John E wrote:
Notice that in both cases the timecode clock shows the playhead as being at timecode 00:20:33:10. And yet:-
1) The playhead is seemingly quite a lot later than that time.
This is really only that the timecode clock lacks resolution - it only resolves down to frames while the markings on the ruler resolve down to 1/100th of a frame.
And yes - looks a lot like the bug I reported some time ago. Maybe conjunctivitis could verify if it only affects the second highest zoom level like it was and still is in my case.
Its sort of a bug and sort of not a bug. You are not ever really looking at the “waveform” in any DAW, but a representation of it. That representation is typically based on finding the maximum and minimum sample values in a given time range and using those to draw the shape. Ideally, this should not change as the zoom level changes, but in ardour, particularly at close-in zoom levels, the way that the “given time range” is selected can lead to the peak-based shape changing.
Having said that, in your example, the change is a bit more extreme than I would expect from this “bug”. There is already one report in our bug tracker on this; it won’t hurt to file another one, pretty much containing what you posted above.
Yes, it only happens on the penultimate zoom level. I can duplicate it as well using ctrl/mouse-wheel scroll (which seems to go through the same discreet steps).
It never made its way into Ardour but I recently did a lot of work on removing some of the zooming problems in Harrison’s Mixbus. I just checked my local copy of Mixbus and it doesn’t display the problem described. Having said that, there are a couple of very obvious anomalies that are evident from the supplied images… Notice that in both cases the timecode clock shows the playhead as being at timecode 00:20:33:10. And yet:-
The playhead is seemingly quite a lot later than that time.
Look directly underneath the time 00:20:33:10. The two images disagree about what waveform is present at that time.
From the work I’ve done lately I strongly suspect that this is neither a problem with the playhead, nor with the waveforms. It’s a problem with the timecode ruler. In fact, all the rulers can get out of sync with the timeline under certain conditions. I think I’ve pretty much covered them all with the fixes I implemented but there were a couple of things remaining to be solved in Mixbus before I’d be happy to release the code generally. Ben at Harrison is helping me with them at the moment.
the C.L.A wrote:
This is really only that the timecode clock lacks resolution - it only resolves down to frames while the markings on the ruler resolve down to 1/100th of a frame.
Ah… it won’t be the problem I was thinking of then. The ruler sync problem tended to happen when zooming out too far, rather than zooming in too far. It may still be fixed though, since my solution was just to limit zooming such that you couldn’t zoom (in or out) to a degree where resolution would be lost when trying to go back the opposite way.