Re: mixed piano bracket style
Hello Michael,
Nothing about the Dynamics context, I just messed up the code for the part if
there is no break (why did I not test this?). The appended file fixes this.
Also if you want this as a general style it is probably better to put it into
a layout or a with block.
Cheers,
Valentin
Am Freitag, 28. Jänner 2022, 21:17:21 CET schrieb Michael Rivers:
> Thanks, Valentin. That looks great. However, when I use it in a Dynamics
> context, I get an error message. Is there something else I would need to do
> to transplant this to a Dynamics context? I appreciate the work you did to
> make this.
>
> Best,
> Michael
>
> \version "2.23.5"
>
> right = \relative c'' {
>
> }
>
> left = \relative c' {
> c1 | c1 |
>
> }
>
> ped = {
> \override Dynamics.PianoPedalBracket.edge-height = #'(0 . 0)
> \override Dynamics.PianoPedalBracket.stencil =
> #(grob-transformer 'stencil
> (lambda (grob orig)
>(let* ((star (grob-interpret-markup grob (markup #:musicglyph
> "pedal.*")))
> (gr_orig (ly:grob-original grob))
> (sibs (if (ly:grob? gr_orig) (ly:spanner-broken-into gr_orig)
> '(
> (if (and (ly:grob? gr_orig) (eq? grob (last sibs)))
>(ly:stencil-combine-at-edge orig X RIGHT star -0.82)
>orig
> \set Dynamics.pedalSustainStyle = #'mixed
>
> s1\sustainOn |
> s\sustainOff |
> }
>
> \score {
> \new PianoStaff <<
> \new Staff = "right" \right
> \new Staff = "left" { \clef bass \left }
> \new Dynamics \ped
>
> }
>
> Drawing systems...
> C:/Users/micha/AppData/Local/Temp/frescobaldi-c_q44hr8/tmpgtfg9hts/document.
> ly:20:48 <0>: In procedure last in expression (last sibs):
>
> C:/Users/micha/AppData/Local/Temp/frescobaldi-c_q44hr8/tmpgtfg9hts/document.
> ly:20:48 <1>: Wrong type argument in position 1 (expecting pair): ()
>
> Exited with return code 1.
>
> On Thu, Jan 27, 2022 at 5:37 PM Valentin Petzel wrote:
> > Hello Michael,
> > Could something like this work?
> >
> > Cheers,
> > Valentin
> >
> > Am Donnerstag, 27. Jänner 2022, 23:13:49 CET schrieb Michael Rivers:
> > > Does anyone know if there was ever an answer to this? I’m re-engraving a
> > > score that has a piano pedal style with “Ped”, then a solid line, then a
> > > “*” at the end. It’s close to “mixed” style but with an added “*” at the
> > > end.
> > >
> > >
> > >
> > > Thanks in advance,
> > >
> > > Michael\relative {
\override Staff.PianoPedalBracket.edge-height = #'(0 . 0)
\override Staff.PianoPedalBracket.stencil =
#(grob-transformer 'stencil
(lambda (grob orig)
(let* ((star (grob-interpret-markup grob (markup #:musicglyph "pedal.*")))
(gr_orig (ly:grob-original grob))
(sibs (if (ly:grob? gr_orig) (ly:spanner-broken-into gr_orig) '(
(if (or (null? sibs) (eq? grob (last sibs)))
(ly:stencil-combine-at-edge orig X RIGHT star -0.82)
orig
\set Staff.pedalSustainStyle = #'mixed
c''4\sustainOn g c d
d g, c2\sustainOff
}
signature.asc
Description: This is a digitally signed message part.
Re: tagGroup question
Simon Albrecht writes: > Thanks, David and Jean, for your replies. I have no intention to > reopen a can of worms here, and I didn’t remember that discussion > (IIRC, that was at a time when I more regularly kept up with all > LilyPond issues). > > Using \keepWithTag a \keepWithTag b \music is very reasonable, > especially considering that I almost exclusively use them either as > toplevelMusicFunctions or wrapping an entire score’s music. On the other hand I am not sure that an interface that I designed myself and still fail to correctly work with is worth keeping. I'll take a look, hopefully not affecting too many scores. -- David Kastrup
Re: tagGroup question
Thanks, David and Jean, for your replies. I have no intention to reopen
a can of worms here, and I didn’t remember that discussion (IIRC, that
was at a time when I more regularly kept up with all LilyPond issues).
Using \keepWithTag a \keepWithTag b \music is very reasonable,
especially considering that I almost exclusively use them either as
toplevelMusicFunctions or wrapping an entire score’s music.
Best, Simon
On 28/01/2022 15:17, David Kastrup wrote:
David Kastrup writes:
Simon Albrecht writes:
Dear list,
I have encountered some unexpected behaviour with tags and
tagGroups. In the following example, I thought the two staffs should
look the same, even without the \removeWithTag command, but they
don’t:
\version "2.23.5"
% tested with 2.23.5 (guile2-build) and 2.22.0
\tagGroup sol,mi
\tagGroup withCClefs,noCClefs
\keepWithTag mi,noCClefs
%\removeWithTag withCClefs
<<
{
\tag mi,withCClefs \clef alto
1
\tag mi,noCClefs \clef bass
1
}
{
\tag withCClefs \clef alto
1
\tag noCClefs \clef bass
1
}
%%
How come the other tagGroup interferes? Is this a bug?
‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
Include only elements of MUSIC that are tagged with one of the tags
in TAGS. TAGS may be either a single symbol or a list of symbols.
Each tag may be declared as a member of at most one tag group
(defined with ‘\tagGroup’). If none of a MUSIC element’s tags
share a tag group with one of the specified TAGS, the element is
retained.
Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
the more inclusive \keepWithTag #'(a b) even when a and b are from
different tag groups. That is in line with this documentation that is
close to the implementation. Whether this is in line with sensible
expectations of what \tagGroup should achieve, I am not sure.
I do think that I have at times described the effect of \tagGroup as
making \keepWithTag #'(a b) equivalent to
\keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
groups: that would point to even my expectations being more in line with
yours than with what the implementation does.
Interesting: in the original issue in the bug tracker, the proposed
commit message is a lot more verbose than what ended up eventually in
the repository:
Issue 4083: Implement \tagGroup command
After mulling this over and figuring out that declaring a \tagGroup
will not just keep \keepWithTag of some package unaffected by any tags
otherwise in use but will _also_ hide the use of tags internal to the
package from any outside use of \keepWithTag, I decided to go forward
on this approach.
The given implementation does "nothing special" for \keepWithTag and
\removeWithTag when given tags from different tag groups, or when
defining the same tag group several times (possibly by loading some
code twice). It is arguable that either could warrant a warning.
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
Also contains:
Basic documentation for \tagGroup command
That would imply that I was very much aware at the time of writing this
of the implications. The question is whether
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
really keeps options open that anybody would use, making this behavior
(that cannot be achieved in reasonably simple other ways) desirable.
Problem is that few uses of \keepWithTag #'(fromgroupI fromgroupII) are
likely to intentionally invoke that behavior. Indeed, in my most recent
score under work I find
\keepWithTag layout,pizz %pause %,dingding
With layout and pizz being in different tag groups and the intent being
exactly to be equivalent to \keepWithTag layout \keepWithTag pizz .
So the question is whether retaining this subtle feature (not otherwise
available) is worth its price when not even the author of it is able to
remember how it applies in case anyone would ever need it.
Re: mixed piano bracket style
Thanks, Valentin. That looks great. However, when I use it in a Dynamics
context, I get an error message. Is there something else I would need to do
to transplant this to a Dynamics context? I appreciate the work you did to
make this.
Best,
Michael
\version "2.23.5"
right = \relative c'' {
}
left = \relative c' {
c1 | c1 |
}
ped = {
\override Dynamics.PianoPedalBracket.edge-height = #'(0 . 0)
\override Dynamics.PianoPedalBracket.stencil =
#(grob-transformer 'stencil
(lambda (grob orig)
(let* ((star (grob-interpret-markup grob (markup #:musicglyph
"pedal.*")))
(gr_orig (ly:grob-original grob))
(sibs (if (ly:grob? gr_orig) (ly:spanner-broken-into gr_orig)
'(
(if (and (ly:grob? gr_orig) (eq? grob (last sibs)))
(ly:stencil-combine-at-edge orig X RIGHT star -0.82)
orig
\set Dynamics.pedalSustainStyle = #'mixed
s1\sustainOn |
s\sustainOff |
}
\score {
\new PianoStaff <<
\new Staff = "right" \right
\new Staff = "left" { \clef bass \left }
\new Dynamics \ped
>>
}
Drawing systems...
C:/Users/micha/AppData/Local/Temp/frescobaldi-c_q44hr8/tmpgtfg9hts/document.ly:20:48
<0>: In procedure last in expression (last sibs):
C:/Users/micha/AppData/Local/Temp/frescobaldi-c_q44hr8/tmpgtfg9hts/document.ly:20:48
<1>: Wrong type argument in position 1 (expecting pair): ()
Exited with return code 1.
On Thu, Jan 27, 2022 at 5:37 PM Valentin Petzel wrote:
> Hello Michael,
> Could something like this work?
>
> Cheers,
> Valentin
>
> Am Donnerstag, 27. Jänner 2022, 23:13:49 CET schrieb Michael Rivers:
> > Does anyone know if there was ever an answer to this? I’m re-engraving a
> > score that has a piano pedal style with “Ped”, then a solid line, then a
> > “*” at the end. It’s close to “mixed” style but with an added “*” at the
> > end.
> >
> >
> >
> > Thanks in advance,
> >
> > Michael
> >
> >
Re: Preventing stuff from clashing with ledger lines
Hi Jean,
> Perhaps, but this becomes hardly feasible when you
> consider
>
> \version "2.22.1"
>
> <<
>{ e' }
>\\
>{ \stemDown g,\tweak Y-offset -1.5-. }
> >>
>
> The script position should normally be below the
> note, not above it. That happens automatically
> if you use \voiceTwo rather than the very specific
> \stemDown.
The staccato problem happens when, say, you have beamed notes very far
apart in terms of pitch. I can see that this is workable due to the rarity
of the occurrence and the ease of the workaround, I am just curious if an
automatic solution exists. Sometimes, passages do appear like this by
themselves, I'm guessing to "denote" a different mood in the music. This is
also a kind of example that I refer to in the slur problem.
> > Slurs also should not do this (I'd say a good limit is in between
> > the final staff line and the first ledger line).
> > Is it also possible to automate this, so that I do not need to tweak
> > it every time it happens?
>
> Could you give an example where this happens?
>
The slur in
\version "2.22.1"
{ \stemDown f'16( d' a f) }
could be better shaped as
\version "2.22.1"
{ \stemDown f'16\shape #'((0 . 0) (0.5 . 0) (-0.3 . 0.9) (0 . 1.5))( d' a
f) }
to avoid the ledger lines.
Re: Preventing stuff from clashing with ledger lines
Hi Jean,
> Perhaps, but this becomes hardly feasible when you
> consider
>
> \version "2.22.1"
>
> <<
>{ e' }
>\\
>{ \stemDown g,\tweak Y-offset -1.5-. }
> >>
>
> The script position should normally be below the
> note, not above it. That happens automatically
> if you use \voiceTwo rather than the very specific
> \stemDown.
The staccato problem happens when, say, you have beamed notes very far
apart in terms of pitch. I can see that this is workable due to the rarity
of the occurrence and the ease of the workaround, I am just curious if an
automatic solution exists. Sometimes, passages do appear like this by
themselves, I'm guessing to "denote" a different mood in the music. This is
also a kind of example that I refer to in the slur problem.
> > Slurs also should not do this (I'd say a good limit is in between
> > the final staff line and the first ledger line).
> > Is it also possible to automate this, so that I do not need to tweak
> > it every time it happens?
>
> Could you give an example where this happens?
>
The slur in
\version "2.22.1"
{ \stemDown f'16( d' a f) }
could be better shaped as
\version "2.22.1"
{ \stemDown f'16\shape #'((0 . 0) (0.5 . 0) (-0.3 . 0.9) (0 . 1.5))( d' a
f) }
to avoid the ledger lines.
Re: tagGroup question
David Kastrup writes:
> Simon Albrecht writes:
>
>> Dear list,
>>
>> I have encountered some unexpected behaviour with tags and
>> tagGroups. In the following example, I thought the two staffs should
>> look the same, even without the \removeWithTag command, but they
>> don’t:
>>
>>
>> \version "2.23.5"
>> % tested with 2.23.5 (guile2-build) and 2.22.0
>>
>> \tagGroup sol,mi
>> \tagGroup withCClefs,noCClefs
>>
>> \keepWithTag mi,noCClefs
>> %\removeWithTag withCClefs
>> <<
>> {
>> \tag mi,withCClefs \clef alto
>> 1
>> \tag mi,noCClefs \clef bass
>> 1
>> }
>> {
>> \tag withCClefs \clef alto
>> 1
>> \tag noCClefs \clef bass
>> 1
>> }
>> %%
>>
>>
>> How come the other tagGroup interferes? Is this a bug?
>
> ‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
> Include only elements of MUSIC that are tagged with one of the tags
> in TAGS. TAGS may be either a single symbol or a list of symbols.
>
> Each tag may be declared as a member of at most one tag group
> (defined with ‘\tagGroup’). If none of a MUSIC element’s tags
> share a tag group with one of the specified TAGS, the element is
> retained.
>
> Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
> the more inclusive \keepWithTag #'(a b) even when a and b are from
> different tag groups. That is in line with this documentation that is
> close to the implementation. Whether this is in line with sensible
> expectations of what \tagGroup should achieve, I am not sure.
>
> I do think that I have at times described the effect of \tagGroup as
> making \keepWithTag #'(a b) equivalent to
> \keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
> groups: that would point to even my expectations being more in line with
> yours than with what the implementation does.
Interesting: in the original issue in the bug tracker, the proposed
commit message is a lot more verbose than what ended up eventually in
the repository:
Issue 4083: Implement \tagGroup command
After mulling this over and figuring out that declaring a \tagGroup
will not just keep \keepWithTag of some package unaffected by any tags
otherwise in use but will _also_ hide the use of tags internal to the
package from any outside use of \keepWithTag, I decided to go forward
on this approach.
The given implementation does "nothing special" for \keepWithTag and
\removeWithTag when given tags from different tag groups, or when
defining the same tag group several times (possibly by loading some
code twice). It is arguable that either could warrant a warning.
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
Also contains:
Basic documentation for \tagGroup command
That would imply that I was very much aware at the time of writing this
of the implications. The question is whether
However, the functionality of \keepWithTag #'(fromgroupI fromgroupII)
cannot easily be provided by anything else.
While I currently cannot imagine a useful application for it myself,
the implemented behavior is logically consistent.
really keeps options open that anybody would use, making this behavior
(that cannot be achieved in reasonably simple other ways) desirable.
Problem is that few uses of \keepWithTag #'(fromgroupI fromgroupII) are
likely to intentionally invoke that behavior. Indeed, in my most recent
score under work I find
\keepWithTag layout,pizz %pause %,dingding
With layout and pizz being in different tag groups and the intent being
exactly to be equivalent to \keepWithTag layout \keepWithTag pizz .
So the question is whether retaining this subtle feature (not otherwise
available) is worth its price when not even the author of it is able to
remember how it applies in case anyone would ever need it.
--
David Kastrup
Re: tagGroup question
Simon Albrecht writes:
> Dear list,
>
> I have encountered some unexpected behaviour with tags and
> tagGroups. In the following example, I thought the two staffs should
> look the same, even without the \removeWithTag command, but they
> don’t:
>
>
> \version "2.23.5"
> % tested with 2.23.5 (guile2-build) and 2.22.0
>
> \tagGroup sol,mi
> \tagGroup withCClefs,noCClefs
>
> \keepWithTag mi,noCClefs
> %\removeWithTag withCClefs
> <<
> {
> \tag mi,withCClefs \clef alto
> 1
> \tag mi,noCClefs \clef bass
> 1
> }
> {
> \tag withCClefs \clef alto
> 1
> \tag noCClefs \clef bass
> 1
> }
>>>
> %%
>
>
> How come the other tagGroup interferes? Is this a bug?
‘\keepWithTag’ [music] - TAGS (symbol list or symbol) MUSIC (music)
Include only elements of MUSIC that are tagged with one of the tags
in TAGS. TAGS may be either a single symbol or a list of symbols.
Each tag may be declared as a member of at most one tag group
(defined with ‘\tagGroup’). If none of a MUSIC element’s tags
share a tag group with one of the specified TAGS, the element is
retained.
Essentially, \keepWithTag #'a \keepWithTag #'b is not the same as
the more inclusive \keepWithTag #'(a b) even when a and b are from
different tag groups. That is in line with this documentation that is
close to the implementation. Whether this is in line with sensible
expectations of what \tagGroup should achieve, I am not sure.
I do think that I have at times described the effect of \tagGroup as
making \keepWithTag #'(a b) equivalent to
\keepWithTag #'a \keepWithTag #'b when a and b belong to different tag
groups: that would point to even my expectations being more in line with
yours than with what the implementation does.
--
David Kastrup
Re: trillSpan question:
> On 28 Jan 2022, at 01:03, Kenneth Wolcott wrote: > > I have trouble understanding how to implement the \startTrillSpan > and \stopTrillSpan. … > Another related question: what is the difference in the actual > performance of the two types? The trill symbol only applies to the note it is written above, so if the latter is tied to one or more following notes, one must make clear which ones of those the trilling should be extended to. The notation says nothing about how the trilled should be performed other than that. Then \stopTrillSpan should be put after the last of those notes that should be trilled. There could be other uses, but that us how I think of it.
Re: tagGroup question
Le 28/01/2022 à 13:45, Simon Albrecht a écrit :
Dear list,
I have encountered some unexpected behaviour with tags and tagGroups.
In the following example, I thought the two staffs should look the
same, even without the \removeWithTag command, but they don’t:
\version "2.23.5"
% tested with 2.23.5 (guile2-build) and 2.22.0
\tagGroup sol,mi
\tagGroup withCClefs,noCClefs
\keepWithTag mi,noCClefs
%\removeWithTag withCClefs
<<
{
\tag mi,withCClefs \clef alto
1
\tag mi,noCClefs \clef bass
1
}
{
\tag withCClefs \clef alto
1
\tag noCClefs \clef bass
1
}
>>
%%
How come the other tagGroup interferes? Is this a bug?
There was a lot of discussion about this on
https://gitlab.com/lilypond/lilypond/-/issues/4083
and https://codereview.appspot.com/137920043.
In the end, it was decided that \keepWithTag
keeps all music that has one matching tag
(and removes other tagged music iff any of its
tag is in the same group as one of the tags
passed to \keepWithTag). This has the consequence
that
\keepWithTag mi,noCClefs ...
and
\keepWithTag mi \keepWithTag noCClefs ...
are different things. You want the latter one
here.
Best,
Jean
tagGroup question
Dear list,
I have encountered some unexpected behaviour with tags and tagGroups. In
the following example, I thought the two staffs should look the same,
even without the \removeWithTag command, but they don’t:
\version "2.23.5"
% tested with 2.23.5 (guile2-build) and 2.22.0
\tagGroup sol,mi
\tagGroup withCClefs,noCClefs
\keepWithTag mi,noCClefs
%\removeWithTag withCClefs
<<
{
\tag mi,withCClefs \clef alto
1
\tag mi,noCClefs \clef bass
1
}
{
\tag withCClefs \clef alto
1
\tag noCClefs \clef bass
1
}
>>
%%
How come the other tagGroup interferes? Is this a bug?
Best, Simon
Re: Preventing stuff from clashing with ledger lines
Le 28/01/2022 à 08:27, Jefferson Skinny a écrit :
Hi,
I noticed that grace notes do not follow the same as normal notes.
Normally, notes which are placed beyond ledger lines will have longer
stems to avoid clashing with them. Certainly, it is possible to tweak
the stems individually, but is it possible to automate this for grace
notes?
This is intentional. You can switch it off using
\version "2.22.1"
\new Voice {
$(add-grace-property 'Voice 'Stem 'no-stem-extend '())
\stemUp \grace g,8-. g,4
}
Note that creating the voice explicitly with
\new Voice is important here. Please see
https://lilypond.org/doc/v2.22/Documentation/notation/special-rhythmic-concerns#grace-notes
Same goes with articulation. Staccato dots and wedges usually don't
leave the staff when there are ledger lines. For example, a better
placement for the staccato dot in
{ \stemDown g-. }
would be
{ \stemDown g\tweak Y-offset -1.5-. }
Perhaps, but this becomes hardly feasible when you
consider
\version "2.22.1"
<<
{ e' }
\\
{ \stemDown g,\tweak Y-offset -1.5-. }
>>
The script position should normally be below the
note, not above it. That happens automatically
if you use \voiceTwo rather than the very specific
\stemDown.
Slurs also should not do this (I'd say a good limit is in between
the final staff line and the first ledger line).
Is it also possible to automate this, so that I do not need to tweak
it every time it happens?
Could you give an example where this happens?
Best,
Jean
