Re: Fingering inside staff

On 5/30/20, Thomas Morley wrote: > add-stem-support is not really documented. > Alas, I've not the time and energy to write a patch myself and fight > my way through the new GitLab process. “Fighting your way” sounds pretty accurate these days. If I may give it a try:

Re: Fingering inside staff

Am Sa., 30. Mai 2020 um 13:18 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Alas, I've not the time and energy to write a patch myself and fight > > my way through the new GitLab process. > > git push -o merge_request.create -o merge_request.title="My patch" -o >

Re: Fingering inside staff

Thomas Morley writes: > Alas, I've not the time and energy to write a patch myself and fight > my way through the new GitLab process. git push -o merge_request.create -o merge_request.title="My patch" -o merge_request.remove_source_branch origin HEAD:my-proposed-branch-name The push message

Re: Fingering inside staff

Am Sa., 30. Mai 2020 um 10:15 Uhr schrieb Valentin Villenave : > > On 5/30/20, Thomas Morley wrote: > > Fingering.add-stem-support is per default set to 'only-if-beamed' > > Of course!! I vaguely remembered having come across something like > that. Sorry for making a fool of myself. > > > Try:

Re: Lilypond not working with Mac 10.15.4

Horst via bug-lilypond writes: > Hello, > > I recently updated to macOS Catalina (Version 10.15.4). Since then I > cannot work with Lilypond anymore. I also downloaded the developer > version lilypond-2.21.1-1. However, when trying to open Lilypond I > always get the following error message: > >

Re: Fingering inside staff

On 5/30/20, Valentin Villenave wrote: > Excellent; NOTABUT then. Ouch. NOTABUG. (Though I can’t say I wasn’t childishly tempted to add an additional T :-) V. ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: Fingering inside staff

On 5/30/20, Thomas Morley wrote: > Fingering.add-stem-support is per default set to 'only-if-beamed' Of course!! I vaguely remembered having come across something like that. Sorry for making a fool of myself. > Try: > \override Fingering.add-stem-support = #'() > and it'll work Excellent;

Re: Fingering inside staff

Am Sa., 30. Mai 2020 um 00:08 Uhr schrieb Valentin Villenave : > > On 5/29/20, Pierre Perol-Schneider wrote: > > Hi Simone, > > A basic solution: > > \relative c' { > > \stemUp > > \override Fingering.staff-padding = #'() > > 4 8 > > } > > Sure there are workarounds, but: shouldn’t we be

Re: Fingering inside staff

On 5/29/20, Pierre Perol-Schneider wrote: > Hi Simone, > A basic solution: > \relative c' { > \stemUp > \override Fingering.staff-padding = #'() > 4 8 > } Sure there are workarounds, but: shouldn’t we be treating this as a bug? There’s no obvious reason why unsetting staff-padding should

Re: musicxml2ly

Am Montag, den 25.05.2020, 16:17 +0200 schrieb Lukas-Fabian Moser: > On Sat, 23 May 2020, Martin Tarenskeen wrote: > > > > There must be something seriously broken if musicxml2ly can't convert > > > > this > > > > > > P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and > > >

Re: musicxml2ly

Lukas-Fabian Moser writes: > On Sat, 23 May 2020, Martin Tarenskeen wrote: There must be something seriously broken if musicxml2ly can't convert this >>> P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and >>> the problem disappeared. So it does look like a

Re: musicxml2ly

On Sat, 23 May 2020, Martin Tarenskeen wrote: There must be something seriously broken if musicxml2ly can't convert this P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and the problem disappeared. So it does look like a regression to me. Thanks Martin; I’ve opened this

Re: musicxml2ly

On Mon, 25 May 2020, Valentin Villenave wrote: Thanks Martin; I’ve opened this tracker page: https://gitlab.com/lilypond/lilypond/-/issues/5994 It seems weird that such a problem wasn’t caught by our pretty-extensive test suite, so I’m wondering what might be particular to your test file.

Re: musicxml2ly

On 5/23/20, Martin Tarenskeen wrote: > > On Sat, 23 May 2020, Martin Tarenskeen wrote: >> There must be something seriously broken if musicxml2ly can't convert >> this > > P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and > the problem disappeared. So it does look like a

