Behavior on Errors; Separate Run Output

[Christopher Heckman]

These would probably count as "annoying" bugs.

(1) When I compile a Lilypond file that contains an error, Lilypond
should not open up the previous .pdf file: An error means I have to go
back to the file, which means closing the .pdf file first. (This could
be added in the form of a preferences menu with items like "behavior
upon error" and "behavior upon warning". Default would be "compile and
open output file".)

(2) When I compile a Lilypond file, make some changes, compile it
again, and so on, the various compilations in the log file are
continuous. Some sort of a separator (even if it's just hyphens)
should be put between compilings.

--- Christopher Heckman

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

Re: Issue 2214 in lilypond: "fatal error" reported when version is too old but correct output is still generated

[christopher-heckman]

Janek Warchoł wrote
> 2012/1/12 -Eluze 

> eluzew@

> :
>> the word error should be reserved for severe situations, there are other
>> words to direct the attention to such discrepancies. for the actual
>> "error"
>> a pointer, a note or another kind of message would suffice.
> 
> I think it would be more informative it this was a Warning, not an
> Error.  Especially
> 
> fatal error: failed files [..]
> 
> is misleading in my opinion.

I concur. "Warning: Version not found" explains what is going on, much
better.

As Gus Baird once said, when something goes wrong in a program, you should
inform a user in the least surprising way.

--- Christopher Heckman




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Issue-2214-in-lilypond-fatal-error-reported-when-version-is-too-old-but-correct-output-is-still-gened-tp84387p196421.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Mark / Barcheck Bug (#1626) Appearing Again

[Christopher Heckman]

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: Mark / Barcheck Bug (#1626) Appearing Again

[Christopher Heckman]

After playing around with Lilypond for a while, I found out that \mark
appears to "gobble up" the next token in the list. For example,

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

and

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

should give barcheck errors but don't. That's because the barcheck
interprets them as

  \new Staff { c c c c | }

and

 \new Staff { c c c c |  c c c c | c c c c | }

--- CCH

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

midi2ly: Fraction Reduction + 2 minor issues

[Christopher Heckman]

(1) When midi2ly is run, it will print fractions with large numerators
and denominators, like

r4*361/120 e4*29/120 r4*31/120 e4*59/120 r4*361/120 e4*29/120

when the actual durations are more likely to be

r2. e4*1/4 r4*1/4 e4*1/2 r2. e4*1/4 r4*1/4 e4*1/2 r2. e4*1/4

I have written a patch to fix this. Inside of the class Duration (line
129), replace the dump function with:

---

def dump (self):
den = self.den; num = self.num;
# code below by C C Heckman
# looks for a neighboring fraction that reduces
if num > 1:
gcd1 = gcd (num - 1, den)
gcd2 = gcd (num, den)
gcd3 = gcd (num + 1, den)
if gcd1 > gcd2 and gcd1 > gcd3:
d = -1; g = gcd1
elif gcd3 > gcd2 and gcd3 > gcd1:
d = +1; g = gcd3
else:
d = 0; g = gcd2
# for now, do nothing
num = (num + d) / g
den = den / g
if den == 1:
if num == 1:
s = '%d' % self.dur
elif num == 3 and self.dur != 1:
s = '%d.' % (self.dur / 2)
else:
s = '%d*%d' % (self.dur, num)
else:
s = '%d*%d/%d' % (self.dur, num, den)
# end modified code

-

This will reduce the fractions (n-1)/d, n/d, and (n+1)/d (where the
original fraction is n/d). If (n-1)/d or (n+1)/d reduces more, its
reduction replaces n/d, except in one technical case. For instance,
the fraction 29/120 is considered to be rounded off after some error
has been added. The possible values to be checked are 28/120 (7/30 in
lowest terms), 29/120 (which does not reduce), and 30/120 (1/4). Since
30/120 reduces to the smallest denominator, 29/120 gets replaced with
1/4.

Now the technical case: If n/d is in lowest terms, n is odd, and d is
even but not divisible by 2, then n/d won't reduce, but you will be
able to cancel a factor of 2 from (n-1)/d and (n+1)/d. Since there is
no way to break this tie, the original value n/d is kept. (Note this
is the only case where (n-1)/d and (n+1)/d will be reduced by the same
denominator. I've proven this.)

Note that this will *not* make changes like 4*1/4 into 16; that might
be in a future version. This would turn the example output into

r2. e16 r16 e8 r2. e16 r16 e8 r2. e16

Also, fractions which don't reduce but have large denominators might
be replaced with approximations with small denominators. (Continued
fractions allow you to calculate these.)

(2) In line 181 of midi2ly.py, the authors talk about how the 7th of a
minor scale should be raised, but this is not notated. The real issue
is that there are two types of minor scale involved, the harmonic
minor (1 2 b3 4 5 b6 7) and the natural minor (1 2 b3 4 5 b6 b7). The
reason that "C# is not put in the key signature of D minor" is that
the minor scale is the natural minor, not the harmonic minor.

(3) At line 677, there's a cryptic comment

# urg, this will barf at meter changes

Is there a brief explanation of the problem available?

==
Christopher Carl Heckman
Honors Faculty
Lecturer
33° 25' 7'' N, 111° 55' 55'' W
ECA 212
School of Mathematical & Statistical Sciences
Arizona State University (T1N R4E Sect22 NW1/4)
Tempe, AZ 85287 - 1804
United States of America
North America
Planet Earth
Solar System
Gould Belt
Local Bubble
Local Fluff
Milky Way Galaxy, Orion Arm
Local Group
Virgo Supercluster
Pisces-Cetus Supercluster Complex
Universe
Multiverse
==

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

Re: bug-lilypond Digest, Vol 173, Issue 17

[Christopher Heckman]

On Mon, Apr 17, 2017 at 9:00 AM,  <bug-lilypond-requ...@gnu.org> wrote:
>
> On Sun, Apr 16, 2017 at 9:00 AM, Martin Tarenskeen
> <m.tarensk...@zonnet.nl> wrote:
>
> On Sun, 16 Apr 2017, Christopher Heckman wrote:
>
>>> I like the idea and really appreciate your efforts, but I tried your patch
>>> and it doesn't seem to work (yet), at least not on my system. I can't
>
>> Hm. My Python might be a bit rusty, but the syntax doesn't differ from
>> the original code. However, you need to answer the "usual questions":
>
> Never mind.
> I found the "error". In your original message you wrote "replace the dump
> function with: (...your code... # end modified code)", so that's what I
> literally did.
>
> But the code you posted did not replace the *complete* function down to
> and including "return s". After your "# end modified code" there were
> still 3 lines of code in the original dump function that had to stay
> unchanged, not replaced.
>
> global reference_note
> reference_note_duration = self
> return s

Okay, that would do it. Sorry about the mixup.

> Now it works. Where can I find your latest Git patch?

That's a good question. I submitted it, I think ... This is the first
time I've used git.

> I did some tests, and found occasions where the original version gives
> better results. I need to do more testing though.

That *is* strange. At worst, the output shouldn't change. Once again,
an example would be nice.

--- Christopher Heckman

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

[no subject]

[Christopher Heckman]

> From: Dan Eble 
> Subject: Default repeat type
>
> It would be convenient if both of these did the same thing:
>
>  A. \lyricmode { Ah __ \repeat unfold 7 _ }
>  B. \lyricmode { Ah __ \repeat 7 _ }

Maybe the user should be able to set the default repeat type? After
all, someone typesetting sheet music might ask for the default to be
volta.

And/or a default type for each mode.

--- CCH

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

Re: bug-lilypond Digest, Vol 189, Issue 17

[Christopher Heckman]

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

Request: Print actual number of pages after compiling

[Christopher Heckman]

This isn't so much a bug as an annoyance.

Frequently when I'm typesetting music, I'm trying to resize the output
to fit on the minimum number of pages (while remaining readable, of
course). When Lilypond is compiling, one of its messages is "Fitting
music on 1 or 2 pages..." Obviously, in this situation, I want to know
the exact number of pages without re-opening the .pdf file. Could
someone add a one-line statement to print out the actual number of
pages, near the "Success: compilation successfully completed" message?

--- Christopher Heckman

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

Bug: q doesn't keep fingerings in TabStaff context

[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

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

Re: bug-lilypond Digest, Vol 197, Issue 11

[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

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

Re: polyphony and TabStaff: don’t put two voices on the same string (Malte Meyn)

[Christopher Heckman]

On Sat, Oct 19, 2019 at 9:00 AM  wrote:
>
> Date: Sat, 19 Oct 2019 10:06:10 +0200
> From: Malte Meyn 
> To: bug-lilypond 
> Subject: polyphony and TabStaff: don’t put two voices on the same
> string
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi list,
>
> this was reported at the LilyPond facebook group. When having “real”
> polyphony with multiple Voice contexts, the notes are put on the strings
> independently which can lead to several voices with different frets on
> the same string.
>
> The first three “chords” on the TabStaff should look the same (1st
> string 3rd fret, 2nd string 5th fret). I’m not sure about the correct
> handling of unisons (second three “chords”) in polyphony because I don’t
> play guitar ;)
>
> %%%
> \version "2.21.0"
>
> music = \relative {
>2
><< g e >>
><< \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) g \\ e >>
>
><< e e >>
><< \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) e \\ e >>
> }
>
> <<
>\new Staff { \clef "treble_8" \music }
>\new TabStaff \music
>  >>
> %%%
>
> I tweaked the extra-offsets so that you can see that LilyPond just
> prints two TabNoteHeads in the exact same space.
>
> Cheers,
> Malte

Even worse, Lilypond can slide from one note to a note on another
string, with something like c \\glissando c'. (The octaves might need
adjusting.)

A few years ago, I worked on an improved tablature algorithm, but
could never get github (or something like it) to work so that other
people could test it out. It would have fixed bugs like this, as well
as being able to tab chords like  (c on E string, d an open D
string, and e on the A string) that Lilypond can't currently handle.

--- Christopher Carl Heckman

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

"Library not loaded" error on MacOS version

[Christopher Heckman]

This is something that has been happening for the past eight months,
since at least version 2.21. I can download and install the latest
version for my operating system (10.12.6), but whenever I try to run
lilypond, I get the "Library not loaded" error:

dyld: Library not loaded: @executable_path/../lib/libintl.8.dylib
   Referenced from: /Applications/LilyPond.app/Contents/Resources/bin/lilypond
   Reason: image not found
Abort trap: 6

There is a fix online --
https://gitlab.com/lilypond/lilypond/-/issues/6143 -- but this doesn't
seem to be helping.

Are any other Mac users having the same problem, and if so, what was
your workaround?

--- Christopher Heckman

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

Re: Polychord Support

[Christopher Heckman]

> Message: 2
> Date: Sat, 29 Jan 2022 21:30:36 +0100
> From: skoop...@web.de
> To: bug-lilypond@gnu.org
> Subject: Polychord support
> Message-ID:
> 
> 
>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> is there meanwhile an easy way to write polychords as a chord name? I found a 
> request on this topic, but no working solution.
>
> "Polychord" means that two chords are layered on top of each other and 
> separated by a horizontal line. For example D major (d - f sharp - a) on top 
> of C major (c - e - g ).
>
> Here are two examples from my work:
> 1) "Bb on top of Ab" (= a flat - c - e flat - f - b flat - d ). I 
> deliberately don't want to notate Ab maj7/#11.
> 2) And this one: "C on top of C#m/Ab" (= a flat - c sharp - e - g - c).
>
> It would be great if there was a workable solution for this by now.
>
> Many greetings
>

There is, as of version 2.20. You can include markup in chord mode,
and use the \fraction construction:

\chords { c1
   \once \override ChordName.text = \markup { \fraction top bottom }
   a1
}

"top" and "bottom" need to be strings, as far as I can tell.

--- CCH

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