View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007575ardourbugspublic2018-02-23 15:332018-02-28 13:11
Reporterjohne53 Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformPCOSWindowsOS Version7 and 8.1
Product Version5.X git (version in description) 
Summary0007575: Timeline "summary" window acting strangely (for high timecode sessions)
DescriptionThis has been a problem in the git builds for about a month or so...

Underneath the main Editor timeline is a smaller window (I'll call it the Summary window). If a session happens to start at a high timecode value (say 10:00:00:00 hrs) the Summary view is mostly empty (basically, the viewable pane and the timeline contents are all condensed into a few pixels width at the RHS of the Summary window).
Steps To ReproduceSimply load a session whose first clip starts at a high timecode value.
Additional InformationRight clicking on the window and choosing "Reset Summary to Extents" will fix the problem - but only temporarily (i.e. for the duration of the current session). If you save the session then re-load it later, the original problem returns.
TagsNo tags attached.

Activities

x42

2018-02-23 16:09

administrator   ~0020180

Since about a month? odd.
The most recent changes to gtk2_ardour/editor_summary.* were in summer/autumn 2017.

Does the editor-zoom-level (saved in instant.xml) plays no role here?

johne53

2018-02-23 17:08

reporter   ~0020181

An interesting suggestion. If I delete instant.xml, it works as expected. But whenever there's an instant.xml file, loading a high timecode session produces the bug.

A problem reading instant.xml maybe?

johne53

2018-02-25 10:46

reporter   ~0020186

Another bit of information... AFAICT the problem doesn't happen if 'Transport->Follow Playhead' and 'Transport->Stationary Playhead' are both disabled.

x42

2018-02-25 12:02

administrator   ~0020187

Have a look at EditorSummary::render and Editor::session_gui_extents().

It does maintain _leftmost and _rightmost {visible} location. They are not reset and always only increase. -- Maybe add some printf() of those values.

Possibly the exposure strategy changed and the values are queried before the editor restores instant.xml

johne53

2018-02-25 12:27

reporter   ~0020188

Thanks Robin - I've just been taking a brief look at this and it seems to be connected with setting the LHS of the timeline window. Let's say that the session got saved with its LHS at 09:59:00:00. If I re-load the session it initially gets set to the correct time. Then (very shortly later) it gets reset so that the LHS will be at 00:00:00:00

I've a feeling there might be some kind of race condition because if I run Ardour in my debugger, those 2 x "setting" operations don't always get called in the same order (if they get called the opposite way around, it works okay).

I should have some old backups saved somewhere so I'll see if I can pinpoint when this started happening (I'm assuming it happens for other people too?)

x42

2018-02-25 12:35

administrator   ~0020189

Since it is set during GUI exposure, I don't expect it to be reliable. Even just running it in a debugger may change the exposure strategy.

Still, the issue is that _leftmost_sample apparently is re-set to "0". Editor::set_session() in editor.cc:1332 explicitly initializes it before the summary (see the comment there).

Can you set a watch-point in the debugger and check when Editor::_leftmost_sample is changed?

x42

2018-02-25 12:41

administrator   ~0020190

PS. a guess, since you mentioned "Follow playhead".


The session-playhead (after load) is at 00:00:00:00. Seeking the session to a given position on the timeline takes an unbound time (read audio from disk, etc.).

Meanwhile Editor::super_rapid_screen_update() is called and updates the position (follow session's positions).

johne53

2018-02-25 14:35

reporter   ~0020191

Ha, I ran my (backed up) version from a few weeks ago. It didn't seem to have this problem although it did have another problem which I reported here:-

http://tracker.ardour.org/view.php?id=7551

I'm wondering now if fixing the 1st problem has somehow introduced the 2nd one? It'd be interesting to know if anyone else can reproduce this (i.e. by running a very recent git build in Windows).

johne53

2018-02-27 09:39

reporter   ~0020197

Hi Robin - fixing that other problem hasn't introduced this one. If anything, it looks like it crept in sometime around Ben's implementations for "new_snap" and "new_grid" (7th - 9th Feb 2018). Four commits earlier (5th Feb) there's commit #913445c981 from Len Ovens (OSC: clean up jog mode, simplify feedback). If I use git bisect, the problem isn't evident up to that point. But by the time we get to Ben's commit #913445c981 (new_grid: Add grid_lines.cc) the bug is now present.

In between those 2 points, Ben's added a couple of commits called "squashed commit". I don't know if that's contributing for the problem somehow? (I'm not quite sure what a squashed commit is...)

johne53

2018-02-27 17:17

reporter   ~0020198

Last edited: 2018-02-28 13:11

 Okay, here's my theory (admittedly it's not proven...)

I think this is being caused by the fact that there are now 2 x cursors (the playhead cursor and the snap cursor). Both (I think) are based on class 'EditorCursor'. In both cases, 'EditorCursor::set_position()' will generate a PositionChanged signal - which ends up calling 'Editor::map_position_change()'

BUT... 'Editor::map_position_change()' knows nothing about the snap cursor. So regardless of which cursor called it, 'Editor::map_position_change()' will assume it's being asked to set the position of the playhead cursor!

The playhead cursor gets its position initialized from the value in instant.xml - but the snap cursor doesn't (its initial position is zero). And that (I think) is why the window initially gets set correctly and then its LHS gets reset (wrongly) to zero.

Maybe that also explains the race condition - i.e. this all depends on which cursor's position happens to get set first?

[Edit...] No this isn't the problem (although I guess it could be contributing to the problem). Something seems to have changed some established functionality within 'Editor::super_rapid_screen_update()' which has these lines:-

    samplepos_t sample = _session->audible_sample (&latent_locate);

    [...] // some other stuff...

    if (playhead_cursor->current_sample () == sample) {
        return;
    }

    playhead_cursor->set_position (sample);

AFAICT (in previous versions) '_session->audible_sample(&latent_locate)' couldn't return zero if the playhead cursor was at a non-zero value. In other words, the line:-

    playhead_cursor->set_position (sample);

could only ever get reached if 'sample' has a non-zero value. But after the snap-cursor addition, that line is now getting called somehow for both zero and non-zero values (a zero value causes the summary window to start at zero).

Issue History

Date Modified Username Field Change
2018-02-23 15:33 johne53 New Issue
2018-02-23 16:09 x42 Note Added: 0020180
2018-02-23 17:08 johne53 Note Added: 0020181
2018-02-25 10:46 johne53 Note Added: 0020186
2018-02-25 12:02 x42 Note Added: 0020187
2018-02-25 12:27 johne53 Note Added: 0020188
2018-02-25 12:35 x42 Note Added: 0020189
2018-02-25 12:41 x42 Note Added: 0020190
2018-02-25 14:35 johne53 Note Added: 0020191
2018-02-27 09:39 johne53 Note Added: 0020197
2018-02-27 17:17 johne53 Note Added: 0020198
2018-02-28 13:09 johne53 Note Edited: 0020198
2018-02-28 13:11 johne53 Note Edited: 0020198
2018-02-28 13:11 johne53 Note Edited: 0020198