Re: \repeat unfold has problems inside \repeat volta

Le 03/07/2022 à 21:33, Simon Albrecht a écrit : On 02/07/2022 18:20, Jean Abou Samra wrote: Simon, you moved this from bug-lilypond to lilypond-user. Was that intentional? Did I? I’m sure I just clicked Reply All, and the thread as I received is on the user list… this e-mail of yours is the

Re: \repeat unfold has problems inside \repeat volta

On 02/07/2022 18:20, Jean Abou Samra wrote: Simon, you moved this from bug-lilypond to lilypond-user. Was that intentional? Did I? I’m sure I just clicked Reply All, and the thread as I received is on the user list… this e-mail of yours is the first that for me shows the bug list as recipien

Re: LilyPond on macOS (was: \repeat unfold has problems inside \repeat volta)

> On 2 Jul 2022, at 18:35, Carl Sorensen wrote: > > On Sat, Jul 2, 2022 at 10:23 AM Jean Abou Samra wrote: > >> Le 02/07/2022 à 18:14, Carl Sorensen a écrit : >> >>> I can't currently run 2.23.10 on my Mac, so I can't try it, >> >> >> What is the problem you are encountering? I think that n

Re: LilyPond on macOS (was: \repeat unfold has problems inside \repeat volta)

Le 02/07/2022 à 18:35, Carl Sorensen a écrit : On Sat, Jul 2, 2022 at 10:23 AM Jean Abou Samra wrote: Le 02/07/2022 à 18:14, Carl Sorensen a écrit : > I can't currently run 2.23.10 on my Mac, so I can't try it, What is the problem you are encountering? I think that normally

Re: LilyPond on macOS (was: \repeat unfold has problems inside \repeat volta)

On Sat, Jul 2, 2022 at 10:23 AM Jean Abou Samra wrote: > Le 02/07/2022 à 18:14, Carl Sorensen a écrit : > > > I can't currently run 2.23.10 on my Mac, so I can't try it, > > > What is the problem you are encountering? I think that normally, it > should work on all 64-bit-capable Macs. I don't r

LilyPond on macOS (was: \repeat unfold has problems inside \repeat volta)

Le 02/07/2022 à 18:14, Carl Sorensen a écrit : On Sat, Jul 2, 2022 at 8:55 AM Jean Abou Samra wrote: Le 02/07/2022 à 16:04, Simon Albrecht a écrit : > Hi David and others, > > On 01/07/2022 12:32, David Kastrup wrote: >> I don't think so.  The problem is that repeats now

Re: \repeat unfold has problems inside \repeat volta

Le 02/07/2022 à 16:04, Simon Albrecht a écrit : Hi David and others, On 01/07/2022 12:32, David Kastrup wrote: I don't think so.  The problem is that repeats now support putting the \alternative phrase inside of the construct since that is a saner way of doing things.  But the previous way is

Re: svg font problems

