Re: Incorrect bar line with voltas, \repeatTie and lyrics

Hi Ole, On 31.12.24 15:54, Ole V. Villumsen wrote: As I think I said, given the attitude with which I was met in this particular case I am not going to this time. from my perspective it seems like you were reading to much into the lines written by Timothy. I’m going to blame the shortcomings

Re: Incorrect bar line with voltas, \repeatTie and lyrics

Thanks, Simon, for your constructive contribution in this situation. It’s interesting that you’ve been able to reduce the example that I thought minimal so much further. I still don’t see how I would have been able to without an unreasonably great effort. Yes, I might have made other requests,

Re: Incorrect bar line with voltas, \repeatTie and lyrics

Hi Ole, it’s OK that you’re dissatisfied with the way LilyPond handles this example, but we do not have the resources or policy to turn every such example coming to the bug list into a constructive issue report ourselves. For one thing, your example is not actually minimal. You are convinced

Re: Incorrect bar line with voltas, \repeatTie and lyrics

This could have been a long and interesting discussion that could at least have lead to noticeable improvements of input validation in Lilypond and of the documentation linked to. However I do not want to discuss with someone who puts a good-faith bug report prepared according to all the guideli

Re: Incorrect bar line with voltas, \repeatTie and lyrics

: warning: barcheck failed at: 7/8             \volta 2 { g2\repeatTie e2                                        | } Two, it now incorrectly sets a bar line between the two notes in the second volta, close to the first note, and no bar line at the end of the piece. I suspect that the bar line is

Incorrect bar line with voltas, \repeatTie and lyrics

\repeatTie e2                                        | } Two, it now incorrectly sets a bar line between the two notes in the second volta, close to the first note, and no bar line at the end of the piece. I suspect that the bar line is set 1/8 into the second volta. This seems to agree with its

Re: Staff lines do not extend to key/time signature after last bar line

> If a key or time signature appears at the very end of a voice, right > after a barline the staff lines do not extend beyond that barline. > The key or time signature seems to be floating in empty space. > Doesn't look nice. [...] Thanks for the report. I've tried to locate this problem in ou

Staff lines do not extend to key/time signature after last bar line

If a key or time signature appears at the very end of a voice, right after a barline the staff lines do not extend beyond that barline. The key or time signature seems to be floating in empty space. Doesn't look nice. Earlier versions of LilyPond up to 2.19.15 looked fine though. score: \

Re: \staffHighlight with tempo indication and whole bar rest incorrect

Hello Thomas, sorry for the late reply. > "\staffHighlight" does not work properly if there is a tempo marking > and a whole bar rest in the first bar. This is now registered in our bug database. https://gitlab.com/lilypond/lilypond/-/issues/6730 Werner

\staffHighlight with tempo indication and whole bar rest incorrect

Hello, "\staffHighlight" does not work properly if there is a tempo marking and a whole bar rest in the first bar. In this case, the marking only starts at the end of the tempo marking. See attached file "staffHighlight.ly" Regards Thomas % The marking should start

Re: Chord names collide with span bar

>> Since I don't have experience with chord names I ask users who need >> this feature to check whether it works as expected in general. > > It works like a charm in my source! Thanks for researching this. :-) https://gitlab.com/lilypond/lilypond/-/merge_requests/2281 Werner

Re: Chord names collide with span bar

On Thu, Mar 21, 2024 at 2:30 PM Werner LEMBERG wrote: > > I think I've found the real fix for the problem. Suddenly remembering > that we already have the `Span_bar_stub_engraver` to handle exactly > such situations I wondered why it works for lyrics but not for chord > names. Comparing the def

Re: Chord names collide with span bar

>>> I remembered that you can add the Bar_engraver to ChordNames. >>> Making them transparent so they do not visually interfere with the >>> SpanBar, but they still take up space. >> >> Nice! This begs the question whether we have a real bug or 'just' >> insufficient documentation... > > I was t

Re: Chord names collide with span bar

On Wed, Mar 20, 2024 at 8:54 AM Aaron Hill wrote: > Oh, I think I found another option: > > > \version "2.25.13" > > #(ly:set-option 'debug-skylines #t) > \layout { >\context { \Score > \override NonMusicalPaperColumn.show-horizontal-skylines = ##t >} >\context { \ChordNames

