Re: Glitch in the documentation?

[Andrew Bernard via bug-lilypond]

Not that it is any help, but I recall reporting the same thing about 
Catalan some years ago.


Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Glitch in the documentation?

[Andrew Bernard via bug-lilypond]

Would not appear to be a browser issue. Mine is English on English 
Windows 11. That page shows Catalan.


Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Glitch in the documentation?

[Andrew Bernard via bug-lilypond]

Also Catalan for me.

Andrew




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: LP v.2.23.13 bin has no executable rights

[Andrew Bernard via bug-lilypond]

Oh - sorry for the noise. I thought it was an ls listing. What a 
dunderhead I am - I did not read carefully enough.


Andrew

On 4/10/2022 6:06 pm, Jean Abou Samra wrote:

The output Jonas shared is from "tar tvf" (list files
inside the archive without extracting), so it has nothing
to do with his installation, it's just the way things
are stored in the archive. By default, extraction
("tar xvf") makes you the owner of the extracted files
in spite of the original owner, although I read that the
--same-owner flag changes that.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: LP v.2.23.13 bin has no executable rights

[Andrew Bernard via bug-lilypond]

No criticism of Lilypond, as I trust it to behave, but for me having 
apps installed as root when not necessary is not a good idea. Just 
sayin' (lest others copy this pattern from reading this thread).


Andrew


On 4/10/2022 7:56 am, Jonas Hahnfeld via bug-lilypond wrote:

On Mon, 2022-10-03 at 09:00 +0200, Pierre Perol-Schneider wrote:

Hi Squad team,
See:
./bin:
total 13228
-rw-r--r-- 1 pierre pierre  418 sept. 18 15:11 abc2ly
-rw-r--r-- 1 pierre pierre  422 sept. 18 15:11 convert-ly
-rw-r--r-- 1 pierre pierre  418 sept. 18 15:11 etf2ly
-rw-r--r-- 1 pierre pierre  420 sept. 18 15:11 lilymidi
-rw-r--r-- 1 pierre pierre 13507344 sept. 18 15:11 lilypond
-rw-r--r-- 1 pierre pierre  425 sept. 18 15:11 lilypond-book
-rw-r--r-- 1 pierre pierre  434 sept. 18 15:11 lilypond-invoke-editor
-rw-r--r-- 1 pierre pierre  420 sept. 18 15:11 lilysong
-rw-r--r-- 1 pierre pierre  419 sept. 18 15:11 midi2ly
-rw-r--r-- 1 pierre pierre  423 sept. 18 15:11 musicxml2ly

The permissions in lilypond-2.23.13-linux-x86_64.tar.gz seem to be fine
on my end:

  $ tar tvf lilypond-2.23.13-linux-x86_64.tar.gz lilypond-2.23.13/bin/
drwxr-xr-x root/root 0 2022-09-18 15:11 lilypond-2.23.13/bin/
-rwxr-xr-x root/root   422 2022-09-18 15:11 lilypond-2.23.13/bin/convert-ly
-rwxr-xr-x root/root   425 2022-09-18 15:11 
lilypond-2.23.13/bin/lilypond-book
-rwxr-xr-x root/root   418 2022-09-18 15:11 lilypond-2.23.13/bin/abc2ly
-rwxr-xr-x root/root   418 2022-09-18 15:11 lilypond-2.23.13/bin/etf2ly
-rwxr-xr-x root/root   419 2022-09-18 15:11 lilypond-2.23.13/bin/midi2ly
-rwxr-xr-x root/root   434 2022-09-18 15:11 
lilypond-2.23.13/bin/lilypond-invoke-editor
-rwxr-xr-x root/root   423 2022-09-18 15:11 lilypond-2.23.13/bin/musicxml2ly
-rwxr-xr-x root/root   420 2022-09-18 15:11 lilypond-2.23.13/bin/lilysong
-rwxr-xr-x root/root   420 2022-09-18 15:11 lilypond-2.23.13/bin/lilymidi
-rwxr-xr-x root/root  13507344 2022-09-18 15:11 lilypond-2.23.13/bin/lilypond

How did you extract the archive?

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: Fonts on Arch Linux

[Andrew Bernard]

Hi Carl,

Thank you so much for this really useful information. I do wonder what
happened to the development of the font. Perhaps just abandoned after
ten years or more. Biolinum was an excellent Optima replacement, and I
use it a lot. All I can find nowadays is scrappy partial sets of
dubious provenance on all those free font sites. So to find out about
this proper and high quality ongoing work with so many improvements,
and mathematical typesetting to boot is wonderful.

I very much appreciate your reply, and I would never have found this without it.

Andrew


On Mon, 29 Jun 2020 at 03:32, Carl Sorensen  wrote:

> You can also get a forked continuation of the now non-developed Linux 
> Libertine fonts as  Libertinus, which has Serif, Sans, and Mono variants.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fonts on Arch Linux

[Andrew Bernard]

Thanks Aaron. I didn't give an MWE as it was a preliminary probe to
see if this is a known issue.

Here's the code in question:

  #(define fonts
 (set-global-fonts
  #:roman "Linux Libertine O"
  #:sans "Linux Biolinum O"
  #:typewriter "Linux Libertine Mono O"
  #:factor (/ staff-height pt 20)
  ))

However, I have only recently moved to Arch, so I am setting up all
anew. After a) going nuts and b) exploring everything there is to be
known about fontconfig, I tried deleting all files in ~/.cache, which
includes a lot of fontconfig cache data. Now the issue has gone away.
I suspect, but I can't be sure that this is a subtle issue - the Linux
Libertine and Biolinum original font site seems to have been defunct
for a long time, and while setting up my new system I had to source
the fonts from a whole lot of dubious free font download sites, and
the all seem to be different all in different ways. I think I just had
a bad set of font data cached. Possibly. but clearing the cache solved
this.

I do not know what happened to the original source of these fonts.
They are veyr fine,. and Biolinum is a very good stand in for Optima.

Andrew

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fonts on Arch Linux

[Andrew Bernard]

More strangeness on Arch Linux. The /paper command set-global-fonts is
having no effect, no matter what fonts are specified. I have checked
and rechecked font availability. This occurs in 2.20.0 and 2.21.2. I
have not tried earlier versions.

If I explicitly specify a font name for a markup it works. But I
refuse to edit thousands of markup commands. Something here is
different to my previous Ubuntu systems.

What factors may be affecting this? I'm stumped.

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

[Andrew Bernard]

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

Lilypond 2.20 and 2.21 crash on Arch Linux

[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?

Andrew

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Non default tuplet error with 2.21

[Andrew Bernard]

Using 2.21 from git, the non-default tuplet example in the NR throws an 
error.



\relative c'' {
  \once \override TupletNumber.text =
    #(tuplet-number::non-default-tuplet-denominator-text 7)
  \tuplet 3/2  { c4. c4. c4. c4. }
  \once \override TupletNumber.text =
    #(tuplet-number::non-default-tuplet-fraction-text 12 7)
  \tuplet 3/2  { c4. c4. c4. c4. }
  \once \override TupletNumber.text =
    #(tuplet-number::append-note-wrapper
  (tuplet-number::non-default-tuplet-fraction-text 12 7) "8")
  \tuplet 3/2  { c4. c4. c4. c4. }
  \once \override TupletNumber.text =
    #(tuplet-number::append-note-wrapper
  tuplet-number::calc-denominator-text "4")
  \tuplet 3/2  { c8 c8 c8 c8 c8 c8 }
  \once \override TupletNumber.text =
    #(tuplet-number::append-note-wrapper
  tuplet-number::calc-fraction-text "4")
  \tuplet 3/2  { c8 c8 c8 c8 c8 c8 }
  \once \override TupletNumber.text =
    #(tuplet-number::fraction-with-notes "4." "8")
  \tuplet 3/2  { c4. c4. c4. c4. }
  \once \override TupletNumber.text =
    #(tuplet-number::non-default-fraction-with-notes 12 "8" 4 "4")
  \tuplet 3/2  { c4. c4. c4. c4. }
}

Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
fatal error: make-note-markup: Invalid argument in position 1. Expect: 
duration, found: "8".

