Re: Custom percussion style is ignored for the first note when it is a grace note
Am Mi., 25. Jan. 2023 um 17:54 Uhr schrieb David Kastrup :
>
> Stu McKenzie writes:
>
> > There seems to have been various reports of bugs when the first note
> > is a grace note, but this bug has been in many LilyPond versions to
> > date.
> >
> > When the first note of a drum score has a grace note, LilyPond outputs
> > the default note, rather than the custom percussion style.
> >
> > In this case, \acciaccatura is used to create each grace note - main
> > note combination.
> >
> > Here's a "Tiny example":
> >
> > \version "2.24.0"
> > #(define mydrums '( (hightom default #f 3)))
> > \score {
> > \new DrumStaff <<
> > \set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> > \new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura
> > tomh8 tomh4 \acciaccatura tomh8 tomh4 } }
> > >>
> > }
>
> This is not a bug. You specify you _want_ simultaneous music by using
> << ... >> and the settings of DrumStaff.drumStyleTable are performed
> _on_ the beat while the grace notes are performed _before_ the beat.
>
> This is _exactly_ as you tell LilyPond you want things to happen. If
> you want to have things to happen in sequence, you have to write them in
> sequence.
>
> Using { ... } instead of << ... >> here probably gives something closer
> to your expectations.
>
> Now for things that _pervade_ a context rather than switch around, it
> makes sense not to set them at the first time step but generally, by
> using a \with block:
>
> \version "2.24.0"
> #(define mydrums '( (hightom default #f 3)))
> \score {
> \new DrumStaff \with { drumStyleTable = #(alist->hash-table mydrums) }
> {
> \new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura tomh8
> tomh4 \acciaccatura tomh8 tomh4 } }
> }
> }
>
> --
> David Kastrup
>
It's unfortunate that we provide an example like:
\new DrumStaff <<
\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
\new DrumVoice { \voiceOne \up }
\new DrumVoice { \voiceTwo \down }
>>
as first code example in NR 2.5 Percussion Custom percussion staves.
I've put up https://gitlab.com/lilypond/lilypond/-/merge_requests/1822
to fix the docs
Cheers,
Harm
Re: Custom percussion style is ignored for the first note when it is a grace note
Stu McKenzie writes:
> There seems to have been various reports of bugs when the first note
> is a grace note, but this bug has been in many LilyPond versions to
> date.
>
> When the first note of a drum score has a grace note, LilyPond outputs
> the default note, rather than the custom percussion style.
>
> In this case, \acciaccatura is used to create each grace note - main
> note combination.
>
> Here's a "Tiny example":
>
> \version "2.24.0"
> #(define mydrums '( (hightom default #f 3)))
> \score {
> \new DrumStaff <<
> \set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> \new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura
> tomh8 tomh4 \acciaccatura tomh8 tomh4 } }
> >>
> }
This is not a bug. You specify you _want_ simultaneous music by using
<< ... >> and the settings of DrumStaff.drumStyleTable are performed
_on_ the beat while the grace notes are performed _before_ the beat.
This is _exactly_ as you tell LilyPond you want things to happen. If
you want to have things to happen in sequence, you have to write them in
sequence.
Using { ... } instead of << ... >> here probably gives something closer
to your expectations.
Now for things that _pervade_ a context rather than switch around, it
makes sense not to set them at the first time step but generally, by
using a \with block:
\version "2.24.0"
#(define mydrums '( (hightom default #f 3)))
\score {
\new DrumStaff \with { drumStyleTable = #(alist->hash-table mydrums) }
{
\new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura tomh8 tomh4
\acciaccatura tomh8 tomh4 } }
}
}
--
David Kastrup
Custom percussion style is ignored for the first note when it is a grace note
There seems to have been various reports of bugs when the first note is
a grace note, but this bug has been in many LilyPond versions to date.
When the first note of a drum score has a grace note, LilyPond outputs
the default note, rather than the custom percussion style.
In this case, \acciaccatura is used to create each grace note - main
note combination.
Here's a "Tiny example":
\version "2.24.0"
#(define mydrums '( (hightom default #f 3)))
\score {
\new DrumStaff <<
\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
\new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura
tomh8 tomh4 \acciaccatura tomh8 tomh4 } }
>>
}
The first combination outputs the default tomh for the first grace note,
with the main note output from the custom mydrums.
The second combination produces the expected output.
Here's a workaround (full bar instead of partial, which is not what was
required):
\version "2.24.0"
#(define mydrums '( (hightom default #f 3)))
\score {
\new DrumStaff <<
\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
\new DrumVoice { \voiceTwo \drummode { r2 \acciaccatura tomh8 tomh4
\acciaccatura tomh8 tomh4 } }
>>
}
Re: Interaction of slurs and bar checks
On 25/01/2023 15:10, Michael Käppler wrote:
> Hi all,
> I'm posting to bug-lilypond instead of opening an issue in the tracker,
> because
> I'm not sure if the behaviour is somehow intended or a bug.
> Consider the following example:
>
> \version "2.24.0"
> {
> \time 2/4
> d''8 r e''4 |
> ( cis''16 ) cis'' d'' d''
> }
>
> It gives a warning "Unattached SlurEvent" and does not print a slur.
>
> Removing the bar check gives the correct rendition.
>
> What also works is:
>
> \version "2.24.0"
> {
> \time 2/4
> d''8 r e''4 ( |
> cis''16 ) cis'' d'' d''
> }
>
> i.e. moving the opening parenthesis before the bar check.
>
> This behaviour is not new, 2.20.0 behaves exactly the same.
> At least NR 1.2.5 does not mention such a kind of interaction.
> Am I missing something?
Why do you expect the first one to work... ?
A slur is a post-event. It attaches to a note. A bar check is not a post-event.
The first example is trying to attach a slur to a bar check. The failure seems
quite logical to me.
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Interaction of slurs and bar checks
Hi all,
I'm posting to bug-lilypond instead of opening an issue in the tracker,
because
I'm not sure if the behaviour is somehow intended or a bug.
Consider the following example:
\version "2.24.0"
{
\time 2/4
d''8 r e''4 |
( cis''16 ) cis'' d'' d''
}
It gives a warning "Unattached SlurEvent" and does not print a slur.
Removing the bar check gives the correct rendition.
What also works is:
\version "2.24.0"
{
\time 2/4
d''8 r e''4 ( |
cis''16 ) cis'' d'' d''
}
i.e. moving the opening parenthesis before the bar check.
This behaviour is not new, 2.20.0 behaves exactly the same.
At least NR 1.2.5 does not mention such a kind of interaction.
Am I missing something?
Michael
