Collision: tie and nothead in different voices

[Malte Meyn]

Hi list,

this collision is present in all stable versions from 2.18.2 to 2.24.0:


\version "2.24.0"

\relative {
  g'2
  << {   } \\ { c~ c4 b4 } >>
}

\relative << { a'2~ a8 } \\ { c2~ c8 } >>


Is there any workaround apart from \shape? And is this a 
known/documented bug?


Cheers,
Malte

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

set-paper-size does not work correctly in \bookpart

[Malte Meyn]

Hi list,

set-paper-size does not work correctly when used in a bookpart:

%%%m

\version "2.22.1"

\bookpart {
  \paper {
annotate-spacing = ##t
#(set-paper-size "a5landscape")
  }
  { R1 }
}

%%%m

The code above gives
• A4 portrait paper
• A4 landscape printable area (This effect can be seen better with 
"a4landscape".)

• A5 landscape margins

Manually setting paper-height and paper-width doesn’t work either.

Cheers,
Malte

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

info-lilypond mailing list

[Malte Meyn]

Hi list,

someone asked me whether LilyPond could have a feature that announces 
new released versions. I don’t think that this is desirable but what 
about the info-lilypond mailing list promoted at 
https://lilypond.org/contact.html ? According to the archives, 2.19.13 
has been the last version announced at the list, so it should be 
reactivated or the website should be updated.


Cheers,
Malte

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

Re: Ottavation markups

[Malte Meyn]

Am 02.03.20 um 21:27 schrieb Jean Abou Samra:
\version "2.21.0" % compiled with HEAD being 
ede0457988716a5e6fa0dd1757db0ebd96107bbc


\score {
{ \ottava 1 c'1 }
\midi { }
}

will trigger the warning
Could not find ottavation markup for 1 octaves up.

CCing Malte Meyne since he's the author of the patch that introduced the 
warning -- see
http://lilypond.1069038.n5.nabble.com/Add-user-definable-ottavation-markups-issue-568970043-by-lilypond-maltemeyn-de-tc223988.html 



The MIDI output is fine though.


Thanks for the report. I’ll try to find some time to have a look at this 
(and issue 5611 which should be for now my last ottavation improvement 
but has waited for completion for some weeks or months now).


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

accidentals after mid-measure break

[Malte Meyn]

Hi list,

I think that accidentals should be repeated after a break in every case. 
LilyPond does this with tied notes over a bar line but not with tied or 
even separate notes within a measure:


\version "2.21.0"
\relative {
  \partial 2 c'2 d e fis \bar "" \break
  fis g1 fis2~ \bar "" \break
  fis g1 fis~ \break
  fis2 g g, \bar "|."
}

Do you agree that this is a bug?

Cheers,
Malte

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

Re: Strange "programming error: Loose column ..."

[Malte Meyn]

Am 27.12.19 um 00:33 schrieb Thomas Morley:

Hi,

the following code returns
programming error: Loose column does not have right side to attach to.
for all versions from 2.14.2 up to 2.21.0
No error for 2.12.3

{
   \set Score.defaultBarType = #""
   r2
   b1\glissando
   c'
}


You don’t need the glissando to get that error:

\version "2.21.0"
{
  \set Score.defaultBarType = ""
  2
  1
}

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

LSR Snippet 318

[Malte Meyn]

Hi list,

I’m not sure where to post an LSR bug report but maybe the people 
responsible for the LSR read this list?


Snippet 318 (http://lsr.di.unimi.it/LSR/Item?id=318) states that 
\parenthesize for notes works only inside chords. That’s not correct, 
the following works as expected in 2.12.3 and newer versions (I haven’t 
tested older ones):


{
  a
  \parenthesize b
  \parenthesize 
  <\parenthesize d'>
}

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

Re: \tripletFeel and \partial

[Malte Meyn]

Am 28.09.19 um 16:57 schrieb Malte Meyn:

Hi list,

\tripletFeel doesn’t automatically work with \partial. IIUC, 
\tripletFeet x is just a shortcut for \applySwing x #'(2 1) and one can 
use \applySwingWithOffset for music with upbeat. I tried that but cannot 
get it to work properly. In the following code, left and right hand are 
offset against each other. What am I (or LilyPond) doing wrong?


I’m writing this to the bug list because it’s a 2.21 feature and at 
least from the existing documentation I’m not able to produce correct 
output which is a program or documentation bug ;)


It’s not a \partial or \applySwingWithOffset problem but a problem with 
how \applySwing works: It seems to take the notes in input order instead 
of sounding order/time. This means that you can have problems with 
unfold repeats and simultaneous music:


\version "2.21.0"
\include "swing.ly"

% bad: all c are long, all d short
\tripletFeel 8 {
  \repeat unfold 8 c'8
  \repeat unfold 8 d'8
}

% good (even number of notes)
\tripletFeel 8 {
  \repeat unfold 8 { c'8 d' }
}

% bad (odd number of notes):
% all c and e are long, all d short
\tripletFeel 8 {
  \repeat unfold 8 { c'8 d' e' }
}

% good (even number of notes in the first staff)
\tripletFeel 8 <<
  \new Staff { c'8 8 8 8 8 8 8 8 }
  \new Staff { d'8 8 8 8 8 8 8 8 }
>>

% bad (odd number of notes in the first staff):
% the swing is shifted in the second staff
\tripletFeel 8 <<
  \new Staff { c'8 8 8 8 8 8 8 8 8 }
  \new Staff { d'8 8 8 8 8 8 8 8 8 }
>>

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

slurring grace to chord: collision

[Malte Meyn]

Hi list,

slurring a grace note to a specific note in a chord gives ugly results. 
The output of the following code is different in 2.19.82 and 
2.19.83/2.21.0 (see attachments) but there are collisions in both cases.


%%
\version "2.19.82"

\relative {
  \override Slur.color = #red
  \override Slur.layer = 2
  \grace c''8( 2
}
%%

Any idea what changed between 2.19.82 and .83?

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

Changes for 2.19/2.20 should mention \afterGrace’s optional argument

[Malte Meyn]

Hi list,

somewhere between 2.19.40 and 2.19.60 the \afterGrace command got an 
optional argument that should be documented in the Changes document at 
http://lilypond.org/doc/v2.19/Documentation/changes/


Cheers,
Malte

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

Re: Clef change and measure length

[Malte Meyn]

Am 27.10.19 um 17:30 schrieb foxfanfare:

Thanks for your replies. Where did you find this reference in Gould's book?
I was looking for that before writing my initial post but without success.
On the contrary, I found this example which suggests otherwise (see the
second one):
mmr.jpg   


That example is the same in the german translation. But at p. 172 
(“Horizontale Ausrichtung von Pausen → Ganztaktige Pausen”, i. e. 
“Horizontal positioning of rests → full measure rests”) she writes 
something like “If the rest measure contains a clef, key signature or 
time signature, one has to center the rest in the remaining space”, see 
attachment.


So Gould is inconsistent here ;)


I also rember writing orchestral music and I found always strange when
several MMR where not centered in their measure because only one instrument
had a clef change... Or maybe I don't get your point.


Yes, that’s what I find strange too.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Malte Meyn]

Am 26.10.19 um 10:40 schrieb foxfanfare:

Hi all,

I think this is a bug: when a clef change appears after a full measure rest,
the rest is no longer centered properly in the measure. The result looks
weird. See that example:

\version "2.19.82"

\new Staff
\relative c' {
   c1
   R-"default"
   \bar "||"
   R_"not centered"
   \clef bass
   \once \override MultiMeasureRest.X-offset = #1
   R-"tweaked"
   \clef treble
   c
}

What do you think?


I think that it depends on context: In a full score where only one 
instrument has a clef change, it would look weird if all the other 
instruments have the rest not centered. But in solo music, I’m not so 
sure which one I would prefer.


According to Gould LilyPond’s behaviour is correct, but she doesn’t say 
anything about full scores …


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

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

[Malte Meyn]

Am 20.10.19 um 04:07 schrieb Christopher Heckman:

On Sat, Oct 19, 2019 at 9:00 AM  wrote:


Date: Sat, 19 Oct 2019 10:06:10 +0200
From: Malte Meyn 
To: bug-lilypond 
Subject: polyphony and TabStaff: don’t put two voices on the same
 string
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi list,

this was reported at the LilyPond facebook group. When having “real”
polyphony with multiple Voice contexts, the notes are put on the strings
independently which can lead to several voices with different frets on
the same string.

The first three “chords” on the TabStaff should look the same (1st
string 3rd fret, 2nd string 5th fret). I’m not sure about the correct
handling of unisons (second three “chords”) in polyphony because I don’t
play guitar ;)

%%%
\version "2.21.0"

music = \relative {
2
<< g e >>
<< \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) g \\ e >>

<< e e >>
<< \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) e \\ e >>
}

<<
\new Staff { \clef "treble_8" \music }
\new TabStaff \music
  >>
%%%

I tweaked the extra-offsets so that you can see that LilyPond just
prints two TabNoteHeads in the exact same space.

Cheers,
Malte


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

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


Do you still have the code? I could bring it to the review process (or 
help you doing it yourself)


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

Re: Regression bug: Assertion error in 2.19.83

[Malte Meyn]

This doesn’t crash in current master.

Am 19.10.19 um 21:11 schrieb Mats Bengtsson:

Sorry, here comes the buggy example:

\version "2.19.83"

\relative c'{
\time 2/4
% This first line gives the error:
d16 d64-. ( d-. d-. d-. ) e16 e16:64 fis16 fis16:64 g16 g16:64 |
% Explicitly shortening the beam helps:
d16 [ d64-. ( d-. d-. d-. )] e16 e16:64 fis16 fis16:64 g16 g16:64 |
% Very similar pattern that doesn't trigger the bug:
d16 d16:64 e16 e16:64 fis16 fis16:64 g16 g16:64 |
}

   /Mats

On 2019-10-19 21:10, Mats Bengtsson wrote:

Hi,

The following example illustrates a bug in 2.19.83 that's a regression 
against 2.18. Compiling with 2.19.83 gives


GNU LilyPond 2.19.83
Processing `bug.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/flower/include/interval.hh:227: 
T Interval_t::center() const [with T = double]: Assertion 
`!is_empty ()' failed.

Abort (core dumped)

Uncommenting the first bar gives a file that can be processed and the 
second bar shows a workaround that works for the piece I'm 
typesetting. The example compiles without problems in 2.18.2, I don't 
have access to 2.21, so I don't know if the bug remains there.


    /Mats



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


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

Re: Rests with stem tremolo cause LilyPond to fail silently

[Malte Meyn]

Am 13.10.19 um 20:30 schrieb Trevor Bača:

Hi,

While "c4:32" correctly expresses a quarter note stem tremolo slashes,
typing (badly-formed) "r4:32" probably only happens when a user is editing
a source file and changes a note to a rest without regard for the stem
tremolo suffix.

However, rather than raising some type of error or warning, Lily fails
silently on this type of badly-formed construction.

[…]

Rather than failing silently, Lily should raise an error or warning:
imagine a large input file failing for no apparent reason and then having
to bisect the entire thing find a single instance of something like
"r4:32".

Thanks,

Trevor.



This is now issue 5579: 
https://sourceforge.net/p/testlilyissues/issues/5579/


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

polyphony and TabStaff: don’t put two voices on the same string

[Malte Meyn]

Hi list,

this was reported at the LilyPond facebook group. When having “real” 
polyphony with multiple Voice contexts, the notes are put on the strings 
independently which can lead to several voices with different frets on 
the same string.


The first three “chords” on the TabStaff should look the same (1st 
string 3rd fret, 2nd string 5th fret). I’m not sure about the correct 
handling of unisons (second three “chords”) in polyphony because I don’t 
play guitar ;)