Re: Keys won't display as text in saxophone diagram

Hi all, I've tested every key in both modes and everything seems to be working more or less as expected. No crashes (except for the issue with the low A key that Torsten already pointed out). One thing I've noticed is that some key names in textual mode might be misplaced; if you look at the

Re: Keys won't display as text in saxophone diagram

On 5/23/20, Antonio Ortega Brook wrote: > @Carl: yes, that's exactly what I was looking for (although things may have > changed a bit, now...), thank you very much. As far as I can tell, > everything seems to be working as expected. Great! Carl, feel free to open a merge request or to push new

Re: Keys won't display as text in saxophone diagram

; { > >^\fingering > > r r > >^\fingeringGraph > > } > > } > > > > I got what appears to match your desired output in Text mode, as well as > the proper output in graphical mode (I think). > > > > Carl > > > > > > *

Re: Keys won't display as text in saxophone diagram

per output in graphical mode (I think). Carl From: Antonio Ortega Brook Date: Thursday, May 21, 2020 at 9:18 PM To: Carl Sorensen Cc: "bug-lilypond@gnu.org" , Valentin Villenave , Valentin Villenave Subject: Re: Keys won't display as text in saxophone diagram This would be the desire

Re: Keys won't display as text in saxophone diagram

d@gnu.org" , Valentin Villenave < > valen...@villenave.net>, Valentin Villenave > *Subject: *Re: Keys won't display as text in saxophone diagram > > > > Oh, don't worry, I've already edited the file (just took a look at > Valentin's merge request to see what was chan

Re: Keys won't display as text in saxophone diagram

What is the desired output? Carl From: Antonio Ortega Brook Date: Thursday, May 21, 2020 at 7:13 PM To: Carl Sorensen Cc: "bug-lilypond@gnu.org" , Valentin Villenave , Valentin Villenave Subject: Re: Keys won't display as text in saxophone diagram Oh, don't worry, I've alre

Re: Keys won't display as text in saxophone diagram

Valentin, Thanks for the quick fix. I was trying to fix it, but I'm not as fast as you. If you attach the proper copy of scm/display-woodwind-diagrams.scm to an email, I can give Antonio instructions about how to get the file into the proper place on his MacOS. The instructions: Browse

Re: Keys won't display as text in saxophone diagram

Oh, don't worry, I've already edited the file (just took a look at Valentin's merge request to see what was changed). After fixing this a new issue came up: in text mode, the octave key is displayed as a misaligned circle, instead of a T letter. I paste the code below an attach the output. Cheers

Re: Keys won't display as text in saxophone diagram

On 5/21/20, Antonio Ortega Brook wrote: > Hello everyone. First of all I think maybe I misunderstood the instructions > for bug reporting and I've opened an issue in GitLab before posting to this > list and now I think that I might not be supposed to do that. I'm very > sorry for the

Re: musicxml2ly fails on with multiple

On Tue, 19 May 2020 at 12:18, Valentin Villenave wrote: > As far as I can see it doesn’t break anything from our regression > tests, so unless someone more knowledgeable than me objects, it should > be merged in the next version (2.21.2). Thanks! ___

Re: musicxml2ly fails on with multiple

On 5/18/20, Noam Postavsky wrote: >> > Ping? >> Ping?? > Ping??? Greetings Noam, thanks for being so persistent; I’m not very familiar with musicxml2ly but I submitted your patch here on your behalf: https://gitlab.com/lilypond/lilypond/-/merge_requests/65 As far as I can see it doesn’t break

Re: musicxml2ly fails on with multiple

On Sun, 26 Apr 2020 at 13:12, Noam Postavsky wrote: > > > The attached example-musicxml-display-part-bug.xml shows a minimal > > > example to trigger the bug. It gives this output: > > > > > get_maybe_exist_typed_child > > > raise "More than 1 child", klass > > > Ping? > Ping?? Ping???

Re: Small bugs in "Changes" document

On 5/16/20, Timothy Lanfear wrote: > The descriptions of changes to \powerChords, \partcombine and > \autochange have acquired an extra backslash. Thanks for catching that; it should be fixed shortly: https://gitlab.com/lilypond/lilypond/-/merge_requests/58 Cheers, -- V.

Re: accidentalStyle choral: too many accidentals in situations with ties

On 5/15/20, Alexander Kobel wrote: > a clear case of undesired behavior. … Otherwise known as a bug. I agree. I’m thinking there’s a good chance that it’s another instance of https://gitlab.com/lilypond/lilypond/-/issues/3466 (but Simon’s example is much nicer so I’ve just added it there.)

Re: accidentalStyle choral: too many accidentals in situations with ties

Hi, agreed, this is unpleasant. FWIW, it's the same behavior in the piano style, which I based choral on. I had to make up my mind whether this is intended or not, but the fact that making up my mind took so long suggests that it's probably not... ;-) The key idea of the choral style is to