> Processing `../repeat-volta.ly' > Parsing... > Interpreting music...[8] > Preprocessing graphical objects... > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > fatal error: cannot find SVG font #f The font problem is issue #3809: the volta number is given

Re: svg font problems

[Changing your e-mail address to 'knupero', which is your preferred one without problems, IIRC] > [...] here's one hint for the volta-spec-once.ly problem: > Roboto-Regular is (on my current system) a font without a glyph > table. You mean the font doesn't have a &

svg font problems

Hi everybody! I try to test  my cairo code using the  input/regression/*.ly files. Of course I need a reference, but to my surprise not all of those regression test files compile fine with our traditional svg backend. I did not investigate the problems and I will not investigate them in the near

Re: Problems with horizontal brackets

Am So., 31. Mai 2020 um 06:35 Uhr schrieb Jon Arnold : > > Hi- > I'm using horizontal brackets to analyze a piece that makes heavy use of > the completion engravers, and I've discovered that the brackets do not > extend the full length of a note when tied over a bar. The bracket only > goes as far

Problems with horizontal brackets

Hi- I'm using horizontal brackets to analyze a piece that makes heavy use of the completion engravers, and I've discovered that the brackets do not extend the full length of a note when tied over a bar. The bracket only goes as far as the beginning of the expanded value. Perhaps the last bit shoul

RE: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

Hello, -Original Message- From: bug-lilypond On Behalf Of Urs Liska Sent: 15 January 2019 09:38 To: bug-lilypond@gnu.org Subject: Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win) Am 15.01.19 um 10:34 schrieb samaru...@aim.com: > Thank you, Carl, for

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

Am 15.01.19 um 10:34 schrieb samaru...@aim.com: Thank you, Carl, for all your research! Normally I'm a searcher and not a questioner, but I hadn't researched StemUp/Down syndrome extensively yet, so I simply added it as a postscript to my more problematic concern, since I also saw it as an XM

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

Thank you, Carl, for all your research! Normally I'm a searcher and not a questioner, but I hadn't researched StemUp/Down syndrome extensively yet, so I simply added it as a postscript to my more problematic concern, since I also saw it as an XML import error and not as a feature. I tried the c

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that woul

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on my Windows system because of the errors listed above (I know that would pr

Re: Windows: XML import problems due to strange blanks in LilyPond 2.19.82 (Win)

On 1/14/19, 9:32 PM, "Carl Sorensen" wrote: On 1/14/19, 11:11 AM, "samaru...@aim.com" wrote: PS Windows+Mac: StemUp/Downs appear everywhere after the import, this was not the case with older LilyPond versions, e.g. 2.19.31, which I still use on

Re: X-aligning problems with chords containing unisons

Hello, On 02/09/18 11:13, Torsten Hämmerle wrote: Hi all, Chords containing unison highest/lowest notes will sometimes produce wrong positioning of articulation marks, dynamics, slurs, etc. These grobs should be centred on the notehead that is on the correct side of the stem (as Gould put it).

Re: X-aligning problems with chords containing unisons

Thanks for reporting, this has been added as . Best, Simon On 02.09.2018 12:13, Torsten Hämmerle wrote: Hi all, Chords containing unison highest/lowest notes will sometimes produce wrong positioning of articulation marks, dynamics, slurs

X-aligning problems with chords containing unisons

Hi all, Chords containing unison highest/lowest notes will sometimes produce wrong positioning of articulation marks, dynamics, slurs, etc. These grobs should be centred on the notehead that is on the correct side of the stem (as Gould put it). Technically, the "correct" side of the stem is deter

Re: [BUG] Problems in gregorian style lyrics with combination of episem and melisma

"James Lowe" writes: > Hello, > > On Sun, 15 Jul 2018 08:59:01 +0200, "Jaap de Wolff" wrote: > >> Hello, >> >> About a week ago I did sent the bug report below. >> There was a comment on it on which I replied. >> At this moment it is still not on the bug list, while younger reports are. >> No o

Re: [BUG] Problems in gregorian style lyrics with combination of episem and melisma

d me it was not a proper bug report, or it was not accepted. > Possible it was not clear that it was intended to be a bug report, so I do > send it again. > > Jaap de Wolff > > > Van: Jaap de Wolff > Verzonden: maandag 9 juli 2018 13:30 > Aan: 'bug-lilypond@gn

[BUG] Problems in gregorian style lyrics with combination of episem and melisma

to be a bug report, so I do send it again. Jaap de Wolff Van: Jaap de Wolff Verzonden: maandag 9 juli 2018 13:30 Aan: 'bug-lilypond@gnu.org' Onderwerp: Problems in gregorian style lyrics with combination of episem and melisma In gregorian lyrics the combination of episem with me

Re: Problems in gregorian style lyrics with combination of episem and melisma

>> In gregorian lyrics the combination of episem with melisma must follow a >> strict order: >> >> \episemInitium \melisma xxx \episemFinis \melismaEnd is the only working >> order >> >> The orders >> >> \episemInitium \melisma xxx \melismaEnd \episemFinis >> \melisma \episemInitium xxx \melisma

Re: Problems in gregorian style lyrics with combination of episem and melisma

"Jaap de Wolff" writes: > In gregorian lyrics the combination of episem with melisma must follow a > strict order: > > \episemInitium \melisma xxx \episemFinis \melismaEnd is the only working > order > > The orders > > \episemInitium \melisma xxx \melismaEnd \episemFinis > \melisma \episemInit

Problems in gregorian style lyrics with combination of episem and melisma

In gregorian lyrics the combination of episem with melisma must follow a strict order: \episemInitium \melisma xxx \episemFinis \melismaEnd is the only working order The orders \episemInitium \melisma xxx \melismaEnd \episemFinis \melisma \episemInitium xxx \melismaEnd \episemFinis \melism

Re: flag position problems with flat-flag style

Hi all, Thanks for all your replies. David Kastrup wrote > You don't _need_ to override the whole list. You could just override > single properties from it. You are of course right, David, I can just use: \override Stem.details.lengths = #'(3.5 3.5 3.5 4.5 5.0 6.0) Thanks for the tip. Torste

Re: flag position problems with flat-flag style

Torsten Hämmerle writes: > Any automatic interference (even if it's only in a special case like for > flat-flag-style) could lead to unpredictable results and the user would lose > part of the freedom and flexibility to set any desired value by modifying > the details lists. > > For this very rea

Re: flag position problems with flat-flag style

Gilberto Agostinho wrote > Wouldn't it be possible to add a conditional to check for those? If an > user > uses flat-flag then they certainly would also prefer these stem length > settings that you posted. Having this automatized would be great. Hmmm, At first glance, that seems to be a good idea

Re: flag position problems with flat-flag style

Gilberto Agostinho wrote > I noticed that the length of the stems in beamed > notes changed considerably after I used your suggestion below, they are > now > much taller than before: Hi Gilberto, Oh, bummer, I had forgotten to set some values back to default after playing around with them... All

Re: flag position problems with flat-flag style

Hi Torsten, Sorry to disturb you but I noticed that the length of the stems in beamed notes changed considerably after I used your suggestion below, they are now much taller than before: Torsten Hämmerle wrote > The modified Stem details are: > > \override Stem.details = #'((lengths 3.5 3.5 3

Re: flag position problems with flat-flag style

Hi Torsten, Thanks a lot for your message and apologies for my late reply, for some reason I did not receive a notification that someone had replied to my post. Also, thank you very much for the modified Stem details, that indeed does the trick. I will add that to all my scores. > There is no c

Re: flag position problems with flat-flag style

Hi Torsten, Thanks a lot for your message and apologies for my late reply, for some reason I did not receive a notification that someone had replied to my post. Also, thank you very much for the modified Stem details, that indeed does the trick. I will add that to all my scores. Torsten Hämmer

Re: flag position problems with flat-flag style

Gilberto Agostinho wrote > I noticed that some of the 32nd-note flags in the flat-flag style seem to > have a layout problem. The flat flags should always match the staff lines > (just like beams do), but in a few cases they are located in between the > staff lines, which looks quite bad. See the m

flag position problems with flat-flag style

Hi all, I noticed that some of the 32nd-note flags in the flat-flag style seem to have a layout problem. The flat flags should always match the staff lines (just like beams do), but in a few cases they are located in between the staff lines, which looks quite bad. See the minimal example below and

Problems with `\repeat percent'

