How can I color specific notes?

[nimblespark]

I'm trying to color certain notes in order to highlight different voices.
I was hoping to be able to specify the color using the api like this.

 apiRef.current.score.tracks[0].staves[0].bars[0].voices[0].beats[0].notes[0].color = '#2f2f78'

I've looked through some other discussions about styling, but it seems like display.resources is focused on global styling (fonts, main colors) and what I want to do is specify colors for specific notes.

If there's some way to get a reference to the SVG element from a note object or a note id I could color it that way too.

Right now, my best solution for highlighting notes is making them ghost notes. My problem with this is that I want to highlight different notes differently (some notes red, some blue, some green, etc.)

What would be the best way to do this?

[Danielku15]

I'm trying to color certain notes in order to highlight different voices.

This is currently not supported. All requests so far in this direction were rather very vague on what the devs were trying to achieve. While technically coloring would be possible, there are various questions to be answered:

• Whats the goal behind it? Can the solution to the problem maybe be tackled differently?
• What exact parts of the note should be highlighted. Only the note head, or other elements as well (stem, dots, effects,...)
• A "note" in the data model might have multiple visual representations (e.g. in tabs, standard notation, numbered notation,..). What exactly should be highlighted? Should individual bits again be addressable "somehow" for coloring?

If there's some way to get a reference to the SVG element from a note object or a note id I could color it that way too.

alphaTab aims to be cross platform and it supports a wide range of render engines. SVG is just one of them. There it is highly discouraged to access the internal rendering structure of alphaTab. within the rendering canvas everything is subject to change at any time.

Right now, my best solution for highlighting notes is making them ghost notes. My problem with this is that I want to highlight different notes differently (some notes red, some blue, some green, etc.)

Depending on the type of highlighting you want to achieve, the noteBounds might be a way of addressing the osition of desired elements.

https://www.alphatab.net/docs/reference/scorerenderer/boundslookup
https://www.alphatab.net/docs/reference/settings/core/includenotebounds/

Typically the usecases are very specific and without good insight it is hard for alphaTab to provide a general solution which works for more than just 1 person. The more information you provide, the more possibilities I have to find solutions for the needs 😁

[nimblespark]

Whats the goal behind it? Can the solution to the problem maybe be tackled differently?

My goal is to highlight different note heads in a chord differently. I'm making a music theory web app and I want to highlight the different chord tones in a chord. For example, maybe all the tonic notes of each chord would be blue, all the thirds would be yellow, and all the fifths would be red.

What exact parts of the note should be highlighted. Only the note head, or other elements as well (stem, dots, effects,...)

For my purposes, all I want to highlight is the note head. I also think that makes the most sense for coloring notes generally.

A "note" in the data model might have multiple visual representations (e.g. in tabs, standard notation, numbered notation,..). What exactly should be highlighted? Should individual bits again be addressable "somehow" for coloring?

I think what makes the most sense is coloring just the note head for standard notation and coloring the number for tabs. I'm not really sure what numbered notation is.

Depending on the type of highlighting you want to achieve, the noteBounds might be a way of addressing the osition of desired elements.

I experimented with this a little bit.

First, I set includeNoteBounds to true like this:

core: {
          includeNoteBounds: true,
        },

But it seems like apiRef.current.renderer.boundsLookup is always null. Even after the score has properly rendered on the screen. Maybe I'm referencing incorrectly?

[Danielku15]

Maybe this helps you on the boundsLookup in general:
https://jsfiddle.net/danielku15/kdrpbL7j/
https://github.com/CoderLine/alphaTabWebsite/blob/develop/src/components/BoundsLookupViewer/index.tsx

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

If we now would want to color "notes" in flexible ways we need a range of color settings on different levels (note/beat) describing which elements should get colored differently.

Thinking of a flexible solution covering many needs and allow future extension could be:

• We have a public colors: Map<NoteElement, Color|null>; on the Note class and a public colors: Map<BeatElement, Color|null>; on the Beat class. (null to indicate you want the default color and a value to override the default)
• NoteElement and BeatElement would be enumerations for the different elements where we want to support custom colors which are then respected by drawing. The enums would need to be fine-grained enough to control one or multiple elements in simple ways.
• 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).
• Whenever needed we could add more enum values to color specific items (or allow resetting it to defaults).

Performance is an important aspect to consider.

[Danielku15]

I added a new feature request in #1769 for this topic.