Allow custom coloring of individual notation elements on specific beats/notes

[Danielku15]

Motivation

There were repeating requests to allow "coloring of notes" from different users. Only a few users reported concrete use-cases on what exactly should be colored, how, and for what purpose. The use case makes sense but to ship the correct coloring of elements is not an easy task. The goal on the most recent request here is that individual notes should be colored for a music theory app. Coloring the notes allows referencing them in the descriptions like "the red note is a C"

Challenge

Here a very extreme case of notation elements related to a note. This should help understanding why "coloring a note" is more complex than initially expected. In this screenshot we see only 2 notes:

On the first beat:

1. We have Tabs, Standard notation, slash notation and numbered notation displayed.
2. The two notes have their own note heads.
3. The two notes share a stem and the bar to the next note.
4. Before the notes we have an accidental, fingering and a arpeggio effect arrow
5. After the notes we have duration dots.
6. Below the notes we have an accentuation.
7. The stem has a tremolo picking bar.
8. Above the beat we have a upper mordent symbol
9. One of the notes has a slide line and tie/slur to the next note

Hence adding a single color property to notes or beats will not serve many use cases but rather only a very specific one.

Proposed Solution

By default the colors of the renderingResources still apply but on different levels of the Score model, users can specify colors for specific notation elements. These colors would then be respected during rendering.

Notes

• We have a public colors: Map<NoteElement, Color|null>; on the Note class where null indicates a reset to the default color of the renderingResources
• NoteElement is an enumerations for the different elements where we want to support custom colors which are then respected by drawing.
• We could start with rather not many enum values covering the main areas (standard notation note heads, accidentals, tab numbers, numbered notation numbers, slash notation note head, stem, bar, and maybe some effect groups).
• There is likely an overlap of one enumeration affecting multiple notation elements. A more coarse enum value might color multiple elements of a notation while a specific enum value addresses only one particular element of a note.
• some good initial defaults would be:
  • standard notation note head
  • standard notation accidentals
  • guitar tablature fret numbers
  • numbered notation numbers
  • slash notation note head
  • staff level note effects/annotations

Beats

On the beat we follow the same principles like on notes but the elements to color would be specific to anything on beat level:

• stems
• flags
• bars

Voice

Voices on colors would be rather simple and override the color defined on renderingResources.

Bars

On the bar we follow the same principles like on notes but the elements to color would be specific to anything on bar level:

• key signature
• time signature
• clefs
• staff lines

Score

On the score we follow the same principles like on notes but the elements to color would be specific to anything on score level:

• Song info
• Tuning info
• Chord diagrams

Performance Consideration

Accessing and changing colors for individual elements can have a quite significant performance impact. We want to avoid that in every glyph we have intensive code for checking for color changes and applying them.

We need some sort of "color container" taking care of providing the colors during rendering. Typically the performance should be on-par with the current logic, only if there are overrides they will have an impact during rendering (e.g. DOM parsing or updates on the rendering context).