[445bf3bb2fbd1f259fe43ade204fb34d68bdd581] Folks, have a look at NR section `Percent Repeats', `Known Issues and Warnings'. There is code like \relative c'' { \repeat percent 3 { \time 5/4 c2. 2 \time 4/4 2 2 } } which generates the attached image. The generation of a second staff

verifying issues and copy&paste problems with Firefox

I just want to share with the few persons who verify the issues that I just realized why gitk did not work for me recently. When I copy a committish using Firefox, the committish seems perfectly selected, but actually it includes an initial space; so gitk considers invalid the committish. What i

Re: Problems with literal fonts

I'm on sabayon linux and using lilypond 2.18.2, freshly installed Il 15/Apr/2016 00:38, "Simon Albrecht" ha scritto: > On 14.04.2016 20:10, Paolo Bacchetta wrote: > >> Let's say that I couldn't post much. If you want here's the lilypond >> script and its rendering. As you see it's not a problem o

Fwd: Re: Problems with literal fonts

Forwarded Message Subject:Re: Problems with literal fonts Date: Thu, 14 Apr 2016 20:10:03 +0200 From: Paolo Bacchetta To: Simon Albrecht Let's say that I couldn't post much. If you want here's the lilypond script and its rendering. As you

Re: Problems with literal fonts

