Re: defineBarLine confusion
On 2023-01-13 6:43 pm, Flaming Hakama by Elaine wrote: Looking at your example, I think the first place you are going off is that you do not define the barlines using ##t, ##f, you instead put the characters that correspond to what you want to appear in those places. #t and #f are valid in bar line definitions, as convenient short hand. See [1]: The \defineBarLine arguments specifying replacement glyphs can be set to #t to copy the mid-line glyph or #f to create no bar line. The empty string, "", yields a zero-width bar line. [1]: https://lilypond.org/doc/v2.24/Documentation/notation/bars#index-defining-bar-line -- Aaron Hill
Re: defineBarLine confusion
> From: David Zelinsky
> To: lilypond-user@gnu.org
> Cc:
> Bcc:
> Date: Fri, 13 Jan 2023 17:37:15 -0500
> Subject: Re: defineBarLine confusion
> David Zelinsky writes:
>
> > I'm trying to understand how to use defineBarLine, based on the
> > documentation in Notation Reference 1.2.5, and bar-line.scm. The
> > meaning of the "bartype" argument seems to not be exactly explained
> > anywhere, but from what is said (mostly in bar-line.scm), and a lot of
> > experimentation, I deduce that all the characters before a possible "-"
> > are taken to be names of existing barline glyph elements, and the new
> > barline glyph is the concatenation of those.
> >
> > Moreover, from the documentation, the second argument is a list of 3
> > things that define the behavior at a line break or for spanning multiple
> > staves. So I expected these to have no effect when the barline is
> > occuring in the middle of a single staff.
> >
> > However, I'm seeing some different behavior:
> >
> > \version "2.24.0"
> > \relative c'' {
> > \defineBarLine ":;|!-a" #'(#t #t #t)
> > \defineBarLine ":;|!-b" #'(#t #t #f)
> > \defineBarLine ":;|!-c" #'(#t #t "||")
> > a1 \bar ":;|!-a"
> > b1 \bar ":;|!-b"
> > c1 \bar ":;|!-c"
> > d1
> > }
> >
> >
> >
> >
> > Since this is a single staff, I expected all these to appear the same.
> > But version "b" only uses the first character of the bartype argument.
> > I don't see this documented anywhere, and can't imagine a use-case.
> >
> > Is it a bug?
> >
> >
> > -David
>
>
>
> After delving into the code in bar-line.scm, I see why this is
> happening, and I'm convinced it *is* a bug, and I can describe what I
> think is a reasonable fix. How should I best go about conveying this to
> the developers?
>
> -David
>
Here is something I wrote up for a blog post during the 2.18 days.
I am not sure if it applies to your case, but it sounds like you probably
are not yet familiar with how barlines are defined. Which is not
surprising, since they are not well documented. Which is why I created
these notes in the first place, to help myself understand how they work.
Lilypond has a conception of barlines that you may not have encountered
before: barlines may be printed differently if they are mid-line, versus
when they are at the end/beginning of a line.
This makes sense when you consider repeats as compared to non-repeat
barlines. Let's assume we have two sections with a barline in between:
either a double bar, or a start-repeat.
* If the second section starts in the middle of the line, there is just one
barline:
** For the non-repeat case, this is a double-bar line
** For the repeat case, this is the start-repeat barline.
* If the second section starts on a new line, there may be one or two
barlines:
** For the non-repeat case, you print the double bar at the end of the
line, and do not print any barline at the start of the next line.
** For the repeat case, you print the double bar at the end of the line,
and then print a start-repeat barline printed at the beginning of the next
line.
You may note that the default starting repeat barline does not print at the
beginning of the line. In order to get a repeat barline to appear at the
beginning of a piece, you need to define a new barline type.
There is a setting for what barlines appear between staves.
Now, to look at the key point of the Lilypond documentation on barlines.
http://lilypond.org/doc/v2.18/Documentation/notation/bars#bar-lines
New bar line types can be defined with \defineBarLine:
\defineBarLine bartype #'(end begin span)
Let's talk about the "bartype" argument.
* "bartype" really acts more like "mid-name". Because the "mid" is what
defines the contents of the barline when it occurs mid-line, in the same
way that "end", "begin" and "span" define the barline at the end of a line,
beginning of a line, and between staves.
* "-name" is an optional name you can choose to identify this custom
bartype. This is probably useful to distinguish two barline types that
have the same "mid" definition.
These strings "mid", "end", "begin" and "span" are composed of the possible
barline elements:
* Normal bar line "|"
* Thick bar line "."
* Dashed bar line "!"
* Dotted bar line ";"
* Repeat dots ":"
* "kievan" bar line "k"
* In-staff segno "S"
* Double bar line for use with in-staff segno "="
* Start repeat bar line with flags "["
* End repeat bar line with flags "]"
* No bar line ""
* Tick "'"
* Standalone thin double barline \bar "//"
They can be in any order, with the exception that the only valid context
for "=" is after "S".
Here are some examples of (somewhat nonsensical) bartype names:
* :.|kS='; ][!-allTheBartypeCharacters
* ...|||'''-patternOfNineBarlines
* .[-barebrace
* S|S|[:=-doubleSegnoBeginRepeat
Here is one that matches the default repeat barline, but prints at the
beginning of a piece:
\version "2.19.15"
\defineBarLine ".|:-printAtBeginning" #'("" ".|:" ".|:")
{
\bar
Re: Image width issue
Jean, Really sorry, I see your answer in the link below, thanks for all the trouble. You were a great help, thanks, Raj On 1/13/2023 3:25 PM, Jean Abou Samra wrote: Le 14/01/2023 à 00:22, Rajesh Baskar a écrit : Hi Jean, I don't think I saw your response.Here is the question again - The solution that you gave makes the 1st image match the width of the 2nd image by reducing it. Can the 2nd images width match the 1st images width by increasing it. Why not, as I said, read the response I gave to this on https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00228.html Why we need this is when there are a lot of notes hidden then this difference between the 2 images looks really bad in our app. I'm curious, could you tell more about what you're using LilyPond for in this app? Regards, Jean
Re: Image width issue
Le 14/01/2023 à 00:22, Rajesh Baskar a écrit : Hi Jean, I don't think I saw your response.Here is the question again - The solution that you gave makes the 1st image match the width of the 2nd image by reducing it. Can the 2nd images width match the 1st images width by increasing it. Why not, as I said, read the response I gave to this on https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00228.html Why we need this is when there are a lot of notes hidden then this difference between the 2 images looks really bad in our app. I'm curious, could you tell more about what you're using LilyPond for in this app? Regards, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
Le 13/01/2023 à 10:16, Werner LEMBERG a écrit : Regardless of that, it is indeed a severe bug: No need to ever align key signatures vertically, AFAIK. Simply left-align them. I have opened an issue for this: https://gitlab.com/lilypond/lilypond/-/issues/6520 OpenPGP_signature Description: OpenPGP digital signature
Re: defineBarLine confusion
Le 13/01/2023 à 23:37, David Zelinsky a écrit : How should I best go about conveying this to the developers? See https://lilypond.org/bug-reports.html Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: defineBarLine confusion
David Zelinsky writes:
> I'm trying to understand how to use defineBarLine, based on the
> documentation in Notation Reference 1.2.5, and bar-line.scm. The
> meaning of the "bartype" argument seems to not be exactly explained
> anywhere, but from what is said (mostly in bar-line.scm), and a lot of
> experimentation, I deduce that all the characters before a possible "-"
> are taken to be names of existing barline glyph elements, and the new
> barline glyph is the concatenation of those.
>
> Moreover, from the documentation, the second argument is a list of 3
> things that define the behavior at a line break or for spanning multiple
> staves. So I expected these to have no effect when the barline is
> occuring in the middle of a single staff.
>
> However, I'm seeing some different behavior:
>
> \version "2.24.0"
> \relative c'' {
> \defineBarLine ":;|!-a" #'(#t #t #t)
> \defineBarLine ":;|!-b" #'(#t #t #f)
> \defineBarLine ":;|!-c" #'(#t #t "||")
> a1 \bar ":;|!-a"
> b1 \bar ":;|!-b"
> c1 \bar ":;|!-c"
> d1
> }
>
>
>
>
> Since this is a single staff, I expected all these to appear the same.
> But version "b" only uses the first character of the bartype argument.
> I don't see this documented anywhere, and can't imagine a use-case.
>
> Is it a bug?
>
>
> -David
After delving into the code in bar-line.scm, I see why this is
happening, and I'm convinced it *is* a bug, and I can describe what I
think is a reasonable fix. How should I best go about conveying this to
the developers?
-David
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
On Fri 13 Jan 2023 at 19:30:29 (+), nitra...@posteo.net wrote: > I was talking about the first note of each measures after the Key Signature. > But you were right, it is the default spacing. > > About the distance between different accidentals, consider the example > bellow. You can see a difference between the "Reference staff" and number > "C" in the "Corrected Output". It looks like an extra space has been added > between the key cancellation and the new one. [ … ] > grob > (+ (- (interval-end (ly:grob-extent can parent X)) > (ly:grob-relative-coordinate grob parent X)) >0.7) > X > \music > } Change 0.7 to 0.1 and you can make the cancellation almost touch the new key signature, so pick your value to taste, I guess. You might need to check how a particular value behaves when staves are stretched or compressed while breaking the music into lines. (Your Reference staff has slightly different measure lengths from the Corrected output.) Cheers, David.
Re: how would one cross-reference two [or more] books?
> Turns out, ironically, that I am now having to add lots more bookparts so > that garbage doesn't build up to where it triggers a third-party GC bug on > Windows. Still waiting for that fix RSN (2.24.1++?) LilyPond 2.24.1 is planned for the end of January or early February. Whether it includes this mostly depends on whether Ivan Maidanski has released BDWGC 8.2.3 by then. Best, Jean
Re: Image width issue
Thanks Jean, really appreciate it. On 1/13/2023 12:00 PM, Jean Abou Samra wrote: Le 13 janv. 2023 à 20:54, Rajesh Baskar a écrit : Hi Jean, I would greatly appreciate if you could help me out on the below request. Did you not receive my reply on this? You can always find it in the list archives: https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00228.html
Re: how would one cross-reference two [or more] books?
(including lilypond-user) On 1/12/2023 7:01 AM, Kieren MacMillan wrote: Hi all, A very large part of my composition [and thus Lilypond engraving] career is concerned with very large, multi-format musical dramas (operas, musicals, plays-with-music, dramatic song cycles, etc.). A typical set of outputs might be: – full orchestra/band score – individual orchestra/band parts – Piano/Conductor score (reduction/arrangement) – Piano/Vocal score (a *different* reduction/arrangement) – Vocal/Choral score (reduction/arrangement) – libretto I would *love* to be able to have a note in the (e.g.) P/C score that says “This song is found on pg. 12 of the Vocal/Choral score” — at the very least at the song level, but optimally at any arbitrary point in the score (e.g., top of every page, beginning of a given section of a song, etc.). 1. What mechanism(s) would be best used to accomplish this? 2. Can it be done [relatively easily] if each of the outputs are driven from an individual .ly file, or would it really require all outputs to be coded in the same .ly file [with separate \book blocks]? Thanks! Kieren. Hi Kieren, IIUC, this sounds like the same problem as how to make an index of items across multiple books. Back in 2.22 where I was running out of 32-bit memory, I was forced to try dividing my 500+ page compilation (logically one book) into multiple books in order stay under the memory limit. I'm guessing the end of a \book throws out all of its grobs while keeping its stencils, and that releases a lot of memory. But in my work, having an index at the end was absolutely essential, and it had to cover everything as though it had been multiple \bookparts instead of multiple \books. The problem was that \page-refs into other \books always failed (they fell back to the default arg). The solution was to save the \page-ref output as stencils at the end of each \book, i.e. to resolve the \labels while you still have them. In my case, there was an index data structure that was designed to save \labels, which ordinarily would be converted into markup stencils when the index was being printed at the very end. What I did was make a function that would re-scan that index structure, resolving any stored \labels into stencils, if that hadn't already been done (i.e. if they weren't already stencils, resolve them to stencils). When it was time to print the final index, you'd test the supposed \label values to see if they were already stencils: (if (ly:stencil? label) (markup #:stencil label) (markup #:page-ref label "XXX" "?"))). Look in the attached dual-index-dev.ily (where dual meant something else: a sorted index plus a simultaneously kept unsorted index). See "% save-page-refs command" and "% index command" for the relevant code. Where things got beyond my abilities was for the parts of document that were before my explicit \books. This is demonstrated by the simple file MWEindex.ly. It has two books, labeled No.1 and No.2., with the non-book stuff before them named "Top" and the stuff after named No.3. It makes a simple index showing those four items, along with their page numbers, which did get correctly resolved outside of the two books: Exercise 0 . . . . . Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Sav1 Exercise 1 . . . . . No.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Exercise 2 . . . . . No.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Exercise 3 . . . . . No.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 No.1 does start on page 101 and No.2 does start on 201, and No.3 is technically correct as page 1. But I could not get items from Top to resolve also to page 1. Instead, it is replaced by the default value supplied as the tag argument to save-page-ref, so I could tell which invocation of save-page-refs was clobbering things. It might help to note which pdf outputs contain which parts: "Number 1" is in MWEindex.pdf "Number 2" is in MWEindex-1.pdf "Top Level", "Number 3" and the "Exercise Index" are in MWEindex-2.pdf (the last to print) Apparently the page-refs from Top are indeed added to the index data first, even though that part of the document is the last to be printed. (Expected) What was unexpected was that the \save-page-refs tagged "Sav0" was executed (or whatever the non-imperative term is) last. This left the item labeled "Top" in the index where it was found during book 1 (by the save-page-refs tagged "Sav1") which couldn't resolve it because that label was not in book 1. I didn't know how to overcome this peculiarity, other than by not indexing any items in the Top section. And I lost interest when I learned that 2.23 was 64-bit and shouldn't need division into books to keep memory in bounds. Turns out, ironically,
Re: Title font changed?
> Le 13 janv. 2023 à 20:19, b...@kummelweb.nl a écrit : > > Hi, > > Since I upgraded tot Lilypond 2.24, I noticed that the title font changed. It > looks much more like standard Times New Roman now, instead of the beautiful > Lilypond text font. (See the attached images: old.png is how it used to be, > new.png is after upgrading to 2.24.) > > I can't find anything about a change of the text font in the CHANGED page, so > I figure there should be something wrong with my install. Yes, there is. It’s a bug in Homebrew. See https://github.com/Homebrew/homebrew-core/issues/119476 Please use the binaries from lilypond.org until this is fixed. Best, Jean
Re: Title font changed?
FWIW, I just tried and with 2.24.0 mine looks just like your old.png. This is using the linux binaries downloaded from the web site. -David b...@kummelweb.nl writes: > Hi, > > Since I upgraded tot Lilypond 2.24, I noticed that the title font > changed. It looks much more like standard Times New Roman now, instead > of the beautiful Lilypond text font. (See the attached images: old.png > is how it used to be, new.png is after upgrading to 2.24.) > > I can't find anything about a change of the text font in the CHANGED > page, so I figure there should be something wrong with my install. I > installed 2.24 via Homebrew on my Mac, running macOS 13.1 > (Ventura). Before I had 2.22, not sure if I installed that via > Homebrew too. > > Where should I start searching. Couldn't find much info in the > docs. Any help would be highly appreciated! > > Best, > Bart Kummel
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
I was talking about the first note of each measures after the Key Signature.
But you were right, it is the default spacing.
About the distance between different accidentals, consider the example
bellow. You can see a difference between the "Reference staff" and number
"C" in the "Corrected Output". It looks like an extra space has been added
between the key cancellation and the new one.
---
\version "2.24.0"
music = \relative c'' {
\key a\major
a4 4 4 4
\key es\major
g4 4 4 4
\key b\major
fis4 4 4 4
\key f\minor
f4 4 4 4
}
musicCorrected = {
\override Staff.KeyCancellation.break-align-symbol = #'key-signature
\override Staff.KeySignature.X-offset =
#(lambda (grob)
(let* ((parent (ly:grob-parent grob X))
(elts (ly:grob-object parent 'elements))
(can (find (lambda (g)
(and (grob::has-interface g
'key-cancellation-interface)
(eq? (ly:grob-object g 'staff-symbol)
(ly:grob-object grob 'staff-symbol
(ly:grob-array->list elts
(when can
(ly:grob-translate-axis!
grob
(+ (- (interval-end (ly:grob-extent can parent X))
(ly:grob-relative-coordinate grob parent X))
0.7)
X
\music
}
\markup \huge "Reference"
\new Staff \music
\markup \huge "Default Output"
\new StaffGroup <<
\new Staff \with {
instrumentName = "A"
}
\transpose c a {
\music
}
\new Staff \with {
instrumentName = "B"
}
\transpose c g {
\music
}
\new Staff \with {
instrumentName = "C"
}
\music
>>
\markup \huge "Corrected output with still some differences"
\new StaffGroup <<
\new Staff \with {
instrumentName = "A"
}
\transpose c a {
\musicCorrected
}
\new Staff \with {
instrumentName = "B"
}
\transpose c g {
\musicCorrected
}
\new Staff \with {
instrumentName = "C"
}
\musicCorrected
>>
Le vendredi 13 janvier 2023 à 09:39, David Wright a écrit :
> On Fri 13 Jan 2023 at 11:58:42 (+), nitra...@posteo.net wrote:
> > Yes it is better, thank you for your fast reply. But several problems are
> > still there in my opinion:
> >
> > - The first note of the measure doesn't align with the last accidental and
> > is still too far.
>
> None of the first notes in any measure has an accidental, so I'm
> not sure what you mean.
>
> If, by the last accidental, you mean the last symbol in the key
> signature, then you certainly shouldn't place the first note in the
> measure too close to the key signature.
>
> > - I don't understand why the distance between different accidentals is
> > wider (for instance between a natural and a sharp, or between a natural
> > and a flat).
>
> Can you be specific about which symbols you're referring to: can you
> give the staff and measure number for the ones you're comparing.
>
> > Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> > > Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > > > which wasn't in the previous version.
> > > > > What previous version did you test this with? For me, the output is
> > > > > the same in 2.22 and in 2.18.2.
> > > > Regardless of that, it is indeed a severe bug: No need to ever align
> > > > key signatures vertically, AFAIK. Simply left-align them.
> > >
> > >
> > > Do you mean like this, or something else?
> > >
> > > (NB this is unreliable code, I was surprised that it even works)
> > >
> > > \version "2.24.0"
> > >
> > > music = \relative c' {
> > > \override Staff.KeyCancellation.break-align-symbol = #'key-signature
> > > \override Staff.KeySignature.X-offset =
> > > #(lambda (grob)
> > > (let* ((parent (ly:grob-parent grob X))
> > > (elts (ly:grob-object parent 'elements))
> > > (can (find (lambda (g)
> > > (and (grob::has-interface g
> > > 'key-cancellation-interface)
> > > (eq? (ly:grob-object g 'staff-symbol)
> > > (ly:grob-object grob
> > > 'staff-symbol
> > > (ly:grob-array->list elts
> > > (when can
> > > (ly:grob-translate-axis!
> > > grob
> > > (+ (- (interval-end (ly:grob-extent can parent X))
> > > (ly:grob-relative-coordinate grob parent X))
> > > 0.7)
> > > X
> > > \key es\major
> > > c d e f
> > > \key c\major
> > > c d e f
> > > \key as\major
> > > c d e f
> > > \key bes\major
> > > c d e f
> > > }
> > >
> > > \new StaffGroup <<
> > > \transpose c a {
> > > \music
> > > }
> > > \new Staff
> > > \transpose c g {
> > > \music
> > > }
> > > \new Staff
> > > \music
> > > >>
>
> Cheers,
> David.
Title font changed?
Hi, Since I upgraded tot Lilypond 2.24, I noticed that the title font changed. It looks much more like standard Times New Roman now, instead of the beautiful Lilypond text font. (See the attached images: old.png is how it used to be, new.png is after upgrading to 2.24.) I can't find anything about a change of the text font in the CHANGED page, so I figure there should be something wrong with my install. I installed 2.24 via Homebrew on my Mac, running macOS 13.1 (Ventura). Before I had 2.22, not sure if I installed that via Homebrew too. Where should I start searching. Couldn't find much info in the docs. Any help would be highly appreciated! Best, Bart Kummel
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
On Fri 13 Jan 2023 at 11:58:42 (+), nitra...@posteo.net wrote:
> Yes it is better, thank you for your fast reply. But several problems are
> still there in my opinion:
>
> - The first note of the measure doesn't align with the last accidental and
> is still too far.
None of the first notes in any measure has an accidental, so I'm
not sure what you mean.
If, by the last accidental, you mean the last symbol in the key
signature, then you certainly shouldn't place the first note in the
measure too close to the key signature.
> - I don't understand why the distance between different accidentals is
> wider (for instance between a natural and a sharp, or between a natural
> and a flat).
Can you be specific about which symbols you're referring to: can you
give the staff and measure number for the ones you're comparing.
> Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> > Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > > which wasn't in the previous version.
> > > > What previous version did you test this with? For me, the output is
> > > > the same in 2.22 and in 2.18.2.
> > > Regardless of that, it is indeed a severe bug: No need to ever align
> > > key signatures vertically, AFAIK. Simply left-align them.
> >
> >
> > Do you mean like this, or something else?
> >
> > (NB this is unreliable code, I was surprised that it even works)
> >
> > \version "2.24.0"
> >
> > music = \relative c' {
> > \override Staff.KeyCancellation.break-align-symbol = #'key-signature
> > \override Staff.KeySignature.X-offset =
> > #(lambda (grob)
> > (let* ((parent (ly:grob-parent grob X))
> > (elts (ly:grob-object parent 'elements))
> > (can (find (lambda (g)
> > (and (grob::has-interface g
> > 'key-cancellation-interface)
> > (eq? (ly:grob-object g 'staff-symbol)
> > (ly:grob-object grob 'staff-symbol
> > (ly:grob-array->list elts
> > (when can
> > (ly:grob-translate-axis!
> > grob
> > (+ (- (interval-end (ly:grob-extent can parent X))
> > (ly:grob-relative-coordinate grob parent X))
> > 0.7)
> > X
> > \key es\major
> > c d e f
> > \key c\major
> > c d e f
> > \key as\major
> > c d e f
> > \key bes\major
> > c d e f
> > }
> >
> > \new StaffGroup <<
> > \transpose c a {
> > \music
> > }
> > \new Staff
> > \transpose c g {
> > \music
> > }
> > \new Staff
> > \music
> > >>
Cheers,
David.
Re: New list admin
Le 10/01/2023 à 22:17, Jean Abou Samra a écrit : In order to increase the bus factor, I would like to nominate one or two other regulars as admins. If you feel like it, please let me know. Thanks to Mark Knoop for accepting this task. He is now a co-admin. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
Yes it is better, thank you for your fast reply. But several problems are
still there in my opinion:
- The first note of the measure doesn't align with the last accidental and
is still too far.
- I don't understand why the distance between different accidentals is
wider (for instance between a natural and a sharp, or between a natural
and a flat).
Le vendredi 13 janvier 2023 à 12:02, Jean Abou Samra a écrit :
> Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
> > > > I just discovered this huge bug in the recent release of 2.24.0
> > > > which wasn't in the previous version.
> > > What previous version did you test this with? For me, the output is
> > > the same in 2.22 and in 2.18.2.
> > Regardless of that, it is indeed a severe bug: No need to ever align
> > key signatures vertically, AFAIK. Simply left-align them.
>
>
> Do you mean like this, or something else?
>
> (NB this is unreliable code, I was surprised that it even works)
>
> \version "2.24.0"
>
> music = \relative c' {
> \override Staff.KeyCancellation.break-align-symbol = #'key-signature
> \override Staff.KeySignature.X-offset =
> #(lambda (grob)
> (let* ((parent (ly:grob-parent grob X))
> (elts (ly:grob-object parent 'elements))
> (can (find (lambda (g)
> (and (grob::has-interface g
> 'key-cancellation-interface)
> (eq? (ly:grob-object g 'staff-symbol)
> (ly:grob-object grob 'staff-symbol
> (ly:grob-array->list elts
> (when can
> (ly:grob-translate-axis!
> grob
> (+ (- (interval-end (ly:grob-extent can parent X))
> (ly:grob-relative-coordinate grob parent X))
> 0.7)
> X
> \key es\major
> c d e f
> \key c\major
> c d e f
> \key as\major
> c d e f
> \key bes\major
> c d e f
> }
>
> \new StaffGroup <<
> \transpose c a {
> \music
> }
> \new Staff
> \transpose c g {
> \music
> }
> \new Staff
> \music
> >>
>
>
Re: Image width issue
Le 12/01/2023 à 05:44, Rajesh Baskar a écrit :
Hi Jean,
Thanks for your help this works. But I have a question, this solution
makes the 1st image match the width of the 2nd image by reducing it.
Can the 2nd images width match the 1st images width by increasing it.
Try
\version "2.24.0"
\language english
RedDotMarkup = \markup \with-color "#FF" \vcenter \fontsize #-1
\musicglyph "dots.dot"
RedDot =
\tweak text \RedDotMarkup
\tweak stencil
#(grob-transformer
'stencil
(lambda (grob original)
(ly:stencil-outline
(ly:text-interface::print grob)
original)))
\tweak staff-position #0
\etc
\header {
tagline = ##f
}
\score {
\new Staff \with { \omit TimeSignature }
{
\set Staff.midiInstrument = #"acoustic grand"
\key c \major
\time 5/1
\clef bass
g,1 a,
\tweak transparent ##t %% Comment or uncomment this line
\RedDot b,
c d
\bar "||"
}
\layout {
\context {
\Score proportionalNotationDuration = #(ly:make-moment 1/2)
}
}
}
Basically, it gives the red dot note head the same width
as a normal note head (although it's not clear to me why
this is important in your use case).
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
Le 13/01/2023 à 10:16, Werner LEMBERG a écrit :
I just discovered this huge bug in the recent release of 2.24.0
which wasn't in the previous version.
What previous version did you test this with? For me, the output is
the same in 2.22 and in 2.18.2.
Regardless of that, it is indeed a severe bug: No need to ever align
key signatures vertically, AFAIK. Simply left-align them.
Do you mean like this, or something else?
(NB this is unreliable code, I was surprised that it even works)
\version "2.24.0"
music = \relative c' {
\override Staff.KeyCancellation.break-align-symbol = #'key-signature
\override Staff.KeySignature.X-offset =
#(lambda (grob)
(let* ((parent (ly:grob-parent grob X))
(elts (ly:grob-object parent 'elements))
(can (find (lambda (g)
(and (grob::has-interface g
'key-cancellation-interface)
(eq? (ly:grob-object g 'staff-symbol)
(ly:grob-object grob 'staff-symbol
(ly:grob-array->list elts
(when can
(ly:grob-translate-axis!
grob
(+ (- (interval-end (ly:grob-extent can parent X))
(ly:grob-relative-coordinate grob parent X))
0.7)
X
\key es\major
c d e f
\key c\major
c d e f
\key as\major
c d e f
\key bes\major
c d e f
}
\new StaffGroup <<
\transpose c a {
\music
}
\new Staff
\transpose c g {
\music
}
\new Staff
\music
>>
OpenPGP_signature
Description: OpenPGP digital signature
Re: Key Signature Bug in 2.24.0
You're right, I worked for my last score on 2.22.0 and the bug was there and I didn't notice it... So it isn't specific to 2.22.4 as written in the subject. Le vendredi 13 janvier 2023 à 09:17, Jean Abou Samra a écrit : > Le 13/01/2023 à 09:34, nitra...@posteo.net a écrit : > > Hi all, > > > > I just discovered this huge bug in the recent release of 2.24.0 which > > wasn't in the previous version. > > > What previous version did you test this with? For me, the output is the same > in 2.22 and in 2.18.2. > > Best, > Jean
Re: Key Signature Bug in 2.24.0,Re: Key Signature Bug in 2.24.0
>> I just discovered this huge bug in the recent release of 2.24.0 >> which wasn't in the previous version. > > What previous version did you test this with? For me, the output is > the same in 2.22 and in 2.18.2. Regardless of that, it is indeed a severe bug: No need to ever align key signatures vertically, AFAIK. Simply left-align them. Werner
Re: Key Signature Bug in 2.24.0
Le 13/01/2023 à 09:34, nitra...@posteo.net a écrit : Hi all, I just discovered this huge bug in the recent release of 2.24.0 which wasn't in the previous version. What previous version did you test this with? For me, the output is the same in 2.22 and in 2.18.2. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Key Signature Bug in 2.24.0
Hi all,
I just discovered this huge bug in the recent release of 2.24.0 which
wasn't in the previous version. Placement of key signatures on multiple
staves with transposed instrument behaves very poorly. Consider this
example :
\version "2.24.0"
music = \relative c' {
\key es\major
c d e f
\key c\major
c d e f
\key as\major
c d e f
\key bes\major
c d e f
}
\new StaffGroup <<
\transpose c a {
\music
}
\new Staff
\transpose c g {
\music
}
\new Staff
\music
>>