Exited with return code 1.


The code compiles fine in 2.19.83.

Has the syntax changed?


Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Assertion !is_empty() failed - yet again

[Andrew Bernard]

Hi David,

The reported error was from 2.19.83. But I built 2.21.0 last night, and the
error persists.

Andrew


On Sat, 27 Apr 2019 at 00:56, David Kastrup  wrote:

> Andrew Bernard  writes:
>
> > Lilypond 2.19.83.
>
> That one or current master?  In the latter, it may be fixed.
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Assertion !is_empty() failed - yet again

[Andrew Bernard]

Thanks David.

I built 2.21.0 on Ubuntu 19.04. Running gdb, sure enough, it's the familiar
tuple bracket issue:

Drawing systems...lilypond:
/home/andro/lilypond-git/flower/include/interval.hh:227: T
Interval_t::center() const [with T = double]: Assertion `!is_empty ()'
failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  0x776bfed7 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x776a1535 in __GI_abort () at abort.c:79
#2  0x776a140f in __assert_fail_base
(fmt=0x7782f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x5594ab94 "!is_empty ()", file=0x5594abb8
"/home/andro/lilypond-git/flower/include/interval.hh", line=227,
function=) at assert.c:92
#3  0x776b1012 in __GI___assert_fail
(assertion=assertion@entry=0x5594ab94 "!is_empty ()",
file=file@entry=0x5594abb8
"/home/andro/lilypond-git/flower/include/interval.hh", line=line@entry=227,
function=function@entry=0x5595c560 ::center()
const::__PRETTY_FUNCTION__> "T Interval_t::center() const [with T =
double]") at assert.c:101
#4  0x556d93c7 in Interval_t::center() const
(this=) at
/home/andro/lilypond-git/lily/include/lily-guile-macros.hh:70
#5  0x556d93c7 in Tuplet_number::calc_x_offset(scm_unused_struct*)
(smob=) at /home/andro/lilypond-git/lily/tuplet-number.cc:293

Last time this arose Aaron provided this code for me:

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

Adding that prints a warning, and works around the issue, and I can,
thankfully go on.

But since this keeps coming up, is it something that should be reported as
a bug, so as to eventually get fixed?

Andrew





On Fri, 26 Apr 2019 at 22:47, David Kastrup  wrote:

> Andrew Bernard  writes:
>
> > Lilypond 2.19.83. Yet again I see this error:
> >
> > Drawing systems...
> > Finding the ideal number of pages...
> > Fitting music on 15 or 16 pages...
> > Drawing systems...lilypond:
> > /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv
> .gnu.org--lilypond.git-stable-test/flower/include/interval.hh:227:
> > T Interval_t::center() const [with T = double]: Assertion `!is_empty
> ()'
> > failed.
> > Aborted (core dumped)
> > make: *** [Makefile:57: sq1-215.pdf] Error 134
> >
> > After only about 30 pages of dense string quartet music, now happens
> when I
> > just add one more note. This came up for me before with tuplets, but now
> a
> > plain note triggers this.
> >
> > How do we move forward on solving this? Once more, irritatingly for me
> and
> > for all, I don;t know how to make an MWE to stimulate this.
> >
> > Perhaps resort to gdb backtrace again?
>
> Yes?  That's what the "core dumped" triggered by assertion failures is
> good for.  Which is why "abort" should not be marked "noreturn" in
> gcclib so that gcc maintains a stack state useful for backtrace analysis
> rather than saying "what the heck, I won't return anyway".  But you tell
> that to Drepper and you'll get derided from here to Westborough.
>
> But most of the time, a backtrace will be useful for failed assertions
> (I debugged around for days for a case where gcc decided to just fold
> all abort calls in some function to the same place but that happens
> rarely).
>
> --
> David Kastrup
>
> ___
> 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

Assertion !is_empty() failed - yet again

[Andrew Bernard]

Lilypond 2.19.83. Yet again I see this error:

Drawing systems...
Finding the ideal number of pages...
Fitting music on 15 or 16 pages...
Drawing systems...lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/flower/include/interval.hh:227:
T Interval_t::center() const [with T = double]: Assertion `!is_empty ()'
failed.
Aborted (core dumped)
make: *** [Makefile:57: sq1-215.pdf] Error 134

After only about 30 pages of dense string quartet music, now happens when I
just add one more note. This came up for me before with tuplets, but now a
plain note triggers this.

How do we move forward on solving this? Once more, irritatingly for me and
for all, I don;t know how to make an MWE to stimulate this.

Perhaps resort to gdb backtrace again?

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: rest + fermata

[Andrew Bernard]

Hi Martin,

   R1^\fermataMarkup

It's special. Refer to the NR.

Andrew


On Sun, 14 Apr 2019 at 21:38, Martin Tarenskeen 
wrote:

>
> Hi,
>
> This is strange:
>
> %%% start of tiny example
>
> \version "2.19.83"
> {
>r1\fermata
>R1\fermata
> }
>
> %%% end of tiny example
>
> r1\fermata works fine, R1\fermata doesn't. No fermata sign is printed.
> Is this a bug?
>
> --
>
> MT
>
> ___
> 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 crash related to tuplets

[Andrew Bernard]

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

[Andrew Bernard]

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

Lilypond crash related to tuplets

[Andrew Bernard]

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: Lilypond 2.19.82 with multiple voices seems to fail

[Andrew Bernard]

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

[Andrew Bernard]

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

[Andrew Bernard]

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: Rehearsal mark interferes with TupletBracket length

[Andrew Bernard]

Hi Harm,

Thanks. Fantastic as always.

Adding this:

\once \override TupletBracket.full-length-to-extent = ##f

before the tuplets in the affected bar in each staff works perfectly. This
is a great help.

Problem with bugs like this is, I always think it is something I have done
wrong in my way too complex scores!


Andrew


On Fri, 22 Feb 2019 at 09:23, Thomas Morley 
wrote:

>
> This is
> https://sourceforge.net/p/testlilyissues/issues/2362/
> "tupletBracket fails with tupletFullLength and a long mark above"
>
> You may try
> \override TupletBracket.full-length-to-extent = ##f
> or
> unset tupletFullLength for the moment.
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Rehearsal mark interferes with TupletBracket length

[Andrew Bernard]

Hi Mark,

No, that's the strange thing.

I can't duplicate it in an MWE.

If's a string quartet by Chris Dench. You can imagine the density and
subtlety of the scoring. There's two hundred pages - hard to give to others
to have a look at for debugging!

Andrew


On Thu, 21 Feb 2019 at 04:22, Mark Knoop  wrote:

>
> I can't test this at the moment, but are you anywhere overriding the
> `extra-spacing-width` of the RehearsalMark grob?
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Rehearsal mark interferes with TupletBracket length

[Andrew Bernard]

Using 2.19.82 on Debian 9, my string quartet displays an issue that is hard
to understand, and appears to be a defect. Referring to the attached image,
the mark makes the tuplet brackets too short in the violin and cello part.
I can prove this by adding an X-offset to the RehearsalMark and the issue
goes away.

It's hard to make an MWE for this as my score is very complex, and I have
not been able to make this occur when simplified to a single bar. [Perhaps
this is telling me something, but I don't know where to look.]

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: slashedGrace and acciaccatura missing slash for multiple notes

[Andrew Bernard]

Hi All,

To that end, based on code by David Nalesnik and my own work, I wrote some
very flexible functions for making slashed stems and slashed beams. You can
find i the functions in openlilylib.

I have no idea if the code works with 2.18. I only use the 2.19 branch.

Andrew



On Tue, 19 Feb 2019 at 04:40, Federico Bruni  wrote:

>
>
> As far as I can see, it's a known limitation.
> See:
> https://sourceforge.net/p/testlilyissues/issues/1333/
> http://lsr.di.unimi.it/LSR/Snippet?id=721
>
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: The Stem of Longa notes is short when Baroque Notehead style is used

[Andrew Bernard]

Hi,

It's meant to be. That's the baroque style. Isn't it?

Andrew


On Tue, 29 Jan 2019 at 11:08, Pothárn Imre  wrote:

> %% The stem length of the longa is very short when Baroque NoteHead style
> is
> used.
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Disappearing dynamics

[Andrew Bernard]

Hi Carl,

Have not tried that idea.

The weird thing is that it's only dynamics that are affected. I thought it
might be some subtle font caching issue with the font I use, but I reverted
to lilypond default and the same occurs. Once the dynamic finally makes
itself visible, it stays.

This may remain forever an unsolved mystery. But it makes Frescobaldi
currently unusable for me, espcially as I am in the 'add dynamics' phase
that I do. I have several decades of UNIX software development experience,
and I have never seen anything resembling this. I promise I am not making
it up!

Andrew



On Wed, 14 Nov 2018 at 05:08, Carl Sorensen  wrote:

> Have you tried changing the lilypond call in Frescobaldi to a gdb lilypond
> call, so that you can pause the execution of lilypond and give Frescobaldi
> time to do whatever it might do -- and then continue lilypond from the
> debugger?
>
> Have you tried changing the Frescobaldi options for displaying the pdf to
> get to a minimal Frescobaldi run that doesn't do much but generate the pdf?
>
> This sounds like a truly bizarre bug.
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Disappearing dynamics

[Andrew Bernard]

Hi k\Kevin and All,

It ranks as one of the most bizarre bugs I have ever seen (and I speak as a
software developer of many decades). It's only with Frescobaldi. Command
line compilation is fine. It's only dynamic markings, which is puzzling -
whatever is going on? Running sync of course I tried, thinking the same as
you. but to no effect. Once the dynamics appear, then they continue to
appear.

A mystery of the cosmos. Perhaps dynamic markings have become shy or
recalcitrant. It's difficult to know how to debug this. Same behaviour in
printing Debian 9.6 and Ubuntu 18.10.

Andrew


On Tue, 13 Nov 2018 at 09:37, Kevin Barry  wrote:

>
> How bizarre. I wonder what difference there could possibly be that
> would make files appear to have different content. Does this issue
> occur in Frescobaldi if opening after a successful (i.e. dynamics
> appear correctly) compile from the cli and without making any edits?
> Does running sync before compilation make any difference? Do dynamics
> ever disappear after they have successfully appeared once?
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Disappearing dynamics

[Andrew Bernard]

Hi Urs,

Installed Debian 9.5 and all. The error, I am sorry to say, is in
Frescobaldi, displayed in Ubuntu 18.10 and Debian 9.5. Using emacs and
command line lilypond works fine on both Linux distros. Using Frescobaldi
3.0.0, the dynamics appear only intermittently, with no apparent pattern.

I am at a complete loss to understand this, and I cannot imagine how to
demonstrate it without giving away my entire library of code and IP. It's
completely inexplicable to me why only dynamics are affected. So far, this
is just a ten page start on a string quartet, so I don't think the system
is stretched to its limits at all.

This behaviour shows up whether using the lilypond default system fonts, or
Linux Biolinum O that I use, or any other font.

What this means is that unless anybody ever sees this that I will have to
give up using Frescobaldi, a great pity.

If anybody has any clue how to debug this it would be great. I do not know
how to get the lilypond command for compiling out of Frescobaldi to examine.

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Disappearing dynamics

[Andrew Bernard]

OK. Using a command line compile there is no sign of this issue.

At least I can continue with the engraving.

This looks not to be a lilypond bug now but an interaction between
Frescobaldi and Ubuntu 18.10.

In which case it looks like I have to abandon Frescobaldi after all these
years. Not good!

I suppose the next test is to try out Frescobaldi with the score on a
different distro. That will take a while. I shall report back in due course.

My guess is that it is Ubuntu 18.10. There's something slightly wobbly
about it in Virtualbox on my machines.

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Disappearing dynamics

[Andrew Bernard]

Hi Urs,

Thanks for the tip. It just happened with the first dynamic I added on
about page seven. Everything fine until then.

Having worked as a UNIX professional developer for a very long time, I can
tell you something equally lunatic sounding. It has a whiff of being
related to file system buffering, again, crazy as that may sound. I have
the music in one file, and the score/layout in another file. I save the
music file, and then in Frescobaldi switch to the score file and compile.
If I save both files and compile each one enough times the dynamics
eventually appear. This is so bizarre I feel like I am in some sort of
science fiction film. It's almost like the score file has not caught the
write to disk of the music file.

Does this add any light to it? Why is it only dynamics that go missing?
Something is playing tricks on me. :-)

I'll test compiling from the command line to eliminate any Frescobaldi
issues.

Andrew


On Fri, 9 Nov 2018 at 16:44, Urs Liska  wrote:

> But if you are using Gut or another VCS you should be able to identify the
> first additions that exposed the issue. This *may* give you some pointers.
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Disappearing dynamics

[Andrew Bernard]

Hi All,

I apologize for the seeming lunacy of this post! I am using lilypond
2.19.82 on Ubuntu 18.10. I am currently engraving a string quarter. Only
seven or eight pages in, I have started added in the dynamics and I find
they just disappear - they don't show. I am simply adding dynamics to the
notes, not in a separate Dynamics context. I am utterly unable to provide
an MWE to support this, as it only happens in the context of my full work,
the complete apparatus of which is very large. I am unable to binary chop
things to see where the error could come from, it's just impractical. The
worst part is that some dynamics show, and they only show after repeated
compile after compile. This latter point is what makes me think there may
be some very subtle memory related bug involved here.

Has anybody heard of this crazy behaviour? There's not a mention of such in
the lilypond user archives.

I cant figure out what to do next, except give up the engraving, which is
slightly sub-optimal.

Any suggestions would be gratefully received.

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: comment bug

[Andrew Bernard]

Isn't it simply that you can't have nested block comments?

Andrew


On 27 May 2018 at 01:14, bb  wrote:

>
> \version "2.19.80"
>
> %{
> \score  {
>  <<
> %{
> %some code
> %}
>  >>
> }
> %}
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond 2.19.80-1 hangs

[Andrew Bernard]

Hi David,

OK, but I have seen this exact thing before with another user I was helping
once and it is only triggered when the number of lines of this construct
become large, past some threshold. It does not seem to happen with minimal
examples. So would perhaps the file Massimo has be able to be submitted as
a bug report, since I gather you are willing to accept this as something to
be fixed?

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond 2.19.80-1 hangs

[Andrew Bernard]

Hi Massimo,

Thanks for sending the file.

It compiles fine under 2.19.18 on Ubuntu,

However, your file is made up of hundreds of lines like this:

 %Sezione M
 << {\parentheAll f,,8 bes,->~  bes,2.} \\ {s4  bes,,-. bes,,-.} >>
 << {bes,,8 f,~  f,2.} \\ {s4  f,,-. f,,-.} >> 8 
 << {g,2.} \\ {g,,4-. g,,-.} >>
 << {g,,8_> ees,~  ees,2.} \\ {s4  ees,,-. ees,,-. r} >> ees,4-.


I have seen this issue before, just the same, with another user.

While there is no written rule saying you cant write like that, and it is
syntactically valid, experienced users just don't write that way. There
seems to be a bug deep in lilypond somewhere that when this construct is
heavily overused that the program can't cope. It is unlikely that anybody
is going to fix this because it is a type of distortion of how lilypond is
normally used, in my view.

The simple solution is to write this with voice parts as per the normal
examples in the Notation Reference and Learning Manual.

This may result in a complete rewrite for you, but I am certain this will
address the problem and serve you in good stead for the future.

The issue seems to show up at different times on different platforms.

Fixing this would be a lot of work for the developers to support a very
idiosyncratic way of writing. I am not sure you would convince them to work
on it.

There's nothing peculiar about this music that cant be done in a more
commonly used way.

Andrew



On 5 May 2018 at 17:24, Massimo Lovato  wrote:

> Good morning.
> I have a "big" lilypond file (20 KB). With lilypond 2.19.80-1 it's
> impossible to compile, because lilypond stops working and the log only
> shows bar numbers in square brackets.
> With lilypond 2.18.2-1 it works.
> I know you only accept "tiny examples", so if you are interested to
> investigate this kind of bug I'll send you my input. Note that if I compile
> 10 bars per time with the "showLastLength = R1*10" statement, it works, so
> I exclude mistyping or things like that. Lilypond restart working only if I
> delete a certain number of bars.
> Regards
> Massimo Lovato
>
> ___
> 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: Long compile times with many empty bars

[Andrew Bernard]

This is an extremely interesting discussion. but given that when there are
non-empty objects present it does not appear to arise. is it simply an
'academic' corner case of purely theoretical interest?

Or perhaps it matters for engraving 4'33' by John Cage. [I believe one
version of the score is available from Peters Edition is set out fully with
nothing. There are at least four versions.]


Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Long compile times with many empty bars

[Andrew Bernard]

Hi Paul,

How is that code recursive?

Confirming the long compile times, Simon.

Andrew


On 7 April 2018 at 08:52, Paul Hodges  wrote:

> Ah, the perils of recursion!  (says an aged programmer)
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: LilyPond Download does not work!

[Andrew Bernard]

Hi Phil,

This is what I keep exhorting people to do - use the latest version. This
is probably a Frequently Issued Response :-) on the list by now! I know
2.20 has not come out yet, and when it does 2.18.2 will be obsolete, but at
the risk of inflaming controversy, isn't about time we started recommending
people to go to the 2.19 series?

Again, I am sure the unnecessarily self-deprecating open source humility of
referring to development versions as 'unstable' puts people off needlessly.

List helpers effectively have to support two streams. I don't have a 2.18.2
installation so I generally ignore questions about that version.

I know this is all problematical, but it would appear that 2.20 is not
coming out in the forseeable future (tell me it will be soon!), so let's
admit that the 2.91.81 and so on are pretty good and very trouble free, and
let new users know on the website.

Andrew



On 5 February 2018 at 04:29, Phil Holmes  wrote:

> "Gunda Hagmüller"  wrote in message
> news:f6e6780485a1ba8f22c0a76290bc6...@gundahagmueller.info...
>
>> Hi!
>>
>> I wanted to download LilyPond 2.18.2 for Windows, but the link
>> ...
>> 
>> 
>>
>
> Note that this is quite an old version, and 2.19.81 is quite stable.  You
> may benefit from using that instead.
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: force-hshift and dotted rhythms, 2.19.57

[Andrew Bernard]

Hi Knute,

I have often seen this. I just move the dot as well. I thought dots had a
more or less independent life. The same occurs when moving dotted rests.

Whether this is a big or not, I can't really say.

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Parenthesis issue with cross staff beaming

[Andrew Bernard]

Hi All,

 

Here is an MWE showing an issue I encounter regularly with the
parenthesizing of accents. It only occurs when using cross staff beaming
which I use a lot.

 

The reported error is:

.

programming error: Improbable offset for stencil: inf staff space

Setting to zero.

continuing, cross fingers

.

 

The output is unsatisfactory and I am unable to use parentheses in this
situation, but I need them.

 

A bug?

 

Andrew

 

== snip

 

\version "2.19.53"

 

 

treble = {

  \clef treble

  \time 1/4

  \override Beam.positions = #'(-4 . -4)

  \tuplet 5/4 {

\stemDown

c''8.

\change Staff = bass

\stemUp

c32 e cis'16-\parenthesize ^>

  } |

}

 

bass = {

  \clef bass

  \time 1/4

  s4

}

 

\score {

  \new PianoStaff

  <<

\new Staff = "treble" \treble

\new Staff = "bass" \bass

  >>

 

  \layout {

  }

}

 

== snip

 

 

 

 

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: #4975 [Windows] Grace notes cause staff to protrude into the margin

[Andrew Bernard]

Hi Ralph,

On Windows 10 under 2.19.49 I get:

Parsing...

Interpreting music...

Preprocessing graphical objects...

programming error: mis-predicted force, 108.120472 ~= 108.221141

continuing, cross fingers

programming error: mis-predicted force, 108.120472 ~= 108.221141

continuing, cross fingers

Finding the ideal number of pages...

Under 2.19.50 on Linux Mint there is no error.


Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

RE: easyHeads size

[Andrew Bernard]

Yes, I am completely wrong. Sorry folks.

Andrew


-Original Message-
From: Simon Albrecht [mailto:simon.albre...@mail.de] 
Sent: Saturday, 12 November 2016 9:11 PM
To: Andrew Bernard <andrew.bern...@gmail.com>; 'Tanner Noguess'
<jtnogu...@gmail.com>; bug-lilypond@gnu.org
Subject: Re: easyHeads size

On 12.11.2016 01:02, Andrew Bernard wrote:
> Hi Simon,
>
> So it is a bug actually?

I think it's very reasonable to expect that functionality.
Best, Simon



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

RE: easyHeads size

[Andrew Bernard]

Mea culpa.

Andrew


-Original Message-
From: Simon Albrecht [mailto:simon.albre...@mail.de] 
Sent: Saturday, 12 November 2016 10:54 AM
To: Andrew Bernard <andrew.bern...@gmail.com>; 'Tanner Noguess'
<jtnogu...@gmail.com>; bug-lilypond@gnu.org
Subject: Re: easyHeads size

Hi Andrew,

it's your turn to be more diligent. The given example quite clearly shows
that the \huge and \teeny commands basically work as desired. They can be
used in music to set the context property fontSize. The bug is that
easyHeads don't make use of this context property.

Best, Simon



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

RE: easyHeads size

[Andrew Bernard]

Hi Simon,

So it is a bug actually?

Andrew


-Original Message-
From: bug-lilypond
[mailto:bug-lilypond-bounces+andrew.bernard=gmail@gnu.org] On Behalf Of
Simon Albrecht
Sent: Saturday, 12 November 2016 10:55 AM
To: Tanner Noguess ; bug-lilypond@gnu.org
Subject: Re: easyHeads size

On 11.11.2016 18:40, Tanner Noguess wrote:
> \version "2.18.2"
> % The \huge (or any resize) command seems to only affect the text, % 
> not the actual note size when \easyHeadsOn is used.

Added to the tracker as
.
Thanks for reporting,
Simon



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

RE: easyHeads size

[Andrew Bernard]

Hello Tanner,

Don't be so quick to assign a bug! :-)

The \huge command only applies to text in markups, not noteheads.

To change the notehead size you can increase the global staff size, or you
can adjust the size of the notehead grob itself.

For example:

  \override NoteHead.font-size = #3

But note that this does not take account of the staff size, and making the
noteheads bigger will overlap the staff lines.

Although this is not stated directly and explicitly in words in the notation
reference manual, the documentation of \huge is under markup and this tends
to imply it is for markup, not noteheads. But given that the way to change
the size shown above is to alter the font size of the note, one could be
forgiven for thinking the text markup commands would apply.

A topic like this would be seen by far more people on the user list. So,
better move the topic there and continue the discussion to clarify what you
want.

Andrew



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Font cache issues on Windows 10

[Andrew Bernard]

Where are we at with the font caching issue on Windows 10? There does not
appear to be much discussion on the bug list presently, but I certainly
experience the slow down. After being advised to remove the font cache
directory, things speed up after that, when using Frescobaldi. But now I am
trying to list the available fonts for lilypond from the command line and it
rebuilds the font cache for every command, at version 2.19.49, as shown by
running the log level at debug.

 

Andrew

 

 

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

RE: Mark / Barcheck Bug (#1626) Appearing Again

[Andrew Bernard]

Hi,

Don't you have to provide an argument for \mark, I thought?

I am not familiar with 2.18.2, but in 2.19.48 you do:


Processing `/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly'
Parsing...
/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly:4:20: error: wrong type
for argument 1.  Expecting number or markup, found (make-music (quote
BarCheck))
\new Staff { \mark 
   | c4 c c c | r1 | \mark c4 c c c |  }