On 14.04.2016 20:10, Paolo Bacchetta wrote: Let's say that I couldn't post much. If you want here's the lilypond script and its rendering. As you see it's not a problem of personal taste. True, sorry for that. I should’ve asked for your output and further clarification. Now I see the point. On

Re: Problems with literal fonts

Hi Paolo, On 14.04.2016 09:40, Paolo Bacchetta wrote: Fonts in title and authors are simply way too big!! Even with no notes Title, Authors etc are rendered so big that it is impossible to read music 1. It’s not clear what you mean, as Urs already pointed out. 2. Please don’t refer to the bug

Re: Problems with literal fonts

Hm, if you want help or suggestions you should give us a better idea of what you want. If I compile your example I can't read music either, but it's not related to the size of any text fonts ... Urs Am 14.04.2016 um 09:40 schrieb Paolo Bacchetta: > Fonts in title and authors are simply way too b

Problems with literal fonts

Fonts in title and authors are simply way too big!! Even with no notes Title, Authors etc are rendered so big that it is impossible to read music \version "2.18.2" \header { title = "Prova" composer = "P. Bacchetta" } global = { \key c \major \time 4/4 } jazzGuitar = \relative c' { \

Problems with --init

Lilypond 2.19.27 Windows 8.1 Global.ily: \version "2.19.27" \language "english" Test.ly: \score { \new Staff { c' d' e' f' } } When I try running "lilypond -init=Global.ily Test.ly", I get: error:

Re: 2 problems using NullVoice to align lyrics

Luming writes: > 1. When I added a NullVoice into a staff with a existing homophony Voice, > all previously-correctly-placed rest marks are engraved in a polyphonic > manner (in the lower-half of the staff instead of in the middle), unless it > is a "r" or a "s" in the NullVoice at the same time

2 problems using NullVoice to align lyrics

1. When I added a NullVoice into a staff with a existing homophony Voice, all previously-correctly-placed rest marks are engraved in a polyphonic manner (in the lower-half of the staff instead of in the middle), unless it is a "r" or a "s" in the NullVoice at the same time. I did not notice any ma

Re: git-cl: Problems with Rietveld authentication

On 07/01/15 02:33, Paul Morris wrote: Heikki Tauriainen wrote >Apparently the problem was that access to the Google account was not >enabled for "less secure apps" in the account's security settings; >git-cl worked after changing this option. Sorry about the noise. I'm glad I found this post.

Re: Cross-staff beam problems (collisions & ugly slope)

On Tue, Nov 18, 2014 at 7:17 PM, Marcus Macauley wrote: > \version "2.18.2" > The example above is my attempt at a "tiny" illustration of three > simultaneous problems with a cross-staff beam: collisions (of beam with > notes or accidentals); ugly slopes; a

Cross-staff beam problems (collisions & ugly slope)

{ \clef bass s4*7} >> The example above is my attempt at a "tiny" illustration of three simultaneous problems with a cross-staff beam: collisions (of beam with notes or accidentals); ugly slopes; and ugly horizontal spacing (stem spacing overcorrection). I checked the Lilypond Google Proj

Fwd: Fwd: 64-bit font problems in GUB

forgot to reply-all -- Forwarded message -- From: Simon Bailey Date: Thu, Jan 23, 2014 at 5:32 PM Subject: Re: Fwd: 64-bit font problems in GUB To: James On Thu, Jan 23, 2014 at 5:19 PM, James wrote: > I think we have it > > http://code.google.com/p/lilypond/issues/

Re: Fwd: 64-bit font problems in GUB