Re: Chord names collide with span bar

On 2024-03-20 9:01 am, Werner LEMBERG wrote: I remembered that you can add the Bar_engraver to ChordNames. Making them transparent so they do not visually interfere with the SpanBar, but they still take up space. Nice! This begs the question whether we have a real bug or 'just' insufficient do

Re: Chord names collide with span bar

> Oh, I think I found another option: > > > \version "2.25.13" > > #(ly:set-option 'debug-skylines #t) > \layout { > \context { \Score > \override NonMusicalPaperColumn.show-horizontal-skylines = ##t > } > \context { \ChordNames > \consists "Bar_engraver" > \override BarLine.

Re: Chord names collide with span bar

On 2024-03-20 8:14 am, Knute Snortum wrote: Ah, I see this is just for debugging. Thank you. Your solution helps when put into my bigger project. Some -- but not all -- of the bars are now wide enough. Oh, I think I found another option: \version "2.25.13" #(ly:set-option 'debug-sky

Re: Chord names collide with span bar

On Wed, Mar 20, 2024 at 8:01 AM Aaron Hill wrote: > ly:separation-item::print no longer exists, as all grobs support the > properties show-horizontal-skylines and show-vertical-skylines. > > So, swap out that \override with: > > >\override NonMusicalPaperColumn.show-horizontal-skylines =

Re: Chord names collide with span bar

On 2024-03-20 8:07 am, Jean Abou Samra wrote: Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit : Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > Your solution requires version 2.22 and I'm using 2.24 > (with the \alternative command so it's not easy to change) T

Re: Chord names collide with span bar

On Wed, Mar 20, 2024 at 8:07 AM Jean Abou Samra wrote: > Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit : > > Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > > > Your solution requires version 2.22 and I'm using 2.24 > > > (with the \alternative command so it's

Re: Chord names collide with span bar

Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit : > Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > > Your solution requires version 2.22 and I'm using 2.24 > > (with the \alternative command so it's not easy to change) > > The old \alternative syntax is still sup

Re: Chord names collide with span bar

r solution convert to 2.24 (no changes) I get an error executing the file: /home/foo/bar/chords-bar-line.ly:7:9 <0>: error: Guile signaled an error for the expression beginning here # ly:separation-item::print Unbound variable: ly:separation-item::print ly:separation-item::print no longe

Re: Chord names collide with span bar

Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > Your solution requires version 2.22 and I'm using 2.24 > (with the \alternative command so it's not easy to change) The old \alternative syntax is still supported in 2.24. signature.asc Description: This is a digitally signed mess

Re: Chord names collide with span bar

l in whatever score you are working on as a stopgap. Aaron, Thank you so much for this fix and for entering an issue! There is just one thing that is a problem for me. Your solution requires version 2.22 and I'm using 2.24 (with the \alternative command so it's not easy to change). W

Re: Chord names collide with span bar

>> Aaron, please file an issue, referring to this e-mail thread. > > First time creating an issue, so hopefully this is up to snuff. Thanks a lot! > Added: https://gitlab.com/lilypond/lilypond/-/issues/6703 > > By the by, I do not appear to have permissions for setting labels, > but I think thi

Re: Chord names collide with span bar

On 2024-03-20 1:45 am, Werner LEMBERG wrote: In some situations, chord names collide with the span bar of a Grand or Piano Staff. Here is an example: [...] [...] Still sounds like a defect of some sort, as the default behavior should probably be handling things. Aaron, please file an issue

Re: Chord names collide with span bar

>> In some situations, chord names collide with the span bar of a >> Grand or Piano Staff. Here is an example: [...] > > [...] Still sounds like a defect of some sort, as the default > behavior should probably be handling things. Aaron, please file an issue, referring

Re: Chord names collide with span bar

On 2024-03-19 2:29 pm, Knute Snortum wrote: I ran into something today -- it's not quite a bug; more of an "ugly." In some situations, chord names collide with the span bar of a Grand or Piano Staff. Here is an example: \version "2.25.13" \score { \new Gra

Chord names collide with span bar

I ran into something today -- it's not quite a bug; more of an "ugly." In some situations, chord names collide with the span bar of a Grand or Piano Staff. Here is an example: \version "2.25.13" \score { \new GrandStaff << \new Staff \relative { c'

