Re: keyAlterationOrder
I know that the alist cannot be read with assoc, at least in its
simple
form.
Why not?
assoc would read the first key of a given value none of the others keys
of
the same value would be read in the chain.
It is at best a stretch to call this property an association list to
begin with. An alist is a list of key-value pairs; but this property is
a list of step-alteration pairs with no associative semantics. To use
this list, you need only filter it to the items you are interested in,
and the resulting list will have the items in the desired order.
Consider this contrived example:
\version "2.20.0"
\new Voice {
\applyContext
#(lambda (context)
(let ((keyAlterationOrder
(ly:context-property context 'keyAlterationOrder))
(pitches #{ \fixed c' { cis dis ees fis gis aes bes } #}))
(set! pitches (map (lambda (pitch)
(cons (ly:pitch-steps pitch)
(ly:pitch-alteration pitch)))
(music-pitches pitches)))
(format #t "\n Unordered: ~s" pitches)
(format #t "\nOrdered: ~s"
(filter
(lambda (elem) (member elem pitches))
keyAlterationOrder
}
Parsing...
Interpreting music...
Unordered: ((0 . 1/2) (1 . 1/2) (2 . -1/2) (3 . 1/2) (4 . 1/2) (5 .
-1/2) (6 . -1/2))
Ordered: ((6 . -1/2) (2 . -1/2) (5 . -1/2) (3 . 1/2) (0 . 1/2) (4 .
1/2) (1 . 1/2))
Converted from (step . alteration) back to pitch, the final order is: Bb
Eb Ab F# C# G# D#. This should make sense given the standard convention
of how flats and sharps are arranged.
One question though, Does the key signature affect the midi output?
Yes, Key_performer generates a key signature meta event (FF 59).
-- Aaron Hill
Re: Custom beam subdivisions
Oops, sorry, not awake...
How about:
\version "2.20.0"
\score {
\new Staff { << \relative c' {
\time 6/8
\set baseMoment = #(ly:make-moment 1/64)
\set beatStructure = #'(16 8 16 8)
\set subdivideBeams = ##t
c16[ c c c c32 c c c]
c16[ c c c c32 c c c]
} >> }
}
Cheers,
Pierre
Le mar. 29 déc. 2020 à 07:08, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> a écrit :
> Hi Vaylor,
>
> Le mar. 29 déc. 2020 à 03:36, Vaylor Trucks a écrit :
>
>
>> Any thoughts?
>>
>
> ???
> \version "2.20.0"
> \score {
> \new Staff { << \relative c' {
> \time 6/8
> %\set baseMoment = #(ly:make-moment 1/8)
> \set beatStructure = #'(2 1 2 1)
> %\set subdivideBeams = ##t
> c16 c c c c32 c c c
> c16 c c c c32 c c c
> } >> }
> }
>
> Cheers,
> Pierre
>
Re: Custom beam subdivisions
Hi Vaylor,
Le mar. 29 déc. 2020 à 03:36, Vaylor Trucks a écrit :
> Any thoughts?
>
???
\version "2.20.0"
\score {
\new Staff { << \relative c' {
\time 6/8
%\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = #'(2 1 2 1)
%\set subdivideBeams = ##t
c16 c c c c32 c c c
c16 c c c c32 c c c
} >> }
}
Cheers,
Pierre
Re: keyAlterationOrder
On Mon, Dec 28, 2020 at 5:10 PM Jean Abou Samra wrote: Jean: > Hello, > > [...] > > And they have it wrong.I believe it should read: … *step *is > a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)? > (Not -2 (sharp) to 2 (flat).) > > > This sounds wrong indeed. FLAT is -1/2 and SHARP is 1/2. > Could you write the bug-lilypond list to report this bug? > See http://lilypond.org/contact.html Thanks. > It is done! > > > [...] > > I know that the alist cannot be read with assoc, at least in its simple > form. > > > Why not? > assoc would read the first key of a given value none of the others keys of the same value would be read in the chain. > > Any suggestions were the details of the keyAlterationOrder >> is explained? >> > > That's the best documentation we have. The next place to look is > in the source. > > > Yes. Please note that with roughly 250 different context properties, > 140 grob types, 400 grob properties, and more, these short descriptions > are really the best that can be done to document the internal > Unfortunately that does little for a dummy > > > It should read: "… *step *is a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)" > > (Not -2 (sharp) to 2 (flat).) = #`((6 . ,FLAT) (2 . ,FLAT) (5 . ,FLAT ) > (1 . ,FLAT) (4 . ,FLAT) (0 . ,FLAT) (3 . ,FLAT)(3 . ,SHARP) (0 . > ,SHARP) (4 . ,SHARP) (1 . ,SHARP) (5 . ,SHARP) (2 . ,SHARP) (6 . ,SHARP) > (6 . ,DOUBLE-FLAT) (2 . ,DOUBLE-FLAT) (5 . ,DOUBLE-FLAT ) (1 . ,DOUBLE-FLAT) > (4 . ,DOUBLE-FLAT) (0 . ,DOUBLE-FLAT) (3 . ,DOUBLE-FLAT)(3 . > ,DOUBLE-SHARP) (0 . ,DOUBLE-SHARP) (4 . ,DOUBLE-SHARP) (1 . ,DOUBLE-SHARP) (5 > . ,DOUBLE-SHARP) (2 . ,DOUBLE-SHARP) (6 . ,DOUBLE-SHARP) ) There are 4 sets with the same 7 keys 2 different orders of the keys. >>> There are several out there. Here is one with the same >>> accidental vertical not horizontal: >>> >> >> It doesn't matter whether it's rows or columns; the alist has no rows or >> columns; it's just sequential. An alteration that shows up earlier in the >> list is displayed before one that shows up later in the list. >> >> >>> keyAlterationOrder = #`( >>> % Flats: >>> (6 . -6/53) (6 . -12/53) (6 . -18/53) (6 . -24/53) (6 . >>> -36/53) (6 . -30/53) (6 . -42/53) (6 . -48/53) (6 . -54/53) (6 . >>> -60/53) (6 . -66/53) (6 . -72/53) >>> (2 . -6/53) (2 . -12/53) (2 . -18/53) (2 . -24/53) (2 . >>> -36/53) (2 . -30/53) (2 . -42/53) (2 . -48/53) (2 . -54/53) (2 . >>> -60/53) (2 . -66/53) (2 . -72/53) >>> (5 . -6/53) (5 . -12/53) (5 . -18/53) (5 . -24/53) (5 . >>> -36/53) (5 . -30/53) (5 . -42/53) (5 . -48/53) (5 . -54/53) (5 . >>> -60/53) (5 . -66/53) (5 . -72/53) >>> (1 . -6/53) (1 . -12/53) (1 . -18/53) (1 . -24/53) (1 . >>> -36/53) (1 . -30/53) (1 . -42/53) (1 . -48/53) (1 . -54/53) (1 . >>> -60/53) (1 . -66/53) (1 . -72/53) >>> (4 . -6/53) (4 . -12/53) (4 . -18/53) (4 . -24/53) (4 . >>> -36/53) (4 . -30/53) (4 . -42/53) (4 . -48/53) (4 . -54/53) (4 . >>> -60/53) (4 . -66/53) (4 . -72/53) >>> (0 . -6/53) (0 . -12/53) (0 . -18/53) (0 . -24/53) (0 . >>> -36/53) (0 . -30/53) (0 . -42/53) (0 . -48/53) (0 . -54/53) (0 . >>> -60/53) (0 . -66/53) (0 . -72/53) >>> (3 . -6/53) (3 . -12/53) (3 . -18/53) (3 . -24/53) (3 . >>> -36/53) (3 . -30/53) (3 . -42/53) (3 . -48/53) (3 . -54/53) (3 . >>> -60/53) (3 . -66/53) (3 . -72/53) >>> % Sharps: >>> (3 . 6/53) (3 . 12/53) (3 . 18/53) (3 . 24/53) (3 . 30/53) (3 >>> . 36/53) (3 . 42/53) (3 . 48/53) (3 . 54/53) (3 . 60/53) (3 . 66/53) >>> (3 . 72/53) >>> (0 . 6/53) (0 . 12/53) (0 . 18/53) (0 . 24/53) (0 . 30/53) (0 >>> . 36/53) (0 . 42/53) (0 . 48/53) (0 . 54/53) (0 . 60/53) (0 . 66/53) >>> (0 . 72/53) >>> (4 . 6/53) (4 . 12/53) (4 . 18/53) (4 . 24/53) (4 . 30/53) (4 >>> . 36/53) (4 . 42/53) (4 . 48/53) (4 . 54/53) (4 . 60/53) (4 . 66/53) >>> (4 . 72/53) >>> (1 . 6/53) (1 . 12/53) (1 . 18/53) (1 . 24/53) (1 . 30/53) (1 >>> . 36/53) (1 . 42/53) (1 . 48/53) (1 . 54/53) (1 . 60/53) (1 . 66/53) >>> (1 . 72/53) >>> (5 . 6/53) (5 . 12/53) (5 . 18/53) (5 . 24/53) (5 . 30/53) (5 >>> . 36/53) (5 . 42/53) (5 . 48/53) (5 . 54/53) (5 . 60/53) (5 . 66/53) >>> (5 . 72/53) >>> (2 . 6/53) (2 . 12/53) (2 . 18/53) (2 . 24/53) (2 . 30/53) (2 >>> . 36/53) (2 . 42/53) (2 . 48/53) (2 . 54/53) (2 . 60/53) (2 . 66/53) >>> (2 . 72/53) >>> (6 . 6/53) (6 . 12/53) (6 . 18/53) (6 . 24/53) (6 . 30/53) (6 >>> . 36/53) (6 . 42/53) (6 . 48/53) (6 . 54/53) (6 . 60/53) (6 . 66/53) >>> (6 . 72/53) >>> ) >>> So where is the order?7 key each with 24 pairs. >>> >> No there are 168 (step . alteration) pairs. These are microtonal >> accidentals. For negative (flat) alterations, b comes first, then e, then >> a, then d, then g, then c, then f. A smaller flat comes before a
Custom beam subdivisions
I am trying to subdivide beams in a figure that has 4 16th followed by 4
32nd notes. Time signature is 6/8 and a single measure has 2 of these
figures. What I want is the 4 16ths all connected by 2 beams, the 4 32nds
all connected by 3 beams, and a single beam connecting the 2 sets. My
thought was this should work, but it doesn't:
\version "2.20.0"
\score {
\new Staff { << \relative c' {
\time 6/8
\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = #'(2 1 2 1)
\set subdivideBeams = ##t
c16[ c c c c32 c c c]
c16[ c c c c32 c c c]
} >> }
}
Any thoughts?
Re: LSR 1118 "Double bar line as system start" currently unapproved
Am Mo., 28. Dez. 2020 um 17:42 Uhr schrieb Jean Abou Samra :
>
> To the author of said snippet
> lsr.di.unimi.it/LSR/Item?u=1=1118
>
> Thanks for your snippet.
>
> Though, wouldn't it be much more elegant (and shorter) to get rid of
> the stencil-override by setting `systemStartDelimiter` and simply
> adjusting some other stuff?
>
> Leading to:
>
> \version "2.18.2"
>
> \layout {
> \context {
> \Score
> \override SystemStartBar.thickness = 1.8
> }
> \context {
> \StaffGroup
> \override Clef.X-extent = #'(-0.4 . 0)
> \override SystemStartBar.padding = -0.65
> systemStartDelimiter = #'SystemStartBar
> }
> }
>
> \new StaffGroup <<
> { c'1 }
> { c'1 }
> >>
>
> Best,
> Harm
>
>
> Well, yes, of course. Please do this!
>
> Thanks,
> Jean
Done, and approved as
http://lsr.di.unimi.it/LSR/Item?id=1118
Thanks,
Harm
Re: keyAlterationOrder
Hello, [...] And they have it wrong. I believe it should read: … /step /is a number from 0 to 6 and /alter /from -2 (flat) to 2 (sharp)? (Not -2 (sharp) to 2 (flat).) This sounds wrong indeed. FLAT is -1/2 and SHARP is 1/2. Could you write the bug-lilypond list to report this bug? See http://lilypond.org/contact.html Thanks. [...] I know that the alist cannot be read withassoc, at least in its simple form. Why not? Any suggestions were the details of the keyAlterationOrder is explained? That's the best documentation we have. The next place to look is in the source. Yes. Please note that with roughly 250 different context properties, 140 grob types, 400 grob properties, and more, these short descriptions are really the best that can be done to document the internals. keyAlterationOrder = #`( (6 . ,FLAT) (2 . ,FLAT) (5 . ,FLAT ) (1 . ,FLAT) (4 . ,FLAT) (0 . ,FLAT) (3 . ,FLAT) (3 . ,SHARP) (0 . ,SHARP) (4 . ,SHARP) (1 . ,SHARP) (5 . ,SHARP) (2 . ,SHARP) (6 . ,SHARP) (6 . ,DOUBLE-FLAT) (2 . ,DOUBLE-FLAT) (5 . ,DOUBLE-FLAT ) (1 . ,DOUBLE-FLAT) (4 . ,DOUBLE-FLAT) (0 . ,DOUBLE-FLAT) (3 . ,DOUBLE-FLAT) (3 . ,DOUBLE-SHARP) (0 . ,DOUBLE-SHARP) (4 . ,DOUBLE-SHARP) (1 . ,DOUBLE-SHARP) (5 . ,DOUBLE-SHARP) (2 . ,DOUBLE-SHARP) (6 . ,DOUBLE-SHARP) ) There are 4 sets with the same 7 keys 2 different orders of the keys. There are several out there. Here is one with the same accidental vertical not horizontal: It doesn't matter whether it's rows or columns; the alist has no rows or columns; it's just sequential. An alteration that shows up earlier in the list is displayed before one that shows up later in the list. keyAlterationOrder = #`( % Flats: (6 . -6/53) (6 . -12/53) (6 . -18/53) (6 . -24/53) (6 . -36/53) (6 . -30/53) (6 . -42/53) (6 . -48/53) (6 . -54/53) (6 . -60/53) (6 . -66/53) (6 . -72/53) (2 . -6/53) (2 . -12/53) (2 . -18/53) (2 . -24/53) (2 . -36/53) (2 . -30/53) (2 . -42/53) (2 . -48/53) (2 . -54/53) (2 . -60/53) (2 . -66/53) (2 . -72/53) (5 . -6/53) (5 . -12/53) (5 . -18/53) (5 . -24/53) (5 . -36/53) (5 . -30/53) (5 . -42/53) (5 . -48/53) (5 . -54/53) (5 . -60/53) (5 . -66/53) (5 . -72/53) (1 . -6/53) (1 . -12/53) (1 . -18/53) (1 . -24/53) (1 . -36/53) (1 . -30/53) (1 . -42/53) (1 . -48/53) (1 . -54/53) (1 . -60/53) (1 . -66/53) (1 . -72/53) (4 . -6/53) (4 . -12/53) (4 . -18/53) (4 . -24/53) (4 . -36/53) (4 . -30/53) (4 . -42/53) (4 . -48/53) (4 . -54/53) (4 . -60/53) (4 . -66/53) (4 . -72/53) (0 . -6/53) (0 . -12/53) (0 . -18/53) (0 . -24/53) (0 . -36/53) (0 . -30/53) (0 . -42/53) (0 . -48/53) (0 . -54/53) (0 . -60/53) (0 . -66/53) (0 . -72/53) (3 . -6/53) (3 . -12/53) (3 . -18/53) (3 . -24/53) (3 . -36/53) (3 . -30/53) (3 . -42/53) (3 . -48/53) (3 . -54/53) (3 . -60/53) (3 . -66/53) (3 . -72/53) % Sharps: (3 . 6/53) (3 . 12/53) (3 . 18/53) (3 . 24/53) (3 . 30/53) (3 . 36/53) (3 . 42/53) (3 . 48/53) (3 . 54/53) (3 . 60/53) (3 . 66/53) (3 . 72/53) (0 . 6/53) (0 . 12/53) (0 . 18/53) (0 . 24/53) (0 . 30/53) (0 . 36/53) (0 . 42/53) (0 . 48/53) (0 . 54/53) (0 . 60/53) (0 . 66/53) (0 . 72/53) (4 . 6/53) (4 . 12/53) (4 . 18/53) (4 . 24/53) (4 . 30/53) (4 . 36/53) (4 . 42/53) (4 . 48/53) (4 . 54/53) (4 . 60/53) (4 . 66/53) (4 . 72/53) (1 . 6/53) (1 . 12/53) (1 . 18/53) (1 . 24/53) (1 . 30/53) (1 . 36/53) (1 . 42/53) (1 . 48/53) (1 . 54/53) (1 . 60/53) (1 . 66/53) (1 . 72/53) (5 . 6/53) (5 . 12/53) (5 . 18/53) (5 . 24/53) (5 . 30/53) (5 . 36/53) (5 . 42/53) (5 . 48/53) (5 . 54/53) (5 . 60/53) (5 . 66/53) (5 . 72/53) (2 . 6/53) (2 . 12/53) (2 . 18/53) (2 . 24/53) (2 . 30/53) (2 . 36/53) (2 . 42/53) (2 . 48/53) (2 . 54/53) (2 . 60/53) (2 . 66/53) (2 . 72/53) (6 . 6/53) (6 . 12/53) (6 . 18/53) (6 . 24/53) (6 . 30/53) (6 . 36/53) (6 . 42/53) (6 . 48/53) (6 . 54/53) (6 . 60/53) (6 . 66/53) (6 . 72/53) ) So where is the order? 7 key each with 24 pairs. No there are 168 (step . alteration) pairs. These are microtonal accidentals. For negative (flat) alterations, b comes first, then e, then a, then d, then g, then c, then f. A smaller flat comes before a larger flat. For positive (sharp) alterations, f comes first, followed by c g d a e b
LSR 1118 "Double bar line as system start" currently unapproved
To the author of said snippet
lsr.di.unimi.it/LSR/Item?u=1=1118
Thanks for your snippet.
Though, wouldn't it be much more elegant (and shorter) to get rid of
the stencil-override by setting `systemStartDelimiter` and simply
adjusting some other stuff?
Leading to:
\version "2.18.2"
\layout {
\context {
\Score
\override SystemStartBar.thickness = 1.8
}
\context {
\StaffGroup
\override Clef.X-extent = #'(-0.4 . 0)
\override SystemStartBar.padding = -0.65
systemStartDelimiter = #'SystemStartBar
}
}
\new StaffGroup <<
{ c'1 }
{ c'1 }
>/>/
Best,
Harm
Well, yes, of course. Please do this!
Thanks,
Jean
Re: how to move a clef horizontally
Folks,
How about: [... very elegant solution ...]
While Harm's solution is great, I'm under the impression that it
shouldn't be needed, i.e., that LilyPond's behaviour classifies as a
bug. I tried to boil the example down to its essentials:
\version "2.20.0"
\new PianoStaff
<<
\new Staff = "upper" {
e''4 \clef bass f
}
\new Staff = "lower" {
\clef bass
c16 e' \change Staff = "upper" g' c''
\change Staff = "lower"
d,4
}
>>
Also, compare:
\version "2.20.0"
\new PianoStaff
<<
\new Staff = "upper" {
\clef bass
e4*3/4 \clef violin s4*1/4 f
}
\new Staff = "lower" {
\clef bass
c16 e \change Staff = "upper" g c''
\change Staff = "lower"
d,4
}
>>
What do you think?
Lukas
It clearly qualifies as a bug to me. It seems to happen whenever a
\change Staff occurs at the same musical moment as a clef or key change.
\version "2.21.80"
<<
\new Staff <<
{
c''4
\clef treble
4
}
\\
{
g'8 8
\change Staff = "lower"
}
>>
\new Staff = "lower" { s2 }
>>
Note that if you comment out the note just after the clef, i.e.
\version "2.21.80"
<<
\new Staff <<
{
c''4
\clef treble
}
\\
{
g'8 8
\change Staff = "lower"
}
>>
\new Staff = "lower" { s2 }
>>
the output gets particularly bad. Yet, I think that is another bug,
probably reminiscent of
https://gitlab.com/lilypond/lilypond/-/issues/4084, because it
disappears if the \clef is no longer played during another note:
\version "2.21.80"
<<
\new Staff <<
{
c''4
\clef treble
}
\\
{
g'8 8
\change Staff = "lower"
}
>>
\new Staff = "lower" { s4 4 }
>>
Best,
Jean
LSR 1118 "Double bar line as system start" currently unapproved
To the author of said snippet
lsr.di.unimi.it/LSR/Item?u=1=1118
Thanks for your snippet.
Though, wouldn't it be much more elegant (and shorter) to get rid of
the stencil-override by setting `systemStartDelimiter` and simply
adjusting some other stuff?
Leading to:
\version "2.18.2"
\layout {
\context {
\Score
\override SystemStartBar.thickness = 1.8
}
\context {
\StaffGroup
\override Clef.X-extent = #'(-0.4 . 0)
\override SystemStartBar.padding = -0.65
systemStartDelimiter = #'SystemStartBar
}
}
\new StaffGroup <<
{ c'1 }
{ c'1 }
>>
Best,
Harm