Re: [bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver

On Wed, May 6, 2020 at 7:06 PM David Kastrup wrote: > Valentin Villenave writes: > > > On 5/6/20, Trevor Bača wrote: > >> The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1. > > > > Wow, that’s a nice one. I’m marking this as Critical because its a/ a > > segfault, b/ a

Re: NR A.11.7 Other -- footnote v2.20 / v2.21

On 05/05/2020 16:12, Pierre Perol-Schneider wrote: Hi Bug squad, Typo here: http://lilypond.org/doc/v2.21/Documentation/notation/other#index-_005cfootnote-2 The code should be: \markup { \footnote a b \override #'(padding . 0.2) \footnote c d } Cheers, Pierre

Re: [bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver

Valentin Villenave writes: > On 5/6/20, Trevor Bača wrote: >> The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1. > > Wow, that’s a nice one. I’m marking this as Critical because its a/ a > segfault, b/ a regression and c/ not that unusual a use case. >

Re: [bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver

On 5/6/20, Trevor Bača wrote: > The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1. Wow, that’s a nice one. I’m marking this as Critical because its a/ a segfault, b/ a regression and c/ not that unusual a use case. https://sourceforge.net/p/testlilyissues/issues/5964/ Since

Re: Unable to generate output

Hello, I ran into the same issue today. Resolved by installing lilypond-2.20.0-1 from the official website. I am running Gentoo Linux with guile 2.2.4 and ghostscript 9.21, for reference. Cheers, Apricot -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

Re: musicxml2ly Pitch Changing Potential Bug

Alex Hansen wrote > I think I have found a bug. The following musicXML, when run through > musicxml2ly, produces lilypond which has entirely different pitches. I've > cut out as much of the XML as possible to ensure it is a minimal example. > Note that the musicXML specifies a single D whole note,

Re: 2.20 Manuals search box

Il giorno sab 2 mag 2020 alle 09:40, Pierre Perol-Schneider ha scritto: Hi Bug squad, Search boxes included in the manuals re-direct to the v2.19 manuals instead of the v2.20. Cheers, Pierre Last month Valentin wrote that v2.20 was not indexed by Google yet: https://lists.gnu.org

Re: Documentation update

Ross On 01/05/2020 20:32, Ross Mohn wrote: LilyPond Usage Manual v2.20.0 Section 4.4.2 OpenOffice and LibreOffice , please update the link when clicking on OOoLilyPond from the old

Re: No Mac OS 64-bit link of Lilypond in non-English Download section

Il giorno gio 30 apr 2020 alle 16:12, Caio Barros ha scritto: Hello! The link to the Unofficial 64-bit app for Mac OS is not present in non-English versions of the website. See, for instance: https://lilypond.org/macos-x.de.html https://lilypond.org/macos-x.pt.html

Re: musicxml2ly fails on with multiple

On Tue, 24 Mar 2020 at 18:38, Noam Postavsky wrote: > > On Thu, 5 Mar 2020 at 22:45, Noam Postavsky wrote: > > > > The attached example-musicxml-display-part-bug.xml shows a minimal > > example to trigger the bug. It gives this output: > > > get_maybe_exist_typed_child > > raise "More than 1

Re: Mac mit Catalina

Hallo, das hier hat schon manchen mit Catalina geholfen (this one did it for some users): https://lists.gnu.org/archive/html/lilypond-user/2019-11/msg00295.html Es gab schon einige Fragen dazu, ich habe sie aber nicht so genau verfolgt, weil ich keinen Mac habe:

Re: Missing link: Rhythms

Am 20.04.2020 um 15:07 schrieb Jean-Charles Malahieude: > Le 20/04/2020 à 14:01, Thomas Morley a écrit : >> Am Mo., 20. Apr. 2020 um 13:16 Uhr schrieb Bernhard Kleine >> : >>> >>> When in >>> http://lilypond.org/doc/v2.19/Documentation/notation/bars#bar-lines I >>> engage the link

Re: Missing link: Rhythms

Le 20/04/2020 à 14:01, Thomas Morley a écrit : Am Mo., 20. Apr. 2020 um 13:16 Uhr schrieb Bernhard Kleine : When in http://lilypond.org/doc/v2.19/Documentation/notation/bars#bar-lines I engage the link "Schnipsel":Rhythms it is not found:

Re: Missing link: Rhythms

Am Mo., 20. Apr. 2020 um 13:16 Uhr schrieb Bernhard Kleine : > > When in > http://lilypond.org/doc/v2.19/Documentation/notation/bars#bar-lines I > engage the link "Schnipsel":Rhythms it is not found: > > http://lilypond.org/doc/v2.19/Documentation/snippets/rhythmus. After doing some random

Re: Bar number with chord name

On 4/19/20, 9:07 AM, "Aidan O Connor" wrote: Hi, Thanks for that info. The workaround makes sense. But the behavior seems a little inconsistent. If the cord names are removed the bar numbers appear above the staff, but below the fret diagram. Is the fret diagram not considered part of the

Re: SystemStart changes after stop/startStaff - how to get it back

Hi Aaron, Am Di., 14. Apr. 2020 um 06:20 Uhr schrieb Aaron Hill : > > I think I have addressed the original issue in this patched version of > the System_start_delimiter_engraver. This is implemented in Scheme, but > the changes should be easily ported back to C++. > > The strategy is to

Re: Bar number with chord name

Hi, Thanks for that workaround, it works well. Regards Aidan From: Xavier Scheuer Sent: Sunday 19 April 2020 05:03 To: Aidan O Connor Cc: bug-lilypond@gnu.org Subject: Re: Bar number with chord name On Sat, 18 Apr 2020 at 19:49, Aidan O Connor mailto:a

Re: Bar number with chord name

From: v.villen...@gmail.com on behalf of Valentin Villenave Sent: Sunday 19 April 2020 15:40 To: Aidan O Connor Cc: bug-lilypond@gnu.org Subject: Re: Bar number with chord name On 4/18/20, Aidan O Connor wrote: > When chord names are included, the bar numbers are positioned ab

Re: Bar number with chord name

On 4/18/20, Aidan O Connor wrote: > When chord names are included, the bar numbers are positioned above the > chord name. Greetings, Well, yes and no. They are positioned above the whole *system* (the Score context), of which the ChordNames context is a part. So whilst that’s certainly quite

Re: Bar number with chord name

On Sat, 18 Apr 2020 at 19:49, Aidan O Connor wrote: > > When chord names are included, the bar numbers are positioned above the chord name. This is particularly noticeable if a fret diagram is also included. The bar numbers should be positioned immediately above the staff. > In this example, the

Re: SVG style and contributing barrier to entry

> In any case, I'm subscribed so I'll cross-post and CC James so > that the patch (which looks correct to me) is not lost. I've just applied it to staging. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: SVG style and contributing barrier to entry

Am Donnerstag, den 16.04.2020, 05:00 -0400 schrieb Patrice Levesque: > Hi! > > I just discovered that the “style” tag created inside svg output uses the > wrong syntax, e.g. > >

Re: bookOutputName variable title

> On 15 Apr 2020, at 22:31, Urs Liska wrote: > > Am Mittwoch, den 15.04.2020, 22:30 +0200 schrieb Hans Åberg: >>> On 15 Apr 2020, at 21:56, Urs Liska wrote: >>> >>> If you change >>> >>> \bookOutputName \title >>> to >>> \bookOutputName "test" >>> it works. >>> >>> This is because

Re: bookOutputName variable title

Am Mittwoch, den 15.04.2020, 22:30 +0200 schrieb Hans Åberg: > > On 15 Apr 2020, at 21:56, Urs Liska wrote: > > > > If you change > > > > \bookOutputName \title > > to > > \bookOutputName "test" > > it works. > > > > This is because Frescobaldi is not able to resolve the "\title" > >

Re: bookOutputName variable title

> On 15 Apr 2020, at 21:56, Urs Liska wrote: > > If you change > > \bookOutputName \title > to > \bookOutputName "test" > it works. > > This is because Frescobaldi is not able to resolve the "\title" > variable. This has been known for a long time and is anything but > trivial, as you can

Re: bookOutputName variable title

Am Mittwoch, den 15.04.2020, 12:50 -0700 schrieb thse: > In Frescobaldi, the filename of the lilypond source should be the > same as of > the output files. In your case - as long as you don't save it under a > different name - the source is named "document.ly" (at least on my > linux > system),

Re: bookOutputName variable title

On 2020-04-15 12:50 pm, thse wrote: In Frescobaldi, the filename of the lilypond source should be the same as of the output files. In your case - as long as you don't save it under a different name - the source is named "document.ly" (at least on my linux system), but the produced files are

Re: bookOutputName variable title

In Frescobaldi, the filename of the lilypond source should be the same as of the output files. In your case - as long as you don't save it under a different name - the source is named "document.ly" (at least on my linux system), but the produced files are "test.pdf" and "test.midi". Frescobaldi

Re: bookOutputName variable title

Hi Torsten I thought exactly the same thing and I contacted Frescobaldi but they sent me here... Thank you for your help. Gloops -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org

Re: bookOutputName variable title

Bugs mailing list wrote > I think it is a Lilypond bug but I let you judge ... > […] Hi Gloops, I can't see a LilyPond bug here because LilyPond does exactly what it is supposed to do (at least in my LilyPond/Frescobaldi/Windows environment): It creates a PDF file named test.pdf and a MIDI file

Re: bookOutputName variable title

Gloops via bug-lilypond writes: > Hello! > I think it is a Lilypond bug but I let you judge ... > No matter the version of Lilypond from "2.18.2" to "2.21.0" > No matter the version of Frescobaldi from "2.18" to "3.1.1" > On Windows 10 64 > Thank you > > \version "2.20.0" > > title = "test" >

Re: Learning Manual: wrong reference to NR manual

> @ruser{Engraving ties manually} in Learning Manual is incorrect, as > such a node doesn't exist. Fixed in staging, thanks for the report. > Perhaps there's a way to use a index link? texinfo's @anchor command is what you are searching for :-) Werner

Re: SystemStart changes after stop/startStaff - how to get it back

I think I have addressed the original issue in this patched version of the System_start_delimiter_engraver. This is implemented in Scheme, but the changes should be easily ported back to C++. The strategy is to acknowledge the end of StaffSymbols to be able to remove their corresponding

Re: Setting SystemStartBracket style to 'brace failing

Am Sa., 11. Apr. 2020 um 14:01 Uhr schrieb Thomas Morley : > > Hi, > > consider the following code: > > mus = > \relative c'' > << > \new Staff { c1 } > \new Staff { c1 } > >> > > \new StaffGroup > \with { > \override SystemStartBracket #'style = #'brace > } > \mus

Re: 3/4 time

Sincerely thanks Sent from my iPhone > On Apr 12, 2020, at 8:56 AM, Noeck wrote: > > Dear Sylvia, > >> Am 12.04.20 um 17:39 schrieb Sylvia Cassel: >> f1:maj7 a1:aug7 bes1:maj7 d1:aug7 > > Your harmonies have a duration of 1 (whole note) but your measures are > only 3 quarters long (time

Re: 3/4 time

Dear Sylvia, Am 12.04.20 um 17:39 schrieb Sylvia Cassel: > f1:maj7 a1:aug7 bes1:maj7 d1:aug7 Your harmonies have a duration of 1 (whole note) but your measures are only 3 quarters long (time 3/4): f2.:maj7 a2.:aug7 … and you can write the duration only once if it is the same as previously:

Re: 3/4 time

Sylvia Cassel writes: > Hello out there, > Has anyone has a chance to look at this? Am I doing something wrong or is > there a bug?? How can I get the chord notations over the right measure? Aaron Hill already posted a reply to the list. These lists aren't write-only dumps: if you post

Re: SystemStart changes after stop/startStaff - how to get it back

On 4/12/20, Thomas Morley wrote: > Over the last decades I tried again and again to find a better > workaround, with less manual work. Apparently we stumbled upon your white whale :-) > I now come up with the attached. Brilliant. Although it’s still a workaround. > To get the gaps in

Re: SystemStart changes after stop/startStaff - how to get it back

Am So., 12. Apr. 2020 um 14:00 Uhr schrieb Aaron Hill : > > On 2020-04-12 3:50 am, Thomas Morley wrote: > > Hi, > > > > consider the following code: > > > > > > mus = \new Staff { R1 \break R \stopStaff s \startStaff R \break R > > \break R } > > > > \new StaffGroup > > \with { > >

Re: SystemStart changes after stop/startStaff - how to get it back

On 2020-04-12 3:50 am, Thomas Morley wrote: Hi, consider the following code: mus = \new Staff { R1 \break R \stopStaff s \startStaff R \break R \break R } \new StaffGroup \with { systemStartDelimiterHierarchy = #'(SystemStartBracket (SystemStartBrace a b c)) } << \mus

Re: SystemStart changes after stop/startStaff - how to get it back

On 4/12/20, Thomas Morley wrote: > Hi, > The SystemStartBrace vanishes after stop/startStaff. Weird. That’s definitely an unwanted behavior (in other words, a bug). > consider the following code: > > > mus = \new Staff { R1 \break R \stopStaff s \startStaff R \break R \break R > } > > \new

Re: lyric in false voice by temporary polyphonic notation

On Fri, Apr 10, 2020 at 10:09:24AM +0200, astrid wrote: > Hallo, > > in the german forum for lilypond -> > https://lilypondforum.de/index.php/topic,667.0.html > > I asked for a solution, but got no answer. It is a bug, I suggest; see here: > > If I write (an it's the same in \version "20.21.0"): >

Re: hide issue

Il giorno gio 9 apr 2020 alle 09:28, dfleu...@free.fr ha scritto: Hi, in this code sample : \relative c' { c d \hide r4. f8 } I expect that the hide command will hide the dot for r4. Regards, PS: Now, I use s4 instead. s (spacer rest) is what you should use in this case. \hide is

Re: associatedVoice in multi-staff score

On 4/4/20, Thomas Morley wrote: > At least it should be documented, probably as "known issues and warnings" The two examples in NR 2.1.2.2 seem clear: """ use the same syntax as above [that is, with \new Lyrics below \new Staff] and explicitly specify the position of the lyrics: " """

Re: Wrong alignment when adding additional lyrics multiple times on the same line

a a a \repeat volta 3 { b4 b b b } c4 c c c \repeat volta 3 { b4 b b b } c4 c c c } } } \new Lyrics = "firstVerse" s1*5 \new Lyrics = "secondVerse" s1*5 \new Lyrics = "thirdVerse" s1*5

Re: 3/4 time

On 2020-04-03 4:04 am, Sylvia Cassel wrote: % In doing a lead sheet in 3/4 time, the melody notation comes out correctly % but the chords don't line up with the measures. They seem to assume 4/4 time. harmonies = \chordmode { f1:maj7 a1:aug7 bes1:maj7 d1:aug7 } You are specifying whole

Re: Message to David Fuqua

Yep sorry for that Francisco... Le mar. 31 mars 2020 à 11:56, Francisco Vila a écrit : > El 31/3/20 a las 7:05, Pierre Perol-Schneider escribió: > > (double post -- to remove tel number) > > If email worked like this, that would be fine. > > -- > Francisco Vila, Ph.D. - Badajoz (Spain) >

Re: Message to David Fuqua

El 31/3/20 a las 7:05, Pierre Perol-Schneider escribió: (double post -- to remove tel number) If email worked like this, that would be fine. -- Francisco Vila, Ph.D. - Badajoz (Spain) paconet.org , lilypond.es ___ bug-lilypond mailing list

Re: Message to David Fuqua

> Regarding this snippet: > http://lsr.di.unimi.it/LSR/Item?id=1005 > See below agreement. > Cheers, > Pierre > > -- Forwarded message - > De : Frog Peak Music > Date: mar. 31 mars 2020 à 00:53 > Subject: Re: Message to David Fuqua > To: Pierre Pe

Re: Spacing in clef changes

Hi, Le 24/03/2020 à 23:54, Trevor a écrit : Valentin, you wrote 24/03/2020 22:35:05 Hi Jean, you may want to open it yourself; you could tag it as "Defect" (I believe "Ugly" would be a bit strong -- there once was an "Engraving_nitpick" tag that would have been perfect, but it doesn’t seem to

Re: Unable to Use LilyPond

On Wed, Mar 25, 2020 at 3:09 PM Jahrme Risner wrote: [...] > > One slight correction here, MacPorts will provide pre-built binaries when > available, building from source is usually only needed if you are on an > unusual platform or attempt to upgrade immediately after an update has been >

Re: Unable to Use LilyPond

On Wed, Mar 25, 2020 at 11:52, Marnen Laibow-Koser <[1]mar...@marnen.org> wrote: On Wed, Mar 25, 2020 at 2:41 PM Jahrme Risner <[2]lilyp...@jahrme.com> wrote: On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes <[3]wesleymrho...@gmail.com> wrote: Hello! I hope you area

Re: Unable to Use LilyPond

On Wed, Mar 25, 2020 at 2:41 PM Jahrme Risner wrote: > > > On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes > wrote: > > Hello! > > > I hope you area all doing well during this time. I am a MacBook user > running macOS Catalina. I was thrilled to find LilyPond, but it appears to > not be working

Re: Unable to Use LilyPond

On Tue, Mar 24, 2020 at 20:43, Wesley Rhodes <[1]wesleymrho...@gmail.com> wrote: Hello! I hope you area all doing well during this time. I am a MacBook user running macOS Catalina. I was thrilled to find LilyPond, but it appears to not be working for me. I

Re[2]: Spacing in clef changes

Valentin, you wrote 24/03/2020 22:35:05 Hi Jean, you may want to open it yourself; you could tag it as "Defect" (I believe "Ugly" would be a bit strong -- there once was an "Engraving_nitpick" tag that would have been perfect, but it doesn’t seem to have survived the migration to Allura…) As a

Re: musicxml2ly fails on with multiple

On Thu, 5 Mar 2020 at 22:45, Noam Postavsky wrote: > > The attached example-musicxml-display-part-bug.xml shows a minimal > example to trigger the bug. It gives this output: > get_maybe_exist_typed_child > raise "More than 1 child", klass > The original case where I ran into this is >

Re: Spacing in clef changes

On 3/19/20, Jean Abou Samra wrote: > Please tell me if you open an issue (I would like to follow the ticket). Hi Jean, you may want to open it yourself; you could tag it as "Defect" (I believe "Ugly" would be a bit strong -- there once was an "Engraving_nitpick" tag that would have been perfect,

Re: [Spam] Re: Re: quoteDuring and repeat tremolo don't work together

For the examples I sent, 2.20 gives the same result as 2.21 (and any previous version, as far as I know). I had also tried with cueDuring but that didn't work either: no tremolos unless a "real" note follows in the quotation. Lilypond still reports these warnings/errors (line numbers apply

Re: Re: quoteDuring and repeat tremolo don't work together

On 2020-03-21 17:15, Mark Knoop wrote: At 15:10 on 21 Mar 2020, David Kastrup wrote: Mark Knoop writes: At 12:52 on 21 Mar 2020, Rutger Hofman wrote: Good morning list, when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo beams are missing or distorted. If the quotation

Re: [Spam] Re: quoteDuring and repeat tremolo don't work together

This 'unterminated chord tremolo' warning says all. Does an event like 'TremoloEnd' exist, which can be patched as a workaround? Rutger On 3/21/20 6:42 PM, Francisco Vila wrote: El 21/3/20 a las 15:20, Mark Knoop escribió: You need to set quotedEventTypes to include tremolo-event I knew

Re: [Spam] Re: quoteDuring and repeat tremolo don't work together

patched -> patched in On 3/22/20 11:41 AM, Rutger Hofman wrote: This 'unterminated chord tremolo' warning says all. Does an event like 'TremoloEnd' exist, which can be patched as a workaround? Rutger On 3/21/20 6:42 PM, Francisco Vila wrote: El 21/3/20 a las 15:20, Mark Knoop escribió: You

Re: quoteDuring and repeat tremolo don't work together

El 21/3/20 a las 15:20, Mark Knoop escribió: You need to set quotedEventTypes to include tremolo-event I knew this was the solution but still can not make it compile correctly. There are many of warning: unterminated chord tremolo programming error: cyclic dependency:

Re: quoteDuring and repeat tremolo don't work together

At 15:10 on 21 Mar 2020, David Kastrup wrote: > Mark Knoop writes: >> At 12:52 on 21 Mar 2020, Rutger Hofman wrote: >>> Good morning list, >>> >>> when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo >>> beams are missing or distorted. If the quotation has nontremolo music >>>

Re: quoteDuring and repeat tremolo don't work together

Mark Knoop writes: > At 12:52 on 21 Mar 2020, Rutger Hofman wrote: >> Good morning list, >> >> when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo >> beams are missing or distorted. If the quotation has nontremolo music >> afterwards, there is no issue. >> >> I didn't find a

Re: quoteDuring and repeat tremolo don't work together

At 12:52 on 21 Mar 2020, Rutger Hofman wrote: > Good morning list, > > when I end a \quoteDuring after a \repeat tremolo { ... }, the tremolo > beams are missing or distorted. If the quotation has nontremolo music > afterwards, there is no issue. > > I didn't find a workaround. I tried adding a

Re: Infinity or NaN encountered when omitting NoteHead

Hi, Eventually, I found a workaround for this: \version "2.21.0" { << { a } \\ { \override NoteHead.stencil = #(lambda (grob) (grob-interpret-markup grob #{ \markup \transparent \filled-box

RE: Segfault when using specific symbol combination

dumped) Best, Mathias -Original Message- From: Federico Bruni Sent: 06 March 2020 16:34 To: Mathias Bockwoldt Cc: bug-lilypond@gnu.org Subject: Re: Segfault when using specific symbol combination Il giorno ven 6 mar 2020 alle 11:38, Mathias Bockwoldt ha scritto: > Dear Lilypond t

Re: abc2ly script doesn't support dynamics

(My comments are below the quoted message) On Fri, 6 Mar 2020, alex wrote: I am using `abc2ly`, provided in the lilypond packaging, to convert the following ABC to Lilypond: C: Alex Hansen L: 1/128 V:TI clef=treble name="Voice 1" snm="V.1" V:TII clef=bass name="Voice 2" snm="V.2"

Re: musicxml2ly unsupported unicode range

> While I am not an apologist for any operating system, I fear folks are being far too quick to blame Windows here. > Like any current operating system concerned with internationalization, Windows and NTFS handles and supports filenames with Unicode characters just fine. There are

Re: Some dots are too far from the note heads

Thank you, Pierre. Jun > 2020/03/09 0:11、Pierre Perol-Schneider のメール: > > Hi Jun, > The v2.18 -- and older -- will give you the same output. It's not a bug. > Try: > > \version "2.20.0" > \relative c'' > { > \time 3/4 > \key d \minor > << > { g'2. f} > \\ > {cis, b} > \\

Re: Some dots are too far from the note heads

Hi Jun, The v2.18 -- and older -- will give you the same output. It's not a bug. Try: \version "2.20.0" \relative c'' { \time 3/4 \key d \minor << { g'2. f} \\ {cis, b} \\ {a' d} \\ {e, gis} >> } \layout { \context { \Staff \remove

<    6   7   8   9   10   11   12   13   14   15   >