bar-extents in magnified staves and staff groups

1. It might be nice to have the systemStartDelimiter (or whatever it's called) of a StaffGroup extend out to the bar-extent . Here is an example with exaggerated bar extents to make the point clear : \new StaffGroup << \new DrumStaff \with { \override StaffSymbol.line-

Re: Dashed bar lines fail requirements at some sizes

Hi, thanks for your report. Apart from the last point (see below), it's mostly caused by: commit cff90246a32186f450bab1f8cd415d320b8c0cf2 Author: Thomas Morley Date: Wed Oct 4 16:18:30 2023 +0200 Dashed bar lines do not stick out Give BarLine a little less, SpanBar a little

Dashed bar lines fail requirements at some sizes

A few potential bugs to consider. Much appreciation! % 1. Dashed bar lines fail requirement at some sizes: % > The dashes in a dashed bar line covers staff lines exactly. Dashed bar % > lines between staves start and end on a half dash precisely. \version "2.24.3" #(set-glob

Re: Double bar not at end of staff with scaled joined staves in 2.24.1 and higher

On Sun, 23 Jul 2023 at 19:28, Heiko Schill wrote: > > Hi all, > > when compiling the attached snippet, the double bar in the first (scaled) > staff of two joined staffs is not at the end of the line but shifted a > little to the left. The smaller the scale factor is, the further

Double bar not at end of staff with scaled joined staves in 2.24.1 and higher

Hi all, when compiling the attached snippet, the double bar in the first (scaled) staff of two joined staffs is not at the end of the line but shifted a little to the left. The smaller the scale factor is, the further to the left the double bar ends up. This happens with lilypond 2.24.1 and

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

On Mar 29, 2023, at 18:04, Grant Diffey wrote: > > I do wonder if there's a way to make the horizontal spacing.. 'nicer' but > it's certainly functional for all my purposes as is. My biggest questions about this use case surround the layout changes that are baked into gregorian.ly, for example

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

Werner, I think the remaining question is how common is this as a style? (I find many examples in books but few online :) and does that warrant adding an additional staff type? I'm very happy with the outcome here. My thanks to all involved, particularly Dan. I do wonder if there's a way to mak

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

Thankyou dan Either of those would be acceptable.. \version "2.24.1" \include "gregorian.ly" ancientmusic = { \clef "vaticana-do3" \[ d8 \pes \melisma f \melismaEnd \] d \[ d \flexa \melisma c \melismaEnd \] f g \[ f \flexa \melisma g \pes a \melismaEnd \] a4 \finalis \[ e8 \pes \meli

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

>> However none of the staff types dan suggested will do what I could >> previously do. Gregorian divisiones not supported on modern staffs >> is a reasonable closure for this as a bug however I've previously >> been able to use the gregorian divisions on a 'normal staff' so >> from my pov this i

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

On Mar 28, 2023, at 16:36, Grant Diffey wrote: > > Sure, > > However none of the staff types dan suggested will do what I could previously > do. Gregorian divisiones not supported on modern staffs is a reasonable > closure for this as a bug however I've previously been able to use the > gre

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

Sure, However none of the staff types dan suggested will do what I could previously do. Gregorian divisiones not supported on modern staffs is a reasonable closure for this as a bug however I've previously been able to use the gregorian divisions on a 'normal staff' so from my pov this is a regr

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

Le mercredi 29 mars 2023 à 07:18 +1100, Grant Diffey a écrit : > To clarify I'm transcribing vaticana using a 'modern' staff and beaming for > melisma none of the staff types support modern beamed 8th notes. this is the > convention in the church music I'm scoring (vaticana original) + modern >

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

On Mar 28, 2023, at 03:02, Jean Abou Samra wrote: > Le mardi 28 mars 2023 à 12:54 +1100, Grant Diffey a écrit : >> The following example: >> \include "gregorian.ly" >> { c' \divisioMaior d' \finalis } >> Renders 'correctly' in 2.22 (using hacklily) >> and incorrectly on my debian machine with Li

Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

Le mardi 28 mars 2023 à 12:54 +1100, Grant Diffey a écrit : > The following example: > > \include "gregorian.ly" >   { c' \divisioMaior d' \finalis } > > Renders 'correctly' in 2.22 (using hacklily) > and incorrectly on my debian machine with Lilypond 2.24 Dan? signature.asc Description: T

Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)

The following example: \include "gregorian.ly" { c' \divisioMaior d' \finalis } Renders 'correctly' in 2.22 (using hacklily) [image: image.png] and incorrectly on my debian machine with Lilypond 2.24 [image: image.png]

Re: Interaction of slurs and bar checks

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.

Interaction of slurs and bar checks

) 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 )

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