"James" wrote in message news:52e1448d.8040...@gmail.com... On 23/01/14 16:32, Simon Bailey wrote: On Thu, Jan 23, 2014 at 5:19 PM, James wrote: I think we have it http://code.google.com/p/lilypond/issues/detail?id=2656 ah right. shall i add some comments there as well? at the moment, that

Re: Fwd: 64-bit font problems in GUB

On 23/01/14 16:32, Simon Bailey wrote: On Thu, Jan 23, 2014 at 5:19 PM, James wrote: I think we have it http://code.google.com/p/lilypond/issues/detail?id=2656 ah right. shall i add some comments there as well? at the moment, that issue only seems to be marked for Windows and Linux. regards

Re: Fwd: 64-bit font problems in GUB

On 23/01/14 10:02, Simon Bailey wrote: Hello, I kicked this thread off last week sometime: http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00762.html TL/DR summary: ligatures were not being shown for lilypond-generated output. further investigation led me to: http://lists.gnu.org/arc

Fwd: 64-bit font problems in GUB

-- Forwarded message -- From: Simon Bailey Date: Thu, Jan 23, 2014 at 10:20 AM Subject: 64-bit font problems in GUB To: lilypond-user Mailinglist Hello, I kicked this thread off last week sometime: http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00762.html TL/DR

Fwd: 64-bit font problems in GUB

Hello, I kicked this thread off last week sometime: http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00762.html TL/DR summary: ligatures were not being shown for lilypond-generated output. further investigation led me to: http://lists.gnu.org/archive/html/lilypond-user/2014-01/msg00804.

Re: Sustain pedal problems with voices/staffs

On 01/04/2014 12:35 PM, Helge Hafting wrote: Notation for the sustain pedal has a problem. \sustainOff must be issued in the same Voice and the same Staff as the corresponding \sustainOn. Or the engraving will fail, the MIDI will be wrong, and there will be error messages about the unknown piano

Sustain pedal problems with voices/staffs

Notation for the sustain pedal has a problem. \sustainOff must be issued in the same Voice and the same Staff as the corresponding \sustainOn. Or the engraving will fail, the MIDI will be wrong, and there will be error messages about the unknown piano pedal. This is a problem, because voices come

Re: More \quoteDuring problems, with and without \partcombine

tcombineChords r4 \quoteDuring #"violin2" { s2 } r4 | }/ ...and it will at least get you around the problem in most cases. Dominic -- View this message in context: http://lilypond.1069038.n5.nabble.com/More-quoteDuring-problems-with-and-without-partcombine-tp66413p148482.html Se

Problems with 'scripts/auxiliar/doc-section.sh

Hi, I'm having problems with the script to build only one doc section. I have LilyPond from the Git repository, on branch master, latest fetches. When running the script I get the following error: /home/uliska/git/3rd-party-repos/lilypond/Documentation/contributor/administration.itely di

Re: Fingerings in chords - accidentals and unison problems

Il 27/01/2013 23:21, Olivier Biot ha scritto: I'm not top posting. %%% BEGIN snippet % Bug report % 1. Accidentals in a chord (slightly) overlap with fingerings (left chord) % 2. Two fingerings assigned to one notehead with unison notes in a chord (right chord) % Extensive "test chart" posted i

Fingerings in chords - accidentals and unison problems

> I'm not top posting. %%% BEGIN snippet % Bug report % 1. Accidentals in a chord (slightly) overlap with fingerings (left chord) % 2. Two fingerings assigned to one notehead with unison notes in a chord (right chord) % Extensive "test chart" posted in http://lilypond.1069038.n5.nabble.com/Fingeri

Re: Changing document fonts with non-standard global font size causes scaling problems.

> It seems to be a duplicate of your other post on that day, > to which the bug squad did respond. Also this explains why > Xavier thought it was an outstanding report the other day. No worries. I don't recall how I submitted it, so I guess something happened and it was double posted. But thanks f

Re: Changing document fonts with non-standard global font size causes scaling problems.

