Re: Core dump in version 2.25.7 (regression)

Opened https://gitlab.com/lilypond/lilypond/-/issues/6654 . Thanks, Jean signature.asc Description: This is a digitally signed message part

Core dump in version 2.25.7 (regression)

Hi, The following non-minimum example results in a core dump, when I process it using 2.25.7 in Linux, it doesn't crash with 2.24.2. I've attempted to cut it down to a smaller example, but as soon as I comment out some lines from partI, it doesn't crash. As you can guess, the eq

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)

. 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 regression. > > > > Does e

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

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 po

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

rmal staff' so >> from my pov this is a regression. > > Does either of these suit your purpose? [...] The whole issue probably warrants an improvement of the documentation, helping users in the transition to the new syntax. Grant, assuming that Dan's code in his last reply f

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

y been able to use the > gregorian divisions on a 'normal staff' so from my pov this is a regression. > Does either of these suit your purpose? \version "2.24.1" \include "gregorian.ly" music = \fixed c' { \key b \minor e8[ g] e~ e[ d~] d4 \divisioMinima

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

y pov this is a regression. Adding \with \EnableGregorianDivisiones fixes things except for finalis which just disappears and never gets rendered. (this may be unsupported but it used to work.) so with new information from dan \include "gregorian.ly" \new Staff \with {\EnableG

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: script stack order regression

Werner LEMBERG writes: >>> I don't think LilyPond guarantees a particular order of events >>> occuring at the same moment, but I agree that wrapping them should >>> not change the order. An issue has been created to track this >> >> But the re

Re: script stack order regression

>> I don't think LilyPond guarantees a particular order of events >> occuring at the same moment, but I agree that wrapping them should >> not change the order. An issue has been created to track this > > But the regression test script-stack-order.ly is quite exp

Re: script stack order regression

Kevin Barry wrote: I don't think LilyPond guarantees a particular order of events occuring at the same moment, but I agree that wrapping them should not change the order. An issue has been created to track this Thanks. But the regression test script-stack-order.ly is quite explicit

Re: script stack order regression

On Sat, Mar 13, 2021 at 05:19:49PM +0100, Robin Bannister wrote: > Hallo there > > I noticed this while trying to make an MWE for a different problem. > > Maybe it counts as a limitation rather than a bug? Hi Robin, Thank you for the report. I don't think LilyPond guarantees a particular order

script stack order regression

Hallo there I noticed this while trying to make an MWE for a different problem. Maybe it counts as a limitation rather than a bug? Cheers, Robin % MWE for post-event ordering via event-function and wrapper \markup #(lilypond-version) ts-first-second = #(define-event-function () () #{ -"1st

Re: Possible regression with changing time-signatures and order of input

Thomas Morley writes: > Am Mi., 29. Juli 2020 um 23:39 Uhr schrieb Thomas Morley > : >> >> Am Mi., 29. Juli 2020 um 23:37 Uhr schrieb Thomas Morley >> : >> > >> > Hi, >> > >> > this just popped up in the german forum: >> > >> > The two scores below return different output since 2.20.0. (see >> >

Re: Possible regression with changing time-signatures and order of input

Am Mi., 29. Juli 2020 um 23:39 Uhr schrieb Thomas Morley : > > Am Mi., 29. Juli 2020 um 23:37 Uhr schrieb Thomas Morley > : > > > > Hi, > > > > this just popped up in the german forum: > > > > The two scores below return different output since 2.20.0. (see > > attached) and warnings/errors are emit

Re: Possible regression with changing time-signatures and order of input

Am Mi., 29. Juli 2020 um 23:37 Uhr schrieb Thomas Morley : > > Hi, > > this just popped up in the german forum: > > The two scores below return different output since 2.20.0. (see > attached) and warnings/errors are emitted for the first score: > warning: barcheck failed at: 1/4 > R1 > > programm

Possible regression with changing time-signatures and order of input

Hi, this just popped up in the german forum: The two scores below return different output since 2.20.0. (see attached) and warnings/errors are emitted for the first score: warning: barcheck failed at: 1/4 R1 programming error: Multi_measure_rest::get_rods (): I am not spanned! With 2.18.2 it'

Re: regression: assertion

Hello, On 27/12/2019 19:19, lilyp...@de-wolff.org wrote: > Code below works fine when run under windows in lilypond 2.18.2 > However when running in 2.19.83, or in 2.21.0 (version end November) an > assertion is thrown: > > File: > /home/jaap/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.

regression: assertion

Code below works fine when run under windows in lilypond 2.18.2 However when running in 2.19.83, or in 2.21.0 (version end November) an assertion is thrown: File: /home/jaap/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-master /lily/page-breaking.cc, Line 1052 Expression: my_index ==

Re: Regression: 2.19.61 doesn't handle melisma properly with multiple voices

e voice in question is in a > polyphonic passage*, they do, which is a regression: 2.18 handles this > correctly. > [...] Further info: I was able to work around this by using \lyricsto instead of \addlyrics. But it’s still a big. > -- Marnen Laibow-Koser mar...@marnen.org http://

Regression: 2.19.61 doesn't handle melisma properly with multiple voices

Hi everyone! I've just run across a bug in 2.19.61. Normally when lyrics are set to a voice with slurs, syllables don't get assigned to the second and subsequent notes in a slur. But in 2.19.61, *if the voice in question is in a polyphonic passage*, they do, which is a regression: 2.

Re: Regression bug: Assertion error in 2.19.83

ug in 2.19.83 that's a regression against 2.18. Compiling with 2.19.83 gives GNU LilyPond 2.19.83 Processing `bug.ly' Parsing... Interpreting music... Preprocessing graphical objects...lilypond: /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/

Re: Regression bug: Assertion error in 2.19.83

g16:64 | % Very similar pattern that doesn't trigger the bug: d16 d16:64 e16 e16:64 fis16 fis16:64 g16 g16:64 | }   /Mats On 2019-10-19 21:10, Mats Bengtsson wrote: Hi, The following example illustrates a bug in 2.19.83 that's a regression against 2.18. Compiling with 2.19.83 giv

Regression bug: Assertion error in 2.19.83

Hi, The following example illustrates a bug in 2.19.83 that's a regression against 2.18. Compiling with 2.19.83 gives GNU LilyPond 2.19.83 Processing `bug.ly' Parsing... Interpreting music... Preprocessing graphical objects...lilypond: /home/gub/NewGub/gub/target/linux-64/sr

Re: Possible regression with box-markup/rounded-box-markup

2018-04-16 1:03 GMT+02:00 Torsten Hämmerle : > I've now started #5307:Skyline Refinements (Rounded Boxes and Rotated > Ellipses) > > It also takes care of rotation issues (both boxes and ellipses) and even > produces skylines with rounded cor

Re: Possible regression with box-markup/rounded-box-markup

I've now started #5307:Skyline Refinements (Rounded Boxes and Rotated Ellipses) It also takes care of rotation issues (both boxes and ellipses) and even produces skylines with rounded corners. Special case: no rotation, small corner radiu

Re: Possible regression with box-markup/rounded-box-markup

the skyline of any line or box with rounded corners, and there are piles of them. After all, a skyline should closely encompass the object and padding should be done exculsively by, well, padding. But in any case, I'll have a closer look, run some regression tests and, ideally will even try to

Re: Possible regression with box-markup/rounded-box-markup

2018-03-28 22:43 GMT+02:00 Torsten Hämmerle : > Yes, and your terrible example looks like > > > > in LilyDev with my slight corrections applied. > Seems OK to me. Indeed, the image looks fine. I really hope there's no impa

Re: Possible regression with box-markup/rounded-box-markup

Yes, and your terrible example looks like in LilyDev with my slight corrections applied. Seems OK to me. Cheerio, Torsten -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html _

Re: Possible regression with box-markup/rounded-box-markup

Hi again, 2018-03-28 21:09 GMT+02:00 Torsten Hämmerle : > In any case, the additional space around the \rounded-box is proportional to > the corner-radius. > If you set corner-radius to 0, there's no gap anymore. As the corner-radius > increases, so does the gap. Setting corner-radius zero gives

Re: Possible regression with box-markup/rounded-box-markup

Hi Harm, I think I've got it... You are perfectly right, there is a slight inconsistency in lily/stencil-integral.cc C++ code. (I just have to get it completely right, still experimenting a bit...): The C++ code obviously confuses line thickness and blot diameter and and "corrects" (i.e. enlarge

Re: Possible regression with box-markup/rounded-box-markup

2018-03-28 21:09 GMT+02:00 Torsten Hämmerle : > In any case, the additional space around the \rounded-box is proportional to > the corner-radius. > If you set corner-radius to 0, there's no gap anymore. As the corner-radius > increases, so does the gap. > > I think it's the rounded-box-stencil's di

Re: Possible regression with box-markup/rounded-box-markup

In any case, the additional space around the \rounded-box is proportional to the corner-radius. If you set corner-radius to 0, there's no gap anymore. As the corner-radius increases, so does the gap. I think it's the rounded-box-stencil's dimensions: when explicitly setting them to xext/yext, ever

Possible regression with box-markup/rounded-box-markup

The gap from a box-markup and a rounded-box-markup to the Staff differs for unknown reason. \version "2.18.2" %% up to current master { c''^\markup \box 1 c''^\markup \rounded-box 1 c''_\markup \box 1 c''_\markup \rounded-box 1 } 2.16.2 and before return same gap. Regresion? Attached i

Re: regression: point-and-click no longer includes absolute path

Mark Knoop writes: >>> The point-and-click link in the resulting pdf is relative: >>> textedit://testpaths.ly:9:2:3 - and therefore doesn't work. >> >>Hm, the PDF you attached *does* give an absolute link, but: > > Yes, sorry, testing with different versions and attached the wrong one. > See atta

Re: regression: point-and-click no longer includes absolute path

>> The point-and-click link in the resulting pdf is relative: >> textedit://testpaths.ly:9:2:3 - and therefore doesn't work. > >Hm, the PDF you attached *does* give an absolute link, but: Yes, sorry, testing with different versions and attached the wrong one. See attached pdf now. >Indeed, this i

Re: regression: point-and-click no longer includes absolute path

Am 17.05.2016 um 09:31 schrieb Mark Knoop: > Thanks Urs, > > At 09:37 on 13 May 2016, Urs Liska wrote: >> Which version of LilyPond and what Linux exactly do you use (2.19.40 >> binary release?)? > lilypond 2.19.40, on Fedora 23, distro build (lilypond-2.19.40-1.fc23) > > However I have just down

Re: regression: point-and-click no longer includes absolute path

Thanks Urs, At 09:37 on 13 May 2016, Urs Liska wrote: >Which version of LilyPond and what Linux exactly do you use (2.19.40 >binary release?)? lilypond 2.19.40, on Fedora 23, distro build (lilypond-2.19.40-1.fc23) However I have just downloaded 2.19.41 binary release from lilypond.org and see th

Re: regression: point-and-click no longer includes absolute path

Which version of LilyPond and what Linux exactly do you use (2.19.40 binary release?)? Compiling your example with LilyPond built from current master gives me: Starting lilypond 2.19.42 [Untitled]... Processing `/tmp/frescobaldi-dW8ldh/tmpTuF3xf/document.ly' Parsing... /tmp/frescobaldi-dW8ldh/tmp

regression: point-and-click no longer includes absolute path

The commit below has broken point-and-click links for me on Linux. Embedded paths are now relative rather than absolute. It seems the assumption in the commit message that an absolute path is always returned is incorrect, as can be seen with the following example. Reverting scm/output-ps.scm fixes

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

> Thanks - although your patch was based on a file location from an > *installation* of LP not the source (if you see what I mean?). Oh right - I just debugged the installation. Thats the beauty of script languages. :-) > That confused me for a moment. It seemed to let me patch the file in > the

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Tobias, On 27/02/16 15:19, Tobias Kretschmar wrote: Hello Werner Please resend the patch using diff option `-u'. I have found a switch in WinDiff that sounds like -u option. Please find attached a new patch. Is it right? Tobias ___ bug-lilypond m

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

>> Please resend the patch using diff option `-u'. > > I have found a switch in WinDiff that sounds like -u option. Please > find attached a new patch. Is it right? Yes, it is, thanks. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org htt

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Hello Werner > Please resend the patch using diff option `-u'. I have found a switch in WinDiff that sounds like -u option. Please find attached a new patch. Is it right? Tobias --- C:/Program Files (x86)/LilyPond-2.19.36/usr/share/lilypond/current/python/musicxml.orig.py Sun Jan 31 17:37:00

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

> I also attached a patch that works for my purposes. At least you can > confirm the 42a-MultiVoice-TwoVoicesOnStaff-Lyrics test. Please resend the patch using diff option `-u'. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://li

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Hello James, > >>> 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in > >>> voice 2? Subsequently the lyrics of voice 2 is moved one note to the > >>> right. > > I cannot comment on the intention of the example, so I guess either the > lyric placement is correct but there shou

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Hello Tobias, On 26/02/16 07:41, Tobias Kretschmar wrote: Hello James, 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2? Subsequently the lyrics of voice 2 is moved one note to the right. This might be a mistake in the xml file. Sorry if I could not make me cl

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Hello James, >> 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in >> voice 2? Subsequently the lyrics of voice 2 is moved one note to the >> right. >> > This might be a mistake in the xml file. Sorry if I could not make me clear. What I meant to say is, that musicxml2ly skip

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

James Lowe gnu.org> writes: > > Is it intended that MusicXML regression test > > 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in > > voice 2? Subsequently the lyrics of voice 2 is moved one note to the right. > This might be a mistake in the xml

Re: MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

Hello Tobias, On 23/02/16 15:13, Tobias Kretschmar wrote: I'm not top posting. Hello Is it intended that MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2? Subsequently the lyrics of voice 2 is moved one note to the right. Re

MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2

> I'm not top posting. Hello Is it intended that MusicXML regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml is missing the first note in voice 2? Subsequently the lyrics of voice 2 is moved one note to the right. Regards, Tobias ___

Re: NullVoice and Ambitus crash (regression?)

On Wed, Feb 25, 2015 at 3:29 PM, Simon Albrecht wrote: > > > if in Lily 2.19.15 NullVoice is \consisted with the "Ambitus_engraver", > there are (for one NullVoice) three instances of > > > programming error: tried to get a translation for something that is no > child of mine > > which cause the p

NullVoice and Ambitus crash (regression?)

Hello, if in Lily 2.19.15 NullVoice is \consisted with the "Ambitus_engraver", there are (for one NullVoice) three instances of programming error: tried to get a translation for something that is no child of mine which cause the program to abort. This used to work in v2.19.8. Minimal exam

Re: Regression: music function applied to a bass figure causes syntax error

Le 6 avr. 2014 à 16:48, David Kastrup a écrit : > Nicolas Sceaux writes: > >> Hi, >> >> With lilypond 2.19.3, applying a music function to a bass figure >> causes a syntax error. At least until 2.17.24 (I have not tested >> later versions), that was not the case. > > http://code.google.com/p

Re: Regression: music function applied to a bass figure causes syntax error

Nicolas Sceaux writes: > Hi, > > With lilypond 2.19.3, applying a music function to a bass figure > causes a syntax error. At least until 2.17.24 (I have not tested > later versions), that was not the case. http://code.google.com/p/lilypond/issues/detail?id=3898> -- David Kastrup ___

Re: Regression: music function applied to a bass figure causes syntax error

David Kastrup writes: > David Kastrup writes: > >> Nicolas Sceaux writes: >> >>> With lilypond 2.19.3, applying a music function to a bass figure >>> causes a syntax error. At least until 2.17.24 (I have not tested >>> later versions), that was not the case. >> >> 2.19.0 is ok, > > I have to t

Re: Regression: music function applied to a bass figure causes syntaxerror

"David Kastrup" wrote in message news:87wqf2zqaq@fencepost.gnu.org... Nicolas Sceaux writes: > With lilypond 2.19.3, applying a music function to a bass figure > causes a syntax error. At least until 2.17.24 (I have not tested > later versions), that was not the case. 2.19.0 is ok,

Re: Regression: music function applied to a bass figure causes syntax error

On 06.04.2014, at 12:49, David Kastrup wrote: > Nicolas Sceaux writes: > >> With lilypond 2.19.3, applying a music function to a bass figure >> causes a syntax error. At least until 2.17.24 (I have not tested >> later versions), that was not the case. > > 2.19.0 is ok, so I suspect 2.18 woul

Re: Regression: music function applied to a bass figure causes syntax error

David Kastrup writes: > Nicolas Sceaux writes: > >> With lilypond 2.19.3, applying a music function to a bass figure >> causes a syntax error. At least until 2.17.24 (I have not tested >> later versions), that was not the case. > > 2.19.0 is ok, I have to take that back. A binary of mine iden

Re: Regression: music function applied to a bass figure causes syntax error

Nicolas Sceaux writes: > With lilypond 2.19.3, applying a music function to a bass figure > causes a syntax error. At least until 2.17.24 (I have not tested > later versions), that was not the case. 2.19.0 is ok, so I suspect 2.18 would not be affected. However, 2.18 might have a few lesser ch

Regression: music function applied to a bass figure causes syntax error

Hi, With lilypond 2.19.3, applying a music function to a bass figure causes a syntax error. At least until 2.17.24 (I have not tested later versions), that was not the case. Example: \version "2.19.3" %% Figured bass %% change a flat or sharp alteration into natural %% unless 'ancient-style op

Regression tests 'page-breaking-count*.ly' generate programming errors

Hello, There are three page-breaking-count regressions tests currently. They all generate the same errors. % .../input/regression/page-breaking-page-count1.ly \version "2.19.3" #(set-default-paper-size "a6") \book { \paper { page-count = 2} \score { {c'1 c'

Regression test 'grace-end-2.ly' generates a programming error

Hello, % .../input/regression/grace-end-2.ly \version "2.19.3" #(ly:set-option 'warning-as-error #f) { e' \acciaccatura << e'8 \\ cis' >> } --snip-- GNU LilyPond 2.19.3 Processing `grace-end-2.ly' Parsing... Interpreting music... Preprocessin

Regression test 'grace-end.ly' generates a programming error

Hello, % .../input/regression/grace-end.ly \version "2.19.3" #(ly:set-option 'warning-as-error #f) \context Voice \relative c' { c4 \grace { d16 d16 } } --snip-- GNU LilyPond 2.19.3 Processing `grace-end.ly' Parsing... Interpreting music... Preprocessing graphic

Regression test 'parenthesize-singlenotes-chords-rests.ly' generates a programming error

Hello, % .../input/regression/parenthesize-singlenotes-chords-rests.ly" \paper { ragged-right = ##t } \version "2.19.3" \relative c'' { % parentheses on single notes (with articulations), inside chord and articulation \parenthesize c \parenthesize c-. <\par

Regression test 'arpeggio-no-staff-symbol.ly' generates a programming error

Hello % ../input/regression/arpeggio-no-staff-symbol.ly \version "2.19.3" \new Staff \with { \remove "Staff_symbol_engraver" } \relative c' { \arpeggio } --snip--- produces:GNU LilyPond 2.19.3 Processing `arpeggio-no-staff-symbol.ly' Parsing... Interpreting mu

Re: nice 2.18 regression tests

On Dec 31, 2013, at 7:52 AM, Keith OHara wrote: > 'lesNereides.ly' collides again. The collision is with a cross-staff slur, > which LilyPond has never so far included in collision-avoidance between > systems. However, we did have 'horizontal-padding' settings so that the > 'm.g.' from the

nice 2.18 regression tests

Not a bug, but probably of interest here. For some reason I compared the regression tests between 2.16 and 2.18, up through lyrics-tenor-clef.ly before I got tired. Many look a bit nicer. For most changes I recognized the cause. Some non-obvious changes: ‘ambitus-with-ligature.ly’ lost

Re: Left aligning lyrics regression in 2.17

Roeland van den Bos gmail.com> writes: > % in version 2.16.2 the lyrics are left aligned by > adding extra spacing width > % in version 2.17.97 this does not work anymore I added a reduced version to the bug tracker http://code.google.com/p/lilypond/issues/detail?id=3761 You can restore the

Left aligning lyrics regression in 2.17

> I'm not top posting. version "2.17.97" \layout { indent = 0 ragged-right = ##t \context { \Score \remove "Bar_number_engraver" \override LeftEdge #'extra-spacing-height = #'(-inf.0 . +inf.0) } } #(define (align-lyrics grob grob-origin context) (if (memq 'lyric-syllable-interf

Re: context-mods / self-alignment-interface problem (regression?)

Am 03.12.2013 16:12, schrieb David Kastrup: I have no problem using annotate = #(define-music-function (parser location properties item) (ly:context-mod? symbol-list-or-music?) ;; annotates a musical object for use with lilypond-doc (display (ly:get-context-mods properties)) ; Dummy coloring #{

Re: context-mods / self-alignment-interface problem (regression?)

Urs Liska writes: > Hi, > > when running this code > > annotate = > > #(define-music-function (parser location properties item) > > (ly:context-mod? symbol-list-or-music?) > > ;; annotates a musical object for use with lilypond-doc > > (display (ly:get-context-mods properties)) > > ; Dummy colori

context-mods / self-alignment-interface problem (regression?)

Hi, when running this code annotate = #(define-music-function (parser location properties item) (ly:context-mod? symbol-list-or-music?) ;; annotates a musical object for use with lilypond-doc (display (ly:get-context-mods properties)) ; Dummy coloring #{ \once \tweak color #magenta #item

Re: lyricmode regression

Vik Reykja writes: > On Sun, Sep 22, 2013 at 8:31 PM, David Kastrup wrote: > >> Vik Reykja writes: >> >> > On Sun, Sep 22, 2013 at 6:39 PM, David Kastrup wrote: >> > >> >> David Kastrup writes: >> >> >> >> Thanks for the report. >> >> >> > >> > And thank you for your quick response. This doe

Re: broken links onhttp://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top

On 13-10-11 06:29 AM, Phil Holmes wrote: "pls" wrote in message news:c776a8a5-e4e2-42df-ad77-99051726b...@gmx.de... Hey all, in case this is not a known issue: all examples on http://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top lead to a 404 Not Found

Re: broken links onhttp://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top

"pls" wrote in message news:c776a8a5-e4e2-42df-ad77-99051726b...@gmx.de... Hey all, in case this is not a known issue: all examples on http://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top lead to a 404 Not Found Error. It says e.g. The requested

broken links on http://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top

Hey all, in case this is not a known issue: all examples on http://www.lilypond.org/doc/v2.17/input/regression/musicxml/collated-files#top lead to a 404 Not Found Error. It says e.g. The requested URL /doc/v2.17/input/regression/musicxml/19/lily-4197d4c2.xml was not found on this server

Re: lyricmode regression

Vik Reykja writes: > On Sun, Sep 22, 2013 at 8:31 PM, David Kastrup wrote: >> > >> > programming error: no solution found for Bezier intersection >> > continuing, cross fingers >> > >> > in my actual file. >> >> Unlikely. That's probably a different bug. > > It is indeed. Commit 7d3d28de0ce6e2

Re: lyricmode regression

On Sun, Sep 22, 2013 at 8:31 PM, David Kastrup wrote: > Vik Reykja writes: > > > On Sun, Sep 22, 2013 at 6:39 PM, David Kastrup wrote: > > > >> David Kastrup writes: > >> > >> Thanks for the report. > >> > > > > And thank you for your quick response. This does indeed fix my minimal > > exampl

Re: lyricmode regression

Vik Reykja writes: > On Sun, Sep 22, 2013 at 6:39 PM, David Kastrup wrote: > >> David Kastrup writes: >> >> > Vik Reykja writes: >> > >> >> Upgrading from 2.14.2 (Ubuntu 12.10) to 2.17.27 (git head) in order to >> try >> >> something, I noticed my music was broken. Here is a minimal example >

Re: lyricmode regression

On Sun, Sep 22, 2013 at 6:39 PM, David Kastrup wrote: > David Kastrup writes: > > > Vik Reykja writes: > > > >> Upgrading from 2.14.2 (Ubuntu 12.10) to 2.17.27 (git head) in order to > try > >> something, I noticed my music was broken. Here is a minimal example > >> illustrating the problem: >

Re: lyricmode regression

David Kastrup writes: > Vik Reykja writes: > >> Upgrading from 2.14.2 (Ubuntu 12.10) to 2.17.27 (git head) in order to try >> something, I noticed my music was broken. Here is a minimal example >> illustrating the problem: >> >> \new Lyrics \lyricmode { \skip 1.*3 } > > The lexer apparently thi

Re: lyricmode regression

Vik Reykja writes: > Upgrading from 2.14.2 (Ubuntu 12.10) to 2.17.27 (git head) in order to try > something, I noticed my music was broken. Here is a minimal example > illustrating the problem: > > \new Lyrics \lyricmode { \skip 1.*3 } > > which now gives > > /home/vik/minimal.ly:1:34: error: no

lyricmode regression

oject well enough to know how strict you are about introducing those. I would prefer for it to be fixed and regression tests added, but it at least needs to be in some kind of release notes. I would like to have included a patch to fix it, but I am not very wise in the ways of lexer

Re: Regression for paper size setting?

"Phil Holmes" writes: > "David Kastrup" wrote in message > news:87r4hllt82@fencepost.gnu.org... >> >> Ah ok, I just saw that the file triggering the problem is much more >> recent than I thought it would be: >> >> commit b4fe233aec83383bd2e6b6170fca67a31a8c492d >> Author: Phil Holmes >> +\

Re: Regression for paper size setting?

"David Kastrup" wrote in message news:87r4hllt82@fencepost.gnu.org... Keith OHara writes: David Kastrup gnu.org> writes: I think that our current code balks at setting paper sizes like "A4" rather than "a4". Can someone check with older versions? At least since 2.12, LilyPond has r

Re: Regression for paper size setting?

Keith OHara writes: > David Kastrup gnu.org> writes: > >> I think that our current code balks at setting paper sizes like "A4" >> rather than "a4". Can someone check with older versions? >> > > At least since 2.12, LilyPond has responded > warning: Unknown paper size: A4 > but continued to p

Re: Regression for paper size setting?

David Kastrup gnu.org> writes: > I think that our current code balks at setting paper sizes like "A4" > rather than "a4". Can someone check with older versions? > At least since 2.12, LilyPond has responded warning: Unknown paper size: A4 but continued to process the input. _

Regression for paper size setting?

I think that our current code balks at setting paper sizes like "A4" rather than "a4". Can someone check with older versions? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Page labels: regression in 2.17

2013/4/28 Nicolas Sceaux > Hi, > > When a page label is refered to inside some music, the corresponding page > is not > found. The delayed evaluation happens before the label pages are collected. > > Compare: > > http://lilypond.org/doc/v2.17/input/regression/collat

Page labels: regression in 2.17

Hi, When a page label is refered to inside some music, the corresponding page is not found. The delayed evaluation happens before the label pages are collected. Compare: http://lilypond.org/doc/v2.17/input/regression/collated-files.html#page-label.ly which reads "A (page ?)", with

Re: Fwd: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof

Reinhold Kainhofer kainhofer.com> writes: > According to David's response (which I will also forward from -devel), > the problem is that the addQuote (and the part-combiner) use a Global > context from the moment the part-combiner is initialized rather than > when addQuote is called. Thus the Glo

Fwd: Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof

Original Message Subject: Re: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof Date: Sat, 28 Jul 2012 07:32:20 +0200 From: David Kastrup Organization: Organization?!? To: lilypond-de...@gnu.org Reinhold Kainhofer writes: > The text span

Fwd: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof

bject: scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof Date: Thu, 26 Jul 2012 20:10:13 +0200 From: Reinhold Kainhofer Organization: FAM, TU Wien To: LilyPond Development The text spanner implemented in scheme (which is also used as a basis for David's measure counte

Re: Beaming regression 2.15.39 compared to 2.14.2

am, as project manager, has confirmed this should not be classed as a regression. Phil Holmes has identified the change to beaming that is most likely responsible. http://code.google.com/p/lilypond/issues/detail?id=2246 which is titled "beaming in 3/4 - a setting to not beam 3 eights agains

Re: TupletNumber regression

On Tue, May 22, 2012 at 08:19:11PM +0200, m...@apollinemike.com wrote: > On 22 mai 2012, at 19:17, JD Duncan wrote: > > > The following snippet shows a measure where the TupletNumber has > > good placement in 2.14.2 but strange placement in 2.15.38. > > > > JD > > > > Dear JD, > > In LilyPond

  1   2   3   4   5   6   7   8   >