2019 Scrubbing the timeline in Ardour

Code for what?

Scrubbing isn’t a plugin thing. The fundamental problem with scrubbing is trying to track the mouse in a sensible way and converting that into “scrubbing”. By contrast, using a jog wheel (which is a physically completely different kind of device) can be made to do something very close to “tape scrubbing”, but (I would argue) a lot more useful and efficient.

One possibility is to have a mode for the “job bar” that works the way our existing Mackie Control jog wheel code works. That’s not hard, but because of other major development and our tiny developer resources, it’s not on the horizon at all.

I don’t think hardware helps here – at least with Ardour’s current implementation a jog-wheel isn’t sufficiently precise.

Back when I made sountracks, I did hack Ardour (2.8) to play audio of a single video-frame and and likewise patched generic-midi surface to allow skipping +/-1 video-frame. That helped a lot for synchronizing foleys of foot-steps, door-clicks and similar sounds to the video-footage.

I wanted to add something like this properly to Ardour ever since, but it’s hard.

The Mackie code has a fixed scroll distance of 1/4 of the visible “page” in the editor.

It would not be hard to make this more controllable, all the way down to a single sample (though that seems a little silly).

Single sample would be pointless obviously.

Single Frame or even down to somewhere between .1 and .25 frame I could see though being useful.

        Seablade

most the animators are using either a touch screen or a tablet. zooming in and scrubbing a timeline is can be very very precise.

We tested out a jog wheel this morning unfortunately we see at as an alternative for promoting good hand health that’s it really.

Not to be nagging but in software seems to be the way to go.

can you explain more about this?

Also at the end of the week kinda need to work out if we will be hiring a developer to implement timeline scrubbing into Ardour.

Is that going to be a problem if that kinda thing happens? I only ask because I know that you wrote that code and it seems like its your baby?

Kinda hoping once its in there for Mac PC Linux that the open source community can take over from there and start pimping it out to make things even better.

Mybe up to 60 fps might be better

Ad

Interesting! What use for sub-frame audio-alignment is there for scrubbing? Do you use that regularly?

Also at 25fps, 0.1 frame would be 4ms – 250Hz audio, ~54 inch sound in air ; I bet your screen is larger :slight_smile:

When it comes to video, humans are surprisingly resistant to audio being even a few frames late. You might want to align some onset to a given frame, but otherwise it’s in the 10-20 Hz range is where humans begin to discern separate events vs an audible frequency.

Uh, what I mentioned would cover 60fps as it would effectively let you sync to a point that is <1 frame at any frame rate.

   Seablade

I have often struggled with single frame alignment in 24 and 30FPS for action shots. As you mentioned in all honesty it is not likely to be noticed at that level, it is just a personal preference for me, it is part of why I prefer to edit audio in a DAW such as Ardour vs many NLEs as I find the jumping between frames to imprecise for my preference.

Pedantic issue, frequency doesn’t apply there, speed of sound in air is dependant on other factors, but frequency isn’t one of them for any purpose we need to worry about:)

Also it would be about 40mS (1 Second = 1000mS, 1000/25=40), not 4mS. While I won’t say I have never worked with a screen that size, it is still fairly rare even for me:)

EDIT: x42 corrected me on IRC, he was referring to .1 frame, not 1 frame, my mistake, in that case the math checks out.

Realistically will 40mS be noticed by many? Maybe not, but it is enough to be noticeable. I personally would just rather align it precisely and not worry about it. Especially when (Again my line of work) you sometimes have a worse AV sync in a presentation situation than might be ideal, say video delayed be 2 frames isn’t uncommon even for fast video switchers if sources aren’t properly sync’d and are retimed at the inputs), you are just adding more possibility for issues.

You know, it is amazing how sensitive some people actually can be to this, you might have to take my word on this though as someone that spent years being responsible for proper alignment for live broadcast over the internet and local IMAG etc. Since I believe in issues as a sum of errors, I tend to say start accurate and less problems down the road to compound into something noticeable.

Just to be clear, I was thinking of “scrubbing”: audition audio corresponding to a frame, one frame at a time.
(not a grid or alignment limitation)

1 Like

Yep. Just showed of my intelligence :sweat_smile::sweat_smile::sweat_smile::sweat_smile:

That’s a great idea because that all you need there may be instances in the edit where the editor maybe use a plugin or something to slow things down but everything should still read as on frame at a time.

Coming from that angle may be a lot easier to implement or am I showing off my supreme intelligence again.

Ad