Re: Getting back the dynamically coloured freboard dots on L2.20
Am Mi., 4. Nov. 2020 um 01:20 Uhr schrieb Thomas Morley
:
>
> Am Di., 3. Nov. 2020 um 23:36 Uhr schrieb Carl Sorensen
> :
> >
> >
> >
> > On Tue, Nov 3, 2020 at 3:18 PM Thomas Morley
> > wrote:
> >>
> >>
> >>
> >> Well, so it's my own patch...
> >> The patch introduces many nice features, among them coloring dots.
> >> Alas, one cannot access the grob-color (if it is the return-value of a
> >> procedure) in a reasonable way to use it as a fallback if dot-color is
> >> unset. I have to think about it...
> >
> >
> > Could one use the property FretBoard.color if dot-color were not set? I
> > think the FretBoard.color is accessible from Scheme...
> >
> > Carl
> >
> Well, yes and no. Consider:
>
> \new FretBoards {
> \once \override FretBoard.fret-diagram-details.dot-color = #'cyan
> a
> \once \override FretBoard.fret-diagram-details.dot-color =
> #(lambda (grob) 'red)
> bes
> }
>
> I can access the value of the first override from inside
> `make-fret-diagram` , ok.
>
> The second override does not work and I currently don't know why not.
> I can access the value of this override from inside make-fret-diagram as well.
> Though, it's the procedure not it's return value.
>
> Cheers,
> Harm
Patch is up:
https://gitlab.com/lilypond/lilypond/-/merge_requests/497
Cheers,
Harm
FretBoards require X11 color names
Possibly silly question, but why are colors forced to be X11 in fret
diagrams?
When you recolor a NoteHead for instance, you just use the literal color
value:
\version "2.20.0"
{
\tweak color #'red b'4 % symbol is invalid, defaults to
black
\tweak color #red b'4 % color value stored in variable
\tweak color #'(0.9 0.5 0.2) b'4 % custom color as an RGB list
\tweak color #(x11-color 'tan) b'4 % looking up X11 color
}
You cannot do this with fret diagrams, as the internal logic assumes
colors are X11 names only.
Not being able to specify a literal color feels inconsistent and
arbitrarily restrictive.
-- Aaron Hill
Re: FretBoards require X11 color names
Am Mi., 4. Nov. 2020 um 23:53 Uhr schrieb Aaron Hill :
>
> Possibly silly question, but why are colors forced to be X11 in fret
> diagrams?
>
> When you recolor a NoteHead for instance, you just use the literal color
> value:
>
>
> \version "2.20.0"
> {
>\tweak color #'red b'4 % symbol is invalid, defaults to
> black
>\tweak color #red b'4 % color value stored in variable
>\tweak color #'(0.9 0.5 0.2) b'4 % custom color as an RGB list
>\tweak color #(x11-color 'tan) b'4 % looking up X11 color
> }
>
>
> You cannot do this with fret diagrams, as the internal logic assumes
> colors are X11 names only.
>
> Not being able to specify a literal color feels inconsistent and
> arbitrarily restrictive.
>
>
> -- Aaron Hill
>
Well, in general overrides/tweaks it's possible:
\new FretBoards {
\override FretBoard.color = #red
a
\tweak color #'(0.9 0.5 0.2)
bes
}
In a verbose fret diagram like
\markup \fret-diagram-verbose #'((place-fret 3 3 3 blue))
you would need to quasiquote/unquote like
\markup \fret-diagram-verbose #`((place-fret 3 3 3 ,blue))
At the time I implemented dot colors I intended to not confuse users
with this syntax.
Probably I should rethink ...
Cheers,
Harm
Re: Getting back the dynamically coloured freboard dots on L2.20
Dear Harm, Carl et al.,
Most of what you discussed went over my head, and I have no idea how
patches work:-)
I understood and tried the hack from Harm:
\override FretBoards.FretBoard.before-line-breaking =
#(lambda (grob)
(ly:grob-set-nested-property! grob '(fret-diagram-details
dot-color)
(color-dot grob)))
It worlds like a charm. I'm more than happy to use it until the patch makes
it to an official release.
Just wanted to say THANK YOU to all of you developers.
Not only for this help, but for all the amazing work you do developing such
a beautiful program for notation such as Lilypond.
I am a primary school music teacher, so* the ability to add colours and
other tweaks made it possible to bring music notation to very young
children. It makes music much more accessible and much less frightening. *
It's just one of the ways your work 'behind the scenes' is like a blessing
for us on the 'frontline'.
---
Viktor🎼Mastoridis
On Wed, 4 Nov 2020 at 21:51, Thomas Morley wrote:
> Am Mi., 4. Nov. 2020 um 01:20 Uhr schrieb Thomas Morley
> :
> >
> > Am Di., 3. Nov. 2020 um 23:36 Uhr schrieb Carl Sorensen
> > :
> > >
> > >
> > >
> > > On Tue, Nov 3, 2020 at 3:18 PM Thomas Morley
> wrote:
> > >>
> > >>
> > >>
> > >> Well, so it's my own patch...
> > >> The patch introduces many nice features, among them coloring dots.
> > >> Alas, one cannot access the grob-color (if it is the return-value of a
> > >> procedure) in a reasonable way to use it as a fallback if dot-color is
> > >> unset. I have to think about it...
> > >
> > >
> > > Could one use the property FretBoard.color if dot-color were not set?
> I think the FretBoard.color is accessible from Scheme...
> > >
> > > Carl
> > >
> > Well, yes and no. Consider:
> >
> > \new FretBoards {
> > \once \override FretBoard.fret-diagram-details.dot-color = #'cyan
> > a
> > \once \override FretBoard.fret-diagram-details.dot-color =
> > #(lambda (grob) 'red)
> > bes
> > }
> >
> > I can access the value of the first override from inside
> > `make-fret-diagram` , ok.
> >
> > The second override does not work and I currently don't know why not.
> > I can access the value of this override from inside make-fret-diagram as
> well.
> > Though, it's the procedure not it's return value.
> >
> > Cheers,
> > Harm
>
> Patch is up:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/497
>
> Cheers,
> Harm
>
