Improving the Timeline

• Jan 14, 2019 - 20:38

Back in GSoC 2017, I created the timeline in musescore: https://musescore.org/en/handbook/3/timeline . While it functionally works, there are multiple issues with it--visual, functional, and maintainable. Keep in mind that this is a work in progress, any pictures of the new timeline are subject to change.

Visual

When I was creating the timeline, I developed it on windows, making it look nice on that platform. I had some limited linux testing as my mentor used linux. However, with the introduction of changing font sizes and styles, my timeline wouldn't update to them. Also, the initial display was variable from screen to screen, OS to OS.
Here is an example of the original timeline on a different computer:
Screenshot from 2019-01-14 12-12-00.png
Clearly, there are large gaps around the text and some text is way smaller than the desired font size. To compare, here is the same score using the new timeline (yes, I see the label bug):
Screenshot from 2019-01-14 12-15-58.png
Now, everything is tight around the text, removing a bunch of useless space.

Another issue that this will fix is the new "Dark Theme". More info on that can be found here: https://musescore.org/en/node/276002

Finally, the original timeline uses bitmap images to draw the arrows and eyes on the labels. This looks jagged and not smooth. I will replace these with proper images that will be smooth.

Functional

The main issue here is speed. The old timeline had issues with lag when handling large scores. The main issue is that it refreshed the entire timeline with every score interaction, even just dragging the score. Now, it only updates the respective parts of the timeline when the user edits the score, drags the score, and changes the selection. Also, there was some lag when dragging the timeline on a large score which has also been fixed. Lastly, zooming in and out caused incredible amounts of lag on a large score. The new timeline will avoid this by adjusting the current timeline, not refreshing the entire timeline.

Another issue is translations. The original timeline responds quite poorly to changing the current language. The new timeline aims to fix any language issues.

Other functional fixes are mentioned here: https://github.com/musescore/MuseScore/pull/4542

Maintainability

This is the main reason for refactoring the timeline. The original code is a big mess. Many constants are used for color, font size, images, etc. instead of dependent variables. The flow of code is confusing with complex data structures where they are not needed and setting item data when a class or struct is better. Some functions are multiple 100s of lines of code and do five different things all at once. To combat this, I have split the timeline into multiple classes, each handling their own part of the timeline and talking with one another. I have not had much developer feedback on the new code, but I still think this is a vast improvement from the original. To see my changes, take a look at my current pull request: https://github.com/musescore/MuseScore/pull/4542 .

Input needed

This is a call for help. Most of the timeline is up for debate and anything can change. Here are a couple of questions:
1. How does the new timeline look so far? The colors will change once dark theme is implemented. The more input I get here, the more I can improve the timeline.
2. What do you wish the timeline did/looked like/didn't do? Should the timeline display a line as the score plays? etc.
3. What are some good colors for the timeline? What about dark theme?

For proper reference, here is the timeline:
Screenshot from 2019-01-14 12-34-50.png

Thank you for your input!


Comments

A fantastic effort! Particularly well done one getting the refresh to be done efficiently!

I think that a lighter colour should be used to indicate empty measures as I find the massive grey area at the bottom of the screen to be very distracting. I would prefer empty regions of the score to be shown in white or the light grey used everywhere else in the UI. Darker colours should only be used for regions with content. Obviously this would be reversed if the dark theme was in use.

I also have a feature request, which is for an option to collapse all the instruments down into a single row that would be coloured in if any instrument had a note in that measure. Similarly, the "signals" (upper part of the timeline) could also be collapsed down to a single row that is coloured in regions where any signal is present. This would offer a much more compact view, which would be particularly important on smaller displays.

In reply to by shoogle

As of right now, the meta rows (what you called signals) are collapsible into a single row (technically 2 rows, one for metas one for measure numbers). The values are then staggered and can be hovered with the mouse.
Here is an example in the original timeline:
Screenshot from 2019-01-14 13-28-57.png

As for collapsing the instruments, that is possible and simple enough to implement. It will most likely be in the context menu for the instruments.

In reply to by JoshuaBonn1

yeah, I would second collapsing the instruments (I believe this is something we talked about as a potential todo in 2017).

And I would second that it it too dark (if it is not in dark theme). I would also say the gridlines are too heavy now, even for a dark theme. I like the gridlines to be just faintly visible, not heavy on the eye, like how they were originally.

One thing which was briefly talked about before you joined I don't know if was mentioned to you was possibly having basic mixer functionality in the timeline. Currently the mixer takes up a lot of space. But there could be a way to have an optional columns next to the instrument names for basic mixer slider, mute, and solo buttons for each instrument. That would take advantage of not having to duplicate instrument list when having a mixer, so would save on screen real-estate.

In reply to by ericfontainejazz

I seem to remember the other side of the debate for this. That the timeline should be used solely for navigation and not playback. I personally have no issue further integrating it with playback. And a small mute and solo and slider, or at least mute and solo doesn't seem that bad of an idea. As long as it is turned off by default.

In reply to by JoshuaBonn1

Yeah, I think that was the other side of the debate. I think the crux of the matter was that the "Timeline" title would be misleading title. But considering that the timeline does allow hiding of instruments, which is beyond simple navigation as that is actual score editing, it seems that the timeline already does more than simply navigation. Maybe the entire dock might be more accurately called a score "Overview", in which the timeline is only one portion of it. A hypothetical volume slider & solo & mute buttons for each could be in a separate collapable QSplitter column, should user want it. But it may be too late to consider such questions.

tried it out. As I mentioned in private chat, I think should disable collapsable for the cell area for the QSplitter.

I'm noticing that zooming into the timeline cell area using Ctrl->Scroll, that the rendering speed slows down dramatically the moment that measure numbers are displayed for each measure (as opposed to every 5 measures). Although seems this problem is still present in 3.0 release...

Also I'm noticing that the measure numbers are very cluttered, and overlap each other...making them not readable:

Screenshot at 2019-01-14 18-51-37.png

when zoom in closer, they at least don't overlap, but still since the end of one measure number is next to the next measure number, there is a still a problem that can't read:

Screenshot at 2019-01-14 18-52-48.png

I would say need at last one width of a number space between consecutive measure numbers to be readable.

In reply to by ericfontainejazz

As for the Ctrl > Scroll, I have not implemented the new logic for that yet. I need to make sure what part is actually going slow. Rescanning the score rapidly or clearing and redrawing all the components on the scene. My plan is to forgo scanning the score and just adjust my existing list of grids/rows/metas/etc. to be the correct size. Might even try some transforms on only the horizontal axis for very quick calculations (if redrawing is the issue)

In reply to by ericfontainejazz

As for the measure numbers, I plan to only draw a number if it is a certain amount away from the previous number. I haven't decided what that amount should be, though... If you have any ideas, that'd be great. I can't just do "a number" because that could be a whole spectrum of widths, even if it was just one digit.

Trying on a huge score, and I'm noticing that dragging the top of the timeline dock up and down is very choppy...as if it is trying to do a complete rerender. However, just dragging the qsplitter up and down is very fast and smooth...as if it is being smart enough to not do a re-render. Can you make dragging the top of the dock be just as fast as dragging the qsplitter?

In reply to by ericfontainejazz

Strange... none of my code is firing when dragging the dock up and down. It's possible it is some underlying issue with Qt views. Also, some of my code should be firing to update the view. However, it seems changing the height of the timeline does not signal a viewRectChanged()... will look into that.

Do you still have an unanswered question? Please log in first to post your question.