Le 23/11/2022 à 18:00, Mats Bengtsson a écrit : On 2022-11-22 19:30, Silas S. Brown wrote: Hm.  Josquin des Prez is sort of borderline here... Hi, yes that has notes going across barlines.  But wouldn't that cause "barcheck failed" warnings anyway, even a

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

On 2022-11-22 19:30, Silas S. Brown wrote: Hm. Josquin des Prez is sort of borderline here... Hi, yes that has notes going across barlines. But wouldn't that cause "barcheck failed" warnings anyway, even apart from the notes using a multiplier? (e.g. the

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

from the > notes using a multiplier? Why would you put bar checks in the middle of a note? > (e.g. the dotted minim already goes across a barline) Sure, but not across a bar check unless you put one there. > I can see why we wouldn't want those warnings to be errors (at least

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

> Hm. Josquin des Prez is sort of borderline here... > Hi, yes that has notes going across barlines. But wouldn't that cause "barcheck failed" warnings anyway, even apart from the notes using a multiplier? (e.g. the dotted minim already goes across a barlin

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

nce for "simile" triplets entered as >> durations with *2/3 multiplier. > > OK, then we'd have to say "it's a warning only if the resulting > note is longer than the bar". Can the existing bar-check code > be modified to take these multipliers into acco

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

ns with *2/3 multiplier. OK, then we'd have to say "it's a warning only if the resulting note is longer than the bar". Can the existing bar-check code be modified to take these multipliers into account? Thanks. Silas -- Silas S. Brown http://ssb22.user.srcf.net __

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

On 11/21/22 05:36, Silas S. Brown wrote: % In 2/4 time, I want to write 4 bars rest % followed by 2 minims (half-notes). % The bar numbering comes out differently: \version "2.22.2" \relative c' { \set Score.skipBars = ##t \time 2/4 R2*4 c ^"This is bar 5" \break d ^&q

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

"Silas S. Brown" writes: > On Mon, Nov 21, 2022 at 12:54:45PM +, Mark Knoop wrote: >> Hi Silas, >> Remember that in LilyPond, durations carry over from the previous event >> if not explicitly specified. This includes the duration of multimeasure >> rests. You have already found the solution -

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

;2" after an "R2*4" by mistake. There was no visual indication that anything was wrong, apart from the bar numbers, which I didn't realise I had to check, until I found in rehearsal that the numbers being used by the conductor did not match with my part. Since I can't think

Re: 2.22: unexpected bar numbering when using * lengths and skipBars

Hi Silas, At 12:36 on 21 Nov 2022, Silas S. Brown wrote: > % In 2/4 time, I want to write 4 bars rest > % followed by 2 minims (half-notes). > % The bar numbering comes out differently: > \version "2.22.2" > \relative c' { > \set Score.skipBars = ##t > \tim

2.22: unexpected bar numbering when using * lengths and skipBars

% In 2/4 time, I want to write 4 bars rest % followed by 2 minims (half-notes). % The bar numbering comes out differently: \version "2.22.2" \relative c' { \set Score.skipBars = ##t \time 2/4 R2*4 c ^"This is bar 5" \break d ^"I think this should be bar 6 but it i

Re: Full bar rest printed incorrectly after time signature change

th = #(ly:make-moment 2/4) << { a4( gis) } \\ { b,2 } >> \unset Timing.measureLength \bar "||" \tempo "Presto di molto" \time 2/4 R2 } \new Staff { \clef F s4*6 d2 dis4^\p c2 r4 r8 e16 gis^\f } >> Cheers, Pierre Le ven.

Re: Full bar rest printed incorrectly after time signature change

Friday, October 28th, 2022 at 17:29, Kevin Barry wrote: > On Fri, Oct 28, 2022 at 03:15:48PM +, Ole V. Villumsen wrote: > > > > If you use \partial at the beginning of a score it treats the resulting > > > duration as the length of music preceding the fi

