Cross staff stems don’t work with shifted notes

> I'm not top posting. The following won’t shift the C (or the A) horizontally and connect the stems of G and C. \version "2.19.13" \new PianoStaff \with { \consists #Span_stem_engraver } << << a' \\ \crossStaff g' %change this to f' and it will work >> c'' >> _

Please add German documentation reference on arpeggio brackets with connectArpeggios.

> I'm not top posting. The English documentation writes “The simple way of setting parenthesis-style arpeggio brackets does not work for cross-staff arpeggios; see Cross-staff stems.” This reference to the section about cross-staff stems isn’t present in the German notation reference: “Die Arpegg

StemTremolo collides with natural Accidental

> I'm not top posting. Hello list, for StemTremolos in short durations the length of a Stem is increased. But it is not long enough when a natural Accidental is directly placed in front of the note, so they collide: \version "2.19.22" { b'!2:16 % default stem length, doesn’t collide b'!2:32

Re: StemTremolo collides with natural Accidental

Am 20.07.2015 um 20:15 schrieb James: Hello Malte, On 20/07/15 17:00, Malte Meyn wrote: \version "2.19.22" { b'!2:16 % default stem length, doesn’t collide b'!2:32 % stem length increased but not enough } I think this has been reported as: https://code.google.com/p/

Re: StemTremolo collides with natural Accidental

Hi James, I don’t think that this is the same thing: The tremolo in issue 3143 is a Beam grob between whole notes/semibreves (and only in the case of whole notes it breaks, not as a beam between half notes/minims); I am talking about StemTremolo grobs. Apart from the collision, I think that

Re: Grace prevents \voiceOne when set at the same time

This was issue 630, fixed in 2.19.16. Am 23.07.2015 um 11:00 schrieb Xavier Scheuer: I'm not top posting. Hi, I do not know if this was already reported (I did not find it in the tracker). \grace (and similar \acciaccatura etc.) prevents \voiceOne (and similar \stemUp etc.) when they are bot

feature request: turn partcombine to partCombine (camelCase)

Hi list, the case of the ‘c’ in partcombine is inconsistent, confusing me every time I use \partcombine(Apart|Chords|…): \partcombine, \partcombineApart, … but \partCombineTextsOnNote, \partCombineListener I would suggest to change all occurences of ‘partcombine’ to ‘partCombine’. Why not ch

Re: avoid-slur should be outside in script.scm for "turn"

