"Library not loaded" error on MacOS version
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
> 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
Re: polyphony and TabStaff: don’t put two voices on the same string (Malte Meyn)
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
Request: Print actual number of pages after compiling
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
Re: bug-lilypond Digest, Vol 197, Issue 11
On Thu, Apr 25, 2019 at 9:05 AM wrote: > > Am Mi., 24. Apr. 2019 um 23:24 Uhr schrieb Christopher Heckman > : > > > > I searched for this at the archives, but maybe I didn't look in the right > > place. > > > > The title is pretty self-expanatory. If the pitch e is normally played > > on the 5th string of a guitar (after transposition), then > > > > \new TabStaff { q } > > > > will show e played on the 6th string and then on the 5th string, even > > if you put a tie after . > > > > (This is Lilypond version 2.18.) > > > > --- Christopher Carl Heckman > > Hi, > > thanks for your report, though, see > http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#index-_005cchordRepeats-1 > for > \tabChordRepeats > > Thus no bug. > > > Cheers, > Harm Fair enough. But shouldn't keeping the fingering information be the default? Especially if the chord is an immediate repeat? --- Christopher Carl Heckman ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug: q doesn't keep fingerings in TabStaff context
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 189, Issue 17
On Sun, Aug 26, 2018 at 7:04 AM, wrote: > > Message: 3 > Date: Sun, 26 Aug 2018 11:43:44 +0200 > From: Thomas Morley > To: Pierre Perol-Schneider > Cc: bug-lilypond > Subject: Re: Doc 2.4.2: Indicating harmonics and dampened notes > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > 2018-08-26 11:14 GMT+02:00 Pierre Perol-Schneider > : >> Hi Bug Squad, >> See: >> http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes >> And: >> http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes >> >> 1. I don't understand the reason to put the NoteHead defs at a Staff level. > > Can't see a specific reason here. So I'd vote for deleting "Staff". > >> 2. Maybe a whole note is not the best example to show the 'harmonic-mixed >> result. >> >> How about changing this snippet: >> >> \relative c' { >> \clef "treble_8" >> \override Staff.NoteHead.style = #'harmonic-mixed >> d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1 >> } >> >> To: >> >> \relative c' { >> \clef "treble_8" >> \override NoteHead.style = #'harmonic-mixed >> d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4 >> } >> >> Cheers, >> Pierre > > > Agreed. Also, why not delete some of the superfluous brackets in the > markup? Only keeping the surrounding ones for better viewable > structure. I.e. > \markup { \italic \fontsize #-2 "harm. 12" } Bad suggestion. Currently, \italic takes one argument, the next token (unless it's an opening bracket). If you want to change it so that \italic takes the rest of the arguments (Scheme-style), then previous code like \italic "this is italic " "and this isn't" will break. --- Chris ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
[no subject]
> 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 173, Issue 17
On Mon, Apr 17, 2017 at 9:00 AM, wrote: > > On Sun, Apr 16, 2017 at 9:00 AM, Martin Tarenskeen > 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
Re: midi2ly: Fraction Reduction + 2 minor issues
On Sun, Apr 16, 2017 at 9:00 AM, Martin Tarenskeen wrote: > > On Thu, 13 Apr 2017, Christopher Heckman wrote: > >> I have written a patch to fix this. Inside of the class Duration (line >> 129), replace the dump function with: > > Hi Chris, thanks for trying to improve the midi2ly tool. > > 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 > convert a midifile after applying your patch. Did anyone try Christophers > proposal succesfully? (I installed modified version of midi2ly as > /usr/bin/midi2ly_ on my system) 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": (1) Did midi2ly work before? (2) Is this failing on all midi files, or just one in particular? (Followup: If it's failing all the time, then post a URL to one of your files.) (3) What OS are you using? (I tested midi2ly on the Ubuntu machine at work, and I had no problems. I can't run it on OSX, maybe because I have the "wrong type" of Python on it.) One other thing to mention is that a patch has been posted at git, and it includes the other change I mentioned. (For instance, e4*1/2 now prints as e8, and e8*7/8 now prints as e2.. ) == 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
midi2ly: Fraction Reduction + 2 minor issues
(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: Issue 2214 in lilypond: "fatal error" reported when version is too old but correct output is still generated
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
Re: Mark / Barcheck Bug (#1626) Appearing Again
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
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
Behavior on Errors; Separate Run Output
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