Arle Lommel gmail.com> writes: > > (Lilypond 2.16.1) > > http://lilypond.org/doc/v2.16/Documentation/notation/fonts contains > instructions on how to change default document fonts. The instructions > require hard coding a staff size of some sort. However, if the global > staff size is set to a

Re: Changing fonts with global staff size other than 20 leads to scaling problems

On Fri, Dec 14, 2012 at 10:45:50AM +0100, Arle Lommel wrote: > (Lilypond 2.16.1) > > http://lilypond.org/doc/v2.16/Documentation/notation/fonts contains > instructions on how to change default document fonts. The instructions > require hard coding a staff size of some sort. However, if the globa

Changing fonts with global staff size other than 20 leads to scaling problems

(Lilypond 2.16.1) http://lilypond.org/doc/v2.16/Documentation/notation/fonts contains instructions on how to change default document fonts. The instructions require hard coding a staff size of some sort. However, if the global staff size is set to a value other than 20, the scaling of note head

Changing document fonts with non-standard global font size causes scaling problems.

(Lilypond 2.16.1) http://lilypond.org/doc/v2.16/Documentation/notation/fonts contains instructions on how to change default document fonts. The instructions require hard coding a staff size of some sort. However, if the global staff size is set to a value other than 20, the scaling of note heads a

Re: Two problems: font choice and lyrics

wrote in message news:14221.193.174.248.2.1352484071.squir...@lavabit.com... Hello everybody, during my recent work with lilypond I encountered two quite annoying problems: - If both fontsize and the font itself have been changed in a document, the font choice is not taken into account and

Re: Two problems: font choice and lyrics

wrote in message news:14221.193.174.248.2.1352484071.squir...@lavabit.com... Hello everybody, during my recent work with lilypond I encountered two quite annoying problems: - If both fontsize and the font itself have been changed in a document, the font choice is not taken into account and

Two problems: font choice and lyrics

Hello everybody, during my recent work with lilypond I encountered two quite annoying problems: - If both fontsize and the font itself have been changed in a document, the font choice is not taken into account and Computer Modern appears nevertheless. Omitting the change of fontsize also rids the

Re: Fingering problems 2.17.4

On 11/10/12 13:18, Nick Payne wrote: > On 11/10/12 08:02, Marek Klein wrote: >> Hello, >> 2012/10/10 Nick Payne > > >> >> See example below: >> >> a) without any fingering orientation specified, the fingerings are >> incorrectly placed, such that the

Re: Fingering problems 2.17.4

On 11/10/12 08:02, Marek Klein wrote: > Hello, > 2012/10/10 Nick Payne > > > See example below: > > a) without any fingering orientation specified, the fingerings are > incorrectly placed, such that the two fingerings above the staff > collide, a

Re: Fingering problems 2.17.4

Hello, 2012/10/10 Nick Payne > See example below: > > a) without any fingering orientation specified, the fingerings are > incorrectly placed, such that the two fingerings above the staff > collide, and the fingerings also appear in the wrong order (the 0 should > not appear next to the E and the

Fingering problems 2.17.4

See example below: a) without any fingering orientation specified, the fingerings are incorrectly placed, such that the two fingerings above the staff collide, and the fingerings also appear in the wrong order (the 0 should not appear next to the E and the 2 should not appear above). b) with fing

Re: Some problems in the docs, as encountered by a beginner

Hello, 2012/9/4 Neil Sands > Hello > > I hope this is the right place to point out some errors in the LilyPond > Learning > Manual. I'm a beginner to LilyPond so I may have got the wrong end of the > stick > about some things. If so, please tell me! > > Thank you for the report, I have added it

Re: Some problems in the docs, as encountered by a beginner

On Tue, Sep 04, 2012 at 05:27:46PM +, Neil Sands wrote: > I hope this is the right place to point out some errors in the LilyPond > Learning > Manual. Thanks for the feedback! Normally this would go to the bug-lilypond mailing list, which I've CC'd. > 1. http://lilypond.org/doc/v2.16/Docum

Re: vertical skylines problems

list > > bug-lilypond@gnu.org > > https://lists.gnu.org/mailman/listinfo/bug-lilypond > > A couple quick responses. > > 1) Get the LedgerLineSpanner to produce vertical skylines and that solves > half of the problems. > 2) Create an override for DynamicText (or wha