Am 14.08.2015 um 12:24 schrieb Martin Müller: Example: \relative c''{ % Problem r2 r4 a8.\turn (c16) % temporary solution % (\turn = script- object) \once \override Script.avoid-slur = #'outside a8.\turn (c16) } Mus. example: Beethoven op. 119 No.1, measur

Re: avoid-slur should be outside in script.scm for "turn"

Am 14.08.2015 um 14:27 schrieb Martin Müller: The example you've posted is not really a counter example, because the turn (and the slur) is above the staff anyway, so setting Script.avoid-slur has no effect in this case: \version "2.18.2" \relative { \key bes \major \time 3/4 \on

\parenthesize script on cross-staff-beamed note fails

Hi list, in the following example, the \parenthesize command doesn’t respect the width of the parenthesized script (same problem for other scripts like fermata). %%% \version "2.19.25" << \new Staff = "upper" { s4 } \new Staff { b16-\parenthesize-> b b \chan

Re: \parenthesize script on cross-staff-beamed note fails

Am 15.08.2015 um 10:43 schrieb Malte Meyn: Hi list, in the following example, the \parenthesize command doesn’t respect the width of the parenthesized script (same problem for other scripts like fermata). %%% \version "2.19.25" << \new Staff = "upper&qu

Re: Another parenthesize issue

Am 15.08.2015 um 16:45 schrieb Andrew Bernard: In the following MWE, when a slur is used, the two articulations overlap. I believe they should be stacked, as in the case shown with no slur. \version "2.19.25" { \slurDown c''16^!-\parenthesize ^> d''-\parenthesize ^> ^!( ees'') fis''-\par

Re: Hairpin flared + circled-tip won't work together.

Am 19.08.2015 um 18:01 schrieb Karim Haddad: Hello list, I hope this issue is not reported. If it is sorry to post it again : It has been reported two years ago: https://code.google.com/p/lilypond/issues/detail?id=3357 It doesn’t work because the default hairpin stencil (ly:hairpin::print,

setting tempo in \midi crashes

% \version "2.19.28" \score { { c' d' e' f' } \midi { \set Score.tempoWholesPerMinute = #(ly:make-moment 4 120) } } % Hi list, this creates an empty midi file and then crashes without (LilyPond) error or warning but with exit status 136. LilyPond 2.19.28 for Linux (64bit) L

Re: setting tempo in \midi crashes

Am 28.10.2015 um 22:41 schrieb Malte Meyn: % \version "2.19.28" \score { { c' d' e' f' } \midi { \set Score.tempoWholesPerMinute = #(ly:make-moment 4 120) } } % Sorry, I just realized I have to write #(ly:make-moment 120 4) instead of #(l

Re: setting tempo in \midi crashes

Am 28.10.2015 um 22:53 schrieb Pierre Perol-Schneider: Hi Malte, Try : % \version "2.19.28" \score { { c' d' e' f' } \midi { tempoWholesPerMinute = #(ly:make-moment 4 120) This doesn’t do anything and if it did it would probably crash for the same reason (swapped 4 and 120)

collision: french beaming vs. articulation

Articulations at stem ends seem to ignore beams so french beaming leads to collisions: \version "2.19.30" { \override Stem.french-beaming = ##t \repeat unfold 8 g'16^> } ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mail

Re: collision: french beaming vs. articulation

It’s not only articulations but slurs, phrasing slurs, fingerings and string numbers (and maybe other things): \version "2.19.30" \relative { \override Stem.french-beaming = ##t g'16 g^> g^\fermata g g a^( g) a g a^\( g\) a g g^3 g^\3 g } Am 20.11.2015 um 21:44

Re: Enhancement: Non-power-of-2 note values

Am 25.11.2015 um 23:12 schrieb Simon Albrecht: I think it would be a nice way to ease writing, unambiguous and LilyPondish :-) The time length of a duration like 1/12 is clear but I don’t think that it’s notational representation is totally unambiguous, see http://lilypondblog.org/2014/09

Re: ugly slur from chord to note

Am 25.11.2015 um 13:54 schrieb David Kastrup: From the issue description of issue 4625 implementing in-chord slurs: Output is still rather rough. Basics are there now, but the finetuning leaves a lot to be desired. The heavy lifting is done, but it requires further work by program

accidental changes beam slope in other staff

Hi list, I found a small but weird bug concerning beam slopes: In the following code, every accidental sign (including quarter tones) except natural and semisharp will change the direction of beam slope the other staff. IMO the changed beam slope looks wrong. % \version "2.19.30" % sha

Re: accidental changes beam slope in other staff

Am 11.12.2015 um 16:54 schrieb James Lowe: Malte, On 11/12/15 14:48, Malte Meyn wrote: Hi list, I found a small but weird bug concerning beam slopes: In the following code, every accidental sign (including quarter tones) except natural and semisharp will change the direction of beam slope

Re: Automatically shift dynamics horizontally?

Am 27.01.2016 um 10:19 schrieb Urs Liska: > In such situations one will usually shift the dynamics to the left, and > Lily will automatically use the space better. You can see that when you > uncomment one of the lines in \off. > > Would there be a way to approach this problem automatically, pre

Re: vergessenes Auflösungszeiche (Fehler in LP?)

Am 21.02.2016 um 11:54 schrieb David Kastrup: So in summary: you state to LilyPond that you never want to see an accidental before a natural G and you complain that you see no accidental before a natural G. I think the problem is: If you set accidentals.natural for G in pitchGlyphs, every G

\displayMusic and UTF-8

Hi list, attached you find a file that tries to \displayMusic a string containing the apostrophe ’ (U+2019). Everything fine with this file says my hexeditor. But not with lilypond’s output which you find in the attached file displayMusic_utf8_output.txt. The apostrophe from the source (disp

incorrect skyline (beam, \changeStaff)

Hi list, the following code produces an incorrect skyline for the "rh" staff. It includes the noteheads but not the stems and beam. This happens only with certain rhythms (for example, 8. 16 in the "lh" staff produces a correct skyline in the "rh" staff). \version "2.19.40" % also 2.18.2, 2.

Re: Parenthesized accent

Am 11.06.2016 um 04:28 schrieb Andrew Bernard: When parenthesizing an accent on a cross staff note, the parentheses are drawn incorrectly. Is this a bug? Andrew == snip \version "2.19.42" treble = { \clef treble \crossStaff { c''4-\parenthesize^> } c'' } bass = { \clef bass \

Re: Parenthesized accent

Am 11.06.2016 um 12:13 schrieb Andrew Bernard: But don’t you think this is a defect in lilypond? Yes, I do. I just wanted to show you a solution to use until it’s fixed ;) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mai

New scheme list/identifier syntax has undocumented side-effects

Hi list, the German LilyPond forum discovered a side effect of the new identifier syntax: additional to \version "2.19.40" FOO = { c d e } \FOO there are now more cases where you cannot use a variable immediately after it’s definition: \version "2.19.40" FOO = "This is a markup" \FOO BAR =

Re: LM 2.4.1: errors in variable definitions

Am 17.07.2016 um 09:16 schrieb Federico Bruni: 3. width variable triggers this error: error: unknown escaped string: `\cm' I don't know how to fix this, Put the definition of width into an \paper block. cm seems to be unknown outside. \paper { width = 4.5\cm }

Re: LM 2.4.1: errors in variable definitions

Am 17.07.2016 um 11:44 schrieb David Kastrup: I thought the default unit was staff spaces? Not in the paper block. See paper-defaults-init.ly, lines 30ff. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug

Fwd: Missing warning about clashing note columns in 2.19

Jul 2016 18:27:09 +0200 Von: Malte Meyn An: lilypond-user Is this a bug/regression? 2.18.2 warns about clashing note columns, 2.19.44 does not. \version "2.19.44" << c''4 \\ \stemUp a'2 >> ___

fingeringOrientations and StringNumber.direction broken?

Hi list, I think I found one or two bugs or at least a *very* confusing inconsistency: \overriding StringNumber.direction and \setting fingeringOrientations seem to have no effect but \overriding Fingering.direction and \setting stringNumberOrientations have an effect. IMO the output sho

fingeringOrientations and StringNumber.direction broken?

Hi list, I think I found one or two bugs or at least a *very* confusing inconsistency: \overriding StringNumber.direction and \setting fingeringOrientations seem to have no effect but \overriding Fingering.direction and \setting stringNumberOrientations have an effect. IMO the output sho

font-encoding and MeasureCounter

Hi list, I wanted to change the font of the MeasureCounter to standard roman font instead of feta number glyphs so i tried \override MeasureCounter.font-family = #'roman This didn’t have an effect but I found something in the LSR: According to http://lsr.di.unimi.it/LSR/Item?id=932 \o

Re: Slur-articulation collision

Am 16.09.2016 um 10:50 schrieb Simon Albrecht: Hello everybody, is this a known bug? I couldn’t find it in the tracker. \version "2.19.47" \relative { \voiceTwo c''4( b e-!) } Best, Simon This first occurs in 2.19.16, maybe introduced by commit 9f966033 (fix for issue 2535)? ___

Re: Pitched Trill Collision

Am 30.09.2016 um 15:47 schrieb dtsmarin: How can I move the pitched trill note so that the ledger lines aren't connected? Try using a version ≤ 2.19.40. This shouldn't happen at all. You have to change the engraving rules for this specific notation. This is a bug which was introduced betw

Re: Bug: Choice of notes provokes unwanted dual staff system

Am 06.10.2016 um 19:13 schrieb Lee Zipin: It doesn't happen (in my testing) if I remove the line specifying the pickup note in the lower staff. And it doesn't happen if I remove the \score (and \layout) wrapper (which I need for multiple bookparts). I get the same results on 2.18.2 and 2.19.4

Re: Mark numbering incorrect at staff level

Am 12.10.2016 um 15:45 schrieb Phil Holmes: As the attached image shows, the mark numbering is incorrect in the first score. Anyone know why? When the \mark command (defined in ly/define-music-functions.ly) is given an integer argument (\mark 6) it sets the context property rehearsalMark f

Download links missing at http://lilypond.org/index.de.html

The german version of index.html is missing the right column with download and manual links. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Download links missing at http://lilypond.org/index.de.html

Am 22.10.2016 um 15:37 schrieb Jean-Charles Malahieude: My German writing is very old, but here is a patch. If any gentle German would kindly proofread… line 43, 57: “LilyPond ist ist” -> “LilyPond ist” line 43, 57: “Werkzeug, dass” -> “Werkzeug, das” line 44, 58: “der unterschiedlichsten Art

Re: Parenthesis issue with cross staff beaming

Am 01.01.2017 um 02:17 schrieb Andrew Bernard: > Here is an MWE showing an issue I encounter regularly with the > parenthesizing of accents. It only occurs when using cross staff beaming > which I use a lot. This is issue 4892, reported half a year ago. _

Re: 2.19.56 Learning Manual correction.

Am 11.03.2017 um 15:30 schrieb Knute Snortum: > 3.3.2 Creating contexts > > In an input file a score block, introduced with a \score command, contains > a single music expression and an associated output definition (either a > \layout or a \midi block). > I'm thinking the last part of the senten

Re: TupletBracket.shorten-pair with strange output

Am 09.04.2017 um 20:53 schrieb Thomas Morley: > I would have expected the whole bracket to be (much) smaller, instead > only the part of the bracket left from TupletNumber is affected. How do you expect any sensible output from that? 10 is so much that the “left” end of the bracket is right from

Programming error when using very many grace notes [was: Re: ]

Hi Alex, please say which LilyPond version you are using. Issues 2 and 3 probably are no bugs but partly intended behaviour (although I really much would like at least a warning and maybe an error when a line is longer than it should be like TeX’s “Overfull hbox”). And I cannot reproduce your

Re: accidentals on merged notes

Am 12.08.2017 um 17:05 schrieb Hauke Rehr: Still, the output doesn’t match at least /my/ expectations: notes should either not be merged at all, or there should be stacked accidentals indicating which one applies to which Voice. How should this be a default behaviour? IMO none of those two op

Re: accidentals on merged notes

Am 13.08.2017 um 09:53 schrieb Knut Petersen: Am 12.08.2017 um 20:56 schrieb Malte Meyn: Am 12.08.2017 um 17:05 schrieb Hauke Rehr: Still, the output doesn’t match at least /my/ expectations: notes should either not be merged at all, or there should be stacked accidentals indicating which

Glissando.font-size

\override-ing Glissando.font-size has an effect. IMO any effect is unexpected here but this particular effect is especially weird. \version "2.19.65" { c'1\glissando c'' \override Glissando.font-size = 10 c'1\glissando c'' } BTW there’s neither 'shorten-pair/'padding/… nor has 'gap a vis

Re: Glissando.font-size

Am 27.09.2017 um 11:48 schrieb Malte Meyn: \override-ing Glissando.font-size has an effect. IMO any effect is unexpected here but this particular effect is especially weird. It seems like this is (partially?) on purpose: The stencil Line_spanner::print from line-spanner.cc scales the

Re: Bad clef change collision when alternating piano staves

Hi Ophir, this bug hasn’t been fixed yet but there’s a cleaner solution than tweaking X-offsets and X-extents: Temporarily use another voice. Cheers, Malte \version "2.18.2" \new PianoStaff << \new Staff = "RH" \relative a' { \clef treble << \new Voice { s2 a8

\tempo feature requests

Hi list, could the snippets http://lsr.di.unimi.it/LSR/Item?id=1008 and http://lsr.di.unimi.it/LSR/Item?id=574 become part of LilyPond? Maybe with all or some of the following additions/changes: Snippet 1008: • To make it backwards-compatible don’t change the default sizes; maybe introduce a

Re: Footnote separator line

Am 11.10.2017 um 14:55 schrieb Malte Meyn: Am 11.10.2017 um 14:42 schrieb Jan-Peter Voigt: Hi fellows, I have a footnote in a score. This footnote is separated by a centered horizontal line. Is there a possibility to remove it or adjust formatting? TIA Jan-Peter \paper {   footnote

\cueDuring at begin of music prevents Voice context

Hi list, I was almost sure that this is a known issue but I couldn’t find it on the tracker. Having a cue at the very beginning of music prevents the implicit creation of a Voice context and puts the “not-cue” notes into the CueVoice context too: %%

Percent repeats

Hi list, in the LilyPond facebook group someone reported again issue 3146 (https://sourceforge.net/p/testlilyissues/issues/3146/). Before I looked at the tracker I tried to find a solution in Scheme but then I saw that 1. almost the whole thing is written in C++ and thus not changeable for a

Re: dead link in http://lilypond.org/doc/v2.18/Documentation/

Am 29.10.2017 um 15:33 schrieb bb: http://lilypond.org/doc/v2.18/Documentation/notation/common-notation-for-percussion the link Schnipsel: Percussion. http://lilypond.org/doc/v2.18/Documentation/snippets/schlagzeug -> not found In the english version it's active http://lilypond.org/doc/v2.18/Docu

Re: dead link in http://lilypond.org/doc/v2.18/Documentation/

Where? I cannot find it … Am 29.10.2017 um 16:41 schrieb Federico Bruni: It's a known problem, already in the tracker Il 29 ottobre 2017 15:46:47 CET, Malte Meyn ha scritto: Am 29.10.2017 um 15:33 schrieb bb: http://lilypond.org/doc/v2.18/Documentation/notation/c

Re: conversion rule for set-octavation/ottava with wrong version number?

Am 01.11.2017 um 09:26 schrieb David Kastrup: I see that commit 589ba7953e92ad4ad793d89291b97d738614408e Author: Reinhold Kainhofer Date: Sat Jun 28 14:07:25 2008 +0200 New function: \ottava #oct, replaces #(set-octavation oct) was introduced in 2.11.53, _including_ the convert-ly ru

Re: conversion rule for set-octavation/ottava with wrong version number?

Am 01.11.2017 um 10:43 schrieb Malte Meyn: One could have the same convert-ly rule twice: First time for the version where a new feature is introduced and it’s *possible and recommended* to use it. Second time for the version where the old feature (and thus backward compatibility) is removed

Position of dots in mensural ligatures

Hi list, according to Willi Apel in “The Notation of Polyphonic Music, 900–1600” augmentation dots in ligatures should be placed above, not right of the note the augment except if it’s the last note of the ligature. See attached picture, it translates to “Every note within a ligature can be

repeatTie and staff-position

Hi list, someone on the german forum asked whether the following is a bug (https://lilypondforum.de/index.php/topic,216.0.html): RepeatTies are longer if the NoteHead lies between two staff lines, but not always. As I found out, they seem to be longer IFF both the NoteHead and the RepeatTie

Re: repeatTie and staff-position

Am 31.12.2017 um 12:57 schrieb Phil Holmes: "Malte Meyn" wrote in message news:91fbce53-6cc1-9f42-7819-52a50ad96...@maltemeyn.de... Hi list, someone on the german forum asked whether the following is a bug (https://lilypondforum.de/index.php/topic,216.0.html): RepeatTies are

\compressMMRests vs. \compressFullBarRests and \expandFullBarRests

Hi list, while looking where the documentation of restNumberThreshold could be adde to the NR (issue 5251) I realized that we have three ways to compress MMRs and all of them do basically the same (though 2 doesn’t do only one \set and one \unset but a \once \set for every rest): 1. \set Sco

GSoC Adding variants of font glyphs

Hi list, don’t we already have different breve heads for on-line and between-line notes? \version "2.19.80" \relative { \omit Staff.StaffSymbol \override NoteHead.style = #'baroque % also mensural/neomensural/… \time 4/2 f'\breve g } Instead, maybe italic numbers (issue 5074, https:

Re: GSoC Adding variants of font glyphs

Am 22.01.2018 um 09:21 schrieb Urs Liska: Yes, but there are others missing. IIRC one trigger for this project idea was Janek complaining about the looks of accidentals on or off the line: Ok, so it’s not only about noteheads. Nevertheless I think the sentence “Another, more specific exampl

Fwd: stanza alignment

It seems to be a bug. Worked as expected in 2.18.2, doesn’t work in 2.19.81 and current master. Weitergeleitete Nachricht Betreff: stanza alignment Datum: Sat, 11 Nov 2017 12:08:53 +0100 Von: Malte Meyn An: lilypond-user Hi list, when I have multiple verses the stanza

Doc: 2.19 changes cuts off varC clef

Hi list, the four varC clefs at http://lilypond.org/doc/v2.19/Documentation/changes/ are cut off at the top (all) and bottom (varC/altovarC). Cheers, Malte ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bu

\offset argument order

Hi list, is there a reason for the special order of \offset arguments? I would prefer \offset Beam positions #'(2 . 3) or—even better because there would be no confusion with \override— \offset Beam.positions #'(2 . 3) instead of the current \offset positions #'(2 . 3) Bea

Re: \offset argument order

Am 23.03.2018 um 12:47 schrieb David Kastrup: Malte Meyn writes: Hi list, is there a reason for the special order of \offset arguments? I would prefer \offset Beam positions #'(2 . 3) or—even better because there would be no confusion with \override— \offset Beam.posi

Re: \offset argument order

Am 23.03.2018 um 19:25 schrieb David Kastrup: Why is this on the bug list? That was an accident, sorry (typed lilypond, hit enter, didn’t realise that autocompletion did not what I had expected) You get the drift. Yes, now that I got to know both versions of the command (\override and

Feature request: LaissezVibrerTie.minimum-length

Hi list, it would be nice if we didn’t need snippet 715 (http://lsr.di.unimi.it/LSR/Item?id=715) for almost every single occurence of \laissezVibrer. Would it be possible to have a property minimum-length, maybe with a default value that makes them longer as they currently are? Same for Rep

Re: Feature request: LaissezVibrerTie.minimum-length

Am 10.04.2018 um 09:04 schrieb Malte Meyn: Hi list, it would be nice if we didn’t need snippet 715 (http://lsr.di.unimi.it/LSR/Item?id=715) for almost every single occurence of \laissezVibrer. Would it be possible to have a property minimum-length, maybe with a default value that makes

Re: Stem lenght and ledger lines

Am 16.04.2018 um 09:14 schrieb foxfanfare: What exactly is Malte's new-flags? I added 256th, 512th, and 1024th rest and flag glyphs to Emmentaler so that you can use these rests and the notes without beams, see issue 5277: https://sourceforge.net/p/testlilyissues/issues/5277/

Re: Note pitches missing in some languages

Am 03.05.2018 um 09:54 schrieb Menu Jacques: Hello, It seems there are no names in Svenska and some other languages for sequiflat and sesquisharp pitches. Will that be added when triple accidentals are introduced? Thanks for your help! JM I don’t think that Torsten is planning to do so b

Re: SmallCaps Gap

Am 07.05.2018 um 15:05 schrieb Torsten Hämmerle: Meanwhile, it's possible to use OTF font features. \override #'(font-features . ("smcp")) Feature request: The markup command \fontCaps should use this feature if no extra font for small caps is available. __

Re: ending bar line too short

Am 13.05.2018 um 17:24 schrieb Étienne PERRINE: In this code, the ending bar line of second staff is very slightly too short (probably due to the magnyfyStaff)… Why ? It’s not the bar line that is too short but the staff lines. And that’s because of wrong alignment of the different bar lines

Re: Accidental Placement and Tie

Am 14.05.2018 um 14:38 schrieb foxfanfare: Simon Albrecht-2 wrote Yes, it does. Looks like ;. Thanks Simon, I should have checked on this page first! Btw, in the issue thread, it is mentioned: "A work-around is to temporarily shift to acc

Re: ending bar line too short

Am 14.05.2018 um 09:09 schrieb Malte Meyn: • The staff line length is correctly chosen for the first staff (not the smallest or largest). Not only the staff line but also the horizontal spacing of SystemStartBar, Clef, and TimeSignature. ___ bug

\RemoveAllEmptyStaves and StaffGroup: StaffSymbol too short

Hi list, the StaffSymbol is too short: % \version "2.19.81" \layout { \context { \Staff \RemoveAllEmptyStaves } } << \new StaffGroup << \new Staff s1 \new Staff s1 >> \new Staff { c'1 \bar "|." } >> % This

\germanChords raises accidentals too high

Hi list, is there a reason why \germanChords raises accidentals higher than in other cases? In the past few years I’ve read now several users complaining about that. Shouldn’t we remove line 92 (and a closing parenthesis) from scm/chord-name.scm? Cheers, Malte

ChordName accidentals don’t scale properly

Hi list, The function alteration->text-accidental-markup (l. 33ff. in scm/chord-name.scm) seems to ignore current font size while raising the accidental: %% \version "2.19.82" \markup \concat { E #(alteration->text-accidental-markup FLAT) } \markup \concat { E #(alter

Re: NR, what type of context is Dynamics

Am 09.07.2018 um 12:40 schrieb Urs Liska: Hi all, NR 5.1.1 Contexts Explained seems to include a list of all contexts from all levels (Score, Staff Containres, Staff, Bottom). But Dynamics isn't even mentioned on that page. Am I completely missing something or is that context missing on th

Re: NR, what type of context is Dynamics

Am 09.07.2018 um 12:49 schrieb Malte Meyn: Am 09.07.2018 um 12:40 schrieb Urs Liska: NR 5.1.1 Contexts Explained seems to include a list of all contexts from all levels (Score, Staff Containres, Staff, Bottom). But Dynamics isn't even mentioned on that page. Am I completely missing some

Collision: Slur/Script/TupletBracket

Hi list, the slur seems to cause a collision of fermata and tuplet bracket although it’s not above the staff. %% \version "2.19.82" % same for 2.12.3 to 2.18.2 \tuplet 3/2 { d'4(\fermata f' d') } %% Cou

Collision: fermata/tuplet bracket/slur

Hi list, the slur seems to cause a collision of fermata and tuplet bracket although it’s not above the staff. %% \version "2.19.82" % same for 2.12.3 to 2.18.2 \tuplet 3/2 { d'4(\fermata f' d') } %% Cou

enable OpenType features globally

Hi list, I could find neither a post on this list (or on devel) nor an issue on the tracker but I cannot imagine this has never been asked for anywhere, did I miss something? Currently, it’s only possible to \override the font-features list for every single grob (okay, you can use something

Re: TimeSignature and magnifyStaff

Am 14.07.2018 um 23:40 schrieb foxfanfare: I found a strange bug when using the magnifyStaff tool. In this example, you can see a collusion between the clef and the time signature occurs when the lowest staff is smaller (and not otherwise). Sounds like a bug to me, what do you think? Is there a

Feature request: let \layout accept several \layouts stored in variables

Hi list, it’s possible to write something like % ambitus = \layout { \context { \Voice \consists Ambitus_engraver } } \score { \relative { c' d e f g a b c } \ambitus } % or put the \layout variable in a \layout block: %%

Re: TimeSignature and magnifyStaff

Am 16.07.2018 um 07:52 schrieb James Lowe: So is this a bug or is it really an enhancement request/feature (i.e. is the code expected to do this or is it just a poorly chosen name for a function)? IMO it’s really a bug for the following reasons: 1. The behaviour of \magnifyStaff is inconsiste

Re: TimeSignature and magnifyStaff

Am 16.07.2018 um 13:06 schrieb Malte Meyn: Of course, maybe I’m wrong and \magnifyStaff wasn’t intended for these use cases (f. e. piano parts in chamber music) but that’s the main purpose I would use it for if I could. I just realized that this use was not intended: The scaling of bar

Re: TimeSignature and magnifyStaff

Am 16.07.2018 um 19:10 schrieb foxfanfare: I also think this tool has been written for chamber music with piano. That's why the smaller staves should be above. But it could be different, for instance, I have to write a piano piece with a "tracker" part (it is an electronic tape). In this case,

\override ClefModifier.text has no effect

Hi list, I’m not sure: Is this a bug? According to the Internals Reference, ClefModifier has ly:text-interface::print as a stencil and should use the 'text property. But the following doesn’t show “8va” as expected but “8”: \version "2.21.0" % same for 2.19.82, 2.18.2 { % make sure the cor

whiteout shouldn’t affect other grobs on same layer

Hi list, in the following example the NoteHead.whiteout doesn’t only cover the tie but also one NoteHead whites out the other: %%% \version "2.19.82" \relative << { \override NoteHead.whiteout = 3 \override NoteHead.layer = -1 r2 } \\ {

Re: Possible bug(s) with vertical alignment on Dynamics staff

Hi Peter, have you read my latest answer on the user list? (https://lists.gnu.org/archive/html/lilypond-user/2018-08/msg00412.html) Am 31.08.18 um 13:36 schrieb Peter Toye: 1. Just inserting the text by attaching it to a silent note using "^" or "_" works as expected. See examples 1 & 2 I

Re: Accidentals and Ledger Lines

[Forwarding to bug-lilypond] Hi foxfanfare, Am 05.09.18 um 11:07 schrieb foxfanfare: As you can see, the ledger line of the note containing the accidental is shortned as expected, but the other aren't and you can see here the natural appears too close. that’s true, neighbouring ledger lines s

Re: Accidentals and Ledger Lines

Am 06.09.18 um 10:04 schrieb Noeck: Thanks for the examples. There is at least one special case missing from the examples: chords on ledger lines. In chords, the ledger lines closer to the staff are not shortened. Two assumptions: either they are over-printed by the ledger lines of the lower (

Re: Subdivised beams bug

Am 06.09.18 um 20:57 schrieb foxfanfare: When the beat ends with a rest, the subdivised beam doesn't work correctly. The result (using LilyPond 2.19.82) is exactly what I would’ve expected. I suppose your expectation is different so what did you expect?

Re: Subdivised beams bug

Am 06.09.18 um 21:39 schrieb foxfanfare: Malte Meyn-3 wrote The result (using LilyPond 2.19.82) is exactly what I would’ve expected. I suppose your expectation is different so what did you expect? The automatic subdivised beam is 16th instead of 8th. Ok, now after a closer look I see that

Ambitus: horizontal spacing

Hi list, I think that the horizontal spacing of Ambitus isn’t optimal: IMO it has too much space on the left side (or too little on the right side). I’d suggest to change the left-hand space from 2.0 to 0.8 or maybe 1.0: %% \version "2.19.82" \new ChoirStaff << \n

Re: Superfluous clef

Am 20.10.18 um 17:54 schrieb Thomas Morley: Hi, with the code below a superfluous clef is printed. \version "2.19.82" \new Staff << \new Voice { s1 s } \new Voice { s \clef treble s } You don’t even need two voices for that: \version "2.19.82" { s1 \clef treble s } % try also s4

ChordNames change measure widths

Hi list, the following code produces measures of different length: The measures containing a ChordName are narrower than the others. That’s a bug, isn’t it? % \version "2.19.82" << \chords { s1*4 % try also s1*3 and see the line break

  1   2   >