Re: \partCombine \pitchedTrill
On Sat, Feb 01, 2020 at 09:35:02AM -0500, Pierre-Luc Gauthier wrote: > In this MWE the trill pitch des''' is not displayed for some reason. > > When \partCombineChords is forced, why doesn't both trill note get displayed ? It looks like this is a limitation of \partcombine. From the manual: "\partcombine keeps all spanners (slurs, ties, hairpins etc.) in the same Voice so that if any such spanners start or end in a different Voice, they may not be printed properly or at all." > Side question : > Why isn't the second bar merged "chorded" by default? > Both parts seems \partCombineApart by default. Part combine expects the first music expression to be the upper voice and the second expression to be the lower voice. When the lower voice goes higher than the upper one (i.e. the parts cross), it will keep the voices separate so that this is clear in the score. If it chorded them by default the part crossing might not be clear. Kevin
Re: \override multiple properties?
Aaron Hill writes:
> Music functions certainly give you the most flexibility, although
> there are simple cases where you can use 2.19's \etc keyword as a
> shorthand to defining the function yourself:
>
>
> \version "2.19"
>
> stemColor = \override Stem.color = \etc
>
> { d'8 \stemColor #red e' f' \undo \stemColor ##f g' }
>
>
> Note the \undo command above is less ideal as one needs to provide a
> dummy argument to the function.
Why not \undo \stemColor #red here ? ##f makes no sense.
--
David Kastrup
Re: \override multiple properties?
On 2020-02-02 2:26 am, David Kastrup wrote:
Aaron Hill writes:
Music functions certainly give you the most flexibility, although
there are simple cases where you can use 2.19's \etc keyword as a
shorthand to defining the function yourself:
\version "2.19"
stemColor = \override Stem.color = \etc
{ d'8 \stemColor #red e' f' \undo \stemColor ##f g' }
Note the \undo command above is less ideal as one needs to provide a
dummy argument to the function.
Why not \undo \stemColor #red here ? ##f makes no sense.
I did not want to give the impression that the arguments *had* to match.
One could just as easily say \undo \stemColor #blue and get the same
outcome. \undo only seems to care about which properties are
\overridden, not the specific values. So the argument to the music
function in this case does not matter. My choice of "false" was purely
arbitrary, but I guess it was too confusing.
A scenario where the mismatch would make sense is using the function
several times in a row:
{ d \stemColor #red e f \stemColor #blue g a
\stemColor #green f c \undo \stemColor #'() d }
This pattern reinforces that it is not required to \undo each
application of the function.
If \undo \stemColor #'() proves to be undesirable, nothing stops a user
just doing the \undo by hand with a manual \revert Stem.color or a
suitably-defined \noStemColor.
-- Aaron Hill
Re: \override multiple properties?
Aaron Hill writes:
> On 2020-02-02 2:26 am, David Kastrup wrote:
>> Aaron Hill writes:
>>
>>> Music functions certainly give you the most flexibility, although
>>> there are simple cases where you can use 2.19's \etc keyword as a
>>> shorthand to defining the function yourself:
>>>
>>> \version "2.19"
>>> stemColor = \override Stem.color = \etc
>>> { d'8 \stemColor #red e' f' \undo \stemColor ##f g' }
>>>
>>> Note the \undo command above is less ideal as one needs to provide
>>> a
>>> dummy argument to the function.
>> Why not \undo \stemColor #red here ? ##f makes no sense.
>
> I did not want to give the impression that the arguments *had* to
> match. One could just as easily say \undo \stemColor #blue and get
> the same outcome. \undo only seems to care about which properties are
> \overridden, not the specific values. So the argument to the music
> function in this case does not matter. My choice of "false" was
> purely arbitrary, but I guess it was too confusing.
>
> A scenario where the mismatch would make sense is using the function
> several times in a row:
>
>
> { d \stemColor #red e f \stemColor #blue g a
> \stemColor #green f c \undo \stemColor #'() d }
>
>
> This pattern reinforces that it is not required to \undo each
> application of the function.
That's just because you have not been using \temporary \stemColor here.
Non-\temporary overrides implicitly cancel the last existing override at
that level, so \undo \stemColor #green would be "correct" here. The
principal purpose of \undo is that it works even if you don't know the
details involved, so it seems self-defeating to use it in a manner
relying on knowing the details.
> If \undo \stemColor #'() proves to be undesirable, nothing stops a
> user just doing the \undo by hand with a manual \revert Stem.color or
> a suitably-defined \noStemColor.
Again, \undo is for those occasions where you are not really interested
in the details. It's always equivalent to something explicit, of course.
If you write
stemColor = \override Stem.color = \etc
\void \displayLilyMusic \undo \stemColor #red
you get the output
lilypond /tmp/baba.ly
GNU LilyPond 2.21.0
Processing `/tmp/baba.ly'
Parsing...
\revert Stem.color
And there is nothing wrong with that.
--
David Kastrup
RE: Clef change placement
> -Original Message- > From: Kieren MacMillan [mailto:kieren_macmil...@sympatico.ca] > Sent: Saturday, February 01, 2020 11:15 AM > To: Daniel Rosen > Cc: Lilypond-User Mailing List > Subject: Re: Clef change placement > > > Is there a way to achieve this placement automatically, other than by > > specifying explicit system breaks? > > Did you ever get an answer to this? > Seems like a perfect job for a [Scheme] engraver… Nope. Yours is the first response I've gotten. DR
TrillPitchHead doesn’t implement note-head-interface (?)
Hi all, Trying to answer a question on the Facebook group led me to discover that (to my surprise!) TrillPitchHead doesn’t implement note-head-interface and thus (I believe) doesn’t respond to the #'style tweak. Is there a good reason (i.e., other than the fact that Somebody™ didn’t code it!) for the interface not being implemented by TPH? Thanks, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info