Re: vertical skylines problems

On Thu, Aug 30, 2012 at 02:50:18PM +0200, Mike Solomon wrote: > On 30 ao?t 2012, at 14:10, Reinhold Kainhofer wrote: > > > I really like the new vertical skylines patch, as it now moves dynamics > > and hairpins much closer to the notes they belong to (so far, they often > > left some ugly space)

Re: vertical skylines problems

t; * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com > ___ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond A couple quick responses. 1) Get the LedgerLineSpanner to produce vertical skyl

Re: Problems with \inversion

On Thu, Jun 21, 2012 at 11:09:13PM +0100, Trevor Daniels wrote: > > David Kastrup wrote Tuesday, June 19, 2012 10:57 AM > > > > "Both in relative notation" is asking for trouble. I'd strongly suggest > > only inverting absolute music, and the result of \relative ... _is_ > > absolute music. >

Re: Problems with \inversion

David Kastrup wrote Tuesday, June 19, 2012 10:57 AM > "Trevor Daniels" writes: > >> Colin Hall wrote Tuesday, June 19, 2012 1:12 AM >> >>> It looks like the behaviour has been explained by David Kastrup here: >>> >>> http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00380.html >>>

Re: Problems with \inversion

"Trevor Daniels" writes: > Colin Hall wrote Tuesday, June 19, 2012 1:12 AM > >> It looks like the behaviour has been explained by David Kastrup here: >> >> http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00380.html >> >> So, no bug in Lilypond to report then. > > Correct. > >> If

Re: Problems with \inversion

Colin Hall wrote Tuesday, June 19, 2012 1:12 AM > It looks like the behaviour has been explained by David Kastrup here: > > http://lists.gnu.org/archive/html/lilypond-user/2012-06/msg00380.html > > So, no bug in Lilypond to report then. Correct. > If either of you, Alexandre or Trevor, woul

Re: Problems with \inversion

On Wed, Jun 13, 2012 at 11:31:34PM +0100, Trevor Daniels wrote: > > ALEXANDRE FICAGNA wrote Wednesday, June 13, 2012 2:57 PM > > > >I still didn't picture exactly how \inverse works in its from-pitch > > to-pitch variables, but I tried an example and what I got is the > > correct inversion of pi

Re: Problems with \inversion

You're right, it worked better with relative for melody. Still, it seems that changing from-pitch alters the note of transposition, while to-pitch changes absolutely nothing. Best Alexandre 2012/6/13 Trevor Daniels : > > ALEXANDRE FICAGNA wrote Wednesday, June 13, 2012 2:57 PM > > >>I still didn'

Re: Problems with \inversion

ALEXANDRE FICAGNA wrote Thursday, June 14, 2012 12:12 PM > You're right, it worked better with relative for melody. > Still, it seems that changing from-pitch alters the note of > transposition, while to-pitch changes absolutely nothing. David explained the reason for the behaviour in your earl

Re: Problems with \inversion

ALEXANDRE FICAGNA wrote Wednesday, June 13, 2012 2:57 PM >I still didn't picture exactly how \inverse works in its from-pitch > to-pitch variables, but I tried an example and what I got is the > correct inversion of pitches, but each one was an octave above. > > Here's the code: > > \version "

Re: slurs in polyphony and TabStaff problems

On Sun, Jun 10, 2012 at 05:22:22PM +0200, Federico Bruni wrote: > Il 10/06/2012 17:11, Colin Hall ha scritto: > >You'll forgive me, I hope, but my interest begins and ends with > >administration of the issue tracker. > > > >So, could you confirm whether there are two distinct bug reports here, or

Re: slurs in polyphony and TabStaff problems

Il 10/06/2012 17:11, Colin Hall ha scritto: You'll forgive me, I hope, but my interest begins and ends with administration of the issue tracker. So, could you confirm whether there are two distinct bug reports here, or just one? they are both about ugly slurs, but they are distinct: #2587: i