/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly:4:44: error: wrong type
for argument 1.  Expecting number or markup, found (ly:make-pitch -1 0)
\new Staff { \mark | c4 c c c | r1 | \mark 
   c4 c c c |  }
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-jzd1sq'...
Converting to `document.pdf'...
fatal error: failed files:
"/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly"



Andrew


-Original Message-
From: bug-lilypond
[mailto:bug-lilypond-bounces+andrew.bernard=gmail@gnu.org] On Behalf Of
Christopher Heckman
Sent: Sunday, 16 October 2016 12:13 PM
To: bug-lilypond@gnu.org
Subject: Mark / Barcheck Bug (#1626) Appearing Again

This was mentioned about five years ago, but I re-discovered it. Does the
so-called patch fix this? The bug is as follows:

Placing the \mark can have an effect on the bar check. If you run Lilypond
with the following code, the barcheck will fail exactly once.

--- CCH

\new Staff { \mark | c4 c c c | r1 | \mark c4 c c c |  }

\version "2.18.2"



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Major Minor Chord

[Andrew Bernard]

Hi Craig,

Not at all. This is not a bug. If you want this to express the chord
construct you are describing, explicitly put in the accidentals. Lilypond
has no notion of standard chords in various periods of music, unless you
are using a chord mode. This is plain note entry.

Andrew


On 10 September 2016 at 00:36, craig  wrote:

> Hi,
>
> A major minor chord is not given proper accidentals by default.  This is a
> standard chord in mondern music.  The following should have a b flat
> marking along with a b natural marking.
>
>
> \version "2.19.45"
>
> \score {
>   
> }
>
>
>
> ___
> 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

Cross staff dynamics

[Andrew Bernard]

I am having difficulties with cross staff dynamics throwing errors and
causing collisions in 2.19.44 (at least).

The issues are the same as reported here:

https://lists.gnu.org/archive/html/bug-lilypond/2014-07/msg00104.html

Has there been any work on this issue and topic?

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Wrongly combined note heads

[Andrew Bernard]

Hi Simon,

What does Elaine Gould say about resolving this?

There are a lot of different styles to adopt when faced with this scenario,
and although the current lilypond approach is unreadable, you can fix it
according to whatever style you prefer. Fixing lilypond would presumably
mean adopting one particular style that may not be what everybody wants.

Andrew


On 23 June 2016 at 5:00:58 PM, Simon Albrecht (simon.albre...@mail.de)
wrote:

Of course,
it’s not a trivial question how it should be written, but what Lily does
now is definitely wrong.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Wrongly combined note heads

[Andrew Bernard]

Hi Paul,

Yo can do this:

\version "2.19.42"
\language "english"

{
  \clef treble
  <<
{
  \voiceOne
  g'!4 gs'4
}
\new Voice
{
  \voiceTwo
  gs'4 \once \override NoteColumn.force-hshift = #1 g'!4
}
  >>
}

I think the behaviour you show is normal lilypond semantics - although it
is not usually what one wants with different accidentals on the same pitch.
I believe this is not a bug as it is up to the individual engraver to
resolve this according to their own taste and style, e.g. which note comes
first if shifted?

Andrew



On 23 June 2016 at 9:30:18 AM, Paul Hodges (p...@cassland.org) wrote:


% Note heads in different voices are combined
% even though they have different accidentals
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Tuplet numbet text

[Andrew Bernard]

When setting the tuplet number text, in a piece that uses the full fraction
throughout, when temporarily set to just the denominator on a nested
tuplet, if the nested tuplet comes first the out tuplet text is also set to
the inner setting. This does not occur if the inner tuplet comes later.

Is this indeed a bug?

Andrew

== snip

\version "2.19.43"

{
  \override TupletNumber.text = #tuplet-number::calc-fraction-text
  \tuplet 7/8 { c'' \tuplet 3/2 { d'' d'' d'' }  c'' c'' c'' c'' } |

  \tuplet 7/8 {
\once \override TupletNumber.text =
#tuplet-number::calc-denominator-text
\tuplet 3/2 { d'' d'' d'' }  c'' c'' c'' c'' c''
  } |

  \tuplet 7/8 {
c''
\once \override TupletNumber.text =
#tuplet-number::calc-denominator-text
\tuplet 3/2 { d'' d'' d'' }  c'' c'' c'' c''
  } |
}


== snip
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond 2.19.43 font issue

[Andrew Bernard]

Hi Hans,


On 13 June 2016 at 02:11, Hans Åberg  wrote:

> The solution: the UTF-8 locale has not been set as it wishes [1]. OS X 
> 10.11.6 has no leading language “en”, only
>   LC_CTYPE=UTF-8
>
> It suffices with any single one of:
>   export LC_CTYPE=en.UTF-8
>   export LC_CTYPE=en_US.UTF-8
>   export LC_ALL=en_US.UTF-8
>


I don't have 10.11.6 but 10.11.5. If you do:

$ locale -a | grep UTF-8

there is no standalone UTF-8 locale without a language prefix.

If there is in 10.11.6 I would be quite surprised. This sounds like a
beta defect in OS X to me. But are you sure you have your regional
settings set up correctly?


> 1. https://github.com/ariya/phantomjs/issues/13433

It's hard to see how that issue relates to the Mac OS X release.

Andrew

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond 2.19.43 font issue

[Andrew Bernard]

Hi Hans,

Mac 10.11.6? Are you on a beta release? All bets are off in that case. Just
asking.

Andrew



On 12 June 2016 at 7:55:48 AM, Hans Åberg (haber...@telia.com) wrote:

The code below produces, using lilypond-2.19.43-1.darwin-x86 on OS X
10.11.6, the diagnostic:
Finding the ideal number of pages...Fontconfig warning: ignoring UTF-8: not
a valid region tag
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Parenthesized accent

[Andrew Bernard]

Hi Malte,

Thanks so much. But don’t you think this is a defect in lilypond? Of all
the workarounds I have seen ever in lilypond, this is the most horrifying
complex and most unsatisfying.

Can we raise this as an issue?

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Beaming and slurs across staves

[Andrew Bernard]

Can we please raise this as a bug in the bug tracker? I encounter this
situation frequently in my scores.

Andrew

On 26 May 2016 at 21:16, David Kastrup <d...@gnu.org> wrote:
> Andrew Bernard <andrew.bern...@gmail.com> writes:
>
>> Thanks. Do we raise a bug? The program stops and will not continue to
>> compile after this error.
>
> Like after any failed assertion since an assertion indicates that the
> program cannot continue sensibly.
>
> So yes, that's a bug.  The proper fix is finding out under which
> conditions the assertion failure can trigger and then figure out how to
> proceed in this case or how to avoid it.
>
> The bandaid fix would be replacing the assertion failure with a
> programming error as long as one can state with confidence that it will
> not result in a hard crash.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Beaming and slurs across staves

[Andrew Bernard]

Thanks. Do we raise a bug? The program stops and will not continue to
compile after this error.

Andrew
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Beaming and slurs across staves

[Andrew Bernard]

I keep finding situations using beamed groups across staves where
adding a slur or a phrasing slur causes lilypond to fail with the
following error:


Processing `/home/andro/work/lilypond/fp/exp-slur-crash.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
/home/andro/work/lilypond/fp/exp-slur-crash.ly:15:6: warning: no
viable initial configuration found: may not find good beam slope
c32
[\( c
lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/include/interval.hh:227:
T Interval_t::center() const [with T = double]: Assertion `!is_empty
()' failed.

Refer to the MWE here for an example. This occurs in 2.19.41 at least.
I have not tried previous versions.

In other scenarios in my score even when the warning about not finding
a good beam slope is not emitted I still get the crash reliably in
this type of situation.

Is this a bug?

Andrew

== snip

\version "2.19.41"

treble = {
  \clef treble
  \time 1/4
  s4 s
}

bass =  {
  \clef bass
  \time 1/4

  %\once \override Beam.positions = #'(4 . 4)
  \stemUp
  c32[\( c
  \change Staff = treble
  \stemDown c' e' g' c'' c'
  \change Staff = bass
  \tuplet 5/4 { e c g, d32\rest e' }
  \change Staff = treble
  g'
  \change Staff = bass
  g
  \change Staff = treble
  a'']\)
}

\score {

  \new PianoStaff
  <<
    \new Staff = "treble" { \treble }

    \new Staff = "bass" { \bass }
  >>

  \layout {
  }
}

== snip

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: fondu fails on newer OS X versions

[Andrew Bernard]

Hi Mats,

This may be a half baked answer, since it is a long time since I ever did any 
Mac programming. But here are some thoughts. The designers of the file system 
for Apple invented the idea of a data fork and a resource fork to store 
everything that they deemed to be not ‘data’, that is, icons and file types and 
so on. This turned out to be a Terrible Idea (TM), partly because it is just 
not portable or interoperable. Thankfully Apple have now abandoned that, as of 
some time ago.

Fonts in particular were stored in the resource fork. (As to why, only those 
programmers can answer). Now, since this is outdated, older font files that 
lived in the resource fork were converted to use the data fork instead, as per 
a normal file. These are the so called dfonts. The good old good fonts like 
Times and Monaco are dfont format, even today on 10.11.4. But there are only 
these in my system fonts directory:

Courier.dfont
Geneva.dfont
Helvetica.dfont
HelveticaNeue.dfont
Monaco.dfont
Times.dfont

The fondu tool was written for mac font conversion, and can convert mac font 
formats to something more universal. But fondu is clearly unmaintained, and the 
reason must be that it is no longer required, since the resource fork issue has 
gone away.

The author of fondu is also the creator of fontforge. This is very actively 
maintained.  While I have not tried that yet, I am fairly confident fontforge 
can do for lilypond what fondu is doing. Using fontforge for conversion of 
older fonts would be a more sustainable solution that forking fondu, which is 
essentialy obsolete. The fontforge program is scriptable, so I am sure it can 
be made to work.

So I would suggest we take a look at replacing the functionality of fondu for 
the mac lilypond distribution with a tool like fontforge. I will try to so some 
experiments.

Andrew








___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: fondu fails on newer OS X versions

[Andrew Bernard]

Hi Thomas et al.,

While I was helping Mats look into this I noticed the same point. The defect 
means you can’t even use a basic system font like Times in a font name override 
in markup on the Mac.

Given that fondu is moribund, does this topic need to go the development list 
for discussion? Are there other tools that can be used instead of fondu that 
are currently maintained? Basing lilypond core code on unmaintained libraries 
for such important functionality such as font rendering in this type of use 
case does not seem robust.

What to do? In any case, a bug should be raised for lilypond don’t you think, 
even though this is an external program? If nothing else, others who encounter 
it will be able to search for it.

Andrew


On 4/04/2016, 06:38, "Thomas Morley" 
 wrote:


Their homepage
http://fondu.sourceforge.net/
was last modified 2008
In the changelog there, the last patch dates 2006.
From Han-Wen, btw.

I think we may have a problem...

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Default font for the web site

[Andrew Bernard]

Hi Simon,

There are a lot of people who strongly dislike Garamond, I know from experience 
with typesetting. [This goes to the point of my previous email.] And a modified 
Garamond is/was the Apple corporate font since 1984, so the whole family looks 
terribly tired and overused.

I am probably making myself unpopular here, but I say leave it alone.

If not to be, then you may want to have a look at the Linxu Libertine fonts, a 
nice open source project with sound typographic design.

But how are you going to serve the web fonts with low latency? What are you 
proposing?

Andrew

[And if you really have to do this I have a lot of experience coding webfont 
techniques for websites, so I am happy to help and contribute.]


On 3/03/2016, 21:02, "Simon Albrecht" 
 wrote:

I was just hoping 
that someone might come up with another good, free Garamond that had 
escaped my notice – probably wishful thinking though.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Default font for the web site

[Andrew Bernard]

Hi Simon,

No. In my experience doing typography for people, for every typeface that one 
person likes, another loathes it. Taste in type is very personal and very 
emotive – you can never win and satisfy all. Everybody now has their own expert 
opinion, even though typography is a very refined and difficult art.

I have found that for those who care about type, they will adjust their 
browsers. For those that don’t, it does not matter.

However, if you want to present an overall fine design feel to the website, 
then you have to serve specific fonts using webfont technology, which took a 
very long time to mature, but is now excellent – providing you use a very high 
speed low latency webfont server to reduce page load time and ‘font flash’. You 
could use Google Fonts I suppose, but commercial servers with other fonts are 
expensive and go against the open source nature of the project. Serving 
webfonts off your own local server is rarely fast enough.

Saying this myself even at all, I feel we are bike-shedding. The whole website 
is is need of a total renovation to bring it into line with contemporary look 
and feel, design, and usage. But even so, it currently serves its purpose just 
fine. I am happy with it as it is. We have a nuclear reactor to build, not a 
bikeshed to paint.

By the way, do not disparage Times New Roman so. Times is a deservedly fine 
font. You see – people can’t agree!

Andrew


On 3/03/2016, 10:08, "Simon Albrecht" 
 wrote:

made me think that we really should specify a default font for our web site. 
Else the 
browser will be left to choose, eventually presenting the user with 
Times New Roman, if he hasn’t made a better choice yet. Shouldn’t we 
avoid that?

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[Andrew Bernard]

Hi Abraham,

Thanks for this explanation. Now that I have read up on this, for TrueType at 
least, I see that FUnits, or font units are used, and that there are a given 
number of units-per-em for a specific design, say 1000 or 2048 and so on. I 
can’t find much reference to em-units - to me that suggests 'units of em’s'. 
Would it not be units per em? I assume this is what you are referring to, that 
fonts designed for lilypond are made with a metric of 1000 font units per em.

Andrew

On 10 February 2016 at 18:45:21, tisimst (tisimst.lilyp...@gmail.com) wrote:

What I'm referring to are the units that are used to define the shape of a 
glyph, called em-units.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Noteheads slightly too large

[Andrew Bernard]

Hi Abraham,

What unit is this particular em? In typography at least an em is a measurement 
equal to the currently specified point size for a font. That does not seem to 
fit your analysis here.

Andrew

On 10 February 2016 at 02:12:48, tisimst (tisimst.lilyp...@gmail.com) wrote:

Relative to a 1000-em unit staff height (which is what the fonts 
are designed to, center of bottom staff line to center of top staff line)
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: PNG output cannot be created with Mac OS X version of Lilipond 2.18.2-1

[Andrew Bernard]

Hi Jun,

What version of Mac OS X are you on? Current version 10.11.2 provides 
libgs.9.16.dylib.

Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Slur inside tuplet bracket causing crash

[Andrew Bernard]

When I attempt to move the following slur inside the the tuplet bracket relese 
2.19.34 crashes with an assertion failure.

Excerpting the code to isolate the issue results in incorrect output and error 
messages, but no assertion failure.

What is going on here? In the context of my very large score, the assertion 
failure prevents me compiling it at all.

\version "2.19.34"

{
  \clef bass
  \time 1/4

  \stemUp
  \tupletDown
  \once \override TupletNumber.avoid-slur = #'around
  %\once \override TupletBracket.Y-offset = #2
  \tuplet 5/4 { gis,16( b,16. } 
  dis16 fis16. g32) c'^.^> r32
}

Log output:

Starting lilypond 2.19.34 [exp-crash.ly]...
Processing `/home/andro/work/lilypond/proportion/exp-crash.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: minimise_least_squares ():  Nothing to minimise
This means that vertical spacing is triggered
before line breaking

continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-azboyo'...
Converting to `exp-crash.pdf'...
Deleting `/tmp/lilypond-azboyo'...
Success: compilation successfully completed
Completed successfully in 0.7”.

Commenting this out removes the error:

\once \override TupletNumber.avoid-slur = #’around

But this is what I need to achieve for the score.

This is the assertion faliure I get in the contrext of the larger score:

Preprocessing graphical objects...lilypond: 
/home/andro/src/lilypond-2.19.34/flower/include/interval.hh:227: T 
Interval_t::center() const [with T = double]: Assertion `!is_empty ()' 
failed.
Exited with exit status 1.

Andrew




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: crescendo & decrescendo marks not end correctly

[Andrew Bernard]

Hi Fan,

Without wishing to sound annoying, this piece is written for harpsichord, and 
crescendo and diminuendo marks do not apply in that context, and Bach never 
used them for harpsichord music. The example you link to is an erroneous modern 
edition. Engraving it as Bach intended would be a better solution.

If you must engrave this, have a read of the Notation Reference under the 
Dynamics section.

The issue you raise is not a bug, but deliberate behaviour:

>From the NR:

 Setting hairpin behavior at bar lines

If the note which ends a hairpin falls on a downbeat, the hairpin stops at the 
bar line immediately preceding. This behavior can be controlled by overriding 
the 'to-barline property.



When you inlcude your snippets, make it easier for people to help you by using 
compilable fragments, like so:

\relative c'' {
  \time 3/4
  a8([\< b] cis[ d] e fis |
  g4)\! fis-. e-.\> |
  fis4-. a,( cis |
  d2.)\! |\break
}

Also, always say what version of lilypond you are using.

Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Cannot locate libffi.so.6 on openSUSE Leap 42.1

[Andrew Bernard]

Confirming this is fixed on a pristine install of openSUSE Leap 42.1, with 
lilypond 2.19.33.

Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fontmap entry for Fontmap.local ends prematurely!

[Andrew Bernard]

Hi Karl,

As mentioned before, I tried this out on a fresh install of Centos 7 and there 
is no issue. Are you rigidly committed to Centos 6? I am not sure how many 
trailing releases behind the lilypond developers generally support, but this is 
a viable solution if it does not break other software you use.

Andrew



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Cannot locate libffi.so.6 on openSUSE Leap 42.1

[Andrew Bernard]

The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap 42.1 
as it is unable to find libffi.so.6, which is not installed on this OS.

The lilypond distribution includes this shared library in its usr/lib64 
directory. But the installer script only creates a lilypond wrapper start 
script referencing usr/lib and not usr/lib64:

#!/bin/sh
me=`basename $0`
#export LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib"
export 
LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib:/home/andro/lilypond/usr/lib64"
exec "/home/andro/lilypond/usr/bin/$me" "$@"


If I add the lib64 directory as above, which contains libffi.so.6 all is well.

Why does the installer script omit the lib64 directory?

This is a defect because users of the downloadable lilypond cannot run it on 
openSUSE.

Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Assertion failed

[Andrew Bernard]

Debugger backtrace attached.

This is from 2.19.30.


Andrew




backtrace
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Vertical alignment - programming error

[Andrew Bernard]

Using a grace note set that spans two staves, reduced from a vastly more 
complex real score to a more minimal example, if I use a hairpin between the 
sfz and the p indications, I get a programming error related to vertical 
alignment that I am unable to understand, or eliminate. Can folks explain this? 
It is unclear to me whether this is a defect, or my incorrect usage.

Andrew

— compilation log

Starting lilypond 2.19.29 [exp-k-p11-simpler.ly 
]...
Processing `/home/andro/work/lilypond/proportion/exp-k-p11-simpler.ly 
'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
programming error: My pure_y_common is a VerticalAlignment, which might contain 
several staves.
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
programming error: bounds of this piece aren't breakable.
continuing, cross fingers
Layout output to `/tmp/lilypond-40hIxW'...
Converting to `exp-k-p11-simpler.pdf'...
Deleting `/tmp/lilypond-40hIxW'...
Success: compilation successfully completed
Completed successfully in 0.7”.

— compilation log

— snip
\version "2.19.29"

treble = {
 \clef treble
 \time 1/4

 c''16_\sfz
 \grace {
   \bar ""
   ees'''8^>]_\sfz\> g''^> f' a' d''
   \change Staff = middle
   b fis_\p
 }
 \change Staff = top
 \bar "!"
}

bass = {
 \clef bass
 \time 1/4
 c16
}

\score {
 \new PianoStaff
 <<
   \new Staff = "top" \with {
   }
   { \treble }
   \new Staff = "middle" \with {
   }
   { \bass }
>>
 \layout { }
}

— snip

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Assertion failed

[Andrew Bernard]

Using 2.19.30, hoping to avoid the core dumps from 2.19.29, I get the following 
error on my moderately large score:

Preprocessing graphical objects...lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/include/interval.hh:227:
 T Interval_t::center() const [with T = double]: Assertion `!is_empty ()' 
failed.
Exited with exit status 1.

There is no line number indication and the score will not compile. Due to the 
massive complexity of my score, a binary chop is difficult and very time 
consuming. Has anybody seen this error? There was an issue like this a few 
releases ago related to nested tuplets I seem to recall.

Andrew




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes and staff miss-alignment

[Andrew Bernard]

Works fine on Ubuntu 15.04, 64 bit, lilypond 2.19.27.

Andrew

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Another parenthesize issue

[Andrew Bernard]

In the following MWE, when a slur is used, the two articulations overlap. I 
believe they should be stacked, as in the case shown with no slur.

\version 2.19.25

{
  \slurDown
  c''16^!-\parenthesize ^ d''-\parenthesize ^ ^!( ees'') fis''-\parenthesize 
^ ^!
}


Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: crash with gs-error

[Andrew Bernard]

At least on Ubuntu 15,04, it's the page number -1 that does it. Zero or
positive numbers work.

Andrew

On 12 July 2015 at 07:06, Thomas Morley thomasmorle...@gmail.com wrote:

 The following crashes with released 2.19.22

 %% snippet-start

 \version 2.19.22

 \paper { first-page-number = #-1 }
 \markuplist \table-of-contents
 \tocItem Adagio
 { c''1 }

 %% snippet-end


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fedora 22 bug lilypond 2.19.21

[Andrew Bernard]

Lilypond 2.19.21 as downloaded from the website does not compile a very
large and complex score. Small scores are fine. The verbose log is provided.
Since the score is large and no indication is found as to the location of
the problem, it is not possible to provide a small snippet that triggers the
bug.

Andrew Bernard

Log level set to 287
GNU LilyPond 2.19.21
Relocation: is absolute: argv0=/home/andro/lilypond/usr/bin/lilypond
PATH=/home/andro/lilypond/usr/bin (prepend)
Setting PATH to /home/andro/lilypond/usr/bin:/opt/anaconda/bin:/opt/anaconda/bin
:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/andro/.local
/bin:/home/andro/bin
Relocation: compile datadir=, new datadir=/home/andro/lilypond/usr/share/lilypon
d//current
Relocation: framework_prefix=/home/andro/lilypond/usr/bin/..
Setting INSTALLER_PREFIX to /home/andro/lilypond/usr/bin/..
Relocation file: /home/andro/lilypond/usr/bin/../etc/relocate//pango.reloc
Setting PANGO_RC_FILE to /home/andro/lilypond/usr/bin/../etc/pango/pangorc
Setting PANGO_PREFIX to /home/andro/lilypond/usr/bin/../
Setting PANGO_MODULE_VERSION to 1.6.0
Relocation file: /home/andro/lilypond/usr/bin/../etc/relocate//fontconfig.reloc
Setting FONTCONFIG_FILE to /home/andro/lilypond/usr/bin/../etc/fonts/fonts.conf
Setting FONTCONFIG_PATH to /home/andro/lilypond/usr/bin/../etc/fonts
Relocation file: /home/andro/lilypond/usr/bin/../etc/relocate//guile.reloc
GUILE_LOAD_PATH=/home/andro/lilypond/usr/bin/../share/guile/1.8 (prepend)
Setting GUILE_LOAD_PATH to /home/andro/lilypond/usr/bin/../share/guile/1.8
Relocation file: /home/andro/lilypond/usr/bin/../etc/relocate//gs.reloc
warning: no such directory: /home/andro/lilypond/usr/bin/../share/ghostscript/9.
15/fonts for GS_FONTPATH
warning: no such directory: /home/andro/lilypond/usr/bin/../share/gs/fonts for G
S_FONTPATH
GS_LIB=/home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resource (prepend)
Setting GS_LIB to /home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resourc
e
GS_LIB=/home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resource/Init (pre
pend)
Setting GS_LIB to /home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resourc
e/Init:/home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resource
PATH=/home/andro/lilypond/usr/bin/../bin (prepend)
Setting PATH to /home/andro/lilypond/usr/bin/../bin:/home/andro/lilypond/usr/bin
:/opt/anaconda/bin:/opt/anaconda/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/us
r/sbin:/bin:/sbin:/home/andro/.local/bin:/home/andro/bin
Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR=/usr/share/lilypond/2.19.21
LOCALEDIR=/usr/share/locale

Effective prefix: /home/andro/lilypond/usr/share/lilypond/current
FONTCONFIG_FILE=/home/andro/lilypond/usr/bin/../etc/fonts/fonts.conf
FONTCONFIG_PATH=/home/andro/lilypond/usr/bin/../etc/fonts
GS_LIB=/home/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resource/Init:/ho
me/andro/lilypond/usr/bin/../share/ghostscript/9.15/Resource
GUILE_LOAD_PATH=/home/andro/lilypond/usr/bin/../share/guile/1.8
PANGO_RC_FILE=/home/andro/lilypond/usr/bin/../etc/pango/pangorc
PANGO_PREFIX=/home/andro/lilypond/usr/bin/../
PATH=/home/andro/lilypond/usr/bin/../bin:/home/andro/lilypond/usr/bin:/opt/anac
onda/bin:/opt/anaconda/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bi
n:/sbin:/home/andro/.local/bin:/home/andro/bin
[]
Guile 1.8
[/home/andro/lilypond/usr/share/lilypond/current/scm/lily-library.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/output-lib.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/markup-macros.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/parser-ly-from-scheme.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/file-cache.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-event-classes.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-music-callbacks.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-music-types.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-note-names.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/c++.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/chord-entry.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/skyline.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/markup.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-markup-commands.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/stencil.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/modal-transforms.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/chord-generic-names.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/chord-ignatzek-names.scm]
[/home/andro/lilypond/usr/share/lilypond/current/scm/music-functions.scm
[/home/andro/lilypond/usr/share/lilypond/current/scm/define-music-display-method
s.scm]
]
[/home