%%%
\version "2.21.0"

music = \relative {
  2
  << g e >>
  << \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) g \\ e >>
  
  << e e >>
  << \tweak TabNoteHead.extra-offset #'(0.3 . 0.3) e \\ e >>
}

<<
  \new Staff { \clef "treble_8" \music }
  \new TabStaff \music
>>
%%%

I tweaked the extra-offsets so that you can see that LilyPond just 
prints two TabNoteHeads in the exact same space.


Cheers,
Malte

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

Re: set-global-staff-size rejects set-global-fonts settings

[Malte Meyn]

Hi,

please always answer to the list.

Am 18.10.19 um 12:03 schrieb CieMaKat .:
Thanks for your answer -- that's it. I couldn't find such restriction in 
the documentation.


I'm facing another problem, which is related to the previous one. Looks 
like notation font is not scalled correctly.


You have to set #:factor. That’s another thing that might need better 
documentation?


#(define fonts
  (set-global-fonts
#:music "gonville"
#:brace "gonville"
#:factor (/ staff-height 20 pt)))

But maybe we should make a feature request for both “problems”:

1. Setting the staffsize shouldn’t reset the fonts.
2. Manually setting #:factor shouldn’t be necessary because it’s always 
(/ staff-height 20 pt), isn’t it?


Cheers,
Malte

Minimal example the same as before with \paper section moved to the very 
bottom and staff size changed to 10:


\version "2.19.83"


#(set-global-staff-size 10)

\score {

   \relative c' { c d es fis }

}

\paper {

   #(define fonts

     (set-global-fonts

      #:music "gonville"

      #:brace "gonville"

    ))

} 



Here's a result of Gonville:
image.png

The problem does not occur with default typeface (whole \paper block 
commented out):

image.png

pt., 18 paź 2019 o 11:25 Malte Meyn <mailto:lilyp...@maltemeyn.de>> napisał(a):




Am 18.10.19 um 10:54 schrieb CieMaKat .:
 > Hi there.
 > I found that use of set-global-staff-size or
layout-set-staff-size makes
 > set-global-fonts irrelevant.

The order is important: The font settings have to come *after* the
staff
size.

I’m not sure whether this really is a bug or just not well documented …

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



--
/M.Ciesiółka/


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

Re: set-global-staff-size rejects set-global-fonts settings

[Malte Meyn]

Am 18.10.19 um 10:54 schrieb CieMaKat .:

Hi there.
I found that use of set-global-staff-size or layout-set-staff-size makes
set-global-fonts irrelevant.


The order is important: The font settings have to come *after* the staff 
size.


I’m not sure whether this really is a bug or just not well documented …

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

\tripletFeel and \partial

[Malte Meyn]

Hi list,

\tripletFeel doesn’t automatically work with \partial. IIUC, 
\tripletFeet x is just a shortcut for \applySwing x #'(2 1) and one can 
use \applySwingWithOffset for music with upbeat. I tried that but cannot 
get it to work properly. In the following code, left and right hand are 
offset against each other. What am I (or LilyPond) doing wrong?


I’m writing this to the bug list because it’s a 2.21 feature and at 
least from the existing documentation I’m not able to produce correct 
output which is a program or documentation bug ;)


Cheers,
Malte

%%

\version "2.21.0"
\language "deutsch"
\include "swing.ly"

perdido = \new PianoStaff <<
  \new Staff \relative {
\key b \major
\partial 8
c'8 es f~ 2 r8 c es f4 c8 es f4 b,8 d f~ 2 r8
b, d f4 b,8 d f4 c8 es f~ 2 r8 c es f d' c~ 4. f,8 g b~ 2.~ 2 r4 r8
\bar "|."
  }
  \new Staff \relative {
\clef bass
\key b \major
r8 c4 c c c f, f f f b b b b d d g, g c c c c f, f f f b b b b b2 r4 r8
  }
