Re: Lilypond 2.23.0 crashes on layout
> This statement seems a little bit strange to me. I didn't think we had a
> lilypond editing app on Linux -- only on Windows and MacOS. How are you
> using lilypond when it is "not told to lay out"? Are you using
> Frescobaldi? Are you using Denemo? Are you using Emacs? I would be
> surprised if Frescobaldi or Emacs had anything to do with the issue,
> because both just call the lilypond executable. But I think it's good to
> understand your use case completely.
I use vim or kate, and I meant omitting \layout{} from the .ly script, sorry
for confusing wordings. I am not a native English speaker, and I sometimes
over-complicate by mistake, especially when it comes to words related to
music.
--
Arusekk
signature.asc
Description: This is a digitally signed message part.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
Am Mittwoch, dem 17.02.2021 um 18:16 +0100 schrieb Jonas Hahnfeld via bug-lilypond: > Am Mittwoch, dem 17.02.2021 um 00:00 +0100 schrieb Arusekk: > > W dniu 16.02.2021 o 18:33, Jonas Hahnfeld pisze: > > > Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet), > > > so you'll definitely see worse performance (mostly slower startup) and > > > might run into occasional issues, like this one. Guile 1.8 should be > > > the safer choice for now (if you still have it in Gentoo). > > I tried to track back the moment the issue was introduced, but then > > found out that guile 2.x has been supported for two versions only, so I > > stopped digging. Good to know. > > > That said, I've seen this issue before during my tests with Guile 2.2 > > > (Translators being collected while still referenced somewhere), but > > > never had a stack trace to investigate. So it's already great to have > > > that, but do I read this correctly that you can reliably reproduce the > > > issue on your system? I'm asking because I can't on mine (Arch Linux) > > > and in fact, your file works just fine for me. So finding out how to > > > trigger this kind of bugs more reliably would be a huge step. > > On my box lilypond crashes every single time I command it to produce > > PDFs (never does if not told to lay out), so I think I can provide much > > help, maybe core files, or recorded execution from GDB (never tried to > > do it before, though). > > Okay, that's good for testing the fix (even though I've managed to > reproduce the report from ASan). > > > > Regarding AddressSanitizer, did you just compile LilyPond with it or > > > all dependencies? I didn't attempt so far because I thought it wouldn't > > > work, but maybe I should try? > > > > I just set CFLAGS='-fsanitize=address -g' and > > LDFLAGS='-fsanitize=address' before configuring lilypond, and installed > > the debug symbols for guile, so that AddressSanitizer could resolve > > function names from it. ASAN wiki suggests to mainly compile executables > > with it, because it does not support sanitized libraries used with not > > sanitized executables (or it does, but requires preloading it manually). > > Ok, makes sense. I guess I confused it with MemorySanitizer then. > > > But maybe sanitizing some library too would help additionally? I could > > try it if you want, but sanitizing guile might break[1] (I have not > > tried). Gentoo gives extreme flexibility as to managing compile-time > > options, while handling the burden of building everything one thing at a > > time, so this does not pose any problem for me (I don't recommend > > setting up a Gentoo VM just for tests, unless you are patient, since > > building lilypond and deps from a base system takes at least an hour). > > It's not needed right now, I think I understand the problem at hand, > see https://gitlab.com/lilypond/lilypond/-/issues/6100 Maybe my plan > for fixing it works, let's see ️ Patch up at https://gitlab.com/lilypond/lilypond/-/merge_requests/655 , this makes the given example work under Asan on my system. It would be great if you could test on your end (as far as I understand, you already compiled master?). The second interesting question is of course if that was the only bug or whether there are other issues lurking around. Unfortunately I can't just run all regression tests with the instrumented version because it reports errors during garbage collection after some time... Jonas signature.asc Description: This is a digitally signed message part ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
On 2/16/21, 4:00 PM, "Arusekk" wrote: On my box lilypond crashes every single time I command it to produce PDFs (never does if not told to lay out), so I think I can provide much help, maybe core files, or recorded execution from GDB (never tried to do it before, though). This statement seems a little bit strange to me. I didn't think we had a lilypond editing app on Linux -- only on Windows and MacOS. How are you using lilypond when it is "not told to lay out"? Are you using Frescobaldi? Are you using Denemo? Are you using Emacs? I would be surprised if Frescobaldi or Emacs had anything to do with the issue, because both just call the lilypond executable. But I think it's good to understand your use case completely. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
Am Mittwoch, dem 17.02.2021 um 00:00 +0100 schrieb Arusekk: > W dniu 16.02.2021 o 18:33, Jonas Hahnfeld pisze: > > Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet), > > so you'll definitely see worse performance (mostly slower startup) and > > might run into occasional issues, like this one. Guile 1.8 should be > > the safer choice for now (if you still have it in Gentoo). > I tried to track back the moment the issue was introduced, but then > found out that guile 2.x has been supported for two versions only, so I > stopped digging. Good to know. > > That said, I've seen this issue before during my tests with Guile 2.2 > > (Translators being collected while still referenced somewhere), but > > never had a stack trace to investigate. So it's already great to have > > that, but do I read this correctly that you can reliably reproduce the > > issue on your system? I'm asking because I can't on mine (Arch Linux) > > and in fact, your file works just fine for me. So finding out how to > > trigger this kind of bugs more reliably would be a huge step. > On my box lilypond crashes every single time I command it to produce > PDFs (never does if not told to lay out), so I think I can provide much > help, maybe core files, or recorded execution from GDB (never tried to > do it before, though). Okay, that's good for testing the fix (even though I've managed to reproduce the report from ASan). > > Regarding AddressSanitizer, did you just compile LilyPond with it or > > all dependencies? I didn't attempt so far because I thought it wouldn't > > work, but maybe I should try? > > I just set CFLAGS='-fsanitize=address -g' and > LDFLAGS='-fsanitize=address' before configuring lilypond, and installed > the debug symbols for guile, so that AddressSanitizer could resolve > function names from it. ASAN wiki suggests to mainly compile executables > with it, because it does not support sanitized libraries used with not > sanitized executables (or it does, but requires preloading it manually). Ok, makes sense. I guess I confused it with MemorySanitizer then. > But maybe sanitizing some library too would help additionally? I could > try it if you want, but sanitizing guile might break[1] (I have not > tried). Gentoo gives extreme flexibility as to managing compile-time > options, while handling the burden of building everything one thing at a > time, so this does not pose any problem for me (I don't recommend > setting up a Gentoo VM just for tests, unless you are patient, since > building lilypond and deps from a base system takes at least an hour). It's not needed right now, I think I understand the problem at hand, see https://gitlab.com/lilypond/lilypond/-/issues/6100 Maybe my plan for fixing it works, let's see ️ Jonas > > (It could of course be an issue in one of the libraries, especially the > > stack trace in Pango looks odd, but it's equally possible that it's a > > heap corruption bug that may show in the least expected places...) > > (These heap bugs are the worst...) > signature.asc Description: This is a digitally signed message part ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
W dniu 16.02.2021 o 18:33, Jonas Hahnfeld pisze: Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet), so you'll definitely see worse performance (mostly slower startup) and might run into occasional issues, like this one. Guile 1.8 should be the safer choice for now (if you still have it in Gentoo). I tried to track back the moment the issue was introduced, but then found out that guile 2.x has been supported for two versions only, so I stopped digging. Good to know. That said, I've seen this issue before during my tests with Guile 2.2 (Translators being collected while still referenced somewhere), but never had a stack trace to investigate. So it's already great to have that, but do I read this correctly that you can reliably reproduce the issue on your system? I'm asking because I can't on mine (Arch Linux) and in fact, your file works just fine for me. So finding out how to trigger this kind of bugs more reliably would be a huge step. On my box lilypond crashes every single time I command it to produce PDFs (never does if not told to lay out), so I think I can provide much help, maybe core files, or recorded execution from GDB (never tried to do it before, though). Regarding AddressSanitizer, did you just compile LilyPond with it or all dependencies? I didn't attempt so far because I thought it wouldn't work, but maybe I should try? I just set CFLAGS='-fsanitize=address -g' and LDFLAGS='-fsanitize=address' before configuring lilypond, and installed the debug symbols for guile, so that AddressSanitizer could resolve function names from it. ASAN wiki suggests to mainly compile executables with it, because it does not support sanitized libraries used with not sanitized executables (or it does, but requires preloading it manually). But maybe sanitizing some library too would help additionally? I could try it if you want, but sanitizing guile might break[1] (I have not tried). Gentoo gives extreme flexibility as to managing compile-time options, while handling the burden of building everything one thing at a time, so this does not pose any problem for me (I don't recommend setting up a Gentoo VM just for tests, unless you are patient, since building lilypond and deps from a base system takes at least an hour). (It could of course be an issue in one of the libraries, especially the stack trace in Pango looks odd, but it's equally possible that it's a heap corruption bug that may show in the least expected places...) (These heap bugs are the worst...) -- Arusekk [1]: https://github.com/hannob/asantoo/blob/add80838689755e74a6c1ca793c49b9dd9c50fcb/sys-devel/asantoo-base/files/package.env-asantoo#L12 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
Am Dienstag, dem 16.02.2021 um 15:44 +0100 schrieb Arusekk:
> Hello lilypond crew!
>
> Reporting the bug here, since I saw on the bug link that you prefer mail
> over GitLab issues.
>
> When trying to process any file with \layout{} directive, lilypond
> crashes (Segmentation fault / address not mapped).
>
> I was able to reproduce it on current git master
> (2c9361d3d2d9e9bdfca626d01076c94fb81e2e88) as well.
>
> My distro: Gentoo Linux
>
> Installed (possibly relevant) library versions:
>
> [IP-] [ ] dev-scheme/guile-2.2.7:12/2.2-1
>
> [IP-] [ ] x11-libs/pango-1.42.4-r2:0
>
> [IP-] [ ] dev-libs/boehm-gc-8.0.4:0
Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet),
so you'll definitely see worse performance (mostly slower startup) and
might run into occasional issues, like this one. Guile 1.8 should be
the safer choice for now (if you still have it in Gentoo).
> typescript.txt contains colored output (made with `script` utility,
> contains ANSI escapes, view best with cat or less -R) from lilypond
> being run under AddressSanitizer, which suggests that there is a
> use-after-free bug, while processing the example from snk6.ly; it also
> fails to process files as simple as `\score{c \layout{}}`, though
> providing arguably less helpful, but distinctly different output
> (attached as basic.txt).
That said, I've seen this issue before during my tests with Guile 2.2
(Translators being collected while still referenced somewhere), but
never had a stack trace to investigate. So it's already great to have
that, but do I read this correctly that you can reliably reproduce the
issue on your system? I'm asking because I can't on mine (Arch Linux)
and in fact, your file works just fine for me. So finding out how to
trigger this kind of bugs more reliably would be a huge step.
Regarding AddressSanitizer, did you just compile LilyPond with it or
all dependencies? I didn't attempt so far because I thought it wouldn't
work, but maybe I should try?
Jonas
>
> I was not able to create such a minimal input file that would trigger
> the helpful trace.
>
> Off-topic, I believe I transcribed the piece to sound pretty accurately,
>
> but I have not seen the layout yet (because of the bug), so please don't
> tell me that it renders ugly.
>
> Million thanks for such an awesome piece of software anyway :)
>
> Please let me know if you need more info, or if the bug should be
> reported to one of the libraries instead.
(It could of course be an issue in one of the libraries, especially the
stack trace in Pango looks odd, but it's equally possible that it's a
heap corruption bug that may show in the least expected places...)
signature.asc
Description: This is a digitally signed message part
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond 2.23.0 crashes on layout
Hello lilypond crew!
Reporting the bug here, since I saw on the bug link that you prefer mail
over GitLab issues.
When trying to process any file with \layout{} directive, lilypond
crashes (Segmentation fault / address not mapped).
I was able to reproduce it on current git master
(2c9361d3d2d9e9bdfca626d01076c94fb81e2e88) as well.
My distro: Gentoo Linux
Installed (possibly relevant) library versions:
[IP-] [ ] dev-scheme/guile-2.2.7:12/2.2-1
[IP-] [ ] x11-libs/pango-1.42.4-r2:0
[IP-] [ ] dev-libs/boehm-gc-8.0.4:0
typescript.txt contains colored output (made with `script` utility,
contains ANSI escapes, view best with cat or less -R) from lilypond
being run under AddressSanitizer, which suggests that there is a
use-after-free bug, while processing the example from snk6.ly; it also
fails to process files as simple as `\score{c \layout{}}`, though
providing arguably less helpful, but distinctly different output
(attached as basic.txt).
I was not able to create such a minimal input file that would trigger
the helpful trace.
Off-topic, I believe I transcribed the piece to sound pretty accurately,
but I have not seen the layout yet (because of the bug), so please don't
tell me that it renders ugly.
Million thanks for such an awesome piece of software anyway :)
Please let me know if you need more info, or if the bug should be
reported to one of the libraries instead.
--
Arusekk
\version "2.14.0"
signa = {
\time 4/4
\tempo 4 = 144
\key cis \minor
}
ini = \relative c'' {
<< {
cis2\fff bis |
cis
} \\ {
dis,2\fff e |
dis
} >>
}
inii = \relative c'' {
e,4\ gis
}
dro = \relative c'' {
cis'8\f b a gis |
}
drond = \relative c'' {
cis8 b a gis |
}
ref = \relative c'' {
cis2 e8 cis\staccato cis\staccato cis\staccato |
cis gis'\staccato gis\staccato gis\staccato gis4
}
refr = \relative c'' {
e8 dis |
}
reff = \relative c'' {
cis4\staccato cis'\staccato cis,\staccato cis'\staccato |
}
refe = \relative c'' {
\reff |
cis8 cis'\staccato cis\staccato cis\staccato
}
refcd = \relative c'' {
cis'2 |
}
refbg = \relative c'' {
f'4.\mf e16 d e4 c |
d4. c16 bes c4 a |
bes4. a16 g a4 f |
e a g8 f e f |
d2 e4 c |
r4 f'4 e8 d c4 |
d c a c |
d2.. a16 c |
d4 d a8 g f4 |
r e f e8 a16 c |
d4. a16 c d4. a16 c |
d1 |
}
strsolo = \relative c'' {
e8\mf dis fis e gis fis a gis |
fis gis e dis e gis dis gis |
cis, gis cis dis e gis, dis' e |
cis gis cis gis cis gis gis'4 |
}
versea = \relative c' {
e4\mf\> fis8 dis~dis e~e cis |
}
verseb = \relative c' {
r8\mp dis8~dis bis~bis gis~gis gis |
}
versec = \relative c' {
r8\mp b'8~b cis~cis4 r4 |
}
refA = \relative c'' {
r4 a4 r a |
r a r f8 e |
r4 d'4 r d |
a8 a a4 a a8 bes |
r4 a4 r a |
r a r f8 e |
r4 d'4 r d |
a8 a a4 a a8 bes |
}
bri = \relative c'' {
cis8\ff cis bis bis
}
bria = \relative c'' {
cis8 cis cis cis |
}
brib = \relative c'' {
cis8 cis gis gis
}
endung = \relative c'' {
a'8 gis fis gis fis e fis e |
dis e dis cis dis bis cis r |
}
\score {
<<
\new Staff {
\signa
\clef treble
\relative c'' {
\set Staff.midiInstrument = #"acoustic grand"
% gpno
\ini \inii |
\ini \dro |
\ini \inii |
\ini \drond |
\ini \inii |
\ini \drond | % ref end
\ini \inii |
\ini \drond | % violin solo end
\ini \inii |
\ini \drond |
\ini \inii |
\ini
\key d \minor
\transpose cis d {
\dro |
r1 r r r |
r1 r r r |
% refbg enters
r1 r r r |
r1 r r r |
r1 r r r |
}
\key cis \minor
% gpno
\bri \bri |
\bri \bria |
\bri \bri |
\brib \bria |
\bri \bri |
\bri \bria |
}
}
\new Staff {
\signa
\clef treble
<<
\new Voice {
\relative c'' {
\set Staff.midiInstrument = #"choir aahs"
gis4\ a~a fis~ |
fis1 |
gis4 a~a fis |
b2\<
% choir
\dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \refcd |
r1 r r r | % violin solo end
\set Staff.midiInstrument = #"synth voice"
% voice
\versea |
\verseb |
\versea |
\versec |
\versea |
\verseb |
cis8\> cis cis cis~cis cis~cis4 |
r2
\set Staff.midiInstrument = #"choir aahs"
\key d \minor
<<
\transpose cis d {
% choir
\dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \refcd |
r1 r | % there should be
lilypond-book can hang on Windows 10
The python script lilypond-book.py can hang on Windows if the user's
Windows user_id is longer than 8 characters and the user's default Windows
temporary directory is in C:\Users\. This is because of an old,
legacy DOS filename convention. A simple fix is to modify book_latex.py
and change line #209 to
(handle, tmpfile) = tempfile.mkstemp('.tex', dir=".")
which will create the temporary file used by the script in the current
directory, rather than in the Windows default location.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: info-lilypond mailing list
Am Montag, dem 28.12.2020 um 21:53 +0100 schrieb Federico Bruni: > > Il giorno mer, dic 23 2020 at 15:05:57 +0100, Malte Meyn > ha scritto: > > Hi list, > > > > someone asked me whether LilyPond could have a feature that announces > > new released versions. I don’t think that this is desirable but > > what about the info-lilypond mailing list promoted at > > https://lilypond.org/contact.html ? According to the archives, > > 2.19.13 has been the last version announced at the list, so it should > > be reactivated or the website should be updated. > > > > > > Hi Malte > > The problem with the info-lilypond list is that requires a person > (Phil) to remember to make the announcement, (besides the long list of > steps to make a new release). I think Phil made the announcements on > lilypond-user only. > > In the tracker you can find some ideas about how to automate this > communication: > https://gitlab.com/lilypond/lilypond/-/issues/1719 > https://gitlab.com/lilypond/lilypond/-/issues/940 > > I don't know what should be write on the website... > > Personally, I would use Gitlab to get release notifications: > https://docs.gitlab.com/ee/user/project/releases/#get-notified-when-a-release-is-created FYI I've been trying to mark the releases since the switch to GitLab. If there's anything else needed, please let me know. Regardless, it would still be nice if we could get the announcements to a dedicated list with less trafic... signature.asc Description: This is a digitally signed message part ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: typo LilyPond Internals
Hello, On 29/12/2020 01:31, Freeman Gilmore wrote: LilyPond Internals Reference, 2.2.58 key_engraver keyAlterationOrder(list) It should read: "… *step *is a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)." (Not -2 (sharp) to 2 (flat).) Thank you, ƒg ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond Thanks, added as https://gitlab.com/lilypond/lilypond/-/issues/6077 James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: typo LilyPond Internals
On 2020-12-28 6:18 pm, Aaron Hill wrote: On 2020-12-28 5:31 pm, Freeman Gilmore wrote: LilyPond Internals Reference, 2.2.58 key_engraver keyAlterationOrder(list) It should read: "… *step *is a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)." (Not -2 (sharp) to 2 (flat).) What version of the docs are you referencing? I do not see such text. Here's what I see: keyAlterations (list) The current key signature. This is an alist containing (step . alter) or ((octave . step) . alter), where step is a number in the range 0 to 6 and alter a fraction, denoting alteration. For alterations, use symbols, e.g. keyAlterations = #`((6 . ,FLAT)). Ignore me. I was looking at the wrong item. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: typo LilyPond Internals
On 2020-12-28 5:31 pm, Freeman Gilmore wrote: LilyPond Internals Reference, 2.2.58 key_engraver keyAlterationOrder(list) It should read: "… *step *is a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)." (Not -2 (sharp) to 2 (flat).) What version of the docs are you referencing? I do not see such text. Here's what I see: keyAlterations (list) The current key signature. This is an alist containing (step . alter) or ((octave . step) . alter), where step is a number in the range 0 to 6 and alter a fraction, denoting alteration. For alterations, use symbols, e.g. keyAlterations = #`((6 . ,FLAT)). -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
typo LilyPond Internals
LilyPond Internals Reference, 2.2.58 key_engraver keyAlterationOrder(list) It should read: "… *step *is a number from 0 to 6 and *alter *from -2 (flat) to 2 (sharp)." (Not -2 (sharp) to 2 (flat).) Thank you, ƒg ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: info-lilypond mailing list
Il giorno mer, dic 23 2020 at 15:05:57 +0100, Malte Meyn ha scritto: Hi list, someone asked me whether LilyPond could have a feature that announces new released versions. I don’t think that this is desirable but what about the info-lilypond mailing list promoted at https://lilypond.org/contact.html ? According to the archives, 2.19.13 has been the last version announced at the list, so it should be reactivated or the website should be updated. Hi Malte The problem with the info-lilypond list is that requires a person (Phil) to remember to make the announcement, (besides the long list of steps to make a new release). I think Phil made the announcements on lilypond-user only. In the tracker you can find some ideas about how to automate this communication: https://gitlab.com/lilypond/lilypond/-/issues/1719 https://gitlab.com/lilypond/lilypond/-/issues/940 I don't know what should be write on the website... Personally, I would use Gitlab to get release notifications: https://docs.gitlab.com/ee/user/project/releases/#get-notified-when-a-release-is-created ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
info-lilypond mailing list
Hi list, someone asked me whether LilyPond could have a feature that announces new released versions. I don’t think that this is desirable but what about the info-lilypond mailing list promoted at https://lilypond.org/contact.html ? According to the archives, 2.19.13 has been the last version announced at the list, so it should be reactivated or the website should be updated. Cheers, Malte ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: "Including" stdin hangs LilyPond during parsing
> On 19 Nov 2020, at 21:17, Trevor Bača wrote:
>
> ### BEGIN ###
>
> \version "2.20.0"
> \include "-"
>
> \new Staff
> {
>c'4
> }
>
> ### END ###
>
> Hangs during parsing:
>
> GNU LilyPond 2.20.0
> Processing `test.ly'
> Parsing...
> < hangs forever >
>
> Presumably the (spurious) filename "-" dereferences to stdin, putting Lily
> in a wait state for user input that's never to come.
Indeed, the input from stdin can be terminated with ^D (END OF TRANSMISSION
U+0004), and then the compile proceeds normally.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
"Including" stdin hangs LilyPond during parsing
Hi,
### BEGIN ###
\version "2.20.0"
\include "-"
\new Staff
{
c'4
}
### END ###
Hangs during parsing:
GNU LilyPond 2.20.0
Processing `test.ly'
Parsing...
< hangs forever >
Presumably the (spurious) filename "-" dereferences to stdin, putting Lily
in a wait state for user input that's never to come.
Seems unlikely anyone would ever type such a thing. But maybe a
special-cased check wouldn't hurt.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fails to create a midi file on lilypond 2.21.4
Hi Jonas, and thanks to fix the problem;
Jonas wrote;
> Thanks for reporting, I can reproduce this problem and created:
> https://gitlab.com/lilypond/lilypond/-/issues/6020
> I think I also have a fix ready, could you maybe try the following
> version? https://cloud.hahnjo.de/index.php/s/cxKW4WZoMK8k27j
The latest lilypond-2.21.5-3.mingw works fine to compile simple
or more complicated source files with \midi{} command,
and everything went well without any failure.
I am looking forward to the new release adopting this workaround.
--
Mizutori Tetsuya
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fails to create a midi file on lilypond 2.21.4
Hi Jonas,
Your fix looks fine from here (test: \version "2.21.5" \score {{ c' }
\layout {} \midi {}} )
Cheers,
Pierre
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fails to create a midi file on lilypond 2.21.4
Am Freitag, den 07.08.2020, 13:01 +0900 schrieb Mizutori Tetsuya: > Thanks Pierre; > > > Same fail here with the pseudo v2.21.5 (see: > > http://lilypond.1069038.n5.nabble.com/2-21-4-released-td235007.html#a235052 > > ) > > I tried the latest development version of lilypond-2.21.5-2.mingw, > unfortunately it does not clear the problem. > > Here is the compiling log messages: > > > GNU LilyPond 2.21.5 > > Changing working directory to: `U:/work' > > Processing `U:/work/sample-01.ly' > > Parsing... > > Interpreting music... > > Preprocessing graphical objects... > > Interpreting music... > > fatal error: cannot create temp file: sample-01.mid.7927: Invalid > > argument Thanks for reporting, I can reproduce this problem and created: https://gitlab.com/lilypond/lilypond/-/issues/6020 I think I also have a fix ready, could you maybe try the following version? https://cloud.hahnjo.de/index.php/s/cxKW4WZoMK8k27j (As before: This might or might not land in time for 2.21.5, no guarantees made.) Jonas signature.asc Description: This is a digitally signed message part ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fails to create a midi file on lilypond 2.21.4
Thanks Pierre; >Same fail here with the pseudo v2.21.5 (see: >http://lilypond.1069038.n5.nabble.com/2-21-4-released-td235007.html#a235052) I tried the latest development version of lilypond-2.21.5-2.mingw, unfortunately it does not clear the problem. Here is the compiling log messages: >GNU LilyPond 2.21.5 >Changing working directory to: `U:/work' >Processing `U:/work/sample-01.ly' >Parsing... >Interpreting music... >Preprocessing graphical objects... >Interpreting music... >fatal error: cannot create temp file: sample-01.mid.7927: Invalid argument -- Mizutori Tetsuya ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fails to create a midi file on lilypond 2.21.4
Same fail here with the pseudo v2.21.5 (see:
http://lilypond.1069038.n5.nabble.com/2-21-4-released-td235007.html#a235052)
(W10, Frescobaldi 3.1.2)
Cheers,
Pierre
Le jeu. 6 août 2020 à 08:07, Mizutori Tetsuya a
écrit :
> The development versions of lilypond-2.21.3-1.mingw and
> lilypond-2.21.4-1.mingw
> on windows 7 fails to create a midi file.
>
> When compiling any simple input file with \midi{} command, lilypond fails
> to
> create a midi file with the following error message.
>
> > fatal error: cannot create temp file: sample-01.mid.
>
> This error may occur at Midi_stream::Midi_stream class to open a temp file:
>
> ---[ in source file lily/midi-stream.cc ]---
> Midi_stream::Midi_stream (const string _name) {
> tmp_file_name_ = String_convert::form_string ("%s.%8x", file_name.c_str
> (), rand ());
> out_file_ = fopen (tmp_file_name_.c_str (), "wbx");
> }
> ---
>
> I don't know what causes the failure.
>
> --
> Mizutori Tetsuya
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Fails to create a midi file on lilypond 2.21.4
The development versions of lilypond-2.21.3-1.mingw and lilypond-2.21.4-1.mingw
on windows 7 fails to create a midi file.
When compiling any simple input file with \midi{} command, lilypond fails to
create a midi file with the following error message.
> fatal error: cannot create temp file: sample-01.mid.
This error may occur at Midi_stream::Midi_stream class to open a temp file:
---[ in source file lily/midi-stream.cc ]---
Midi_stream::Midi_stream (const string _name) {
tmp_file_name_ = String_convert::form_string ("%s.%8x", file_name.c_str (),
rand ());
out_file_ = fopen (tmp_file_name_.c_str (), "wbx");
}
---
I don't know what causes the failure.
--
Mizutori Tetsuya
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.20 and 2.21 crash on Arch Linux
Well, it just so happened that the first file I tried on Arch makes lilypond dump core, sheer bad luck. As per the suggestion here (which I didn't even think of, too busy rushing into worrying about this) my other files compile fine. So in fact there is no real issue. I'll binary chop the file to see what's going one. I did have my suspicions about the file to begin with, as it had somehow lost more recent changes I thought I had made. Thanks all for your assistance. This is so great, and I can say after having used pretty much every major linux distro over the decades, that Arch is by far the best of all, for my personal development use anyway! I even have Manjaro running on my Pi 4 and as far as I am concerned it's far and away superior to Debian on the Pi. But I am veering off topic. Andrew ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.20 and 2.21 crash on Arch Linux
Jonas' idea is good. If you (can) share your score with Jonas, don't hesitate to share with me, and I'd be happy to try and compile it and tell you if I run in the same problem. With three distros instead of one, we might be able to narrow down a little the source of the issue. Claire On Wed, Jun 24, 2020 at 12:11 PM Jonas Hahnfeld via bug-lilypond < bug-lilypond@gnu.org> wrote: > Am Mittwoch, den 24.06.2020, 19:17 +1000 schrieb Andrew Bernard: > > Just getting back into lilypond but nowadays on Arch Linux. Sorry to > > say both recent versions dump core: > > ... > > elapsed time: 0.61 seconds > > Element count 12833 (spanners 1146) > > Preprocessing graphical objects... > > Grob count 19105Segmentation fault (core dumped) > > > > Version from Arch AUR repository and Arch repository. > > > > I have not yet tried building from source. > > > > Anybody else out there on Arch? > > Yes, I'm hacking on LilyPond under Arch. This works fine for current > master (not sure what's in AUR) and I also haven't seen crashes with > 2.20 from the official repos (but I'm not the maintainer). > Maybe it's related to the score you're compiling? If you've something > that you could possibly share, I can take a look. > > Jonas > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.20 and 2.21 crash on Arch Linux
Am Mittwoch, den 24.06.2020, 19:17 +1000 schrieb Andrew Bernard: > Just getting back into lilypond but nowadays on Arch Linux. Sorry to > say both recent versions dump core: > ... > elapsed time: 0.61 seconds > Element count 12833 (spanners 1146) > Preprocessing graphical objects... > Grob count 19105Segmentation fault (core dumped) > > Version from Arch AUR repository and Arch repository. > > I have not yet tried building from source. > > Anybody else out there on Arch? Yes, I'm hacking on LilyPond under Arch. This works fine for current master (not sure what's in AUR) and I also haven't seen crashes with 2.20 from the official repos (but I'm not the maintainer). Maybe it's related to the score you're compiling? If you've something that you could possibly share, I can take a look. Jonas signature.asc Description: This is a digitally signed message part ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.20 and 2.21 crash on Arch Linux
I'm on Manjaro KDE 5.4.44-1, whis is Arch-based. I use lilypond 2.20.0-3 (build date 2020/03/16, packager Antonio Rojas : aro...@archlinux.org) and it works fine for me. If I'm not mistaken, Manjaro uses Arch repositories, with some additional code review before incorporating the last changes, so that there are potential corrections. In particular, the stable repositories *contains only packages that are deemed stable by the development team, which can mean weeks of delay before getting major releases of certain software* (source for italic claims : wikipedia). So maybe that's why I don't have the same problem ? Claire On Wed, Jun 24, 2020 at 11:19 AM Andrew Bernard wrote: > Just getting back into lilypond but nowadays on Arch Linux. Sorry to > say both recent versions dump core: > ... > elapsed time: 0.61 seconds > Element count 12833 (spanners 1146) > Preprocessing graphical objects... > Grob count 19105Segmentation fault (core dumped) > > Version from Arch AUR repository and Arch repository. > > I have not yet tried building from source. > > Anybody else out there on Arch? > > Andrew > > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond 2.20 and 2.21 crash on Arch Linux
Just getting back into lilypond but nowadays on Arch Linux. Sorry to say both recent versions dump core: ... elapsed time: 0.61 seconds Element count 12833 (spanners 1146) Preprocessing graphical objects... Grob count 19105Segmentation fault (core dumped) Version from Arch AUR repository and Arch repository. I have not yet tried building from source. Anybody else out there on Arch? Andrew ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond not working with Mac 10.15.4
Horst via bug-lilypond writes: > Hello, > > I recently updated to macOS Catalina (Version 10.15.4). Since then I > cannot work with Lilypond anymore. I also downloaded the developer > version lilypond-2.21.1-1. However, when trying to open Lilypond I > always get the following error message: > > “LilyPond” needs to be updated. > The developer of this app needs to update it to work with this version > of macOS. Contact the developer for more information. > > Apparently, there is some change in Catalina that is incompatible with > the existing versions of Lilypond. Can you please have a look at this? You downloaded the wrong version. On all download pages I can find on the web page (including for developer versions), there are unofficial downloads for 64Bit MacOSX that should be working with Catalina. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond not working with Mac 10.15.4
Hello, I recently updated to macOS Catalina (Version 10.15.4). Since then I cannot work with Lilypond anymore. I also downloaded the developer version lilypond-2.21.1-1. However, when trying to open Lilypond I always get the following error message: “LilyPond” needs to be updated. The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information. Apparently, there is some change in Catalina that is incompatible with the existing versions of Lilypond. Can you please have a look at this? Thanks and best regards, Horst Väth ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: No Mac OS 64-bit link of Lilypond in non-English Download section
Il giorno gio 30 apr 2020 alle 16:12, Caio Barros ha scritto: Hello! The link to the Unofficial 64-bit app for Mac OS is not present in non-English versions of the website. See, for instance: https://lilypond.org/macos-x.de.html https://lilypond.org/macos-x.pt.html https://lilypond.org/macos-x.es.html It's normal, as it's up to translators to update their files. The italian and french pages are up-to-date. I guess that spanish (and maybe catalan) will follow soon. AFAIK the other languages are not maintained, unfortunately. PS If we used gettext, we might force the english for fuzzy or new strings, so any page would be always up-to-date but possibly with a mix of translated paragraphs and untranslated (english) paragraphs. But we are not using gettext :-) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
No Mac OS 64-bit link of Lilypond in non-English Download section
Hello! The link to the Unofficial 64-bit app for Mac OS is not present in non-English versions of the website. See, for instance: https://lilypond.org/macos-x.de.html https://lilypond.org/macos-x.pt.html https://lilypond.org/macos-x.es.html Thanks! Caio Barros ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unable to Use LilyPond
On Wed, Mar 25, 2020 at 3:09 PM Jahrme Risner wrote: [...] > > One slight correction here, MacPorts will provide pre-built binaries when > available, building from source is usually only needed if you are on an > unusual platform or attempt to upgrade immediately after an update has been > submitted. > You’re quite right; thanks for the correction (although builds with variants still go from source, right?). I still think .app bundles play nicer with Mac OS and are easier to work with in terms of being self-contained, but I should have been more precise. (Fun fact: the MacPorts install on the box that I’m using to produce the LilyPond builds *does* have to install everything from source, because I put MacPorts in a nonstandard location to make system administration easier. Apparently MacPorts builds for a specific installation location...) Best, > -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unable to Use LilyPond
On Wed, Mar 25, 2020 at 11:52, Marnen Laibow-Koser <[1]mar...@marnen.org> wrote: On Wed, Mar 25, 2020 at 2:41 PM Jahrme Risner <[2]lilyp...@jahrme.com> wrote: On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes <[3]wesleymrho...@gmail.com> wrote: Hello! I hope you area all doing well during this time. I am a MacBook user running macOS Catalina. I was thrilled to find LilyPond, but it appears to not be working for me. I downloaded it, but when I try to run the program I get the following error: "The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information." Can you tell me if there is a fix for this issue? I would really appreciate it. Thank you! First of all, I’m sorry you’ve run into this. For a long time there were no 64-bit Mac binaries of LilyPond available at all. I’ve fixed that situation now; binaries are available for download at [4]https://bintray.com/marnen/lilypond-darwin-64 . I hope to get this mentioned on the LilyPond website sometime in the near future so fewer people are confused. Build scripts and an issue tracker for 64-bit Mac builds are at [5]https://gitlab.com/marnen/lilypond-mac-builder , if you want to contribute or need to report problems. Again, I hope to get this better integrated with the rest of the LilyPond project. One option is to use MacPorts ([6]macports.org) which is a package manager for macOS that provides both stable and development versions of LilyPond (among other programs). Using a package manager like MacPorts is my preferred solution. And my explicitly dispreferred one if you don’t already have some other need for MacPorts. But you knew that. :) Yes, and that is why I CC’d you, to make sure Wesley had all the option available. Some people would rather download a .app bundle; if you fall into this camp I know that Marnen on the list has been working on such a bundle. I believe there are links in the chat history, and I’m cc’ing in Marnen in case you need help with this approach. Yes, see above. I believe this should be the preferred option for most Mac users who don’t have a specific reason to need to build from source. One slight correction here, MacPorts will provide pre-built binaries when available, building from source is usually only needed if you are on an unusual platform or attempt to upgrade immediately after an update has been submitted. Best, -- Marnen Laibow-Koser [7]mar...@marnen.org [8]http://www.marnen.org Sent from Gmail Mobile References 1. mailto:mar...@marnen.org 2. mailto:lilyp...@jahrme.com 3. mailto:wesleymrho...@gmail.com 4. https://bintray.com/marnen/lilypond-darwin-64 5. https://gitlab.com/marnen/lilypond-mac-builder 6. http://macports.org/ 7. mailto:mar...@marnen.org 8. http://www.marnen.org/ signature.asc Description: OpenPGP digital signature ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unable to Use LilyPond
On Wed, Mar 25, 2020 at 2:41 PM Jahrme Risner wrote: > > > On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes > wrote: > > Hello! > > > I hope you area all doing well during this time. I am a MacBook user > running macOS Catalina. I was thrilled to find LilyPond, but it appears to > not be working for me. I downloaded it, but when I try to run the program I > get the following error: > > > "The developer of this app needs to update it to work with this version of > macOS. Contact the developer for more information." > > > Can you tell me if there is a fix for this issue? I would really appreciate > it. Thank you! > > First of all, I’m sorry you’ve run into this. For a long time there were no 64-bit Mac binaries of LilyPond available at all. I’ve fixed that situation now; binaries are available for download at https://bintray.com/marnen/lilypond-darwin-64 . I hope to get this mentioned on the LilyPond website sometime in the near future so fewer people are confused. Build scripts and an issue tracker for 64-bit Mac builds are at https://gitlab.com/marnen/lilypond-mac-builder , if you want to contribute or need to report problems. Again, I hope to get this better integrated with the rest of the LilyPond project. > One option is to use MacPorts (macports.org) which is a package manager > for macOS that provides both stable and development versions of LilyPond > (among other programs). Using a package manager like MacPorts is my > preferred solution. > And my explicitly dispreferred one if you don’t already have some other need for MacPorts. But you knew that. :) > > Some people would rather download a .app bundle; if you fall into this > camp I know that Marnen on the list has been working on such a bundle. I > believe there are links in the chat history, and I’m cc’ing in Marnen in > case you need help with this approach. > Yes, see above. I believe this should be the preferred option for most Mac users who don’t have a specific reason to need to build from source. Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unable to Use LilyPond
On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes <[1]wesleymrho...@gmail.com> wrote: Hello! I hope you area all doing well during this time. I am a MacBook user running macOS Catalina. I was thrilled to find LilyPond, but it appears to not be working for me. I downloaded it, but when I try to run the program I get the following error: "The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information." Can you tell me if there is a fix for this issue? I would really appreciate it. Thank you! One option is to use MacPorts (macports.org) which is a package manager for macOS that provides both stable and development versions of LilyPond (among other programs). Using a package manager like MacPorts is my preferred solution. Some people would rather download a .app bundle; if you fall into this camp I know that Marnen on the list has been working on such a bundle. I believe there are links in the chat history, and I’m cc’ing in Marnen in case you need help with this approach. Best, Wesley ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond References 1. mailto:wesleymrho...@gmail.com signature.asc Description: OpenPGP digital signature ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Unable to Use LilyPond
Hello! I hope you area all doing well during this time. I am a MacBook user running macOS Catalina. I was thrilled to find LilyPond, but it appears to not be working for me. I downloaded it, but when I try to run the program I get the following error: "The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information." Can you tell me if there is a fix for this issue? I would really appreciate it. Thank you! Best, Wesley ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond & macOS
See https://lists.gnu.org/archive/html/lilypond-user/2019-11/msg00295.html > On 10 Dec 2019, at 22:30, B.M. van t Veer via bug-lilypond > wrote: > > % Version 2.18.2 cannot run under macOS 10.15 (19A602) > % also tried version unstable 2.19.83, same issue > \version "2.18.2" ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond & macOS
% Version 2.18.2 cannot run under macOS 10.15 (19A602) % also tried version unstable 2.19.83, same issue \version "2.18.2" ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Rests with stem tremolo cause LilyPond to fail silently
Am 13.10.19 um 20:30 schrieb Trevor Bača: Hi, While "c4:32" correctly expresses a quarter note stem tremolo slashes, typing (badly-formed) "r4:32" probably only happens when a user is editing a source file and changes a note to a rest without regard for the stem tremolo suffix. However, rather than raising some type of error or warning, Lily fails silently on this type of badly-formed construction. […] Rather than failing silently, Lily should raise an error or warning: imagine a large input file failing for no apparent reason and then having to bisect the entire thing find a single instance of something like "r4:32". Thanks, Trevor. This is now issue 5579: https://sourceforge.net/p/testlilyissues/issues/5579/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Rests with stem tremolo cause LilyPond to fail silently
Hi,
While "c4:32" correctly expresses a quarter note stem tremolo slashes,
typing (badly-formed) "r4:32" probably only happens when a user is editing
a source file and changes a note to a rest without regard for the stem
tremolo suffix.
However, rather than raising some type of error or warning, Lily fails
silently on this type of badly-formed construction.
Rests shorter than the duration of a whole note cause LilyPond to fail
silently at system drawing:
%%% BEGIN 1 %%%
\version "2.19.83"
\new Staff { r4:32 }
%%% END %%%
Output:
GNU LilyPond 2.19.83
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
*[no more output]*
Longer rests cause Lily to fail even more laconically:
%%% BEGIN 2 %%%
\version "2.19.83"
\new Staff { r1:32 }
%%% END %%%
GNU LilyPond 2.19.83
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
*[no more output]*
Rather than failing silently, Lily should raise an error or warning:
imagine a large input file failing for no apparent reason and then having
to bisect the entire thing find a single instance of something like
"r4:32".
Thanks,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
_______
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond — Notation Reference: 2.9.4 Divisiones (v2.18/2.19)
Thank you Jean-Charles. Le mar. 10 sept. 2019 à 20:13, Jean-Charles Malahieude a écrit : > Le 09/09/2019 à 20:09, Jean-Charles Malahieude a écrit : > > I'll take care of this (in Translation and stable/2.20). > > > > Done as commit 2b6b44d46e5af1b61ff5b1be98f48e44bc27f3aa > > -- > Jean-Charles > > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond — Notation Reference: 2.9.4 Divisiones (v2.18/2.19)
Le 09/09/2019 à 20:09, Jean-Charles Malahieude a écrit : I'll take care of this (in Translation and stable/2.20). Done as commit 2b6b44d46e5af1b61ff5b1be98f48e44bc27f3aa -- Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond — Notation Reference: 2.9.4 Divisiones (v2.18/2.19)
Le 09/09/2019 à 10:31, Pierre Perol-Schneider a écrit : Hi bug Squad, There's a typo in the french translation: http://lilypond.org/doc/v2.19/Documentation/notation/typesetting-gregorian-chant#divisiones : ‘gregorian-init.ly’ appears twice instead of ‘gregorian.ly’ I'll take care of this (in Translation and stable/2.20). gregorian-init.ly has been renamed in late 2008, but some strings in the docs have been missed. Cheers, -- Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
LilyPond — Notation Reference: 2.9.4 Divisiones (v2.18/2.19)
Hi bug Squad, There's a typo in the french translation: http://lilypond.org/doc/v2.19/Documentation/notation/typesetting-gregorian-chant#divisiones : ‘gregorian-init.ly’ appears twice instead of ‘gregorian.ly’ (reported from the french list: http://lilypond-french-users.1298960.n2.nabble.com/Coquille-include-gregorian-manuel-2-18-2-FR-td7587997.html ) Cheers, Pierre ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 201, Issue 7
Sure, thank you for taking the time to help.
"
\version "2.19.82"
\header {
title = "all hornpipe from water music suite"
piece = "D Major"
tagline = ##f
}
\relative a' {
\clef "treble" \key d \major \time 3/2 | % 1
a2 d2 e2 | %
}
"
I am also using Manjaro 64-bit. It was working fine a few weeks ago.
When I run the above code I get this in the log:
Starting lilypond 2.19.82 [lilypond issue.ly]...
Processing `/tmp/frescobaldi-ffbixek6/tmp39ojq71a/lilypond issue.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
warning: compressing over-full page by 77044.3 staff-spaces
warning: page 1 has been compressed
Layout output to `/tmp/lilypond-WYPnPS'...
Converting to `lilypond issue.pdf'...
Deleting `/tmp/lilypond-WYPnPS'...
Success: compilation successfully completed
Completed successfully in 0.8".
Aug 14, 2019, 6:25 AM by bug-lilypond-requ...@gnu.org:
> Send bug-lilypond mailing list submissions to
> bug-lilypond@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> or, via email, send a message with subject or body 'help' to
> bug-lilypond-requ...@gnu.org
>
> You can reach the person managing the list at
> bug-lilypond-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-lilypond digest..."
>
>
> Today's Topics:
>
> 1. Re: Error on Linux (Malte Meyn)
> 2. Re: Error on Linux (Aaron Hill)
>
>
> --
>
> Message: 1
> Date: Wed, 14 Aug 2019 15:24:14 +0200
> From: Malte Meyn
> To: bug-lilypond@gnu.org
> Subject: Re: Error on Linux
> Message-ID: <74f42921-ecb3-6657-739e-68cac66b4...@maltemeyn.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
>
> Am 14.08.19 um 15:16 schrieb Anzick:
>
>> Hello, with even the most simple score I am getting this error:
>>
>>
>> warning: compressing over-full page by 77044.3 staff-spaces
>>
>>
>> warning: page 1 has been compressed
>>
>>
>> The same file apears to work fine on Mac, but not on Linux.
>>
>
> Hi Anzick,
>
> I cannot reproduce that behaviour using LilyPond 2.19.82 for 64-bit
> Linux (Manjaro). Apart from that it’s not the “most simple score”, could
> you please try to make a minimal example?
>
> Cheers,
> Malte
>
>
>
> --
>
> Message: 2
> Date: Wed, 14 Aug 2019 06:25:29 -0700
> From: Aaron Hill
> To: bug-lilypond@gnu.org
> Subject: Re: Error on Linux
> Message-ID: <5055799f36d16d94f7dca8361d58d...@hillvisions.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 2019-08-14 6:16 am, Anzick wrote:
>
>> Hello, with even the most simple score I am getting this error:
>>
>> warning: compressing over-full page by 77044.3 staff-spaces
>> warning: page 1 has been compressed
>>
>> The same file apears to work fine on Mac, but not on Linux.
>>
>
> Could you provide details of your system?
>
> I tried this on Ubuntu 18.04 with LilyPond 2.19.83 and encountered no
> errors (results attached).
>
>
> -- Aaron Hill
> -- next part --
> A non-text attachment was scrubbed...
> Name: lilypond issue.pdf
> Type: application/pdf
> Size: 50323 bytes
> Desc: not available
> URL:
> <https://lists.gnu.org/archive/html/bug-lilypond/attachments/20190814/3bc664da/attachment.pdf>
>
> --
>
> Subject: Digest Footer
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
> --
>
> End of bug-lilypond Digest, Vol 201, Issue 7
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.83 - ragged-right problem
On 2019-07-01 10:29 am, John McWilliam wrote: I forgot to include the pdf which illustrates my problem. 25th_kosbs_test.pdf <http://lilypond.1069038.n5.nabble.com/file/t2471/25th_kosbs_test.pdf> If I had to guess, it looks like overfull lines of music where LilyPond runs beyond the right margin. Note that LilyPond usually warns you of this, so double-check your compiler output to confirm. You will likely need to reduce the spacing between notes if you are intent on squeezing in that much music on a single line. Review the documentation on horizontal spacing [1]. [1]: http://lilypond.org/doc/v2.19/Documentation/notation/horizontal-spacing.en.html -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.83 - ragged-right problem
I forgot to include the pdf which illustrates my problem. John 25th_kosbs_test.pdf <http://lilypond.1069038.n5.nabble.com/file/t2471/25th_kosbs_test.pdf> - John McWilliam -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.83 - ragged-right problem
Am Mo., 1. Juli 2019 um 17:54 Uhr schrieb John McWilliam
:
>
> Windows 10
> Lilypond 2.19.83
>
> Hi,
> I have written a bagpipe tune (25th_kosbs) which has four parts, each
> with a repeat which should start on a new line. The format is A4 in lanscape
> mode. I cannot get this to work and at the same time maintain a flush right
> margin. Suggestions please
>
> John McWilliam
>
> PS I know this should have gone into the Lilypond-User list but am waiting
> for my registration to go through the system.
>
> Sent from Mail for Windows 10
Hi John,
please only post to the bug-list, if you are sure you noticed a bug.
Even if you're sure about the bug, it may be none, people here can
sort it out ...
Never ask for usage-problems here, but on the user-list.
If you ask there please reduce your score to a minimal working example
exposing the problem.
Please double check its a _minimal_ _working_ example.
The three files you posted are far from minimal, so much code,
unrelated settings, unrelated comments etc etc
I can't imagine how you are not completely confused by your own code.
P.e. you have settings for the paper-size at toplevel, as well as in
\paper of an included file
And it even not compiles, your \include "..." is spelled wrongly.
Additionally, with a minimal working example (MWE) you probably would
have seen the problem yourself.
Such a MWE could be:
\version "2.19.82"
#(set-default-paper-size "a4" 'landscape)
{ R1 }
Then you could have looked into the NR's index:
http://lilypond.org/doc/v2.19/Documentation/notation/lilypond-index
looking for landscape leads to
http://lilypond.org/doc/v2.19/Documentation/notation/paper-size-and-automatic-scaling#index-paper-size_002c-landscape
Which demonstrates all about 'landscape.
I don't understand the ragged-right problem, probably because I'm not
a native speaker.
If it persists after solving the 'landscape thingy reask on user-list.
-Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond 2.19.83 - ragged-right problem
Windows 10 Lilypond 2.19.83 Hi, I have written a bagpipe tune (25th_kosbs) which has four parts, each with a repeat which should start on a new line. The format is A4 in lanscape mode. I cannot get this to work and at the same time maintain a flush right margin. Suggestions please John McWilliam PS I know this should have gone into the Lilypond-User list but am waiting for my registration to go through the system. Sent from Mail for Windows 10 25th_kosbs_test.ly Description: Binary data Bagpipe_new.ly Description: Binary data BP_format.ly Description: Binary data ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: bug-lilypond Digest, Vol 199, Issue 17
Snygt!! Tack Torsten
MvH
John
Sent from Mail for Windows 10
From: bug-lilypond-requ...@gnu.org
Sent: Sunday, June 30, 2019 6:00 PM
To: bug-lilypond@gnu.org
Subject: bug-lilypond Digest, Vol 199, Issue 17
Send bug-lilypond mailing list submissions to
bug-lilypond@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/bug-lilypond
or, via email, send a message with subject or body 'help' to
bug-lilypond-requ...@gnu.org
You can reach the person managing the list at
bug-lilypond-ow...@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bug-lilypond digest..."
Today's Topics:
1. Re: Markup question (Torsten Hämmerle)
--
Message: 1
Date: Sun, 30 Jun 2019 08:27:58 -0700 (MST)
From: Torsten Hämmerle
To: bug-lilypond@gnu.org
Subject: Re: Markup question
Message-ID: <1561908478807-0.p...@n5.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hi John,
perhaps I'm getting something wrong, but there is a very straight-forward
and easy solution to your problem: the \tempo command can handle this case
all by itself:
%
\version "2.19.83"
{
\tempo "Moderato" 4 = 84
c''1
}
%
HTH,
Torsten
--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html
--
Subject: Digest Footer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
------
End of bug-lilypond Digest, Vol 199, Issue 17
*
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
Am Fr., 26. Apr. 2019 um 11:10 Uhr schrieb Thomas Morley : > Can't dive deeper into it right now. I'll open a tracker issue in > order it will not be forgotten. https://sourceforge.net/p/testlilyissues/issues/5516/ Cheers, Harm ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
Am Fr., 26. Apr. 2019 um 10:22 Uhr schrieb David Kastrup : > > Federico Bruni writes: > > > Il giorno gio 25 apr 2019 alle 23:40, Thomas Morley > > ha scritto: > >> Probably one could think of making `\tabChordRepeats´ the default > >> for TabStaff. > >> > >> Opinions? > > > > I'm in favour of making it the default for TabStaff. > > How? (Automatic) expansion of q happens at scorification time. There > are no contexts at that time and the context definitions may still > change after scorification. > > You'd have to move some of the repeat chord expansion business right > into iteration and engraving. > > -- > David Kastrup In my naivity I thought adding `\tabChordRepeats´ to TabStaff's layout would work. I should have read up how `\tabChordRepeats´ is defined and how it works. Basically a music-function returning music. Thus the naive approach will not work. Can't dive deeper into it right now. I'll open a tracker issue in order it will not be forgotten. Cheers, Harm ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
Federico Bruni writes: > Il giorno gio 25 apr 2019 alle 23:40, Thomas Morley > ha scritto: >> Probably one could think of making `\tabChordRepeats´ the default >> for TabStaff. >> >> Opinions? > > I'm in favour of making it the default for TabStaff. How? (Automatic) expansion of q happens at scorification time. There are no contexts at that time and the context definitions may still change after scorification. You'd have to move some of the repeat chord expansion business right into iteration and engraving. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
Il giorno gio 25 apr 2019 alle 23:40, Thomas Morley ha scritto: Probably one could think of making `\tabChordRepeats´ the default for TabStaff. Opinions? I'm in favour of making it the default for TabStaff. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
Am Do., 25. Apr. 2019 um 22:35 Uhr schrieb Christopher Heckman
:
>
> On Thu, Apr 25, 2019 at 9:05 AM wrote:
> >
> > Am Mi., 24. Apr. 2019 um 23:24 Uhr schrieb Christopher Heckman
> > :
> > >
> > > I searched for this at the archives, but maybe I didn't look in the right
> > > place.
> > >
> > > The title is pretty self-expanatory. If the pitch e is normally played
> > > on the 5th string of a guitar (after transposition), then
> > >
> > > \new TabStaff { q }
> > >
> > > will show e played on the 6th string and then on the 5th string, even
> > > if you put a tie after .
> > >
> > > (This is Lilypond version 2.18.)
> > >
> > > --- Christopher Carl Heckman
> >
> > Hi,
> >
> > thanks for your report, though, see
> > http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#index-_005cchordRepeats-1
> > for
> > \tabChordRepeats
> >
> > Thus no bug.
> >
> >
> > Cheers,
> > Harm
>
> Fair enough. But shouldn't keeping the fingering information be the
> default? Especially if the chord is an immediate repeat?
>
> --- Christopher Carl Heckman
Well, in general `q´ shouldn't, imho.
Probably one could think of making `\tabChordRepeats´ the default for TabStaff.
Opinions?
Cheers,
Harm
P.S.
Please always try to reply to the original mail not a digest, it
breaks threads in the archives.
Thanks.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 197, Issue 11
On Thu, Apr 25, 2019 at 9:05 AM wrote:
>
> Am Mi., 24. Apr. 2019 um 23:24 Uhr schrieb Christopher Heckman
> :
> >
> > I searched for this at the archives, but maybe I didn't look in the right
> > place.
> >
> > The title is pretty self-expanatory. If the pitch e is normally played
> > on the 5th string of a guitar (after transposition), then
> >
> > \new TabStaff { q }
> >
> > will show e played on the 6th string and then on the 5th string, even
> > if you put a tie after .
> >
> > (This is Lilypond version 2.18.)
> >
> > --- Christopher Carl Heckman
>
> Hi,
>
> thanks for your report, though, see
> http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#index-_005cchordRepeats-1
> for
> \tabChordRepeats
>
> Thus no bug.
>
>
> Cheers,
> Harm
Fair enough. But shouldn't keeping the fingering information be the
default? Especially if the chord is an immediate repeat?
--- Christopher Carl Heckman
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
On 2019-03-23 5:46 pm, Andrew Bernard wrote: Hi Aaron, I know it would be great to see my code, but the quartet is 11,000 lines long and that's only half, and my library of which I use everything is 13,000 lines of code (for all the New Complexity stuff). I would never expect anybody to go through it, let alone set it all up for compiling. I am unable to extract an MWE from the score that proves it. However, being clued in to a possible issue around tuplets, I found the issue by trial and error rather than gdb. Here it is: calling tupletFullLengthNote = ##t causes the crash. This is definite. But it only occurs in my reasonably large score. I am unable to stimulate this in a simple example. Does knowing that combined with the gdb backtrace help pinpoint this? Yes. The issue is as I mentioned in my pathological example. You may be able to counteract the effects by reducing break-overshoot and/or full-length-padding: %% Here are the defaults. % \override TupletBracket.break-overshoot = #'(-0.5 . 0) % \override TupletBracket.full-length-padding = #1 \override TupletBracket.break-overshoot = #'(-0.25 . 0) \override TupletBracket.full-length-padding = #0.5 Alternately, you could patch the behavior by correcting the invalid intervals when they show up: \override TupletBracket.X-positions = #(lambda (grob) (let ((xpos (ly:tuplet-bracket::calc-x-positions grob))) (if (> (car xpos) (cdr xpos)) (let ((mid (/ (+ (car xpos) (cdr xpos)) 2))) (format #t "\nwarning: Fixing invalid X-positions ~a" xpos) (cons mid mid)) xpos))) This variant of my prior procedure opts to use the artificial "center" of the invalid interval as the result. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
Here it is:
Using tupletFullLengthToNote = ##t crashes it.
\version "2.19.82"
\paper { indent = 0 ragged-right = ##t }
\layout {
\set tupletFullLength = ##t
\set tupletFullLengthNote = ##t
}
{ \tuplet 1/1 { b'1 } \break 4 }
That qualifies as a bug worth registering, does it not?
Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
Hi Aaron, I know it would be great to see my code, but the quartet is 11,000 lines long and that's only half, and my library of which I use everything is 13,000 lines of code (for all the New Complexity stuff). I would never expect anybody to go through it, let alone set it all up for compiling. I am unable to extract an MWE from the score that proves it. However, being clued in to a possible issue around tuplets, I found the issue by trial and error rather than gdb. Here it is: calling tupletFullLengthNote = ##t causes the crash. This is definite. But it only occurs in my reasonably large score. I am unable to stimulate this in a simple example. Does knowing that combined with the gdb backtrace help pinpoint this? Andrew ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
On 2019-03-23 3:39 pm, Thomas Morley wrote:
Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill
:
\override TupletBracket.X-positions = #(lambda (grob)
(let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
(if (> (car xpos) (cdr xpos))
(format #t "\nwarning: Inverted X-positions ~a" xpos))
We have `ordered-cons´ for:
(cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr
xpos)
Thanks, Harm. Would it be reasonable for Internals to include
documentation on the various helper functions in lily-library.scm? Some
have documentation strings already, but even just a list of all
define-public procedures could be useful. That, or I just need to
review that file enough to commit it to memory.
Here's a pathological example to trigger bad behavior:
\version "2.19.82"
\paper { indent = 0 ragged-right = ##t }
\layout {
\set tupletFullLength = ##t
\set tupletFullLengthNote = ##t
\override Staff.TupletBracket.X-positions = #(lambda (grob)
(let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
(if (> (car xpos) (cdr xpos))
(format #t "\nwarning: Inverted X-positions ~a" xpos))
(ordered-cons (car xpos) (cdr xpos
}
{ \tuplet 1/1 { b'1 } \break 4 }
It should be possible to avoid this with the following change to
tuplet-bracket.cc:
241,243c241
< coord = max (coord, x_span[LEFT]);
<
< x_span[d] = coord - padding;
---
x_span[d] = max (coord - padding, x_span[LEFT]);
This does make break-overshoot take priority over full-length-padding,
as the left bound is computed first.
-- Aaron Hill
_______
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill : > > On 2019-03-23 6:46 am, Andrew Bernard wrote: > > What calls calc_x_offset for Tuplet Number? > > This likely may be coming from Scheme. If you look at the Internals > reference, you will see that the X-offset property for TupletNumber is > by default set to ly:tuplet-number::calc-x-offset. > > That means that if you were to call (ly:grob-property grob 'X-offset) > against a TupletNumber, it will end up consulting the specified > procedure which is in this case implemented in C++. > > > Any assistance would be greatly appreciated. My string quartet is going > > nowhere but I am learning a lot about debugging lilypond. > > Are you able to share your .ly that exhibits this behavior? Without a > failing case on my side, I am left to only guess what might be > triggering the behavior. I'd like to second. > That said, I have found a few things in the > code that *could* be problematic. > > For instance, would you try adding this to your project: > > >\override TupletBracket.X-positions = #(lambda (grob) > (let ((xpos (ly:tuplet-bracket::calc-x-positions grob))) >(if (> (car xpos) (cdr xpos)) > (format #t "\nwarning: Inverted X-positions ~a" xpos)) We have `ordered-cons´ for: >(cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr xpos) > > > This will emit a warning when it detects that the calculated X-positions > are inverted, but it also patches the issue by making the interval > valid. > > -- Aaron Hill It's worth checking LigatureBracket as well, they share the same procedures for stencil/X-offset. HorizontalBracket probably too (same procedure for `connect-to-neighbor´), although this is unlikely to trigger the problem, imho. Cheers, Harm ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash related to tuplets
On 2019-03-23 6:46 am, Andrew Bernard wrote: What calls calc_x_offset for Tuplet Number? This likely may be coming from Scheme. If you look at the Internals reference, you will see that the X-offset property for TupletNumber is by default set to ly:tuplet-number::calc-x-offset. That means that if you were to call (ly:grob-property grob 'X-offset) against a TupletNumber, it will end up consulting the specified procedure which is in this case implemented in C++. Any assistance would be greatly appreciated. My string quartet is going nowhere but I am learning a lot about debugging lilypond. Are you able to share your .ly that exhibits this behavior? Without a failing case on my side, I am left to only guess what might be triggering the behavior. That said, I have found a few things in the code that *could* be problematic. For instance, would you try adding this to your project: \override TupletBracket.X-positions = #(lambda (grob) (let ((xpos (ly:tuplet-bracket::calc-x-positions grob))) (if (> (car xpos) (cdr xpos)) (format #t "\nwarning: Inverted X-positions ~a" xpos)) (cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr xpos) This will emit a warning when it detects that the calculated X-positions are inverted, but it also patches the issue by making the interval valid. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond crash related to tuplets
I'm not sure if this is the right list to discuss this on. Recently in my 200 page string quartet the tuplet brackets, which always used to be fine, have started becomg too short, randomly, with no apparent obvious pattern, and only a little bit, but enough to make the score very unprofessional looking. Worse, for no reason I can fathom, suddenly I can't compile any more due to lilypond dumping core. So I went through the exercise of building lilypond in order to get an executable with debugging symbols. learned how to run gdb, and was interested to observe this in the (very long) backtrace: #2 0x774c640f in __assert_fail_base (fmt=0x77652858 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55915f81 "!is_empty ()", file=0x55915f63 "../flower/include/interval.hh", line=227, function=) at assert.c:92 #3 0x774d6142 in __GI___assert_fail (assertion=assertion@entry=0x55915f81 "!is_empty ()", file=file@entry=0x55915f63 "../flower/include/interval.hh", line=line@entry=227, function=function@entry=0x55928280 <_ZZNK10Interval_tIdE6centerEvE19__PRETTY_FUNCTION__> "T Interval_t::center() const [with T = double]") at assert.c:101 #4 0x556e4a06 in Interval_t::center() const (this=) at ./include/lily-guile-macros.hh:70 #5 0x556e4a06 in Tuplet_number::calc_x_offset(scm_unused_struct*) (smob=) at tuplet-number.cc:293 I am running 2.19.83 on Ubuntu 18.10. The same occurs with 2.19.82. This seems to indeed indicate something in the tuplet machinery going wrong. I have disabled ally my music functions that have anything to do with modifying tuplets. I did this because the exact error came up a year or two go and that turned out to be related to matters regrading setting the stencil to #point-stencil or not. But that's not the current issue, although I suspect it is close. What calls calc_x_offset for Tuplet Number? Do I need to compile a non-optimised version of lilypond to trace this further? Any assistance would be greatly appreciated. My string quartet is going nowhere but I am learning a lot about debugging lilypond. I am not sure what list this belongs to as I feel this may very well be a conding error in my source, and not a lilypond bug, but it's very hard to determine. I cannot make it happen in an MWE. Andrew ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur
Il giorno ven 15 mar 2019 alle 20:20, Edward McGuire
ha scritto:
The full work from which the tiny example is taken generates both
printed output and MIDI output. The structure of the full work is
something like:
\include "articulate.ly"
stringpart = { [music] }
\book {
% generated printed output
\bookpart {
\score { \stringpart }
\layout { }
}
% using articulate, generate MIDI output
\bookpart {
\score { \unfoldRepeats \articulate \stringpart }
\midi { }
}
}
(When I say "something like" I mean that this is still a
simplification of the structure of the full work, which actually
contains more parts, i.e., multiple staves, multiple voices.)
A workaround is moving the include of articulate.ly after the "PDF
score" and just before the "MIDI score", so that it won't affect the
former. This might be possible or not depending on the structure of
your input files.
If you omit the \book block in above example and place the include
between the two bookparts, it should work fine.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur
On 2019-03-15 12:20 pm, Edward McGuire wrote:
On Fri, Mar 15, 2019 at 11:34 AM Aaron Hill
wrote:
I thought articulate.ly was *only* for \midi, and its modifications
are
not intended to be printed.
The full work from which the tiny example is taken generates both
printed output and MIDI output. The structure of the full work is
something like:
\include "articulate.ly"
stringpart = { [music] }
\book {
% generated printed output
\bookpart {
\score { \stringpart }
\layout { }
}
% using articulate, generate MIDI output
\bookpart {
\score { \unfoldRepeats \articulate \stringpart }
\midi { }
}
}
(When I say "something like" I mean that this is still a
simplification of the structure of the full work, which actually
contains more parts, i.e., multiple staves, multiple voices.)
Or is this an issue where the modifications are inappropriate
resulting
in bad MIDI output?
The MIDI output seems great. What's getting screwed up is just the
printed output.
My humble apologies that I overlooked your example only *includes* the
script, but it does not call \articulate.
The problem is caused by articulate.ly redefining \appoggiatura just by
including [1] the script. David K. fixed [2] this issue many years ago,
but it is part of the 2.19 branch.
[1]: https://sourceforge.net/p/testlilyissues/issues/4517/
[2]:
https://github.com/lilypond/lilypond/commit/55ea0719e3383f52cec434c6fcb5e6776b741d48
You should definitely consider moving up to the latest build of
LilyPond. It may be called "unstable" for official reasons, but it is
actually quite stable for practical purposes.
-- Aaron Hill
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur
On Fri, Mar 15, 2019 at 11:34 AM Aaron Hill wrote:
> I thought articulate.ly was *only* for \midi, and its modifications are
> not intended to be printed.
The full work from which the tiny example is taken generates both
printed output and MIDI output. The structure of the full work is
something like:
\include "articulate.ly"
stringpart = { [music] }
\book {
% generated printed output
\bookpart {
\score { \stringpart }
\layout { }
}
% using articulate, generate MIDI output
\bookpart {
\score { \unfoldRepeats \articulate \stringpart }
\midi { }
}
}
(When I say "something like" I mean that this is still a
simplification of the structure of the full work, which actually
contains more parts, i.e., multiple staves, multiple voices.)
> Or is this an issue where the modifications are inappropriate resulting
> in bad MIDI output?
The MIDI output seems great. What's getting screwed up is just the
printed output.
Cheers
Edward
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur
On 2019-03-15 8:50 am, Edward McGuire wrote: <<\include "articulate.ly">> adds an unwanted slur to the printed score, and causes slur warnings in the log. I can reproduce the problem using this tiny example. The example does not call for slurs, but a slur gets added to the printed score. [ . . . ] If I comment out <<\include "articulate.ly">>, I do not get the slur or the warnings. In real world music, I use <<\articulate>> in the score. The error is reproducible whether or not I use <<\articulate>>. I thought articulate.ly was *only* for \midi, and its modifications are not intended to be printed. Or is this an issue where the modifications are inappropriate resulting in bad MIDI output? -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Windows Lilypond 2.18.2 articulate.ly adds an unterminated slur
<<\include "articulate.ly">> adds an unwanted slur to the printed
score, and causes slur warnings in the log. I can reproduce the
problem using this tiny example. The example does not call for slurs,
but a slur gets added to the printed score.
\version "2.18.2"
\include "english.ly"
\include "articulate.ly"
part = {
\time 6/8
\relative d' {
\set tieWaitForNote = ##t
\appoggiatura { d8[ ~ a' ~ fs'] ~ } 4. r4. |
\appoggiatura { d8[ ~ a' ~ fs'] ~ } 4. r4. |
}
}
\score {
\part
}
Here is the log.
Processing `unterminated-slur.ly'
Parsing...
Interpreting music...
warning: cannot end slur
warning: unterminated slur
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `unterminated-slur.ps'...
Converting to `./unterminated-slur.pdf'...
Success: compilation successfully completed
If I comment out <<\include "articulate.ly">>, I do not get the slur
or the warnings.
In real world music, I use <<\articulate>> in the score. The error is
reproducible whether or not I use <<\articulate>>.
I looked at existing defects. #5389 "partcombine warns about
unterminated slur" was suspicious, but I'm not calling <>
so I really don't know that it's the same.
Cheers
Edward
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
On 03/03/2019 16:36:31, "DaveAtkinson" wrote: The second reason, if I were to write a staff as two lines, all the parts where there is effectively only a single voice look horrible, because all the rests and note stems look wrong. This is where you need to learn about "\oneVoice" and "\voiceOne", "\voiceTwo" etc commands, and maybe the staff property: "\consists "Merge_rests_engraver"". It took me a while, not because the documentation is lacking, but because it took me a while to realise that the facilities were even there; Lilypond is a large package! Paul ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
"DaveAtkinson" wrote in message
news:1551630991699-0.p...@n5.nabble.com...
Dear LilyPond folks
Thanks so much for taking an interest. First, I forgot two important
pieces
of information - yes, I am using Windows... (hangs head in shame) and it
has
16 Gb of memory.. The OS is 64 bit, but I don't suppose that matters to
lilypond as compiled for windows..?
So interesting... it is clear that overuse of the << \\ >> construct
causes
issues. I would welcome comments about how to re-write the score without
it.
If the correct way to do it is
then an affirmation would be sufficient rather than a tutorial, which
would
be greatly appreciated otherwise ;-).
I can't see your example, but I would do your first two bars like this:
global = {
\key f \major
\time 3/4
}
rhnotesupper = \relative c' {
\clef treble
\global
\tempo 4=83
s4 s 16-.( -. -. -.) |
\voiceOne -.( -. -. -.) \oneVoice 16-.( -.
-. -.) -.( -. -. -.) |
}
rhnoteslower = \relative c' {
\clef treble
\global
\tempo 4=83
s1*3/4 |
\voiceTwo 4 s s |
}
lhnotesupper = \relative c {
\clef bass
\global
\voiceOne 16-.( -. -. -.) -.( -.
-. -.) \oneVoice 4 |
s |
}
lhnoteslower = \relative c {
\clef bass
\global
\voiceTwo f,,4\sustainOn |
s1*3/4 |
}
\score {
\new PianoStaff \with { instrumentName = #"Piano" }
<<
\new Staff = "upper"
<<
\new Voice = "top" \rhnotesupper
\new Voice = "next" \rhnoteslower
>>
\new Staff = "lower"
<<
\new Voice = "topLH" \lhnotesupper
\new Voice = "nextLH" \lhnoteslower
>>
>>
\layout { }
\midi { }
}
The first, I confess to sometimes using lilypond to generate midi files
from
piano accompaniments so that I can practise the main part when I don't
have
the luxury of a pianist (which is almost all the time). I am therefore
copying existing scores. In order to eliminate (!) mistakes, I do it a few
bars at a time, as corrections are much easier for me to do in the last
few
bars. If I were to use two voices for the whole of a staff, once I'd
written
the first staff, going back and finding the places where two voices are
required, and filing in all the spaces, is tedious and taxing for me...
I create music (normally from renaissance polyphony) and simply have four
voices and add a few bars to each at a time. I then compile, check and add
a few more bars to each. My only other suggestion (which Kieren, a regular
contributor and composer would agree with) is that you might find not using
\relative means it's easier to keep track of which octave you're currently
in.
The second reason, if I were to write a staff as two lines, all the parts
where there is effectively only a single voice look horrible, because all
the rests and note stems look wrong.
\oneVoice, \voiceOne, \voiceTwo etc. are your friends.
--
Phil Holmes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
DaveAtkinson writes: > Dear LilyPond folks > > So interesting... it is clear that overuse of the << \\ >> construct > causes issues. In this case it's more like "triggers" rather than "causes" issues. I'd guess that the kind of weak continuation caused by << \context "1" ... \context "2" ... >> << \context "1" ... \context "2" >> triggers the problem. Are there grace notes involved, too? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Dear LilyPond folks Thanks so much for taking an interest. First, I forgot two important pieces of information - yes, I am using Windows... (hangs head in shame) and it has 16 Gb of memory.. The OS is 64 bit, but I don't suppose that matters to lilypond as compiled for windows..? So interesting... it is clear that overuse of the << \\ >> construct causes issues. I would welcome comments about how to re-write the score without it. If the correct way to do it is then an affirmation would be sufficient rather than a tutorial, which would be greatly appreciated otherwise ;-). I would like to address the point about why people do this - although obviously I can only speak for myself, and I have two reasons. The first, I confess to sometimes using lilypond to generate midi files from piano accompaniments so that I can practise the main part when I don't have the luxury of a pianist (which is almost all the time). I am therefore copying existing scores. In order to eliminate (!) mistakes, I do it a few bars at a time, as corrections are much easier for me to do in the last few bars. If I were to use two voices for the whole of a staff, once I'd written the first staff, going back and finding the places where two voices are required, and filing in all the spaces, is tedious and taxing for me... The second reason, if I were to write a staff as two lines, all the parts where there is effectively only a single voice look horrible, because all the rests and note stems look wrong. Very best regards, and thanks to all who've replied, Dave -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Thomas Morley writes: > Am So., 3. März 2019 um 08:18 Uhr schrieb Andrew Bernard > : >> >> HI James, >> >> This elusive defect comes up a lot. See the User archives. I have seen in >> on Linux also, > > Yep, me too. Though I'm surprised to see the problem on this fairly short > score. > > ### > > Anyway, what _is_ the problem? > > As far as I can tell, creating lots and lots of new contexts > overcharges lilypond. With some OS earlier, with Linux obviously > later. If the score is small, the "overcharge" does not appear like a necessity. It probably just increases the probability of a garbage collection happening at an inopportune point of time. We don't really want to have windows of instability like that. But we haven't had something dependable enough to actually trace down the problem that is happening. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Am So., 3. März 2019 um 08:18 Uhr schrieb Andrew Bernard
:
>
> HI James,
>
> This elusive defect comes up a lot. See the User archives. I have seen in
> on Linux also,
Yep, me too. Though I'm surprised to see the problem on this fairly short score.
###
Anyway, what _is_ the problem?
As far as I can tell, creating lots and lots of new contexts
overcharges lilypond. With some OS earlier, with Linux obviously
later.
Lots and lots of contexts may be created by excessive use of << \\ >>
or (rarely) by some user-defined procedure.
Look at this short example, where I coded an engraver to display
contexts-info, duplicated contexts are discarded!
#(define (my-engraver ctx)
(let ((new-contexts '()))
`(
(listeners
(AnnounceNewContext
.
,(lambda (engraver event)
(set! new-contexts (cons event new-contexts)
(finalize
.
,(lambda (trans)
(let ((ctx-type-id
(map
(lambda (c)
(let ((creator (ly:event-property c 'creator)))
(list
(ly:event-property creator 'type)
(ly:event-property creator 'id
(delete-duplicates (reverse new-contexts)
(format #t
"\nInside this score ~a new contexts are created. Type and id are:\n~y"
(length ctx-type-id)
ctx-type-id)))
\score {
{
<< c''1 \\ c' >>
R1
<< d''1 \\ d' >>
}
\layout {
\context {
\Score
\consists \my-engraver
}
}
}
It returns:
Inside this score 6 new contexts are created. Type and id are:
((Staff "")
(Voice "1")
(Voice "2")
(Voice "")
(Voice "1")
(Voice "2"))
And this music is close to minimal !!!
Applying the same engraver to the OP's original code returns:
Inside this score 56 new contexts are created. Type and id are:
((PianoStaff "")
(Staff "upper")
(Dynamics "dyn")
(Staff "lower")
(Voice "")
(Voice "")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2")
(Voice "1")
(Voice "2"))
###
What does the docs say?
From
http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#single_002dstaff-polyphony
"
The double backslash construct
The << {…} \\ {…} >> construct, where the two (or more) expressions
are separated by double backslashes, behaves differently to the
similar construct without the double backslashes: all the expressions
within this construct are assigned to new Voice contexts. These new
Voice contexts are created implicitly and are given the fixed names
"1", "2", etc.
[...]
This syntax can be used where it does not matter that temporary voices
are created and then discarded.
[...]
In all but the simplest works it is advisable to create explicit Voice
contexts as explained in Contexts and engravers and Explicitly
instantiating voices.
"
Imho, it's all there:
<< \\ >> creates _new_ Voices.
Use it where it _does not matter_
Recommended are explicit Voices.
Can it be improved?
Not sure. Opinions?
Suggestions/sollutions
(1) Use explicit Voices, meaning enter the entire music of a Voice in
a (named) Voice, kept alive, and finally join it in a Staff in \score
I'm aware some people want to keep measures (with all Voices)
together, << \\ >> is a bad way to do so, though.
Instead one could use:
(2) \parallelMusic
See:
http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#writing-music-in-parallel
(3)
If one really, really wants to keep the << \\ >> construct a method
could be to explicitely create Voices named "1" and "2&q
Re: Lilypond 2.19.82 with multiple voices seems to fail
Hi Paul, I have not actually said to the OP it is 'wrong', just that it's not a good way to write, as it turns out. I knew somebody would chime in with this exact comment. Fact is, it's completely valid code, and I pointed this out. The issue is that it just causes problems for lilypond in reality, and there is a more 'normal' way tor write that completely obviates the problem. Each to his own, but I find that style very difficult to read. I did also suggest that an addition to the NR may be a good idea. But I know where that suggestion will lead - the NR is a reference manual, and deliberately terse. This sort of information is tutorial in nature, and belongs somewhere else, but I don't know where. Also, there are good ways and bad ways to use lilypond. People are free to do what they want. People are free to not use bar checks, and then they get into all sorts of trouble. We cant mandate their use, but it's a really good idea, and does no harm. Similarly in this case. This now seems to be becoming emotionally charged, so I will depart this thread. If the OP is interested to see another way of setting piano music, he is welcome to contact me off list, as I have offered. Andrew On Sun, 3 Mar 2019 at 19:48, Paul Hodges wrote: > > > Now my main profession was as a computer programmer, so I well > understand the difficulty of finding a fix for a bug like this. I also > appreciate that in a substantial software development which relies on > voluntary effort (and is the most wonderful of such projects that I > know!), this may be a thing that never gets fixed. But an honest > statement of that, perhaps as a warning in the documentation of the > multiple voices feature, is what is required - rather than telling > people that they are in some way wrong to write such a Lilypond file. > > Paul > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
On 2019-03-02 11:15 pm, Andrew Bernard wrote: If the OP is interested, I can recast his score in what I consider a more normal way - it would be very little effort, in order to show how to do it. This might be a good thing for more than just OP. As you mentioned, a number of folks have found themselves going down the path that leads to this issue. Having a good side-by-side that shows an alternate structure would be useful to direct folks to. Ultimately, this could be make for a post on the blog. And I, for one, would appreciate seeing your ideas on file structure for piano scores. To date, I have only needed to typeset vocal parts. However, engraving a piano part is something that I likely will need to do in the coming months. I would greatly appreciate any additional reference materials. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Hello, On 03/03/2019 01:54, Andrew Bernard wrote: You won't find bug reports about this, but if you search the user archives you will find this comes up a lot. I don't haunt the user lists (I've enough to do keeping up here!) but I wonder if there has been any 'finger-in-the-air' check here to see which OS these users run LP on? I saw Thomas' comment about it working fine on his system but for instance, we know from experience that Windows and Mac Builds can behave 'differently' in these odd cases. So @Dave, what OS are you using and again just for comment, what RAM do you have installed (I seem to recall some 'memory leak' type issues that would simply fall over on Windows in a simillar fashion? If Dave is using Windows then quite often you will see something in the Application Event Logs (not that will necessarily help us but it can sometimes point somewhere). *If* we could reproduce this on an OS (and we have David's ly file now) then perhaps it would be useful for a tracker? Regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
HI James, This elusive defect comes up a lot. See the User archives. I have seen in on Linux also, when attempting to help people with it in the past. But I cant see it is worth expending effort on it since it is, simply put, a stilted way to enter music on lilypond. I am unable to see the necessity for it. The example is incredibly simple piano music, and this way of entering the score offers nothing significant or crucial or essential - except bugs in compilation. Plus, it's also hard to read the code. Perhaps there should be something in the learning manual that indicates this is not the best way to enter music. Or something. If the OP is interested, I can recast his score in what I consider a more normal way - it would be very little effort, in order to show how to do it. Andrew On Sun, 3 Mar 2019 at 18:07, James wrote: > Hello, > > On 03/03/2019 01:54, Andrew Bernard wrote: > > You won't find bug reports about this, but if you search the user > archives > > you will find this comes up a lot. > > I don't haunt the user lists (I've enough to do keeping up here!) but I > wonder if there has been any 'finger-in-the-air' check here to see which > OS these users run LP on? > > I saw Thomas' comment about it working fine on his system but for > instance, we know from experience that Windows and Mac Builds can behave > 'differently' in these odd cases. > > So @Dave, what OS are you using and again just for comment, what RAM do > you have installed (I seem to recall some 'memory leak' type issues that > would simply fall over on Windows in a simillar fashion? If Dave is > using Windows then quite often you will see something in the Application > Event Logs (not that will necessarily help us but it can sometimes point > somewhere). > > *If* we could reproduce this on an OS (and we have David's ly file now) > then perhaps it would be useful for a tracker? > > Regards > > James > > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Hello Dave, We keep seeing this a lot on the various lilypond lists. I don't think anybody really knows why, but having lots of voices coming and going like you have seems to throw errors with the compiler under poorly defined conditions. With the politest respect, can I say this? You are not the only one that writes like this. While is is legal, and parses, and works to a certain extent, it seems to me that people have got hold of the wrong end of the stick. Basically one would normally write a set of continuous voices for the piece, not one per bar. I can't fathom where that idea came from, but it seems to be a recurring meme. The best advice is to write in the commonly accepted way. I write massively complex piano music and using the normal lilypond way of multiple long running voices, several per hand for piano, works fine for scores well over 200 pages long. So, yes, I think it's a bug, but because it is a stilted usage for which there is a perfectly good solution - write more normal code - it's unlikely to get fixed, as it is very elusive. As others say, it's hard to establish just exactly what pushes it over the edge. Another comment is that this appears to be perfectly normal, and indeed simplistic, piano music - I cant see any musical reason for what you are doing. This answer is not meant to offend you. But it's funny how this style of writing keeps popping up. Perhaps there is something in the NR that gives people the wrong impression when reading about multiple voices, maybe? You won't find bug reports about this, but if you search the user archives you will find this comes up a lot. Andrew ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
Am Sa., 2. März 2019 um 23:58 Uhr schrieb DaveAtkinson : > > Hi LilyPond folks, > > I think I've found a bug in the above version of LilyPond and I can't find > another report of it, so I thought I'd report it. Apologies if it's a known > issue. > > I'm trying to produce a score of a piano accompaniment in which I'm making > extensive use of multiple voices in a bar. These seem to work at first but > then start failing. By failing, I mean lilypond quits after the > "interpreting music" message with no errors, no log, and no output. The > score is quite long, so I've uploaded it. The failing lines are commented > out with the word 'fail' inside the comment (and a line of spaces outside > the comment to keep the staves lining up). There are 3 examples in the file > (all in the variable 'lhnotes' which are the notes for the piano left hand > part). The final line that I've written also fails and is not commented out. > > Aria_-_Mon_coeur_s_ouvre_a_ta_voix_-_C.ly > <http://lilypond.1069038.n5.nabble.com/file/t5797/Aria_-_Mon_coeur_s_ouvre_a_ta_voix_-_C.ly> > > Any thoughts would be appreciated. > > Cheers, > Dave Works fine here on Ubuntu 18.04 64-bit with lilypond 2.18.2 and 2.19.82 Cheers, Harm ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.19.82 with multiple voices seems to fail
On 02/03/2019 22:36:39, "DaveAtkinson" wrote: >I'm trying to produce a score of a piano accompaniment in which I'm making >extensive use of multiple voices in a bar. These seem to work at first but >then start failing. By failing, I mean lilypond quits after the >"interpreting music" message with no errors, no log, and no output. I've observed this instability with multiple voices newly created in lots of bars, but never been able to tie it down to anything other than "complexity", even in a single page of piano music. Sometimes changing a single note can bring it on; sometimes adding another bar (with yet more voices!) makes it work again. I conjecture that creating new voices in every bar puts a strain on the memory management which it is not up to. I have changed to the style of having just a few multiple voices which run for the length of the piece, only adding local voices occasionally when called for. Writing like this the problem doesn't appear. Paul _______ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond 2.19.82 with multiple voices seems to fail
Hi LilyPond folks, I think I've found a bug in the above version of LilyPond and I can't find another report of it, so I thought I'd report it. Apologies if it's a known issue. I'm trying to produce a score of a piano accompaniment in which I'm making extensive use of multiple voices in a bar. These seem to work at first but then start failing. By failing, I mean lilypond quits after the "interpreting music" message with no errors, no log, and no output. The score is quite long, so I've uploaded it. The failing lines are commented out with the word 'fail' inside the comment (and a line of spaces outside the comment to keep the staves lining up). There are 3 examples in the file (all in the variable 'lhnotes' which are the notes for the piano left hand part). The final line that I've written also fails and is not commented out. Aria_-_Mon_coeur_s_ouvre_a_ta_voix_-_C.ly <http://lilypond.1069038.n5.nabble.com/file/t5797/Aria_-_Mon_coeur_s_ouvre_a_ta_voix_-_C.ly> Any thoughts would be appreciated. Cheers, Dave -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
New lilypond 2.21.0 installers
I tried an install into /opt/lilypond. I do not have access to /opt but the folder /opt/lilypond is completely mine. The help says it will install into PREFIX/lilypond, but it also tries to install scripts outside this directory in PREFIX/bin. It refuses to install into an existing (even empty) directory. While this may be good in some cases, it would be nice if this could be overridden. Fun fact: The script first checks if the directory exists and bails out if so. If not, it carefully checks if the directory exists before creating it :). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
RE: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
Hello, -Original Message- From: bug-lilypond On Behalf Of Urs Liska Sent: 15 January 2019 09:38 To: bug-lilypond@gnu.org Subject: Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win) Am 15.01.19 um 10:34 schrieb samaru...@aim.com: > Thank you, Carl, for all your research! > Normally I'm a searcher and not a questioner, but I hadn't researched > StemUp/Down syndrome extensively yet, so I simply added it as a > postscript to my more problematic concern, since I also saw it as an > XML import error and not as a feature. > I tried the command line options --nsd/--no-stem-directions and they > worked perfectly. It wouldn't be bad to add the new options to the > official documentation, or is it just for the stable version? Indeed, http://lilypond.org/doc/v2.19/Documentation/usage/invoking-musicxml2ly doesn't document --nsd, so that should be considered a bug. *** Created: https://sourceforge.net/p/testlilyissues/issues/5460/ Regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
Am 15.01.19 um 10:34 schrieb samaru...@aim.com: Thank you, Carl, for all your research! Normally I'm a searcher and not a questioner, but I hadn't researched StemUp/Down syndrome extensively yet, so I simply added it as a postscript to my more problematic concern, since I also saw it as an XML import error and not as a feature. I tried the command line options --nsd/--no-stem-directions and they worked perfectly. It wouldn't be bad to add the new options to the official documentation, or is it just for the stable version? Indeed, http://lilypond.org/doc/v2.19/Documentation/usage/invoking-musicxml2ly doesn't document --nsd, so that should be considered a bug. Urs Andreas Am 15.01.2019 um 05:36 schrieb Carl Sorensen: On 1/14/19, 9:32 PM, "Carl Sorensen" wrote: On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that would probably be another separate issue). Further searching for philomelos (which was a fork of musicxml2ly that was apparently reintegrated into lilypond in the commit I referenced earlier) led to the following: https://github.com/Philomelos/lilypond-musicxml2ly-dev which contains the following in its release notes: v0.1.13: added the command line options --nsd / --no-stem-directions to ignore stem direction indications given in MusicXML, and use lilypond's automatic stemming instead. You might try using the command option --no-stem-directions or --nsd and see if that eliminates the spurious stem direction commands. HTH, Carl And LilyPond issue #4751 (https://sourceforge.net/p/testlilyissues/issues/4751/?page=1) confirms that the stem directions and the new command-line option were added as part of 2.19.44 HTH, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
Thank you, Carl, for all your research! Normally I'm a searcher and not a questioner, but I hadn't researched StemUp/Down syndrome extensively yet, so I simply added it as a postscript to my more problematic concern, since I also saw it as an XML import error and not as a feature. I tried the command line options --nsd/--no-stem-directions and they worked perfectly. It wouldn't be bad to add the new options to the official documentation, or is it just for the stable version? Andreas Am 15.01.2019 um 05:36 schrieb Carl Sorensen: On 1/14/19, 9:32 PM, "Carl Sorensen" wrote: On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that would probably be another separate issue). Further searching for philomelos (which was a fork of musicxml2ly that was apparently reintegrated into lilypond in the commit I referenced earlier) led to the following: https://github.com/Philomelos/lilypond-musicxml2ly-dev which contains the following in its release notes: v0.1.13: added the command line options --nsd / --no-stem-directions to ignore stem direction indications given in MusicXML, and use lilypond's automatic stemming instead. You might try using the command option --no-stem-directions or --nsd and see if that eliminates the spurious stem direction commands. HTH, Carl And LilyPond issue #4751 (https://sourceforge.net/p/testlilyissues/issues/4751/?page=1) confirms that the stem directions and the new command-line option were added as part of 2.19.44 HTH, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that would probably be another separate issue). Further searching for philomelos (which was a fork of musicxml2ly that was apparently reintegrated into lilypond in the commit I referenced earlier) led to the following: https://github.com/Philomelos/lilypond-musicxml2ly-dev which contains the following in its release notes: v0.1.13: added the command line options --nsd / --no-stem-directions to ignore stem direction indications given in MusicXML, and use lilypond's automatic stemming instead. You might try using the command option --no-stem-directions or --nsd and see if that eliminates the spurious stem direction commands. HTH, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
On 1/14/19, 9:32 PM, "Carl Sorensen" wrote:
On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote:
PS Windows+Mac: StemUp/Downs appear everywhere after the import, this
was not the case with older LilyPond versions, e.g. 2.19.31, which I
still use on my Windows system because of the errors listed above (I
know that would probably be another separate issue).
Further searching for philomelos (which was a fork of musicxml2ly that was
apparently reintegrated into lilypond in the commit I referenced earlier) led
to the following:
https://github.com/Philomelos/lilypond-musicxml2ly-dev
which contains the following in its release notes:
v0.1.13:
added the command line options --nsd / --no-stem-directions to ignore stem
direction indications given in MusicXML, and use lilypond's automatic stemming
instead.
You might try using the command option --no-stem-directions or --nsd and
see if that eliminates the spurious stem direction commands.
HTH,
Carl
And LilyPond issue #4751
(https://sourceforge.net/p/testlilyissues/issues/4751/?page=1) confirms that
the stem directions and the new command-line option were added as part of
2.19.44
HTH,
Carl
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)
On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that would probably be another separate issue). Having only briefly looked at it, it appears that a new dictionary that uses \stemUp, \stemDown, and \stemNeutral was added to xml2ly in commit author John Gourlay 2016-02-18 21:47:49 -0500 committer John Gourlay 2016-02-18 21:47:49 -0500 commit 2ab5d80245dcab194daea64ec83ded3ec8252e51 (patch) I have not checked whether this commit is the source of the spurious stemXXX commands. But I do note that it comes after 2.19.31. I don't do any musicXML import, so I'm a poor person to check this out further, but I thought I could at least point you in this promising direction. HTH, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond can't engrave 16 pages of music
On 2018-12-21 4:53 pm, Aaron Hill wrote:
I tried the following approach to break up the piece into three scores:
\score {
{ \time 4/4 \repeat unfold 1000 { c4 d e f } }
}
\score {
{ \set Score.currentBarNumber = #1001 \bar ""
\time 4/4 \repeat unfold 1000 { f1 } }
\layout { indent = 0 }
}
\score {
{ \set Score.currentBarNumber = #2001 \bar ""
\time 4/4 \repeat unfold 1000 { c4 d e f } }
\layout { indent = 0 }
}
This only took 42 seconds to complete and I believe it peaked under
2GiB.
I reran my multi-score version using time -v:
Command being timed: "lilypond allocbug.ly"
User time (seconds): 32.29
System time (seconds): 9.48
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:42.05
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1978288
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 1003509
Voluntary context switches: 0
Involuntary context switches: 0
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Providing this is accurate, I suspect this approach may still be too
much for a 32-bit process, given the overhead of the program executable,
DLLs and the like.
-- Aaron Hill
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond can't engrave 16 pages of music
On 2018-12-21 4:28 pm, Karlin High wrote:
On 12/21/2018 5:56 PM, Kieren MacMillan wrote:
It's
only 16 pages and LilyPond crashes.
That looks like a [serious] bug to me. I’ve cc'ed the bug list.
Reproduced crash on LilyPond 2.19.80, Windows 7 Pro 64-bit SP1, Intel
Core i5-3450, 24GB RAM.
At crash, lilypond-windows.exe in Task Manager as showing 1,080,744K
of Memory (Private Working Set.) Perhaps this problem is similar to
other large-memory-use crashes reported lately on Windows?
Almost definitely. I ran this in using my setup which is 64-bit Linux
LilyPond running under WSL on 64-bit Windows 10. Peak memory usage
during compilation was around 4.4GiB, so there is no way a 32-bit
process could do this.
It took my computer about two minutes to process all 3000 measures,
which by the way typeset to 25 pages in the end--many of which are
virtually identical save for page and measure numbers.
I tried the following approach to break up the piece into three scores:
\score {
{ \time 4/4 \repeat unfold 1000 { c4 d e f } }
}
\score {
{ \set Score.currentBarNumber = #1001 \bar ""
\time 4/4 \repeat unfold 1000 { f1 } }
\layout { indent = 0 }
}
\score {
{ \set Score.currentBarNumber = #2001 \bar ""
\time 4/4 \repeat unfold 1000 { c4 d e f } }
\layout { indent = 0 }
}
This only took 42 seconds to complete and I believe it peaked under
2GiB.
-- Aaron Hill
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond can't engrave 16 pages of music
On 12/21/2018 5:56 PM, Kieren MacMillan wrote: It's only 16 pages and LilyPond crashes. That looks like a [serious] bug to me. I’ve cc'ed the bug list. Reproduced crash on LilyPond 2.19.80, Windows 7 Pro 64-bit SP1, Intel Core i5-3450, 24GB RAM. At crash, lilypond-windows.exe in Task Manager as showing 1,080,744K of Memory (Private Working Set.) Perhaps this problem is similar to other large-memory-use crashes reported lately on Windows? -- Karlin High Missouri, USA ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: LilyPond can't engrave 16 pages of music
Hi Reggie, > I am trying to understand theoretically why this is failing. It's only 16 > pages. I am a minimalist composer so as a test I tried this extreme > situation. But yet I don't quite agree rather that it's that extreme. It's > only 16 pages and LilyPond crashes. That looks like a [serious] bug to me. I’ve cc'ed the bug list. Thanks! Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Request PATCH to ensure LilyPond SVG compatibility with Scribus
Hello, (cc-ing the bug list) On 11/10/2018 2:56 pm, d_l wrote: I have joined this list today just for the purpose of facilitating a link between Scribus and LilyPond forums and posting one PATCH suggestion before next imminent release of lilypond. Over at the Scribus forum a small issue prevents svg output from lilypond commandline being rendered in Scribus the desktop publishing tool. PNG output works. The Scribus issue refers to SVG fill attribute "currentColor" being used instead of "black". Perhaps at this 11th hour before next release this might be looked at? LilyPond printing through Scribus would make a nice team. References: https://bugs.scribus.net/view.php?id=15454 http://lilypond.1069038.n5.nabble.com/rsvg-view-can-t-display-SVG-files-created-by-lilypond-tc191462.html#a191496 Here is a quote from a Scribus forum snr. member: "the lillypond authors seem to know about the issue but (probably) wrongly decided to do nothing... can somebody who uses lillypond try to post a bug report for this issue with jean's explanation from the bug tracker and telling them that this shortcut makes hard to import the svg in scribus? (i mean, they could keep track of the color used and always set it explicitly, instead of relying on a default value that seems not to be 100% standardized)." I have created https://sourceforge.net/p/testlilyissues/issues/5429/ Regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Request PATCH to ensure LilyPond SVG compatibility with Scribus
Hello, (cc-ing the bug list) On 11/10/2018 2:56 pm, d_l wrote: I have joined this list today just for the purpose of facilitating a link between Scribus and LilyPond forums and posting one PATCH suggestion before next imminent release of lilypond. Over at the Scribus forum a small issue prevents svg output from lilypond commandline being rendered in Scribus the desktop publishing tool. PNG output works. The Scribus issue refers to SVG fill attribute "currentColor" being used instead of "black". Perhaps at this 11th hour before next release this might be looked at? LilyPond printing through Scribus would make a nice team. References: https://bugs.scribus.net/view.php?id=15454 http://lilypond.1069038.n5.nabble.com/rsvg-view-can-t-display-SVG-files-created-by-lilypond-tc191462.html#a191496 Here is a quote from a Scribus forum snr. member: "the lillypond authors seem to know about the issue but (probably) wrongly decided to do nothing... can somebody who uses lillypond try to post a bug report for this issue with jean's explanation from the bug tracker and telling them that this shortcut makes hard to import the svg in scribus? (i mean, they could keep track of the color used and always set it explicitly, instead of relying on a default value that seems not to be 100% standardized)." I have created https://sourceforge.net/p/testlilyissues/issues/5429/ Regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug-lilypond Digest, Vol 189, Issue 17
On Sun, Aug 26, 2018 at 7:04 AM, wrote:
>
> Message: 3
> Date: Sun, 26 Aug 2018 11:43:44 +0200
> From: Thomas Morley
> To: Pierre Perol-Schneider
> Cc: bug-lilypond
> Subject: Re: Doc 2.4.2: Indicating harmonics and dampened notes
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
>
> 2018-08-26 11:14 GMT+02:00 Pierre Perol-Schneider
> :
>> Hi Bug Squad,
>> See:
>> http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>> And:
>> http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>>
>> 1. I don't understand the reason to put the NoteHead defs at a Staff level.
>
> Can't see a specific reason here. So I'd vote for deleting "Staff".
>
>> 2. Maybe a whole note is not the best example to show the 'harmonic-mixed
>> result.
>>
>> How about changing this snippet:
>>
>> \relative c' {
>> \clef "treble_8"
>> \override Staff.NoteHead.style = #'harmonic-mixed
>> d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
>> }
>>
>> To:
>>
>> \relative c' {
>> \clef "treble_8"
>> \override NoteHead.style = #'harmonic-mixed
>> d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
>> }
>>
>> Cheers,
>> Pierre
>
>
> Agreed. Also, why not delete some of the superfluous brackets in the
> markup? Only keeping the surrounding ones for better viewable
> structure. I.e.
> \markup { \italic \fontsize #-2 "harm. 12" }
Bad suggestion. Currently, \italic takes one argument, the next token
(unless it's an opening bracket). If you want to change it so that
\italic takes the rest of the arguments (Scheme-style), then previous
code like
\italic "this is italic " "and this isn't"
will break.
--- Chris
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond-invoke-editor runs twice (2.19.82)
Il giorno mer 1 ago 2018 alle 17:21, Federico Bruni ha scritto: The first of below files is actually a symlink to another file: lilypond-invoke-editor -> /usr/local/bin/lilypond-wrapper.guile I made a backup copy of that file, then removed "-e main" from the original and now lilypond-invoke-editor is run only once. Good catch! I'll wait for comments from developers and then add an issue to the tracker. I guess it's a GUB issue. I've added it to the tracker: https://sourceforge.net/p/testlilyissues/issues/5396/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond-invoke-editor runs twice (2.19.82)
Hey Aaron I've just tried using nano as editor and I see that indeed I have to close it twice: $ lilypond-invoke-editor textedit:///home/myfile.ily:1:3:4 lilypond-invoke-editor (GNU LilyPond) 2.19.82 lilypond-invoke-editor (GNU LilyPond) 2.19.82 When I use gedit, it's the same: I close one window and then another one pops up. The first of below files is actually a symlink to another file: lilypond-invoke-editor -> /usr/local/bin/lilypond-wrapper.guile I made a backup copy of that file, then removed "-e main" from the original and now lilypond-invoke-editor is run only once. Good catch! I'll wait for comments from developers and then add an issue to the tracker. I guess it's a GUB issue. PS I've just realized that the bash script is what I needed to make lilypond-invoke-editor work on Mac and Windows. Tested successfully on Mac only so far. I'll try to write a blog post about this before I go in vacation (next Monday). Thanks Federico Il giorno mer 11 lug 2018 alle 0:35, Aaron Hill ha scritto: While getting point-and-click working in my setup, I ran across this minor issue. After installation, there are two `lilypond-invoke-editor` files: /usr/local/bin/lilypond-invoke-editor /usr/local/lilypond/usr/bin/lilypond-invoke-editor The first is a simple script that sets some environment and invokes the LilyPond version of Guile with the second file, which is the actual Scheme program. The script uses the `-e main` option which causes Guile to invoke the named function; however, there is already an explicit invocation of `main` at the end of the Scheme program. This results in the functionality running twice. I suppose that, depending on how you have your EDITOR or LYEDITOR variables configured, you might not notice a double launch; but I was certainly confused at first why I was getting repeated behavior. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
lilypond-invoke-editor runs twice (2.19.82)
While getting point-and-click working in my setup, I ran across this minor issue. After installation, there are two `lilypond-invoke-editor` files: /usr/local/bin/lilypond-invoke-editor /usr/local/lilypond/usr/bin/lilypond-invoke-editor The first is a simple script that sets some environment and invokes the LilyPond version of Guile with the second file, which is the actual Scheme program. The script uses the `-e main` option which causes Guile to invoke the named function; however, there is already an explicit invocation of `main` at the end of the Scheme program. This results in the functionality running twice. I suppose that, depending on how you have your EDITOR or LYEDITOR variables configured, you might not notice a double launch; but I was certainly confused at first why I was getting repeated behavior. -- Aaron Hill ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
