Bug #1996
Not handling correctly the case of a long track + a shorter subtrack (or more than one)
Status: | New | Start date: | 2020-06-30 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | - |
Description
Load a long track (e.g. an entire concert recording) and a shorter one (e.g. a single song from the concert) and align them. (At the moment it'll be necessary to use some fancy-pants external aligner that can cope with such subsequences. Or fake one for testing purposes.)
Now scroll through the long track. What we sort of instinctively expect is that the shorter track is visible whenever any part of the subsection of long track that it is aligned with is on the screen, but when you scroll that entire area off the screen, the shorter track should probably skedaddle as well. I'm not sure whether we can easily formalise that behaviour, but the current behaviour (where the shorter track is always pinned on the screen, regardless of whether its corresponding part of the long one is visible or not) really doesn't feel right.
Things get much worse again when you add a third track (or more) lining up with a different part of the longer one - say one song from near the beginning of the concert and one from the end, with a big gap in between. Now both of the shorter tracks are always visible, which creates the false impression that they have some part of their timeline in common. This is compounded by the way the salient feature layer is mapped - all features from the whole of the concert recording are mapped into each subset (with the earlier/later ones all mapped into a single point at beginning/end) which means we get an extremely deceptive mapping from one of the shorter tracks to the other that appears to corroborate the erroneous timeline.