>>

\book {
  \bookOutputSuffix "perdido"
  \header { title = "Perdido" }
  \score { \perdido }
  \score { \applySwingWithOffset 8 #'(2 1) #(ly:make-moment 1/8) 
\perdido \midi { } }

}

%%

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

Stockhausen example on the website is missing

[Malte Meyn]

Hi list,

the example on http://lilypond.org/examples.html#Customized-Output is 
missing: http://lilypond.org/ly-examples/stockhausen-klavierstueckII.png 
is not found.


Cheers,
Malte

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

Re: Override Staff.StaffSymbol.color has no effect when first note is grace note

[Malte Meyn]

Am 11.09.19 um 18:18 schrieb Florian Grundig:

Hi all,

it seems there's an issue when using an
override of Staff.StaffSymbol.color in combination with a grace note as
first note in score -> in this case the override seems to be ignored...
when using no grace at all or at a different position the override
works as expected:


Hi Florian,

this is issue 34 (https://sourceforge.net/p/testlilyissues/issues/34/), 
one of the oldest and best-known bugs. You could place the override in a 
with block, then it will happen before any music, even grace music:


\new Staff \with {
  \override StaffSymbol.color = #red
}

HTH,
Malte

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

AccidentalSuggestion only for cautionary accidentals?

[Malte Meyn]

Hi list,

currently setting suggestAccidentals to ##t lets the Accidental_engraver 
make AccidentalSuggestion grobs instead of both Accidental and 
AccidentalCautionary grobs. Shouldn’t this replacement be done only for 
cautionary accidentals? When transcribing mensural music, one needs both 
Accidental grobs (for accidentals present in the facsimile) and 
AccidentalSuggestion grobs (for implicit musical ficta accidentals). Any 
opinions on that?


Cheers,
Malte

%%

\version "2.19.83"

\markup { without suggestAccidentals: }
\relative {
  \time 2/1
  \set Staff.timeSignatureFraction = 2/2
  c''1 d
  bes1 a2 g
  a d1 cis?2
  d\breve
}

\markup { current output: }
\relative {
  \set suggestAccidentals = ##t
  \time 2/1
  \set Staff.timeSignatureFraction = 2/2
  c''1 d
  bes1 a2 g
  a d1 cis?2
  d\breve
}

\markup { suggested output: }
\relative {
  \time 2/1
  \set Staff.timeSignatureFraction = 2/2
  c''1 d
  bes1 a2 g
  a d1 \once \set suggestAccidentals = ##t cis?2
  d\breve
}

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

break-visibility of KeySignature and KeyCancellation inconsistent

[Malte Meyn]

Hi list,

I wonder why there is two different ways to change the break-visibility 
of KeySignature and KeyCancellation grobs:


%%%
\version "2.21.0"

{
  \set Staff.explicitKeySignatureVisibility = #end-of-line-invisible
  \override Staff.KeyCancellation.break-visibility = #end-of-line-invisible
  \key g \major
  R1
  \break \key f \major
  R
}
%%%

\overriding KeySignature.break-visibility has no effect and there is no 
context property explicitKeyCancellationVisibility, however there is 
printKeyCancellation which is a boolean, not a boolean vector. That’s 
inconsistent and I cannot imagine why this would be necessary. I 
searched the tracker and the mailing list archives but I couldn’t find 
any hints … Should we consider this a bug?


Cheers,
Malte

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

Re: Error on Linux

[Malte Meyn]

Am 14.08.19 um 15:16 schrieb Anzick:

Hello, with even the most simple score I am getting this error:


warning: compressing over-full page by 77044.3 staff-spaces


warning: page 1 has been compressed


The same file apears to work fine on Mac, but not on Linux.


Hi Anzick,

I cannot reproduce that behaviour using LilyPond 2.19.82 for 64-bit 
Linux (Manjaro). Apart from that it’s not the “most simple score”, could 
you please try to make a minimal example?


Cheers,
Malte

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

Re: Bug Report: fingering collide with phrasing slure

[Malte Meyn]

Am 13.08.19 um 21:45 schrieb Ruth Mersmann:


\version "2.18.2"

   \relative c'' {
   \time 9/8


d8\(( e-4 d) e-0( f e) g( a g)\)

}


Seems like Fingering cannot avoid both Slur and PhrasingSlur at the same 
time …


\version "2.21.0"

\relative d'' {
  d8\(  e-4  d  e\) % OK
  d8(   e-4  d  e)  % OK
  d8\(( e-4) d  e\) % FAIL
  d8\(  e-4( d) e\) % FAIL
}

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

Re: Bug with Ambitus and ottava ???

[Malte Meyn]

Am 10.07.19 um 10:09 schrieb lilyp...@maltemeyn.de:

Am 2019-07-10 10:02, schrieb Simon Albrecht:

On 09.07.19 22:14, Malte Meyn wrote:


The bug is that when the Staff starts with an \ottava setting this 
affects the AmbitusNoteHeads. A later setting of \ottava doesn’t 
change that behaviour:


It seems as if it’s another case similar to 
https://sourceforge.net/p/testlilyissues/issues/2575/



But it’s a different issue, right? #2575 is fixed, and this one
doesn’t have anything to do with staff line layout or middleCPosition.

Best, Simon


Yes, it's a different issue. It looks similar and the reasons might be 
similar (IIRC \ottava doesn't change middleCPosition but middleCOffset 
or something related). I'll have a closer look in a few days.


https://sourceforge.net/p/testlilyissues/issues/5532/

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

Re: Bug with Ambitus and ottava ???

[Malte Meyn]

Am 09.07.19 um 22:08 schrieb Malte Meyn:



Am 09.07.19 um 20:35 schrieb James:
I am not sure what the exact bug is here (if only to give a more 
comprehensive report in a tracker).


Can you expand?


The bug is that when the Staff starts with an \ottava setting this 
affects the AmbitusNoteHeads. A later setting of \ottava doesn’t change 
that behaviour:


It seems as if it’s another case similar to 
https://sourceforge.net/p/testlilyissues/issues/2575/


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

Re: Bug with Ambitus and ottava ???

[Malte Meyn]

Am 09.07.19 um 20:35 schrieb James:
I am not sure what the exact bug is here (if only to give a more 
comprehensive report in a tracker).


Can you expand?


The bug is that when the Staff starts with an \ottava setting this 
affects the AmbitusNoteHeads. A later setting of \ottava doesn’t change 
that behaviour:


%
\version "2.21.0" % current master

\new Staff \with {
  \consists Ambitus_engraver
} {
  \ottava 1
  c''2 e''
  \ottava 0
  a' f'
}
%

The \grace s16 *before the \ottava 1* is just a workaround.

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

\caps and \fontCaps don’t work as expected

[Malte Meyn]

Hi list,

\caps doesn’t work if unless it’s the very last markup command before 
the actual text.


\fontCaps seems to have no effect at all. Shouldn’t it enable the smcp 
feature?


Cheers,
Malte


\version "2.21.0"

\markup \bold \caps "AaBbCc" % ok
\markup \caps \bold "AaBbCc" % FAIL

\markup \caps { "Aa" "Bb" "Cc" } % ok
\markup \caps \line { "Aa" "Bb" "Cc" } % FAIL

\markup \bold \override #'(font-features . ("smcp")) "AaBbCc" % ok
\markup \override #'(font-features . ("smcp")) \bold "AaBbCc" % ok

\markup \fontCaps "AaBbCc"   % FAIL


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

ChordNames depend on input language

[Malte Meyn]

Hi list,

I just stumbled upon a change in ChordNames: Their language depends on 
the input language in 2.21.0. Until 2.19.83, all of


\language "français"   \chords { sib }
\language "deutsch"\chords { b }
\language "nederlands" \chords { bes }

give the same output “B♭”. In 2.21.0, it’s “Si♭”, “H♭” and “B♭”. Not 
only that “H♭” is wrong (it should be B), I always thought that input 
and output were independent in LilyPond. I use \language "deutsch" for 
all my projects but I would like to have English chord names nevertheless.


How would I achieve that in 2.21.0? And am I the only one who thinks 
that the input language and output language should be independently 
settable? That could be done f. e. by a context property 
ChordNames.chordLanguage that defaults to "english" and can be set to 
any language that is accepted by the \language command.


Cheers,
Malte

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

Re: rest + fermata

[Malte Meyn]

Am 14.04.19 um 13:38 schrieb Martin Tarenskeen:


Hi,

This is strange:

%%% start of tiny example

\version "2.19.83"
{
   r1\fermata
   R1\fermata
}

%%% end of tiny example

r1\fermata works fine, R1\fermata doesn't. No fermata sign is printed.
Is this a bug?

That’s the third time in a few weeks that someone asks why that doesn’t 
work at a list/forum/… that I read.


Looks like I should continue my work on issue 5486 
(https://sourceforge.net/p/testlilyissues/issues/5486/) and maybe find a 
way that \fermataMarkup isn’t needed anymore and R1\fermata works instead …


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

Windows, Lilypad, and UTF8

[Malte Meyn]

Hi list,

is it correct that Lilypad doesn’t do UTF8 correctly? A user on the 
german forum said that one has to input ä for ä, ö for ö etc., see 
https://lilypondforum.de/index.php?topic=448


Cheers,
Malte

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

Re: ChordNames change measure widths

[Malte Meyn]

Am 12.11.18 um 18:07 schrieb Torsten Hämmerle:

Hi Malte,

That's strange, but it seems to be related to the *3 (length factor) used in
g1*3.
Restricting the use of these multipliers to full measure rests (i.e. writing
g1 s1*2) I couldn't reproduce the effect.
Can you confirm this?


I can confirm for that particular code example. But I found another 
(slightly bigger) example that doesn’t need such scaled durations:


%
\version "2.19.82"

<<
  \chords {
s1 s s s s s g
  }
  \relative {
\repeat unfold 32 b16
b4 b b b
\repeat unfold 16 b16
R1 R R R R
  }
>>
%

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

Re: ChordNames change measure widths

[Malte Meyn]

Am 12.11.18 um 17:05 schrieb Malte Meyn:

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"


Same for 2.12.3 to 2.18.2 and the last version that I compiled from master.

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

ChordNames change measure widths

[Malte Meyn]

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 move
g1*3
d1
  }
  \new Staff {
\repeat unfold 16 d''16
R1*8
  }
>>
%

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

Re: Superfluous clef

[Malte Meyn]

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 instead of s1

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

Ambitus: horizontal spacing

[Malte Meyn]

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 <<
\new Staff { c' c'' }
\new Staff { c' c'' }
>>

\layout {
  \context {
\Staff
\consists Ambitus_engraver
  }
  \context {
\Score
\override LeftEdge.space-alist = #'((ambitus extra-space . 0.8))
  }
}
%%

Opinions? Gould remains silent about that.

Cheers,
Malte

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

Re: Subdivised beams bug

[Malte Meyn]

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 the problem is not *where* the 
beams are subdivided but *how*. That’s a bug, yes, see Urs’s reply.


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

Re: Subdivised beams bug

[Malte Meyn]

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?


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

Re: Accidentals and Ledger Lines

[Malte Meyn]

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 (more distant) note or their shortening is overwritten by the
other note's settings. In any case they are not shortened.

{
   4^"upper ledger line not shortended"
   cisis'!4_"shortened"
}

Cheers,
Joram


That’s even worse than I thought. I wish I had time to tackle that 
issue. Not before mid of october …


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

Re: Accidentals and Ledger Lines

[Malte Meyn]

[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 should be shortened in some 
cases. LilyPond’s documentation advertises the ledger line shortening 
(http://lilypond.org/doc/v2.18/Documentation/essay/engraving-details#ledger-lines), 
IMHO that’s a good reason why it should really work ;)



I can fix this by moving the accidental with \once \override
Accidental.X-offset = #-1.25, see:

accidentals2.JPG


But this tweak has to be done every time... My question is: is it possible
to add more padding between ledger lines and accidentals? I tried many
combinations but nothing worked so far...


Of course you could use \override instead of \once \override but of 
course that’s not optimal, therefore I’m forwarding this to the bug 
list. The following code shows in which cases also a neighbouring ledger 
line should be shortened and where there are ledger lines that are 
shortened but shouldn’t be.


%
\version "2.19.82"
<<
  \new Staff \relative c''' {
\set Score.extraNatural = ##f
ceses feses % feses: no need for shortening
ceseh feseh % feseh: no need for shortening
ces fes % fes:   no need for shortening
ceh feh % ok
c! f!   % both: more shortening needed
cih fih % ok
cis fis % ok
cisih fisih % ok
cisis fisis % ok
  }
  \new Staff \relative {
aeses eeses % ok
aeseh eeseh % ok
as es   % ok
aeh eeh % both:  more shortening needed
a! e!   % a: more shortening needed
aih eih % aih:   more shortening needed
ais eis % ais:   more shortening needed
aisih eisih % aisih: more shortening needed
aisis eisis % ok
  }
>>
%

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

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

[Malte Meyn]

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 suppose that’s not one of your “possible bugs”, is it? ;)


2. Trying "-" is the same as "_". This isn't documented, and probably shouldn't 
be. But it would be useful to have this syntax for horizontally aligned text. See example 3.


_ and ^ set the direction property of an Event (in this case a 
TextScriptEvent) to #DOWN and #UP. “-” doesn’t set it at all—this means 
that LilyPond decides whether to set it down or up depending on 
different things (type of grob, voice direction in polyphony, …). Your 
suggestion would mean that “-” sets the direction to #CENTER. This isn’t 
supported at the moment, it’ll throw an error (you can try that: 
\override TextScript.direction = #CENTER).


Now what should #CENTER behave like? If there is some space like in your 
example, your suggestion is legitimate IMO. But in most cases one has 
only two options, up and down (f. e. think of articulations). Letting 
“-” set the direction to #CENTER, even if #CENTER would mean “automatic 
default behaviour” would be wrong because direction information coming 
from \voiceX commands would be overridden.



3. Tweaking the Y-offset by 0.0 using "_" appears to change it to having used 
"^" if you see what I mean. Example 4. Tweaking it to -0.6 gives the result I want. 
Example 5.


The Y-offset is calculated (see my answer to 4. below) depending on 
different things including the 'direction property. So if you tweak the 
Y-offset, the direction will be ignored (at least for the positioning 
question).



4. In the Internals manual, the unit for the Y-offset property is not 
mentioned. This wastes a lot of time in experimentation, especially given issue 
3!


What do you mean by unit? Yes, the IR 
(http://lilypond.org/doc/v2.19/Documentation/internals/user-backend-properties) 
doesn’t say whether Y-offset is measured in staff-spaces, half 
staff-spaces or some different unit. But I suppose you mean “value” 
here? That value is calculated by a procedure that uses information 
about the context (type of grob, neighbouring grobs, font sizes, line 
breaks, voice direction, …). That’s why the manual cannot give the 
default value as a number—there is no such thing as a default value.


I hope I made clear what the problems are here. If not, just ask ;) (And 
have a look at the \offset command I mentioned on the user list :))


Cheers,
Malte

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

whiteout shouldn’t affect other grobs on same layer

[Malte Meyn]

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 
  } \\ {
\override Tie.layer = -2
1~ q4
  }
>>
%%%

Of course, it would be possible to use a \tweak here:

r2 <\tweak whiteout 3 \tweak layer -1 f' a>

But that makes the code less readable and if more notes are affected 
it’s a pain.


IMO it would be nice if a grob’s white box on one layer wouldn’t cover 
grobs on the same layer; or at least not grobs of the same type on the 
same layer.


Would it be possible to put the whiteout part half a layer below so that 
\override NoteHead.layer = -1 puts the notehead at layer -1 and the 
surrounding white box at layer -1.5? (Or, if you want only integers: -1 
puts the notehead at layer -2 and the white box at layer -3.)


Cheers,
Malte

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

\override ClefModifier.text has no effect

[Malte Meyn]

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 correct grob is targeted
  \override Staff.ClefModifier.color = #red
  % nothing happens:
  \override Staff.ClefModifier.text = "8va"
  \clef "treble^8"
  R1
}

I suppose that there’s a reason for that behaviour (maybe in the 
definition of the \clef command?) but could be considered a bug 
nevertheless. I found the following workaround but it’s not very 
comfortable:


{
  \override Staff.ClefModifier.before-line-breaking =
  #(lambda (grob)
 (ly:grob-set-property! grob 'text "8va"))
  \clef "treble^8"
  R1
}

Cheers,
Malte

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

Re: TimeSignature and magnifyStaff

[Malte Meyn]

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, it's better to have the tracker part bellow
as it is used only as a guide.


As mentioned earlier, IMO the order of staves shouldn’t change the 
behaviour of \magnifyStaff. I have the following setup with alternating 
staff sizes:


Soprano: small
Alto: normal
Tenor: small
Bass: normal

Soprano and Tenor aren’t notated in the original because they follow 
Alto and Bass as “Canon in diatessaron [i. e. [upper] fourth]”.


So different orders of staves of different sizes should be no problem.

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

Re: TimeSignature and magnifyStaff

[Malte Meyn]

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 lines 
is explicitely intended, as one can see by looking at the regtest 
magnifyStaff-bar-lines.ly.


But then I have to ask what this function is used for. If you don’t need 
differently-sized staves, why not just use set-global-staff-size or 
layout-set-staff-size?


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

Re: TimeSignature and magnifyStaff

[Malte Meyn]

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 inconsistent, it depends on the 
order of staves.
2. There are several horizontal spacing issues (position of clef, bar 
lines/span bars, …) that are really ugly, therefore \magnifyStaff is 
practically unusable in these cases.


I cannot imagine that Mark (who wrote that function) intended either of 
these. According to the doc string a change in horizontal spacing *is* 
intended but there haven’t been any regtests that test simultaneous 
staves of different sizes.


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.


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

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

[Malte Meyn]

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:

%
\score {
  \relative { c' d e f g a b c }
  \layout { \ambitus }
}
%

Now it would be nice if \layout could accept several such \layout variables:

%
musicaFicta = \layout {
  \context {
\Voice
suggestAccidentals = ##t
  }
}

\score {
  \relative { c' d e f g a b c }
  \layout {
\ambitus
\musicaFicta
  }
}
%

Currently, that gives an “error: bad expression type” for \musicaFicta. 
If not putting \ambitus and \musicaFicta in another \layout layer, that 
will give two scores, one with Ambitus_engraver and one with 
suggestAccidentals.


Would it be possible to implement this?

Cheers,
Malte

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

Re: TimeSignature and magnifyStaff

[Malte Meyn]

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 way to avoid this?


Yes, that’s a bug. IMHO horizontal spacing in general is crap with 
magnifyStaff and differently sized staves. Look f. e. at the clef 
position in your second example, at the note spacing of the second and 
third example and at the ending bar line in the following cases:


\new StaffGroup <<
  \new Staff \with { \magnifyStaff #(magstep -3) } { R1 \bar "|." }
  \new Staff R1
>>

\new StaffGroup <<
  \new Staff R1
  \new Staff \with { \magnifyStaff #(magstep -3) } { R1 \bar "|." }
>>

I think horizontal spacing should follow either the largest staff or at 
least a normal-size staff. Also, it shouldn’t depend on the order of staves.


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

enable OpenType features globally

[Malte Meyn]

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 like snippet 443 
http://lsr.di.unimi.it/LSR/Item?id=443 for automization) and for every 
single markup. It would be nice if you could set font features when 
selecting the font in the \paper block:


%
\paper {
  #(define fonts
(set-global-fonts
 #:music "cadence"
 #:brace "cadence"
 #:roman "Vollkorn:liga=0"
 #:factor (/ staff-height pt 20)))
}
%

This would set Vollkorn as roman font, disable liga (for example ff 
ligature), and enable dlig (for example st ligature) and slashed zero. 
The suggested syntax using : and & is how it’s done in LibreOffice.


Cheers,
Malte

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

Collision: fermata/tuplet bracket/slur

[Malte Meyn]

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')
}
%%

Couldn’t find it on the tracker.

Cheers,
Malte

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

Collision: Slur/Script/TupletBracket

[Malte Meyn]

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')
}
%%

Couldn’t find it on the tracker.

Cheers,
Malte

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

Re: NR, what type of context is Dynamics

[Malte Meyn]

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 something 
or is that context missing on the page?


There are twelve more contexts missing, for example KievanStaff, 
NullVoice, PetrucciStaff/Voice, see 
http://lilypond.org/doc/v2.19/Documentation/internals/contexts


Oh, and what about Timing? Isn’t that a context too? Why isn’t it listed 
in the Internals Reference?


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

Re: NR, what type of context is Dynamics

[Malte Meyn]

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 the page?


There are twelve more contexts missing, for example KievanStaff, 
NullVoice, PetrucciStaff/Voice, see 
http://lilypond.org/doc/v2.19/Documentation/internals/contexts


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

ChordName accidentals don’t scale properly

[Malte Meyn]

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 #(alteration->text-accidental-markup SHARP) }

\markup \fontsize #-10 \concat { E #(alteration->text-accidental-markup 
FLAT) }
\markup \fontsize #-10 \concat { E #(alteration->text-accidental-markup 
SHARP) }


\markup \fontsize #10 \concat { E #(alteration->text-accidental-markup 
FLAT) }
\markup \fontsize #10 \concat { E #(alteration->text-accidental-markup 
SHARP) }

%%

This leads to ugly ChordNames when font-size is relatively small. I’ve 
no idea how to retrieve the current font-size. Maybe this should be a 
real markup-command?


Cheers,
Malte

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

\germanChords raises accidentals too high

[Malte Meyn]

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

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

\RemoveAllEmptyStaves and StaffGroup: StaffSymbol too short

[Malte Meyn]

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 reminds me of the problem shown here because if you put the single 
Staff above the StaffGroup the output is ok: 
https://lists.gnu.org/archive/html/bug-lilypond/2018-05/msg00059.html 
Are they related?


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

Re: ending bar line too short

[Malte Meyn]

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-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental Placement and Tie

[Malte Meyn]

Am 14.05.2018 um 14:38 schrieb foxfanfare:

Simon Albrecht-2 wrote

Yes, it does. Looks like
https://sourceforge.net/p/testlilyissues/issues/612/;.


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 accidental style 'no-reset."

I can't find any information on that, how does this work?


\accidentalStyle no-reset

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

Re: ending bar line too short

[Malte Meyn]

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:


• Bar lines from different staves are left-aligned.
• The score’s right end aligns with the paper (so no “too big” bar lines 
extend into the right margin, instead “too small” bar lines end earlier 
than they should).
• The staff line length is correctly chosen for the first staff (not the 
smallest or largest).


The second and third point would be ok *iff* bar lines would be 
right-aligned. But then also we would have a problem with SpanBars 
(uncomment the % \new StaffGroup lines).


%%

\version "2.19.81"

\paper {
  ragged-right = ##f
}

\new Staff { s1 \bar "|." }

% \new StaffGroup
<<
  \new Staff { s1 \bar "|." }
  \new Staff \with { \magnifyStaff #4 } { s1 \bar "|." }
>>

% \new StaffGroup
<<
  \new Staff \with { \magnifyStaff #4 } { s1 \bar "|." }
  \new Staff { s1 \bar "|." }
>>

% \new StaffGroup
<<
  \new Staff { s1 \bar "|." }
  \new Staff \with { \magnifyStaff #1/4 } { s1 \bar "|." }
>>

% \new StaffGroup
<<
  \new Staff \with { \magnifyStaff #1/4 } { s1 \bar "|." }
  \new Staff { s1 \bar "|." }
>>

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

Re: SmallCaps Gap

[Malte Meyn]

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.

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

Re: Note pitches missing in some languages

[Malte Meyn]

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 but I’m forwarding this 
to the bug-list as an enhancement request.


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

Re: Stem lenght and ledger lines

[Malte Meyn]

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/


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

Re: Feature request: LaissezVibrerTie.minimum-length

[Malte Meyn]

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 them longer as 
they currently are?


Same for RepeatTie of course.

Cheers,
Malte


Another idea: It would be nice if the user could choose whether the Tie 
should have a length (in staff-spaces) or a duration/moment as length.


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

Feature request: LaissezVibrerTie.minimum-length

[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 them longer as 
they currently are?


Same for RepeatTie of course.

Cheers,
Malte

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

Re: \offset argument order

[Malte Meyn]

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 
\tweak style) it’s clear why things are as they are and that it doesn’t 
make much sense to change it.


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

Re: \offset argument order

[Malte Meyn]

Am 23.03.2018 um 12:47 schrieb David Kastrup:

Malte Meyn <lilyp...@maltemeyn.de> 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.positions #'(2 . 3)
instead of the current
\offset positions #'(2 . 3) Beam


\offset can be applied to music expressions.  And something like

\offset \offset c' positions #'(2 . 3) Y-offset #'3

would be a lot less pleasant to read than

\offset Y-offset #'3 \offset positions #'(2 . 3)  c'

For that reason, \tweak-like expressions generally take the music
expression to be tweaked as their last argument.  That makes nesting
them reasonably clean.



Thanks for explanation! After reading that and trying some more stuff I 
learned that

\offset Beam.positions #'(2 . 3)
works also but it’s a \tweak and
\offset positions #'(2 . 3) Beam
is an \override that can be prefixed with a \once.

So
\offset Beam.positions #'(2 . 3)
and
\single \offset positions #'(2 . 3) Beam
should be the same?

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

\offset argument order

[Malte Meyn]

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) Beam

Cheers,
Malte

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

Doc: 2.19 changes cuts off varC clef

[Malte Meyn]

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/bug-lilypond

Fwd: stanza alignment

[Malte Meyn]

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 <lilyp...@maltemeyn.de>
An: lilypond-user <lilypond-u...@gnu.org>

Hi list,

when I have multiple verses the stanza numbers are aligned. This works 
also I put some verses above the a staff and some below. But it doesn’t 
work anymore if I then add another staff. Any ideas how to solve this 
problem? Is this a bug?


Cheers,
Malte

%

\version "2.19.80"

<<
   % uncommenting the following line will break (?) the stanza alignment
   %\new Staff { b b b b }
   \lyrics {
 \set stanza = "3." a a a a
   }
   \new Staff { b b b b }
   \lyrics {
 \set stanza = "1." aa a a a
   }
   \lyrics {
 \set stanza = "2." a a a a
   }
 >>

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

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

Re: GSoC Adding variants of font glyphs

[Malte Meyn]

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 example could be an ancient notation breve 
notehead coming in two variants one with a small or big ‘hole’ within it.”


is misleading. Or doesn’t this refer to on-line and on-space variants?

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

GSoC Adding variants of font glyphs

[Malte Meyn]

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://sourceforge.net/p/testlilyissues/issues/5074/) could be included 
in that project.


Cheers,
Malte

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

\compressMMRests vs. \compressFullBarRests and \expandFullBarRests

[Malte Meyn]

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 Score.skipBars = ##t MUSIC \unset Score.skipBars
2. \compressMMRests { MUSIC }
3. \compressFullBarRests MUSIC \expandFullBarRests

2 is documented in English NR, 3 in German NR. I wasn’t aware of 2 until 
now and of course I prefer 3 because I’ve known it for long time, but 
also because you can put it in a \layout-\context block ;)


So now my question: Why are there both 2 and 3?

Cheers,
Malte

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

Re: repeatTie and staff-position

[Malte Meyn]

Am 31.12.2017 um 12:57 schrieb Phil Holmes:
"Malte Meyn" <lilyp...@maltemeyn.de> 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 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 lie inside the staff. For example code see 
below (same output in 2.18.2 and earlier stable versions).


But shouldn’t all RepeatTies either have the same length or be longer 
also if only one of RepeatTie and NoteHead are inside the staff (f. e. 
g'' and f' with \stemUp in 5-line treble clef)?



I don't see a problem here.  There's lots of stuff about tie size and 
placing in Gould, but she says (amongst other stuff) "Where there is 
plenty of space  the tie starts and finishes at the centre of the 
notehead." "Where the tie needs to be brought closer to the notehead ... 
the ends of the tie align with the edge of the notehead."


I don’t see the longer ties per se as a problem either but this should 
be consistent and IMHO it is not (have a look at those two notes).


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

repeatTie and staff-position

[Malte Meyn]

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 lie inside the staff. For example code see below (same 
output in 2.18.2 and earlier stable versions).


But shouldn’t all RepeatTies either have the same length or be longer 
also if only one of RepeatTie and NoteHead are inside the staff (f. e. 
g'' and f' with \stemUp in 5-line treble clef)?


%%%
\version "2.19.80"

music = \relative {
  f'''\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
  d\repeatTie
  c\repeatTie
  b\repeatTie
  a\repeatTie
  g\repeatTie
  f\repeatTie
  e\repeatTie
}

{ \stemUp \music }

{ \stemDown \music }

{
\override Staff.StaffSymbol.line-count = 9
\stemUp \music
}

{
\override Staff.StaffSymbol.line-count = 9
\stemDown \music
}

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

Position of dots in mensural ligatures

[Malte Meyn]

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 dotted. If the note in question stands at the beginning or center, 
the dot is printed above it, f. e.: [picture of three ligatures]”


Here is the third example in LilyPond code; as you can see in the second 
attached picture, LilyPond places the dot right instead of above.


%%%
\version "2.19.80"

\new Voice \with {
  \remove Ligature_bracket_engraver
  \consists Mensural_ligature_engraver
} \relative {
  \cadenzaOn
  \[ c''1 b g\breve. b\breve \]
}
%%%

I’m not sure if Apel is 100% correct for all cases; does anyone know 
other sources?


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

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

[Malte Meyn]

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 and you *have to* 
use it.


F. e. if the \override syntax

\override Staff.TimeSignature #'color = #red

is removed some day IMO one would have to add the convert-ly rule that 
turns it to


\override Staff.TimeSignature.color = #red

again because many people still use the old syntax that they find in old 
code.


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

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

[Malte Meyn]

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 rule.

However,

commit d00ca5c25ad78a6de4ed5098673bb151707f28c1

[…]

removed set-octavation in version 2.13.29 .  So set-octavation seems
more like a backward compatibility remnant than anything else in 2.12.0.

I don't see that we can do this significantly better than it is
currently done.


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 and you *have to* 
use it.


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

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

[Malte Meyn]

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 <lilyp...@maltemeyn.de> ha 
scritto:


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/Documentation/snippets/percussion


Forwarding to bug-lilypond. This bug report is about the German version
of the documentation (“Schnipsel” = snippets) but it’s the same f. e. in
Spanish.

Same for 2.19.
Same for other links to the snippets.



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



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

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

[Malte Meyn]

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/Documentation/snippets/percussion


Forwarding to bug-lilypond. This bug report is about the German version 
of the documentation (“Schnipsel” = snippets) but it’s the same f. e. in 
Spanish.


Same for 2.19.
Same for other links to the snippets.

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

Percent repeats

[Malte Meyn]

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 “normal” user
2. there are different Events, Grobs and Engravers for percent repeats 
lasting 2 measures, 1 measure, and other durations:


\version "2.19.65"

{
  \override RepeatSlash.color = #blue
  \override PercentRepeat.color = #red
  \override DoublePercentRepeat.color = #magenta
  \repeat percent 4 { a16 b a b }
  \repeat percent 2 { a1 }
  \repeat percent 2 { a b }
  \repeat percent 2 { a b a b }
}

IMO that’s very confusing; would it be possible to have a more 
consistent way to print percent repeats?


Cheers,
Malte

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

\cueDuring at begin of music prevents Voice context

[Malte Meyn]

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:



%%

\version "2.21.0" % current master

\addQuote "foo" \relative { c'4 d e f g a b c }

% add this line to force the creation of a Voice context
%\new Voice
\relative {
  \cueDuring "foo" #DOWN R1
  f'4 e d c
}

%%

This also isn’t listed under “known issues” in the NR (section 1.6.3).

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

Re: Footnote separator line

[Malte Meyn]

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-separator-markup = ##f
}


This should be documented. At the moment, it isn’t mentioned anywhere a 
normal user can find it:


$ git grep footnote-separator-markup
lily/page-layout-problem.cc:  SCM markup = paper->c_variable 
("footnote-separator-markup");
ly/paper-defaults-init.ly:  footnote-separator-markup = \markup 
\fill-line { \override #'(span-factor . 1/2) \draw-hline }

$

CC to bug list.

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

\tempo feature requests

[Malte Meyn]

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 grob property which scales the notes.

• IMO coloring (only) the number is very special and could be omitted.
• Offer three values for tempoShowParentheses: #t, #f and 'if-no-text 
(the latter mimicking the current default behaviour).

• Add ASCII/scheme symbol shorthands for non-ASCII symbols like ≈ and ≙.

Snippet 574:
• Either introduce a new command \tempoEquiv which takes two durations
• or extend \tempo. Suggested backwards-compatible syntax:
\tempo [string] [duration [~ duration] [= number [- number]]]
Examples:
\tempo "Allegro"
\tempo 4 = 120 - 126
\tempo 4 ~ 2
\tempo "L’istesso tempo" 4 ~ 4. = 120-126
The latter should output “L’istesso tempo (텟 = 텟텭 = 120 – 126)”
• Add MIDI support: if a number is given, use this. If only an 
equivalence like 4 ~ 4. is given, compute the new tempoWholesPerMinute 
from the old one. (Is this possible?)


Any opinions?

Cheers,
Malte


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

Re: Bad clef change collision when alternating piano staves

[Malte Meyn]

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[ b c d]
  }
  \new Voice {
a8
\change Staff = "LH" \clef treble a_1
\change Staff = "RH"  a
\change Staff = "LH"  a_2
\clef bass
cis,, d e f
  }
>>
e''2
  }
  \new Staff = "LH" \relative a, {
\clef bass
a8 s2..
e'2
  }
>>

Am 09.10.2017 um 05:23 schrieb Ophir Lifshitz:

Hello,

Can someone please triage this bug?

Thanks again,
Ophir

On Sun, Jan 31, 2016 at 4:57 PM, Ophir Lifshitz 
wrote:


Hello,

Would it be possible to triage this bug I reported 3 months ago?

Thanks,
Ophir

On Fri, Jan 1, 2016 at 10:03 AM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


Hello again,

Has anyone been able to triage this bug yet?

Thanks,
Ophir

On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


I was browsing through recent bugs on the new tracker and found this
one: http://sourceforge.net/p/testlilyissues/issues/4642/

I wonder whether it is related?

Ophir

On Tue, Oct 27, 2015 at 6:15 PM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


And so in that case, probably something like \hideNotes r ...
\unHideNotes will be sufficient.

Ophir

On Tue, Oct 27, 2015 at 6:10 PM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


Hello again,

Yes, thank you Pierre. I believe that will work temporarily, but I'm
still mostly convinced it's a bug that needs to be fixed.

For example, change the space s4. near the bottom of the file between
three eighth rests r r r (clef change is – mostly – properly spaced)
and two rests plus a space r r s (collision). It seems that Lilypond
can't detect the RH's note's presence in the 4th position of the LH staff,
and it only detects the presence of a LH note/rest starting somewhere in
the 4th position.

Ophir

On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:


Oops, sorry, too fast reading...

How about :

\version "2.19.22"
\new PianoStaff <<
 \new Staff = "RH" \relative a' {
 \clef treble
 a8
 \change Staff = "LH" \clef treble a_1
 \change Staff = "RH"  a
 \change Staff = "LH"
 \tweak X-extent #'(0 . -2)
 \tweak X-offset #-3.3 a_2
 \clef bass
 \change Staff = "RH"
 \tweak X-extent #'(-7 . 1.3) a
 }
 \new Staff = "LH" \relative a, {
 \clef bass
 a8 s4. cis8_3
 }






2015-10-27 22:37 GMT+01:00 Ophir Lifshitz  wrote:


Hi Ophir,

Try :
\once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass

Cheers,
~Pierre

2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <
hangfromthefl...@gmail.com>:


Hello all,

I believe there is a bug in making space for clef changes. You can
find the
MWE here: http://lilybin.com/gs2oks/7

The notes labeled 1 and 2 on the lower LH staff are both notated
in treble
clef. But because space wasn't made for the bass clef change, the
bass clef
misleadingly appears slightly before note 2. I would have instead
expected
to see a lot of space made between notes 2 and 3 where the clef
can fit
properly. The clef change before note 1 shows that Lilypond can
indeed make
space for clef changes.

If not a bug, what is the best way to fix the collision?

Thanks in advance,
Ophir

P.S. The MWE was gradually simplified (1 <
http://lilybin.com/gs2oks/1> 2
 3  4
 current )
in
case anyone is curious for the source
.
Also attached are the source and an image in case of linkrot.

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



















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



___
bug-lilypond mailing list
bug-lilypond@gnu.org

Re: Glissando.font-size

[Malte Meyn]

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 padding by something 
that imitates (magstep font-size). But why? I would understand this when 
bound-details.left.padding was the distance between 
bound-details.left.text and the glissando line but it’s the distance 
outside of the text:


\version "2.19.65"

{
  \override Glissando.bound-details.left.text = "a"
  \override Glissando.bound-details.right.text = "z"
  \override Glissando.bound-details.left.padding = 0
  \override Glissando.bound-details.right.padding = 4
  c''1\glissando c''
}


\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 visible effect.


There is no padding but bound-details.left.padding and 
bound-details.right.padding.


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

Glissando.font-size

[Malte Meyn]

\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 visible effect.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: accidentals on merged notes

[Malte Meyn]

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 one applies to which Voice.


How should this be a default behaviour? IMO none of those two options 
looks good and unambiguous. But here are three possible solutions to 
your problem (I like the third most):


We might decide that it is ok to provide an ambiguous engraving, but the 
engraving lilypond provides is clearly broken and should be fixed.


I agree on that and on the comments to your examples
• Hauke A (current default is buggy)
• Knut C (why Malte B is no solution)
• Malte C (don’t add staves automagically)

Some comments of mine to the other examples:
• Knut A: I agree it looks a little bit ambiguous but in chords (not in 
polyphony though) it’s the best solution for a *default* behaviour. (btw 
it has to be sharp-natural like here, not natural-sharp)
• Knut B: This works only unambiguously with much more horizontal space. 
So IMO not a good solution for default behaviour.
• Malte A: Same problem as Knut B but Knut B is better (look at the 
g-sharp/a-sharp on beat 4)
• Malte B: Not a thing for default because of cases like Knut C and the 
accidentals are too small to read.


So IMO the default should be changed from Hauke A to Knut A. This works 
only for chords but polyphony should use seperate staves here anyway.


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

Re: accidentals on merged notes

[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 one applies to which Voice.


How should this be a default behaviour? IMO none of those two options 
looks good and unambiguous. But here are three possible solutions to 
your problem (I like the third most):


\version "2.19.63"

\relative {
  <<
{
  c''4
  \tweak NoteColumn.X-offset 2.5
  \tweak Accidental.X-offset 1.6
  g
  \tweak NoteColumn.X-offset 1.5
  \tweak Accidental.extra-offset #'(1.65 . 0)
  g!
  ais
} \\ {
  gis
  gis
  \tweak NoteHead.extra-offset #'(-1 . 0)
  \tweak Stem.extra-offset #'(-1 . 0)
  gis
  gis
}
  >>
}

\relative {
  <<
{
  c''4
  \tweak Accidental.stencil #ly:text-interface::print
  \tweak Accidental.text
  \markup \fontsize #-5 \override #'(baseline-skip . 2) \vcenter 
\center-column {

\musicglyph #"accidentals.natural"
\musicglyph #"accidentals.sharp"
  }
  g
  g
  ais
} \\ {
  gis
  gis
  \tweak Accidental.stencil #ly:text-interface::print
  \tweak Accidental.text
  \markup \fontsize #-5 \override #'(baseline-skip . 2) \vcenter 
\center-column {

\musicglyph #"accidentals.natural"
\musicglyph #"accidentals.sharp"
  }
  gis
  gis
}
  >>
}

\new StaffGroup \new Staff = "orig" \relative {
  <<
{
  c''4 c c c
  \new Staff \with {
alignAboveContext = "orig"
  } \relative {
\omit Staff.TimeSignature
\omit Staff.Clef
c'' g! g a
  }
  c c c c
} \\ {
  gis gis gis gis
  gis gis gis gis
  gis gis gis gis
}
  >>
}

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

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

[Malte Meyn]

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 first 
issue so please give us a minimal example like the following that 
illustrates your problem:


%%% BEGIN MINIMAL EXAMPLE (all three issues)
\version "2.18.2"

\relative {
  % issue 2: very long instrument name
  \set Staff.instrumentName = "This is a very long instrument"
  % issue 3: too many notes per line
  \repeat unfold 64 d'64
  % issue 1: very many grace notes
  \repeat unfold 1024 { \grace e8 d }
}
%%% END MINIMAL EXAMPLE

Now here comes a solution for issue 2 and 3:
2. Change the indent (and if you use shortInstrumentName also the 
short-indent) as shown in this pdf: 
http://joramberger.de/files/LilypondSpacing.pdf
3. Use a very small font size or, probably better, allow line breaks at 
some reasonable points in the measure:


  \repeat unfold 16 d'64 \bar ""
  \repeat unfold 16 d64 \bar ""
  \repeat unfold 16 d64 \bar ""
  \repeat unfold 16 d64

Am 05.06.2017 um 01:54 schrieb alex a:

sorry issue #3 below got chopped off. Here is the complete statement:


3. If a bar in a 4/4 rhythm piece has 64 notes (of 1/64 value each), then 
Lilypond will run the notes off the page. One can only see about 2/3 of the 
notes in that bar.


From: alex a 
Sent: June 4, 2017 7:48:34 PM
To: bug-lilypond@gnu.org
Subject:


HI

I am not sure if this the result of bugs or something else but here are three 
issues I found using this great product:



   1.  When using too many grace notes and you run the code it will give a 
message that says:

“Programming error: going back in MIDI time”

   1.  Instrument names that are not very short get chopped
   2.  If a bar in a 4/4 rhythm piece has 64 note



Sent from Mail for Windows 10


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



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

Re: TupletBracket.shorten-pair with strange output

[Malte Meyn]

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 the right end.

Maybe this is what you are looking for?:

\override TupletBracket.shorten-pair = #'(2.5 . 2.5)
\override TupletBracket.X-offset = 2.5

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

Re: 2.19.56 Learning Manual correction.

[Malte Meyn]

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 sentence should be "(either a \layout or
> a \midi block or both)."

Either \layout or \midi or both or even none of them; the \score block
can also contain a \header block.

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

Re: Parenthesis issue with cross staff beaming

[Malte Meyn]

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.

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

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

[Malte Meyn]

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: Mark numbering incorrect at staff level

[Malte Meyn]

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 for the Score context instead of the context the 
Mark_engraver lives in. Try

\set Staff.rehearsalMark = 6 \mark \default
instead of
\mark 6

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

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

[Malte Meyn]

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.40.  (This is on Win7, 64-bit.)


This looks like a problem with autobeaming and negative measurePosition 
(it seems like LilyPond tries to figure out the beaming for all three 
eigth notes).


Workaround for 2.18.2 and 2.19.xx: manually beam the two eights in the 
first staff: a2. a8[ a]


Workaround/solution only for 2.19.xx: use \partial instead of setting 
measurePosition. \partial has been improved so it can now be used in the 
middle of a piece and doesn’t simply set measurePosition. So I 
personally would consider this bug as fixed. Opinions?


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

Re: Pitched Trill Collision

[Malte Meyn]

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 between 2.19.40 and 2.19.42, probably 
by commit b184142c; the commit message says “Merge overlapping ledger 
data before producing ledger stencils so we only produce one stencil for 
each ledger line.”


Here a minimal example:

\version "2.19.42"
\pitchedTrill a''\startTrillSpan a''

I’ll CC this to the bug list.

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

Re: Slur-articulation collision

[Malte Meyn]

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)?


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