Re: slurs in polyphony and TabStaff problems

On Sun, Jun 10, 2012 at 03:42:36PM +0200, Federico Bruni wrote: > Il 10/06/2012 14:42, Colin Hall ha scritto: > >Hi Federico, > > > >The SVG file you sent looks nothing like the PNG images that you sent > >in your original bug report that started this thread. It looks a bit > >like the one for your

Re: slurs in polyphony and TabStaff problems

Il 10/06/2012 14:42, Colin Hall ha scritto: Hi Federico, The SVG file you sent looks nothing like the PNG images that you sent in your original bug report that started this thread. It looks a bit like the one for your other bug report "Ugly slur in TabStaff if font is changed" Can you clarify p

Re: slurs in polyphony and TabStaff problems

back. > I'm not expert in notation at all. All I can say is that slur should > be closer to notes (see .svg file edited in Inkscape). Hi Federico, The SVG file you sent looks nothing like the PNG images that you sent in your original bug report that started this thread. It looks a bit like the

Re: slurs in polyphony and TabStaff problems

On Sun, Jun 10, 2012 at 03:08:58AM +0200, Federico Bruni wrote: > Il 07/06/2012 11:21, m...@apollinemike.com ha scritto: > > > >On 7 juin 2012, at 07:36, Federico Bruni wrote: > > > > > > The slur in TabStaff is really ugly. > > > Tested with 2.15.40 packaged version > > > > > > Thanks, > > > Feder

Re: slurs in polyphony and TabStaff problems

Il 07/06/2012 11:21, m...@apollinemike.com ha scritto: On 7 juin 2012, at 07:36, Federico Bruni wrote: Il 04/06/2012 09:11, m...@apollinemike.com ha scritto: On 4 juin 2012, at 08:05, David Kastrup wrote: Federico Bruni writes: Another report about slurs and TabStaff. IIUC, now slurs co

Re: slurs in polyphony and TabStaff problems

ek, I'm guessing you started work on this and then found 2587. I know how annoying that can be. Sorry about any wasted effort on your part. Federico, being a well behaved user, filed separate bug reports for distinct problems even though both problems were about slurs and TabStaff. Thank you,

Re: slurs in polyphony and TabStaff problems

Hello, 2012/6/3 Federico Bruni > Another report about slurs and TabStaff. > IIUC, now slurs connect note heads in polyphony (instead of stems). > I _think_ that it's a desired output. > > However, it's breaking the TabStaff slurs. > Find attached .png examples (see differences between 2.14.2 and

Re: slurs in polyphony and TabStaff problems

"m...@apollinemike.com" writes: > Thanks Federico, > > The issue must be that, somewhere, stems are being read as visible for > the slur. Should be a one liner[1]. > > ~Mike > > [1] If I had a nickel for every time I said "should be a one liner" > and I was wrong by 3 orders of magnitude, I'd ha

Re: slurs in polyphony and TabStaff problems

On 7 juin 2012, at 07:36, Federico Bruni wrote: > Il 04/06/2012 09:11, m...@apollinemike.com ha scritto: >> On 4 juin 2012, at 08:05, David Kastrup wrote: >> >>> Federico Bruni writes: >>> Another report about slurs and TabStaff. IIUC, now slurs connect note heads in polyphony (inste

Re: slurs in polyphony and TabStaff problems

On 7 juin 2012, at 07:36, Federico Bruni wrote: > Il 04/06/2012 09:11, m...@apollinemike.com ha scritto: >> On 4 juin 2012, at 08:05, David Kastrup wrote: >> >>> Federico Bruni writes: >>> Another report about slurs and TabStaff. IIUC, now slurs connect note heads in polyphony (inste

Re: slurs in polyphony and TabStaff problems

Il 04/06/2012 09:11, m...@apollinemike.com ha scritto: On 4 juin 2012, at 08:05, David Kastrup wrote: Federico Bruni writes: Another report about slurs and TabStaff. IIUC, now slurs connect note heads in polyphony (instead of stems). I _think_ that it's a desired output. Frankly, it does n

  1   2   3   4   5   6   >