Re: Full bar rest printed incorrectly after time signature change

On Fri, Oct 28, 2022 at 03:15:48PM +, Ole V. Villumsen wrote: > > If you use \partial at the beginning of a score it treats the resulting > > duration as the length of music preceding the first bar. This is how bar > > numbering generally works for upbeats/anacrusis. >

Re: Full bar rest printed incorrectly after time signature change

g from Lilypond: "mid-measure time > signature without \partial". Hi Ole, I'm not sure why you think the NR says to use "\partial 8*0", but the following should work for your CPE Bach example. { \time 3/4 \partial 4 c'4 | c'4 4 4 | 4

Re: Full bar rest printed incorrectly after time signature change

PS. See also: https://lilypond.org/doc/v2.22/Documentation/notation/special-rhythmic-concerns#time-administration ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

: Fantasia C major H.291, bars > 71 - 72.) > ... This should do the trick: { \time 3/4 \set Timing.measureLength = #(ly:make-moment 2/4) % bar 1 f'4 f' \time 2/4 %\partial 8*0 % Required, NR 1.2.3 R2 | % Prints incorrectly R2 | % Prints corr

Re: Full bar rest printed incorrectly after time signature change

Hi Kevin, Thank you for your input. > If you use \partial at the beginning of a score it treats the resulting > duration as the length of music preceding the first bar. This is how bar > numbering generally works for upbeats/anacrusis. Obviously confirmed. > Partial expects t

Re: Full bar rest printed incorrectly after time signature change

On Fri, Oct 28, 2022 at 01:04:38PM +, Ole V. Villumsen via bug-lilypond wrote: > The incomplete 3/4 measure still has not got bar number 1. For most > purposes we can probably live with that. Setting the current bar > number explicitly to 1 did not help (apparently upbeats don’t

Re: Full bar rest printed incorrectly after time signature change

Hi Paul, that’s an interesting suggestion. The following can be considered working: \time 3/4 \partial 4*2 % defines an upbeat holding two crotchets f'4 f' | \time 2/4 \set Score.currentBarNumber = #2 R2 | R2 | The incomplete 3/4 measure still has not got bar number 1. For most purpos

Re: Full bar rest printed incorrectly after time signature change

Is this not you want: \version "2.22.2" {   \time 3/4   \partial 4*2  % defines bar as holding two crotchets   f'4 f' |   \time 2/4   R2 |   R2 |  } Paul From: Ole V. Villumsen via bug-lilypond To: "bug-lilypond@gnu.org" Sent: 28/10/2022 10

Re: Full bar rest printed incorrectly after time signature change

o since I explicitly state that the upbeat > is zero (\partial 8*0), I expect a new full 2/2 measure to begin right there. > When I put anything else in the new bar, it also works the way I expect. I > tried r2, and I tried f'4 f'. > > Best regards, Ole > > Sent

Re: Full bar rest printed incorrectly after time signature change

: So since I explicitly state that the upbeat is zero (\partial 8*0), I expect a new full 2/2 measure to begin right there. When I put anything else in the new bar, it also works the way I expect. I tried r2, and I tried f'4 f'. Best regards, Ole Sent with [Proton Mail](https://pr

Re: Full bar rest printed incorrectly after time signature change

There are only two crotchets between your 3/4 signature and your 2/4 signature - what do you expect to happen? Paul From: Ole V. Villumsen via bug-lilypond To: "bug-lilypond@gnu.org" Sent: 28/10/2022 10:52 Subject: Full bar rest printed incorrectly after time

Full bar rest printed incorrectly after time signature change

first full bar rest (R2) is printed % incorrectly as a 2 bars rest between the previous and the current bar. % The rest comes immediately after a mid-measure time signature change % with zero upbeat. % The second full bar rest is printed correctly. % The first one should be printed in the same way

Re: Ancient bar lines

On Feb 14, 2021, at 23:26, Jürgen Reuter wrote: > > Hi Dan and all others, > > yes, the second, more compact / dense version definitely looks _much_ better! > I would be happy if you could commit your change! https://gitlab.com/lilypond/lilypond/-/issues/6098 _

Re: Ancient bar lines

f the first system produced for regression test input/[1]breathing-sign-ancient.ly and included the relevant portion of the input below. The current version of master adds some horizontal space after every fourth note. It happens because there are transparent "|" bar lines

Ancient bar lines

e are transparent "|" bar lines there. It is easy to eliminate those spaces by changing the default bar line to "" in gregorian.ly, and the other attached image shows the result. I am willing to create a ticket and submit the change for review, but I don't have the backgroun

Bar number too close to volta bracket

\version "2.20.0" { \set Score.barNumberVisibility = #(every-nth-bar-number-visible 2) \override Score.BarNumber.break-visibility = #end-of-line-invisible \repeat volta 2 R1 \alternative { R1 R1 } } With master, the bar number is placed up against the volta bracket. With 2

Re: Bar number with chord name

On 4/19/20, 9:07 AM, "Aidan O Connor" wrote: Hi, Thanks for that info. The workaround makes sense. But the behavior seems a little inconsistent. If the cord names are removed the bar numbers appear above the staff, but below the fret diagram. Is the fret diagram not considered p

Re: Bar number with chord name

Hi, Thanks for that workaround, it works well. Regards Aidan From: Xavier Scheuer Sent: Sunday 19 April 2020 05:03 To: Aidan O Connor Cc: bug-lilypond@gnu.org Subject: Re: Bar number with chord name On Sat, 18 Apr 2020 at 19:49, Aidan O Connor mailto:a

Re: Bar number with chord name

Hi, Thanks for that info. The workaround makes sense. But the behavior seems a little inconsistent. If the cord names are removed the bar numbers appear above the staff, but below the fret diagram. Is the fret diagram not considered part of the score system? Thanks Aidan

Re: Bar number with chord name

On 4/18/20, Aidan O Connor wrote: > When chord names are included, the bar numbers are positioned above the > chord name. Greetings, Well, yes and no. They are positioned above the whole *system* (the Score context), of which the ChordNames context is a part. So whilst that’s certainly

Re: Bar number with chord name

On Sat, 18 Apr 2020 at 19:49, Aidan O Connor wrote: > > When chord names are included, the bar numbers are positioned above the chord name. This is particularly noticeable if a fret diagram is also included. The bar numbers should be positioned immediately above the staff. > In this exa

Bar number with chord name

When chord names are included, the bar numbers are positioned above the chord name. This is particularly noticeable if a fret diagram is also included. The bar numbers should be positioned immediately above the staff. In this example, the chord name forces the second measure bar number out of

Re: DynamicText artificially extends bar size when within a StaffGroup

I'm going to go out on a limb and say I think the “fix“ was worse than the problem. I've got cases where it doesn't even need a barline to degenerate into crazy spacing! %% dynamic-span-exhibit-two.ly \version "2.19.81" \new StaffGroup { a'16-\tweak DynamicText.X-offset #-1 -#(make-dynami

Re: DynamicText artificially extends bar size when within a StaffGroup

Le dim. 19 janv. 2020 à 00:25, David Kastrup a écrit : > This wants improvement. Basically we probably need a better way to > figure out whether we are in the middle of a StaffGroup with spanbars? > I assume that would clear the simple case of the dynamic that spans across the line without cros

Re: DynamicText artificially extends bar size when within a StaffGroup

usly, I'll stand in and say I disagree with the premise, given my > context, but now at least I see what the change's aim was. > Could we find some (more) compromise here? > It seems right now, the dynamic will refuse to cross a virtual bar line, > even if it causes a layout

Re: DynamicText artificially extends bar size when within a StaffGroup

hat the change's aim was. Could we find some (more) compromise here? It seems right now, the dynamic will refuse to cross a virtual bar line, even if it causes a layout stretch, even if there's no barline to cross at all (single staff within a group; last staff of the group; etc). The U

Re: Midi block gives errors with bar number checks

For what it's worth, I'm one of those users who makes use of the MIDI output from LilyPond frequently, and while I have not needed to mess with bar numbers on the MIDI side, I have found it's repeat support serviceable aside from D.C./D.S. being unsupported. Unfortunately, in my

Re: Midi block gives errors with bar number checks

On Wed, 27 Nov 2019, Peter Toye wrote: I'm not sure how many LP user use the MIDI output anyway, given its restrictions. Personally, I use it for proof-reading only, so lack of repeats isn't an issue. I use MIDI output mainly for proofreading, but at occasions where I need better MIDI out

Re: Midi block gives errors with bar number checks

Carl, I've been thinking about this, and my guess is that LP uses the bar number to calculate the beat clock. And when there are repeats, MIDI bar number != engraving bar number, so it goes wrong. This is presumably why the MIDI generator in LP doesn't handle repeats, and to mak

Re: Midi block gives errors with bar number checks

From: Peter Toye Reply-To: Peter Toye Date: Tuesday, November 26, 2019 at 11:43 AM To: Carl Sorensen , "bug-lilypond@gnu.org" Subject: Re: Midi block gives errors with bar number checks Carl, I've just found the MIDI "beat clock" - 24 per crotchet. Still no bar nu

Re: Midi block gives errors with bar number checks

Carl, I've just found the MIDI "beat clock" - 24 per crotchet. Still no bar numbers though! Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Tuesday, November 26, 2019, 5:21:07 PM, Carl Sorensen wrote: > On 11/26/19, 9:24 AM, &qu

Re: Midi block gives errors with bar number checks

Dear Carl, I take this point. I don't know MIDI at all - I thought it was more to do with sound generation than score output! Why should an instrumentalist be expected to know what bar number they're playing (until the conductor says "back to bar 52")? I've just had

Re: Midi block gives errors with bar number checks

On 11/26/19, 9:24 AM, "Peter Toye" wrote: The following MWE gives bar number check errors. If you comment out the midi block they go away. Bizarre, but a definite bug IMHO. I don't think it's a bug at all. Midi files require ascending bar numbers, IIUC. You can&#

Midi block gives errors with bar number checks

The following MWE gives bar number check errors. If you comment out the midi block they go away. Bizarre, but a definite bug IMHO. Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com \version "2.19.52" \language "english" \score { \new Staff { \repeat vo

DynamicText artificially extends bar size when within a StaffGroup

, it just makes it more visible dyn = \tweak DynamicText.self-alignment-X #LEFT #(make-dynamic-script (markup #:normal-text "dynamic text shouldn't push next bar to the right")) % Occurs within a StaffGroup: \score { \new StaffGroup { r r r e''\dyn e'' e

Update on 2965: mid-bar \newSpacingSection leads to collisions

Dear folks, I hit another instance of issue 2965, which allowed me to see clearer what the core problem seems to be and to update the issue. Best, Simon ___ bug-lilypond mailing list bug-lily

bug-report: stanza wit forced \bar""\break behaves strange in Windows

\version "2.19.82" %{ strange behaviour of horizontal spacing with \set stanza in combination with \bar""\break occurs only in Windows (tested with Win7) and only with versions 2.19 (tested 2.19.80 - 2.19.82), this does *not* occur in linux or with version 2.18.2 (both l

Re: Too short crescendo mark when it is supposed to end on a note after a bar

. > > Cheers, > > Pierre > > > > > > > > > > 2018-07-08 10:12 GMT+02:00 Johannes Ammon > <mailto:j.am...@dr-ammon.de>>: > > > > Hello, > > > > when a crescendo mark is supposed to end on a note after a bar, it > en

Re: Too short crescendo mark when it is supposed to end on a note after a bar

ersion "2.18" > \relative c' { >   c4\< c\! c c-\tweak to-barline #f \< | c\! c c c\< | c c\! c c > } > > should work as you expected. > Cheers, > Pierre > > > > > 2018-07-08 10:12 GMT+02:00 Johannes Ammon <mailto:j.am...@dr-amm

Re: Too short crescendo mark when it is supposed to end on a note after a bar

c\< | c c\! c c } should work as you expected. Cheers, Pierre 2018-07-08 10:12 GMT+02:00 Johannes Ammon : > Hello, > > when a crescendo mark is supposed to end on a note after a bar, it ends > before the bar. Here an example with the resulting image in the attachment: > >

Too short crescendo mark when it is supposed to end on a note after a bar

Hello, when a crescendo mark is supposed to end on a note after a bar, it ends before the bar. Here an example with the resulting image in the attachment: \version "2.18.2" \relative c' { c4\< c\! c c\< | c\! c c c\< | c c\! c c } The second hairpin should be as long

  1   2   3   4   5   6   7   8   >