font-encoding and MeasureCounter

[Malte Meyn]

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

\override MeasureCounter.font-encoding = #'latin1
does the trick. But section A.18 of the NR states that font-encoding 
only allows the values fetaText, fetaMusic, and fetaBraces. And neither 
#'ascii nor #'utf8 have an effect.


I see here a bug but I’m not sure which one or two:
1. Is it a bug that overriding font-family doesn’t work?
2. Is it a bug that #'ascii and #'utf8 don’t work?
3. It *is* a bug that #'latin1 isn’t mentioned in the docs.

%%% MWE following

\version "2.19.47"

\new Staff \with {
  \consists #Measure_counter_engraver
  %\override MeasureCounter.font-family = #'roman% no effect
  %\override MeasureCounter.font-encoding = #'latin1 % only latin1 works
} {
  \startMeasureCount
  \repeat unfold 10 a1
  \stopMeasureCount
}

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

fingeringOrientations and StringNumber.direction broken?

[Malte Meyn]

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 should be the same for the second, third, and fourth note.

\version "2.19.46"

{
  % Everything ok:
  g'\1-2

  % This looks broken to me:
  \once \override StringNumber.direction = #DOWN
  \once \override Fingering.direction = #DOWN
  g'\1-2

  \once \set stringNumberOrientations = #'(DOWN)
  % This looks broken to me:
  \once \set fingeringOrientations = #'(DOWN)
  g'\1-2

  % Everything ok:
  g'_\1_2
}

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