Improving the Timeline
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:
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):
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:
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 I also have a feature… 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.
![Screenshot from 2019-01-14 13-28-57.png]()
Here is an example in the original timeline:
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 As of right now, the meta… 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 One thing which was briefly… 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 I seem to remember the other… 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:
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:
I would say need at last one width of a number space between consecutive measure numbers to be readable.
In reply to tried it out. As I… by ericfontainejazz
regarding the vertical QSplitter...I don't think it should collapse the timeline area either...as I see no purpose in that. Also I see no reason why should be able to drag that QSplitter further right than the end of the longest instrument or meta row label...
In reply to regarding the vertical… by ericfontainejazz
Regarding the vertical QSplitter. That is planning to be implemented soon. It will drag only as far as the longest label text. If the above mentioned simplified mixer controls are added, then they will drag as far as needed for them.
In reply to tried it out. As I… 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 tried it out. As I… 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.
In reply to As for the measure numbers,… by JoshuaBonn1
> "can't just do "a number" because that could be a whole spectrum of widths, even if it was just one digit."
I'd pick the fattest number, which I guess would be '0', and save it width as the minimum distance to use.
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 Trying on a huge score, and… 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.
In reply to Strange... none of my code… by JoshuaBonn1
actually I've discovered the culprate for the slow drag was the navigator, not your timeline. Turning off the navigator, and the dragging is fast.
will it be possible to get colors in timeline in the next Muse-score version ? It would be great if instrument colors in the timeline are the same in the mixer ;)
In reply to will it be possible to get… by Benjamin_P
Thanks for your efforts and work, timeline is now my swiss army knive in musescore !
As another feature request, would it be also possible to get the chords line ? If chords are entered, a linear version of them could help to quickly move into a project song.