Hi
The follow playhead function seems to have stopped working properly regardless of zoom level in 8.11.
I’m finding when i set it, it may refresh once then cease to follow. If i then zoom it will re-follow for one screenful then cease again.
I think this may be an option in the preferences…so maybe there’s a keybinding for it that was hit accidentally too? I feel like I’ve run into this in the distant past with an older version, but if you were going to find it anywhere, I’d assume it to be under Edit -> Preferences -> Transport -> Chase…but I’m not seeing anything obvious in the Transport section…
It may also be worth double-checking your session start and end markers to make sure it’s not behaving strangely by being out of bounds…though from your screenshot it looks like this is likely okay.
I’ll keep it in mind and if a solution presents itself, I’ll come share.
Ah ha…at the top-level of the Transport menu there is Follow Playhead with CTRL+F as the shortcut key. I knew I had seen it somewhere. Lets see if that fixes you.
This is known bug reported over 5 months ago here:
https://tracker.ardour.org/view.php?id=9794
Not fixed yet.
If you would like to have this bug fixed, please comment on the report.
Regards!
Skygge
I realize now that I read this wrong earlier… But every time I’ve encountered this (which I will admit has been a while now), a restarting Ardour would generally fix it for me, but this was also on an older Debian machine where I had encountered it. Right now I’m theoretically running the same problematic version in Ubuntu now and have been for a while, but I haven’t had it pop up at all. Are there not any workarounds currently? Does it just get stuck that way?
Thank you for all this. I am well familiar with Ctrl F and the screenshot I posted also show Follow playhead ticked. The problem does seem to be intermittent.
Does toggling Follow playhead off and back on help?
It only works for one screenful, then it ceases again
Yeah, initially I was thinking like Robin I think, in that toggling it on/off or not noticing that it happened…but the bug report video made it clear.
I was asking about “does it get stuck?” to get a hint of whether or not this bug happened to tarnish the session file or something, leaving it effectively permanently broken for a project. It sounds like that thankfully isn’t the case. This is is both good and annoying though, because repeatability is important if we can find it.
After writing that, I was also thinking of other ideas that could be a factor…most of those factors I could think of would possibly also relate to the GUI library (Gtk2, IIRC, but I’ll confirm this part) and/or active window manager (like Gnome or KDE, etc), and it made me think of a few other potentially relevant questions. For those of you that encounter this problem…
If you turn Follow Playhead OFF instead of on, does it simply behave in an inverted fashion?
Do you use fractional scaling in your display settings? I think there are likely system-wide settings for this, and also in Ardour itself (under Edit -> Preferences -> Appearance -> Size and Scale)? Environmental settings can do this too (like setting QT_SCALE_FACTOR before launching a QT-based app…I’m pretty sure most GUI libraries have some way to adjust this on the fly, per-app too).
Do you have the Ardour application spanning across multiple displays? Especially if any displays involved are “ultra-wide” or anything outside of 16:9 or 16:10 ratios?
Does project zoom level have any effect on the behavior? Does it always happen when zoomed either way in or way out? (But still obviously leaving room for it to leave the current window…a full zoom out is probably not helpful, of course. 
)
Is there a certain length your project needs to reach before this starts to appear? While I have used Ardour quite a lot recently with potentially problematic version, I also haven’t in that same time span worked on a particularly long project either.
When this problem occurs, are there any other indicators of any other problems that occur simultaneously? Does system resource usage look normal?
Ultimately, I figured that since I may be primed to run into the problem that I might spend a little time just trying to recreate the problem…and I’m just getting started diving into the Ardour code for understanding in general anyway, and if we can find it, a fix for something like this should hopefully not be too difficult if we can find a reliable way to reproduce. It sounds like it could be anything from Ardour not understanding the sate of the Follow Playhead (like, if it believes it to be incorrectly inverted due to GUI/app data getting out of sync), or the window manager perhaps incorrectly reporting or calculating the size of windowed components (for example, Gnome with a semi-broken Gtk can enter a sort of a fallback state where windows are no longer properly decorated and window sizes is absolutely one of the metrics that breaks because the fallback decoration is not set the same as the normal system, font sizes, etc.). Because it doesn’t appear to be a problem in other environments, I’m thinking we need to probably consider the potential problems within our specific environments as well.
The last bit that I will note, is that throughout my time recording on Linux with Ardour, it doesn’t seem to be all that uncommon to run into some really strange things that seem to fix themselves after restarting Ardour. In the past I had chalked this up to my older laptop, specifically it’s rather low amount of RAM (and I further thought that may be due to inherent slowdown from running into swap space usage). I had dedicated it to tracking because it was “good enough” and more portable, but it was indeed mostly in that context that I had any issue (as opposed to mixing, even with the same audio interface and all other things the same except the computer itself). This has ultimately trained me to save often and restart the session anytime anything starts to even hint at going off the rails.
Sorry again for the initial misunderstanding too…I came in wanting to help with a little bit of blind ignorance of the current state of things, but I’m learning/correcting myself and would indeed still like to assist if I can. I’ll try a few things too, but I’ll also specifically take a look for the playhead features in the source to see if there’s any other hints and I’ll let you know if I come up with any further ideas.
No worries, thank you for your interest. Its good when ppl want to help each other.
If I find out anything, I will post it
It’s going to take a short while to wrap my head around some of this, but another thing to try might be to see if the problem still persists when the playhead is playing backwards instead of forward. Or if it happens at different playback speeds (slower and/or faster).
It looks like a lot of these things are working their magic from inside a state machine, so trying that feature under as many conditions as possible (while broken, of course) will likely be helpful to narrow it down.
Edit: I think I’ve found the logic for this now. In the project, in ardour/gtk2_ardour/editor.cc there are a number of searchable references to _follow_playhead, and it looks like some of these calculations may be sample rate dependent. It may also be worth it to test different project sample rates to see if the problem is limited to certain settings there too.
Edit 2: I’ve also found this to link into GTK calculations with the _track_canvas across several editor*.cc files. I’m going to keep chasing these into the actual GTK calls if I can so I can look into potential GTK-specific window size calculation issues. This is where the application scaling and broken decorations and things may come into play.
Edit 3: In ardour/libs/canvas/canvas.cc there resides many of the specific window size calculations. Making note here, but leaving this trail for now until we get some more feedback on the issue.
We had a bug a decade years ago, that the checkbox in the menu did not correspond to the actual state. That bug resurfaced a few times …
but the issue at hand is apparently different.
It would be nice to get confirmation of testing that toggle, because especially if there’s been regression on this in the past, I wouldn’t necessarily be quick to dismiss this rearing its head again. Regardless, I’m still chasing other leads on a similar presumption of maybe it’s not that conveniently simple.
Do you happen to have any old bug tracker links that we can reference?
Not that I know of.
The problem was that we relied GTK’s menu item’s state in the past, during state restore.
The toggle-action only emits a “toggled signal” when the value changes. So there was no callback when setting an already active checkbox as active (or vice versa). That was an issue when loading a session from an already running instance.
–
You can also use Lua to introspect the actual value (Menu > Window > Scripting)
print (Editor:follow_playhead())
Thanks for that, it at least gives me a few ideas of how to possibly rule out that particular bug…I’m going to create a few lengthy-enough test sessions that I can go between and try to break that specifically.
I’ve also been only doing MIDI-related tracks of late, and it looks like I may need to test with audio tracks specifically for reproduction too.
More on this soon, I hope…
Edit: I created 2 files, imported an audio track to each, then tried to break this specifically without any luck. It seems like Ardour is pretty good about remember the state of this toggle right now.
Okay, I’ve tried a whole lot of my earlier thoughts out now too, and I’m having trouble replicating still.
I guess I’ll have to keep trying periodically…especially after I’ve been working on a project for a bit, it may be a good test to just here and there load up one of these other files just to check.
I’m running out of ideas here…hopefully those of you affected more regularly can give some of these kinds of things a test as well.