Adding quote with a custom context inside throws warning

[Simon Albrecht via bug-lilypond]

Hello,

when \addQuote is used and the music within creates a custom context, 
this works as intended but outputs a warning:


%%%
\version "2.25.12"

\layout {
  \context {
    \Voice
    \name VocalVoice
    \alias Voice
  }
}

sop = \new VocalVoice { 1 }
\addQuote "sop" \sop
%

=>

Starting lilypond 2.25.12 [Untitled]...
Processing `/tmp/frescobaldi-x5k4p__3/tmpinzgj_k6/document.ly'
Parsing...
/tmp/frescobaldi-x5k4p__3/tmpinzgj_k6/document.ly:12:17: warning: cannot 
create context: VocalVoice

\addQuote "sop"
    \sop
Success: compilation successfully completed
Completed successfully in 0.2".

Best regards
Simon

Re: Reply to digest

[Simon Albrecht via bug-lilypond]

On 04.03.24 14:12, David Kastrup wrote:

Did you really have to_quote_  all of the quoted messages of last week
_again_  to make that point?

That will make all of those nonsensically quoted messages from last week
appear_twice_  in next week's digest.


I did not have to, and that was again inconsiderate. Sorry!

Reply to digest

[Simon Albrecht via bug-lilypond]

Hi Cameron,

please never reply to the digest form. The email will have incorrect 
headers, be displayed incorrectly in thread views, and mixing replies to 
different threads is wholly inconvenient as well. Bear in mind that this 
is sent to very many people who may or may not be interested in all 
topics on the list.


Best, Simon


On 03.03.24 19:11, Cameron Crowe via bug-lilypond wrote:

Thank you- good points, RE backups and copyrights.

Similar punishment!



Sent with Proton Mail secure email.

On Sunday, March 3rd, 2024 at 12:00 PM, bug-lilypond-requ...@gnu.org 
 wrote:


Send bug-lilypond mailing list submissions to
bug-lilypond@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/bug-lilypond
or, via email, send a message with subject or body 'help' to
bug-lilypond-requ...@gnu.org

You can reach the person managing the list at
bug-lilypond-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bug-lilypond digest..."


Today's Topics:

1. (non-bug) lilypond-book & secondary source files (Cameron Crowe)
2. Re: (non-bug) lilypond-book & secondary source files
(David Kastrup)
3. copyright date (Cameron Crowe)
4. Re: copyright date (Ruud Harmsen)


--

Message: 1
Date: Sat, 02 Mar 2024 17:50:28 +
From: Cameron Crowe cameron.cr...@protonmail.com

To: "bug-lilypond@gnu.org" bug-lilypond@gnu.org

Subject: (non-bug) lilypond-book & secondary source files
Message-ID:
KdjNdh4gfHFebEWvNLLMS0ROWa9MuFHJvGlv9nj0nztVvZf2lnJ_4_jhuAYAmPccVwQ8LqbOWMrOlYYKqOj5MqWHNXGkFpu6Fega7o_Y3PM=@protonmail.com


Content-Type: text/plain; charset=utf-8

Just a thought--not a bug.

lilypond-book refuses to overwrite a main source file, but happily overwrites 
secondary source files included into the main source file. Irritating if you 
use the .tex extension for included chapters of a musicological document and 
even just accidentally call lilypond-book without specifying a separate output 
dir.

"Don't do that." and "Version control!" would be perfectly good responses, and 
I probably have a few other minor (shrug-worth?) points if there is interest in hearing them.

In any case, I'm hugely fond of LP. Truly, thank you, devs and other 
contributors!

- Cam

--

Message: 2
Date: Sat, 02 Mar 2024 19:04:33 +0100
From: David Kastrup d...@gnu.org

To: bug-lilypond@gnu.org
Subject: Re: (non-bug) lilypond-book & secondary source files
Message-ID: 87y1b05x3i@fencepost.gnu.org

Content-Type: text/plain

Cameron Crowe via bug-lilypond bug-lilypond@gnu.org writes:


Just a thought--not a bug.

lilypond-book refuses to overwrite a main source file, but happily
overwrites secondary source files included into the main source
file. Irritating if you use the .tex extension for included chapters
of a musicological document and even just accidentally call
lilypond-book without specifying a separate output dir.

"Don't do that." and "Version control!" would be perfectly good
responses,


Version control is not a substitute for backups.


and I probably have a few other minor (shrug-worth?) points if there
is interest in hearing them.


Just anecdotally: on MSDOS file systems, writing a file whatever.tex.aux
was equivalent to writing a file whatever.tex and when writing
\include{something} in a LaTeX file, this caused a file something.aux to
be created/written.

This made the punishment for writing \include{something.tex} instead of
the correct \include{something} pretty severe (until MikTeX was made to
detect this special case and refuse the operation).

--
David Kastrup



--

Message: 3
Date: Sat, 02 Mar 2024 21:01:14 +
From: Cameron Crowe cameron.cr...@protonmail.com

To: "bug-lilypond@gnu.org" bug-lilypond@gnu.org

Subject: copyright date
Message-ID:
9ZBjOvJUSI-FNgj-nQJLy1aEQv_S3jtAXlUA4Ke5SrGbbnnCXmyR_XNlj_wf9JXlbR2LyiUUhl8UE44CRxXuSmWvhYTULXIjx8pxWPpmHFs=@protonmail.com


Content-Type: text/plain; charset=utf-8

I think the copyright is out of date for versions 2.24 and 2.25

GNU LilyPond 2.24.3 (running Guile 2.2)

Copyright (c) 1996--2023 by
Han-Wen Nienhuys han...@xs4all.nl

Jan Nieuwenhuizen jann...@gnu.org

and others.

GNU LilyPond 2.25.13 (running Guile 3.0)

Copyright (c) 1996--2023 by
Han-Wen Nienhuys han...@xs4all.nl

Jan Nieuwenhuizen jann...@gnu.org

and others.

--

Message: 4
Date: Sun, 03 Mar 2024 10:25:58 +0100
From: Ruud Harmsen ru...@rudhar.com

To: bug-lilypond@gnu.org
Subject: Re: copyright date
Message-ID: 20240303092600.00bb969...@rudhar.com

Content-Type: text/plain; charset="us-ascii"; format=flowed

10:01 PM 3/2/2024, Cameron Crowe via bug-lilypond:


I think the copyright is out of date for versions 2.24 and 2.25
GNU LilyPond 2.24.3 (running Guile 2.2) Copyright (c) 1996--2023
by Han-Wen Nienhuys han...@xs4all.nl Jan Nieuwenhuizen
jann...@gnu.org and 

Re: Custos_engraver crash with no explicit pitches

[Simon Albrecht]

On 17/03/2023 16:26, David Kastrup wrote:

That is not a minimal example.  Try

\new Staff \with { \consists "Custos_engraver" } { 1 }


Of course, I should have thought of that.

Best, Simon

Re: Custos_engraver crash with no explicit pitches

[Simon Albrecht]

Hi Jean,

On 17/03/2023 16:38, Jean Abou Samra wrote:

Thanks, but you already reported that bug about a year ago.



Thanks for digging that up/remembering. I did search the issue database 
for ‘custos crash’ (or ‘crash custos’ maybe), but despite the label 
“Crash” issue 6327 didn’t show up. ‘custos segfault’ would’ve worked, 
and maybe once that comment I now added is in the search index (?) 
‘custos crash’ might also work?


Anyway, my bad for not checking twice.

Best, Simon

Custos_engraver crash with no explicit pitches

[Simon Albrecht]

Hello everyone,

found this while creating a minimal example. The following code crashes 
on both 2.24.0 and 2.25.2:



\version "2.24.0"

\new Staff \with {
  \consists Custos_engraver
} { 1 \break r1 1 }


Not sure it’s ever going to trigger in real-life situations, but it’s a 
crash without error handling. “Output code 11.”


Best, Simon

Melody_engraver and tied notes

[Simon Albrecht]

Hello everyone,

Melody_engraver readily sets different stem directions either side of a 
tie. I don’t think it should do that.


%
\version "2.25.2"

\layout {
  \context {
    \Voice
    \remove Note_heads_engraver
    \consists Completion_heads_engraver
    \consists Melody_engraver
  }
}
\relative {
  d''2. b4~ 4 g2 b2 d2.
}
%%

Technically, not a minimal example, since Completion_heads_engraver 
isn’t really related. I just figured I include it to be safe, in case 
behaviour differs in any way with regard to potential fixes.


Best, Simon

Indistinct spacing of long note values

[Simon Albrecht]

Hello folks,

I’ve wrestled with this before, asked about it on the user list, and 
been told that I need to use spacing-increment to deal with it. However, 
the progression of spacing between note values always seems to reach a 
plateau above the whole notes and any longer values simply receive the 
exact same space as a whole note.


See attachment.

Should I go create a ticket?

Best, Simon

%% Attached code 
\version "2.23.11"

m =
#(define-music-function (csd inc) (fraction? number?)
   #{
  \override Score.SpacingSpanner.common-shortest-duration
  = $(fraction->moment csd)
  \override Score.SpacingSpanner.spacing-increment = $inc
  \cadenzaOn
  32 32 \bar "|"
  16 16 \bar "|"
  8 8 \bar "|"
  4 4 \bar "|"
  2 2 \bar "|"
  1 1 \bar "|"
  \breve \breve \bar "|"
  \longa \longa \bar "|"
   #})
% default increment is 1.2
\m 1/32 1.2
\m 1/8 1.2
\m 1/2 1.2
\m 2/1 1.2

\m 1/2 0.7
\m 1/2 1.2
\m 1/2 1.7
\m 1/2 2.2
%%%
\version "2.23.11"

m =
#(define-music-function (csd inc) (fraction? number?)
   #{
  \override Score.SpacingSpanner.common-shortest-duration
  = $(fraction->moment csd)
  \override Score.SpacingSpanner.spacing-increment = $inc
  \cadenzaOn
  32 32 \bar "|"
  16 16 \bar "|"
  8 8 \bar "|"
  4 4 \bar "|"
  2 2 \bar "|"
  1 1 \bar "|"
  \breve \breve \bar "|"
  \longa \longa \bar "|"
   #})
% default increment is 1.2
\m 1/32 1.2
\m 1/8 1.2
\m 1/2 1.2
\m 2/1 1.2

\m 1/2 0.7
\m 1/2 1.2
\m 1/2 1.7
\m 1/2 2.2

experiment-long-durations-2.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \repeat unfold has problems inside \repeat volta

[Simon Albrecht]

On 02/07/2022 18:20, Jean Abou Samra wrote:
Simon, you moved this from bug-lilypond to lilypond-user. Was that 
intentional? 


Did I? I’m sure I just clicked Reply All, and the thread as I received 
is on the user list… this e-mail of yours is the first that for me shows 
the bug list as recipient as well.


Best, Simon


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

Re: DynamicText.extra-spacing-width in StaffGroups and similar

[Simon Albrecht]

Hi Jean,

On 19/06/2022 22:22, Jean Abou Samra wrote:
Hope that's clearer? 



thanks, it is!

Best, Simon


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

Re: DynamicText.extra-spacing-width in StaffGroups and similar

[Simon Albrecht]

On 19/06/2022 19:17, Jean Abou Samra wrote:
For my own use now, it’s easy to override extra-spacing-width to 
infinitesimal for all Voice contexts.




You're welcome. Just curious: what do you mean by 'infinitesimal'?
'(+inf.0 . -inf.0)? That simply means to make the height entirely
empty. 



That’s what I meant—didn’t want to type it out… did I misunderstand? I 
thought it’s an infinitely small interval, because '(0 . 0) would/might 
lead to some sort of computational problem… My programming knowledge is 
very superficial.


Best, Simon


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

Re: DynamicText.extra-spacing-width in StaffGroups and similar

[Simon Albrecht]

Hi Jean,

On 19/06/2022 00:08, Jean Abou Samra wrote:
The point of this override is to avoid placing dynamics over span 
bars. With the general default of '(+inf.0 . -inf.0), they are mostly 
ignored in the horizontal spacing problem, which causes problems with 
things like



…


So this override shouldn't be specific to Dynamics in StaffGroup.

For discussion of the problems this override causes, see

https://gitlab.com/lilypond/lilypond/-/issues/6350



Thanks, that gives me a much clearer perspective. I commented on the issue.

For my own use now, it’s easy to override extra-spacing-width to 
infinitesimal for all Voice contexts.


Best, Simon



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

DynamicText.extra-spacing-width in StaffGroups and similar

[Simon Albrecht]

Hello everyone,

it seems that some unorthodox elements in my style sheets tend to 
unearth issues.


StaffGroup and similar contexts set DynamicText.extra-spacing-width to 
#f, I guess with Dynamics contexts in mind (?). The following example 
shows that in the absence of Dynamic_align_engraver, this setting 
becomes falsely applied to Staff contexts within.


I suppose it should be ensured some other way that this doesn’t carry 
over. (with an override in the definition for Voice contexts or Staff 
contexts?)


%%%
\version "2.23.9"

\layout {
  \context {
    \Voice
    \remove "Dynamic_align_engraver"
    %\override DynamicText.extra-spacing-width = #'(+inf.0 . -inf.0)
  }
}

sOne = {
  <>\p
  \repeat unfold 40 c'4
}

\paper {
  system-count = 1
}

\score {
  \new StaffGroup
  \sOne
}


(Nevermind the nonsensical vertical placement of the dynamic in this 
tiny example.)


Best regards,
Simon


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

Crash with bare duration at the start of a Voice-alias context

[Simon Albrecht]

Hello list,

this causes a crash while Interpreting music (Exiting with return code 11.):



% also happens with 2.20.0
\version "2.23.6"
%%{
% also happens with VaticanaVoice,MedicaeaVoice,PetrucciVoice
\new MensuralVoice {
  % this prevents the crash
  %c'1
  1
}
%}
% none of these cause the crash
%{
\new Voice \with {
  \remove Ligature_bracket_engraver
  \consists Mensural_ligature_engraver
  \override NoteHead.style = #'mensural
  autoBeaming = ##f
} { 1 }
%}

%%

Best, Simon



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

Re: Odd interaction between ly:grob-property and hairpin

[Simon Albrecht]

On 11/02/2022 00:50, Jean Abou Samra wrote:

When you get around to it, could you explain this? Maybe I'm
being dense, but it's not obvious to me. Do you expect it
to save enough vertical space that it will enable LilyPond
to cram more systems on a page?

Anyway, this might be a topic for the user list in the end. 



It is, which is why I’ll only give a brief example here. Have a look at 
the first few bars at this: 
https://imslp.org/wiki/File:SIBLEY1802.14023.d867-39087011616572score.pdf


It shows various strategies of placing dynamics and articulations 
overlapping with the staff (without there even being strict necessity 
for some of them). All of these are abundantly common in 19th century 
engraving and enable far more compact layout. The issue can more severe 
in choral music due to lyrics, but in orchestral music there are more 
ledger lines, articulations, slurs  exacerbating the need for 
flexibility with dynamic placement.


Modern aesthetics often favour exact alignment, no overlapping and very 
loose spacing at the expense of huge increases in page count. I rarely 
agree…


Best, Simon


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

Re: Odd interaction between ly:grob-property and hairpin

[Simon Albrecht]

Hello Jean,

thanks for the information. I can’t respond to each point right now, too 
tired. But…


On 10/02/2022 19:40, Jean Abou Samra wrote:
What are you trying to achieve in the first place? 


I’m in another iteration of writing a macro for adjusting placement of 
dynamics (Hairpin, DynamicText and DynamicTextSpanner). It needs to 
allow intersection with staff lines, interact well with 
DynamicLineSpanner and have a concise, reliable, clear user interface 
suitable for frequent use. (What I’m after and have been using in most 
iterations is something like @code{ c1\off #'(-1 . 2) \f }). I have 
switched to using grob callbacks since I didn’t see another way of 
reacting to grob type, direction and previous offsets adequately. I need 
to set multiple grob properties (of more than one grob) and since saving 
large amounts of vertical space is the whole point, it obviously needs 
to be before-line-breaking.


However, I’m slowly realising that I don’t know well enough what exactly 
the functionality is supposed to be and how much of that is even feasible.


I’m hoping to get back to you tomorrow.

Best, Simon


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

Re: Odd interaction between ly:grob-property and hairpin

[Simon Albrecht]

Hi Aaron,

thanks a lot for the help! I knew that these pure vs. impure issues 
exist, but I’ve never been able to wrap my head around them and this is 
the first time I ever needed to account for them in practice.


Looking at Extending Manual section 2.8, it seems that Y-offset is 
likely to be affected, so that makes sense.


What I don’t quite get is the meaning of the ‘begin’ and ‘end’ 
parameters in ly:grob-pure-property, but as long as 0 0 works, I’m good 
;) (and it’s not a topic for the bug list)


Best, Simon

On 10/02/2022 03:29, Aaron Hill wrote:


A pure vs. unpure issue perhaps?  If you use ly:grob-pure-property to 
access it, it seems to work. 


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

Odd interaction between ly:grob-property and hairpin

[Simon Albrecht]

Hello list,

if a grob callback queries a grob property on a hairpin as follows, the 
hairpin gets printed infinitely short (with a corresponding warning: 
crescendo too small):


%%
% tested with version 2.22.0 as well -- same bug
\version "2.23.6"
% guile2 binary from
% 
https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1/downloads/lilypond-2.23.6-linux-x86_64.tar.gz

off =
#(define-event-function
  (ev)
  (ly:music?)
  (let ((offsetter-fn
 (lambda (grob)
   (let* (
   ; comment/uncomment the following to trigger bug:
   ; if the grob property is queried, the hairpin gets 
infinitely short

   (yoff-prev (ly:grob-property grob 'Y-offset 0))
   )
 (ly:grob-set-property! grob 'color red)
 
    #{
  - \tweak before-line-breaking $offsetter-fn
  - $ev
    #}))

{ 2\off \< 2\f }
%

Best, Simon


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

Re: self-alignment-X has the opposite effect on Lyric syllables narrower than the note-head

[Simon Albrecht]

Hi Aaron,

thanks for looking into this.

On 20/01/2022 14:07, Aaron Hill wrote:
Firstly, alignment values outside the interval [-1, 1] in general 
behave oddly as the result depends on the size of the object in 
question.  Larger things do end up moving more.


Well, I wouldn’t call that ‘odd’ since it is a very useful effect and I 
very often use alignment values other than -1 or 1, which makes it 
intuitive to work with. The step from 0.8 to 1 is the same as the step 
from 1 to 1.2.



Secondly, LyricText has parent-alignment-X set to '() which, as far as 
I can tell, results in inheriting self-alignment-X. Choosing #RIGHT, 
for example, means to have the right side of the text align with the 
right edge of the note. 


That’s unexpected and explains it perfectly. I will set 
parent-alignment-X to 0 in my default style sheet.


However, it may be worthwhile opening a ticket like “Unset 
parent-alignment-X causes unexpected behaviour” IMO.


Best, Simon


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

Re: Horizontal alignment of DynamicTextSpanner left text

[Simon Albrecht]

Thanks for the encouragement ;)

I don’t have any knowledge of C++ at all and haven’t made any 
contributions to the code for a long time. I’ll see whether I can find 
time to try.


Best, Simon

On 31/01/2022 17:39, Jean Abou Samra wrote:

Do you have some knowledge of C++? Unlike vertical
placement, which is a little subtler, horizontal placement
in lily/line-spanner.cc is quite straightforward.
I'd expect a patch for this not to require extensive
knowledge of internals. 


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

Horizontal alignment of DynamicTextSpanner left text

[Simon Albrecht]

Hello list,

normally, horizontal alignment of grobs to other grobs is adjusted using 
self-alignment-X and parent-alignment-X—IIRC, this was homogenised some 
a couple years ago.


However, when wanting to adjust the alignment of a DynamicTextSpanner’s 
left bound, I found that this is much less clear for spanners. They have 
the parent-alignment-X component hidden behind the misleading property 
name attach-dir, and no default way of adjusting self-alignment-X via 
grob property (see this thread [1] for workarounds).


I suggest modifying line-spanner-interface to use self-alignment-X and 
parent-alignment-X in all subproperties of bound-details, and heeding 
these properties for DynamicTextSpanner and similar grobs.


Best, Simon


[1] https://lists.gnu.org/archive/html/lilypond-user/2022-01/msg00389.html


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

self-alignment-X has the opposite effect on Lyric syllables narrower than the note-head

[Simon Albrecht]

Hello everyone,

when setting self-alignment-X on a lyric syllable that is narrower than 
its corresponding note-head, it takes the opposite effect of what should 
be expected:


%%
\version "2.23.5"

<<
  { 1 1 }
  \addlyrics {
    \tweak self-alignment-X #3 test
    \tweak self-alignment-X #3 i
  }
>>
%%

(output attached)

Best, Simon

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

accidentalStyle choral: too many accidentals in situations with ties

[Simon Albrecht]

Hello everyone,

I found a kind of situation in which the ‘choral’ accidental style 
produces too many accidentals:


\version "2.19.84"

\new ChoirStaff \with {
  \accidentalStyle choral
} <<
  { cis'1 4 4 }
  { cis'1~4 4 }
>>

See attachment for output: the last note in the top staff shouldn’t get 
an accidental.


Due to an unrelated issue, I couldn’t test 2.21.0, but I guess there’s 
no reason why it would be different.


Best, Simon

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

Update on 2965: mid-bar \newSpacingSection leads to collisions

[Simon Albrecht]

Dear folks,

I hit another instance of issue 2965, which allowed me to see clearer 
what the core problem seems to be and to update the issue.




Best, Simon


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

Re: staffgroup-staff-spacing may be applied multiple times per StaffGroup

[Simon Albrecht]

Entered as .

On 15.10.18 14:12, Thomas Morley wrote:

Hi,

for nested container-contexts StaffGrouper.staffgroup-staff-spacing is
applied not only to the last Staff (as opposed to the NR).
See code below, png attached.

\version "2.19.82"

mus = \new Voice { c''1 }

\score {
   <<
 \new StaffGroup
   <<
 \mus
 \new GrandStaff << \mus \mus >>
 \mus
 \new GrandStaff << \mus \mus >>
 \mus
   >>
 \mus
   >>
   \layout {

   %% Play with the padding-values
 \override StaffGroup.StaffGrouper.staffgroup-staff-spacing =
 #'((basic-distance . 0)
(minimum-distance . 0)
(padding . 10)
(stretchability . 0))
 \override GrandStaff.StaffGrouper.staffgroup-staff-spacing =
 #'((basic-distance . 0)
(minimum-distance . 0)
(padding . 0)
(stretchability . 0))

   %% Don't get disturbed by other settings
   \override Staff.VerticalAxisGroup.default-staff-staff-spacing =
 #'((basic-distance . 0)
(minimum-distance . 0)
(padding . 0)
(stretchability . 0))
 \override StaffGroup.StaffGrouper.staff-staff-spacing =
 #'((basic-distance . 0)
(minimum-distance . 0)
(padding . 0)
(stretchability . 0))
   }
}

http://lilypond.org/doc/v2.19/Documentation/notation/flexible-vertical-spacing-within-systems
states:
"Properties of the StaffGrouper grob
[...]
staffgroup-staff-spacing
The distance between the last staff of the current staff-group and the
staff just below it in the same system,
[...]."

Actually, the last Staff of a StaffGroup (or equivalent) _and_ every
Staff right before another container-context is spaced by
staffgroup-staff-spacing.

I'm undecided whether I'd call this behaviour a bug or a feature.
Opinions?

In any case the doc is currently wrong, at least incomplete.

Cheers,
   Harm

___
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: Subdivised beams bug

[Simon Albrecht]

Hello Urs, James, and everybody else,

I’ve finally come around and made an attempt at sensible bookkeeping of 
these issues by creating 
 and closing some 
of the related issues that I think it supersedes as Duplicates.


I hope that is considered appropriate.

Best, Simon

On 07.09.18 09:04, Urs Liska wrote:
There are a number of open issues, (at least) one lengthy discussion, 
and an entry on the GSoC page, but not a comprehensive tracker item.


I suggest someone from the bug squad (deliberately not myself) creates 
a new issue for this,


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

Re: Almost-synchronous accidental makes the first one collide

[Simon Albrecht]

Entered as <https://sourceforge.net/p/testlilyissues/issues/5546/>.

Best, Simon

On 10.09.18 18:10, Simon Albrecht wrote:

Hello,

have a look at this:

\fixed c'' <<
  \time 2/4
  { a8*2/3 c' b c' a f  a c' b c' a fis }
  \repeat unfold 2 { d4. e16 fis }
>>

Output attached.

Best, Simon


___
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: Compilation error, due to changes in pango

[Simon Albrecht]

Thanks for reporting, this has been entered as

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

I hope the ‘maintainability’ label is appropriate.

Best, Simon

On 30.07.19 21:18, t.sefzick wrote:

With the new pango version 1.44 compilation of

src/lilypond/lily/pango-font.cc

gives warnings about
'void* pango_fc_font_lock_face(PangoFcFont*)'
to be deprecated and
'pango_font_get_hb_font'
should be used instead.

followed by
error: invalid conversion from 'gpointer' {aka 'void*'} to 'FT_Face' {aka 
'FT_FaceRec_*'}

Seems that pango doesn't work with freetype fonts anymore.

A side note: lilypond executables compiled with pango <=1.43
produce an empty 1st page when run with pango 1.44 installed.

___
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: Bug with Ambitus and ottava ???

[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


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

Re: dyld: Library not loaded: @executable_path/../lib//libintl.8.dylib

[Simon Albrecht]

On 09.07.19 05:33, instopcs wrote:

I'm using abjad and through abjab, lilypond is used. However, when I try to
run sample code through PyCharm. I get that dyld: Library not loaded:
@executable_path/../lib//libintl.8.dylib, referenced from my python
virtualenv path. On Mac OS 10.14.5 and when I type python --version, I get
2.7.10 and python3 --version, 3.7.3.



That doesn’t seem like a lilypond problem, rather one with abjad and/or 
python.


Best, Simon


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

Re: Markup question

[Simon Albrecht]

Hi John,

On 30.06.19 15:37, John McWilliam wrote:

I am new to this forum and have registered myself to the bug-lilypond list but 
am not sure whether most question should go via the user list.



indeed these are questions for the user list, which is very open to all 
kinds of Lily-related questions. The bug list is to be used according to 
, i.e. only in very limited cases.


Also, a policy issue: if you are receiving the daily digest, make sure 
to at least edit the subject line when responding. However, it’s more 
convenient to turn off digest mode and direct the e-mails to a dedicated 
folder using automated filters or a separate inbox; then you can just 
reply to the individual messages.


Best, Simon


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

Re: ChordNames depend on input language

[Simon Albrecht]

See also discussion at https://sourceforge.net/p/testlilyissues/issues/4337/.

Best, Simon

> On 28.04.2019 - 18:07, Malte Meyn wrote:
>
>
> 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


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

Fwd: Re: Re: The Stem of Longa notes is short when Baroque Notehead style is used

[Simon Albrecht]

 Forwarded Message 
Subject: 	Re: Re: The Stem of Longa notes is short when Baroque Notehead 
style is used

Date:   Wed, 30 Jan 2019 11:38:56 +0100
From:   Simon Albrecht 
To: potharn.i...@gmail.com



That sounds like a valid enhancement request, but you should back it up 
with evidence (longs glyphs from other music fonts, or old 
prints/manuscripts). The stem wasn't made that short by accident – it's 
designer had a reason for that as well.


Best, Simon


On 30.01.2019 - 03:53, Pothárn Imre wrote:


Well, I suppose it's useless to try to argue, but that glyph might be

supposed to be like that, but it is completely useless. I am posting a
lot of Renaissance music on CPDL using the original note values. The
final note is invariably a longa, which I have always substituted with
a breve because of Lilypond's longa looks so bad with its short stem.
In Renaissance music (i.e. everywhere where this kind of note-head is
used as longa) the stem of the longa is as long as all the other
stems. So this short stem is clearly wrong. But I since I can't force
you to draw a proper longa, I must resign that I cannot use longa in
transcriptions of Renaissance music in the future, either, since
apparently you do not care. (And I think it's also useless to remind
you that other engraving programs - notably Finale - have a proper
longa, which I therefore used as a Finale user before switching to
Lilypond.)

Mit freundlichen Grüßen
Imre

Simon Albrecht  ezt írta (időpont: 2019. jan.
29., K, 9:57):
>
> On 28.01.19 23:57, Pothárn Imre wrote:
> > %% The stem length of the longa is very short when Baroque 
NoteHead style is

> > used.
>
>
> That’s because it’s not technically a stem, but part of the notehead
> glyph. It’s supposed to be like that.
>
> Best, Simon
>




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

Fwd: Re: The Stem of Longa notes is short when Baroque Notehead style is used

[Simon Albrecht]

Please never move conversations off-list unless absolutely necessary.
Best, Simon



 Forwarded Message 
Subject: 	Re: The Stem of Longa notes is short when Baroque Notehead 
style is used

Date:   Wed, 30 Jan 2019 03:53:41 +0100
From:   Pothárn Imre 
To: Simon Albrecht 



Well, I suppose it's useless to try to argue, but that glyph might be
supposed to be like that, but it is completely useless. I am posting a
lot of Renaissance music on CPDL using the original note values. The
final note is invariably a longa, which I have always substituted with
a breve because of Lilypond's longa looks so bad with its short stem.
In Renaissance music (i.e. everywhere where this kind of note-head is
used as longa) the stem of the longa is as long as all the other
stems. So this short stem is clearly wrong. But I since I can't force
you to draw a proper longa, I must resign that I cannot use longa in
transcriptions of Renaissance music in the future, either, since
apparently you do not care. (And I think it's also useless to remind
you that other engraving programs - notably Finale - have a proper
longa, which I therefore used as a Finale user before switching to
Lilypond.)

Mit freundlichen Grüßen
Imre

Simon Albrecht  ezt írta (időpont: 2019. jan.
29., K, 9:57):

On 28.01.19 23:57, Pothárn Imre wrote:

%% The stem length of the longa is very short when Baroque NoteHead style is
used.



That’s because it’s not technically a stem, but part of the notehead
glyph. It’s supposed to be like that.

Best, Simon



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

Fwd: Re: Re: The Stem of Longa notes is short when Baroque Notehead style is used

[Simon Albrecht]

 Forwarded Message 
Subject: 	Re: Re: The Stem of Longa notes is short when Baroque Notehead 
style is used

Date:   Wed, 30 Jan 2019 11:41:49 +0100
From:   Simon Albrecht 
To: potharn.i...@gmail.com



It wouldn't even be difficult to write a music function that adds a line 
stencil to every Longa note head such as to mimick a longer stem. You 
could ask for that on the user list.

How about the other note head styles?


On 30.01.2019 - 03:53, Pothárn Imre wrote:


Well, I suppose it's useless to try to argue, but that glyph might be

supposed to be like that, but it is completely useless. I am posting a
lot of Renaissance music on CPDL using the original note values. The
final note is invariably a longa, which I have always substituted with
a breve because of Lilypond's longa looks so bad with its short stem.
In Renaissance music (i.e. everywhere where this kind of note-head is
used as longa) the stem of the longa is as long as all the other
stems. So this short stem is clearly wrong. But I since I can't force
you to draw a proper longa, I must resign that I cannot use longa in
transcriptions of Renaissance music in the future, either, since
apparently you do not care. (And I think it's also useless to remind
you that other engraving programs - notably Finale - have a proper
longa, which I therefore used as a Finale user before switching to
Lilypond.)

Mit freundlichen Grüßen
Imre

Simon Albrecht  ezt írta (időpont: 2019. jan.
29., K, 9:57):
>
> On 28.01.19 23:57, Pothárn Imre wrote:
> > %% The stem length of the longa is very short when Baroque 
NoteHead style is

> > used.
>
>
> That’s because it’s not technically a stem, but part of the notehead
> glyph. It’s supposed to be like that.
>
> Best, Simon
>




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

Re: The Stem of Longa notes is short when Baroque Notehead style is used

[Simon Albrecht]

On 28.01.19 23:57, Pothárn Imre wrote:

%% The stem length of the longa is very short when Baroque NoteHead style is
used.



That’s because it’s not technically a stem, but part of the notehead 
glyph. It’s supposed to be like that.


Best, Simon


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

Re: Ambitus: horizontal spacing

[Simon Albrecht]

See also https://sourceforge.net/p/testlilyissues/issues/4396/.

Best, Simon

> On 30.09.2018 - 18:50, Malte Meyn wrote:
>
>
> 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
>

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

Fwd: [testlilyissues:issues] #5419 merge-differently-headed and merge-differently-dotted merge incorrectly with NoteColumn.force-hshift overridden

[Simon Albrecht]

 Forwarded Message 
Subject: 	[testlilyissues:issues] #5419 merge-differently-headed and 
merge-differently-dotted merge incorrectly with NoteColumn.force-hshift 
overridden

Date:   Wed, 19 Sep 2018 18:42:10 -
From:   Simon Albrecht 
Reply-To:   Ticket 5419 <5...@issues.testlilyissues.p.re.sourceforge.net>
To: Ticket 5419 <5...@issues.testlilyissues.p.re.sourceforge.net>




---

** [issues:#5419] merge-differently-headed and merge-differently-dotted merge 
incorrectly with NoteColumn.force-hshift overridden**

**Status:** Accepted
**Created:** Wed Sep 19, 2018 06:42 PM UTC by Simon Albrecht
**Last Updated:** Wed Sep 19, 2018 06:42 PM UTC
**Owner:** nobody
**Attachments:**

- [Screenshot from 2018-09-19 
20-41-47.png](https://sourceforge.net/p/testlilyissues/issues/5419/attachment/Screenshot%20from%202018-09-19%2020-41-47.png)
 (3.1 kB; image/png)


Reported by Peter Terpstra:


:::TeX
\version "2.18.2" % same in 2.19.82

<<
  \mergeDifferentlyHeadedOn
  \mergeDifferentlyDottedOn
  {
g'2 s
g'8 % doesn’t happen with a quarter note, but with shorter values it does
  }
  \\
  {
\override NoteColumn.force-hshift = #1
g'2. s4
g'2
  }






---

Sent from sourceforge.net because you indicated interest in 
<https://sourceforge.net/p/testlilyissues/issues/5419/>



To unsubscribe from further messages, please visit 
<https://sourceforge.net/auth/subscriptions/>


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

Re: Feature request: paper variable for odd-only or even-only pagination

[Simon Albrecht]

On 11.09.2018 16:32, Aaron Hill wrote:

On 2018-09-11 3:03 am, Simon Albrecht wrote:

this is a suggestion by Urs from a user list thread on 2018-08-30: for
putting together scores of four-hand music with the typical primo
right page, secondo left page layout it would be useful to select
through a paper variable whether the music of a \book be typeset on
only odd or only even pages, with according page numbers and margins
(in case of twosided = ##t).


Just to clarify, is this request strictly about page numbering and 
margins (something I believe LilyPond already supports albeit via 
manual* configuration), or does it also encompass the automatic 
synchronization between the primo and secondo parts at each page break 
(also something that requires manual** intervention to achieve at the 
moment)?


* Each part's margins can be customized uniquely to achieve the 
desired mirroring, and the page numbering needs only a little 
arithmetic to show up as odd-only or even-only.


** Providing things do not align by chance, adding explicit \pageBreak 
commands would ensure that page turns happen at the same moment. 


This is not about automatic synchronization. That’s of course a far 
longer shot, and there’s already an issue for it (don’t want to search 
it right now).
If adding a simple switch for odd-only/even-only is only syntactic sugar 
of sorts for functionality that with some effort is already available, 
that’s all the better, then this is only about designing the interface.


Best, Simon

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

Feature request: paper variable for odd-only or even-only pagination

[Simon Albrecht]

Hello everybody,

this is a suggestion by Urs from a user list thread on 2018-08-30: for 
putting together scores of four-hand music with the typical primo right 
page, secondo left page layout it would be useful to select through a 
paper variable whether the music of a \book be typeset on only odd or 
only even pages, with according page numbers and margins (in case of 
twosided = ##t).


Best, Simon


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

Re: Almost-synchronous accidental makes the first one collide

[Simon Albrecht]

It appears like issues 472 and 1152 might have touched a similar part of 
the code.


<https://sourceforge.net/p/testlilyissues/issues/472/>
<https://sourceforge.net/p/testlilyissues/issues/1152/>

Best, Simon


On 10.09.2018 18:10, Simon Albrecht wrote:

Hello,

have a look at this:

\fixed c'' <<
  \time 2/4
  { a8*2/3 c' b c' a f  a c' b c' a fis }
  \repeat unfold 2 { d4. e16 fis }
>>

Output attached.

Best, Simon



___
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

Almost-synchronous accidental makes the first one collide

[Simon Albrecht]

Hello,

have a look at this:

\fixed c'' <<
  \time 2/4
  { a8*2/3 c' b c' a f  a c' b c' a fis }
  \repeat unfold 2 { d4. e16 fis }
>>

Output attached.

Best, Simon

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

Re: X-aligning problems with chords containing unisons

[Simon Albrecht]

Thanks for reporting, this has been added as 
.


Best, Simon


On 02.09.2018 12:13, Torsten Hämmerle wrote:

Hi all,

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

Technically, the "correct" side of the stem is determined by the first note
in the chord, i.e. the note opposite the stem's direction.

If this extremal note happens to have a unison sibling, LilyPond currently
will pick the wrong notehead in some cases (stem up), thus causing a wrong
positioning of articulations, dynamics, slurs, …  The spacing will be
widened up a bit, too, as a chord-building side-effect.



The misplaced grobs are coloured in red and below, there's my proposed
solution for correct positioning.

That's a nice little bug for the issue tracker, isn't it?

Thanks,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
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: modern-straight and flat- flags too thick and too spaced apart

[Simon Albrecht]

Thanks, this has been entered as 
.


Best, Simon


On 27.08.2018 01:08, edes wrote:

Hello, list.

For some reason, when using modern-straight-flag or flat-flag, flags are
much thicker than normal beams, and the distance is also much bigger.

Straight and flat flags were widely used by modern composers like Pierre
Boulez and Karlheinz Stockhausen, and in all cases flags were treated like
beams, with the same distance and the same width.

Please see the attached examples and images (I'm using 2.12.0 from git).

BTW, the first flag does not align with the end of the stem.

Best,

e.

8< ---

\version "2.21.0"

\layout {
   \context {
 \Score
   \override Flag.stencil = #flat-flag
   }
}

\relative c' {
<<
   {
 r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
   \\
   { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
}

8< ---

\version "2.21.0"

\layout {
   \context {
 \Score
   \override Flag.stencil = #modern-straight-flag
   }
}

\relative c' {
<<
   {
 r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
   \\
   { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
}

8< ---



--


___
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: whiteout shouldn’t affect other grobs on same layer

[Simon Albrecht]

Thanks Malte, I opened 
https://sourceforge.net/p/testlilyissues/issues/5411/ as an enhancement 
request.


Best, Simon


On 26.08.2018 16:49, Malte Meyn wrote:

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



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

Re: Two issue with Measure_grouping_engraver

[Simon Albrecht]

On 07.08.2018 13:08, Thomas Morley wrote:

MeasureGrouping also relies on the actual music rhythmically matching
the beatStructure.

\new Staff \with { \consists "Measure_grouping_engraver" }
{
   \time 4/8
   a'2
}
Will print only one bracket.


That doesn’t seem helpful, does it? IIUC, Measure_grouping_engraver is 
supposed to show the properties of the meter regardless of notes, so 
that a conductor will have a visual aid in cases like


{
  \time 4/8
  a'2
  \time 5/8
  4.~ 4
  \time 6/8
  2.
  \time 3/4
  2.
}

Best, Simon

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

Re: http://lilypond.org/productions.html

[Simon Albrecht]

On 31.07.2018 13:07, Rafael Fontenelle wrote:

1-  In this page there is the following snippet of paragraph:

"He has also worked on the score and parts for an arrangement of
Moussurgsky’s Boris Godounov for wind quartet"

On the other side, a few paragraphs below we find:

"Mussorgsky’s Pictures at an exhibition[...]"

Searching the web, I found "Mussorgsky" and "Godunov" (without 'o'
from 'ou') in pages like e.g. Wikipedia[1], but found no occurrence
"Moussurgsky" and "Godounov". So, just checking: is the spelling
correct?

[1]https://en.wikipedia.org/wiki/Modest_Mussorgsky


Cyrillic transliteration is always subject to discussion. The versions 
with ‘ou’ hint French transliteration, traditional English 
transliteration is always ‘Mussorgsky’ and ‘Godunov’, the former is 
scientifically transliterated as ‘Musorgskiy’ or ‘Musorgskij’. The only 
thing that’s completely uncontroversial is that the second ‘u’ in 
‘Moussurgsky’ is a typo.
Like most of the time, Wikipedia follows a very well-established policy 
and it’s perfectly OK to follow them.


Best, Simon

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

Re: LigatureBracket extent

[Simon Albrecht]

On 18.07.2018 13:24, Torsten Hämmerle wrote:

Solution: It's the stem direction (even if the semibreves don't have stems).


Good catch: semibreves do have stems, only they are invisible (IIUC).
I’ve created .

Best, Simon

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

Re: Crash with simultaneous-duplicating music function and \once\offset

[Simon Albrecht]

On 18.07.2018 10:59, David Kastrup wrote:

basically one of the calls to \offset gets junked because of LilyPond
not being able to disentangle them (one could extend the code to handle
this case but it would still balk at more complex combinations).


Great! This is exactly what would be needed in my use case, since I 
wouldn’t have wanted the offset to be applied twice. ly:expect-warning 
exists.
I suppose the better solution would be for the makeOctaves function to 
filter out overrides and \offset calls from the duplicate of the music?


Best, Simon

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

LigatureBracket extent

[Simon Albrecht]

Hello everybody,

is it just me or is there no reason why these two should have different 
output?


\version "2.19.82"
<<
  \new Staff {
    \override NoteColumn.horizontal-shift = 1
    \override LigatureBracket.direction = #DOWN
    \[ c'1 d' \]
  }
  \new Staff {
    \voiceTwo
    \[ c'1 d' \]
  }
>>

Best, Simon

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

Re: Crash with simultaneous-duplicating music function and \once\offset

[Simon Albrecht]

On 17.07.2018 20:46, David Kastrup wrote:

I got
Tracker issue: 5386 (https://sourceforge.net/p/testlilyissues/issues/5386/)
Rietveld issue: 367760043 (https://codereview.appspot.com/367760043)
Issue description:
   Make grob-transform robust against cloned invocations  Well,
   "robust" is a bit of an exaggeration but at least it doesn't crash
   anymore.  It just drops transforms (and warns about that) until the
   rest can be handled safely.   Also contains commit:  Add ly:grob-
   warning function

for this one.


Thanks for working on it!
Best, Simon

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

Crash with simultaneous-duplicating music function and \once\offset

[Simon Albrecht]

Hello everybody,

this combination of a custom music function that combines the music 
simultaneously with itself and a \once\offset command causes LilyPond to 
crash (exit with return code 11):



\version "2.19.82"
test =
#(define-music-function (parser location mus) (ly:music?)
  #{ << $mus $mus >> #})

\test { \once\offset length 1 Stem 4 }


Best, Simon


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

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

[Simon Albrecht]

On 15.07.2018 16:48, David Kastrup wrote:

What?  Being able to specify two conflicting \layout definitions at once
and having LilyPond magically merge them by guessing correctly how the
user wants every conflict to be resolved?

Magic is always a great thing to wish for.  Until it does stuff you
actually did not intend it to do.


That’s not what the request was about. Lily already merges subsequent 
toplevel layout definitions, IIUC simply following the order at which 
they are encountered, and why shouldn’t the same be possible inside one 
layout block?


This works just as expected:


\version "2.19.82"

\score {
  { c'8 }
  \layout {
    \context {
  \Voice
  \override NoteHead.color = #red
    }
    \context {
  \Voice
  \omit Flag
  \override NoteHead.color = #green
    }
  }
}


and IIUC the request asks for this


\version "2.19.82"

redhead = \layout {
  \context {
    \Voice
    \override NoteHead.color = #red
  }
}
greenhead = \layout {
  \context {
    \Voice
    \omit Flag
    \override NoteHead.color = #green
  }
}
\score {
  { c'8 }
  \layout {
    \redhead
    \greenhead
  }
}


to be treated exactly the same instead of discarding \greenhead.
Of course, I don’t have sufficient understanding to judge whether Lily 
has trouble discerning the order if it’s stored in variables.


Best, Simon

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

Re: End-of-line-Slur shortend by clef in other staff

[Simon Albrecht]

This should be the same as 
.


Best, Simon


On 25.06.2018 09:22, Wendl, Arnold wrote:

very ugly

Hello,

The end of line occurrence of a broken slur is shortened,
if another staff contains a clef change at that line break.

Example shows this in version 2.18.2, version 2.19.81, and also 2.15.41 (and 
newer).
It did work correctly in version 2.15.39 (and more early versions).

\score {
   <<
 \new Staff {
   \repeat unfold 6 c''8 c''8( d''
   e''1)
 }
 \new Staff {
   e'1
   \break
   \clef bass
   c1
 }
   >>
   \layout {
 % reduce line length for a more obvious display
 indent = 0
 line-width = 50
   }
}

Arnold (from the German user forum)

___
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: Should I remain on the list?

[Simon Albrecht]

On 22.06.2018 14:35, David Kastrup wrote:

Palmer Ralph  writes:


Hi -

Thanks to all of you for all your hard work.

In the rush up to leaving on a 2-month road trip that began March 29,
I neglected to let anyone on the bug list know that I would be out of
touch and unable to review the new bug requests while I was gone.
After I returned, I was busy with settling back in, then entertaining
house guests. It has looked for awhile like the list doing quite well
without my interference.

Not my impression.  Quite a few reports lying dormant for days and I am
not sure that all of them eventually got swept up again.  "quite well"
is not my impression, more like "astonishing how much the usual suspects
manage not to let drop through the floor after all".


Would I be missed if I resigned from the Bug Squad?

My impression is that you _have_ been missed but I cannot really speak
for those who have been tasked with picking up the slack.  And of course
you being missed cannot be converted into an obligation for you to pick
up again what amounted to doing more than a single's person share of Bug
Squad work.


I have to plead guilty here of being altogether oblivious of the 
schedule and just doing the work when I happened to be free at the time 
I saw a bug report. Which independently of what circumstances in my life 
cause it is of course not helpful for the stability of the process and 
for our project. Sorry for that.

So I have to second David’s thoughts here.

Best, Simon

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

Re: Notehead below Key signature

[Simon Albrecht]

Ouch, very ugly indeed.

Thanks for reporting – added as 
.


Best, Simon


On 21.06.2018 15:27, Wendl, Arnold wrote:

very ugly

Hello,

in some situations (e.g. a StaffGroup without key signature above a staff with 
key signature) the notehead is placed too far left, below the key signature.

Example (both 2.18.2 and 2.19.81):

\score {
   <<
 \new StaffGroup <<
   \new Staff \with { instrumentName = "Horn I in E" } {
 e'1 \break e' \bar "|."
   }
   \new Staff \with { instrumentName = "Horn II in E" } {
 g1 \break c' \bar "|."
   }
 >>
 \new Staff \with { instrumentName = "Bass clarinet in B♭" } {
   \key fis \major
   fis1 \break cis1 \bar "|."
 }
   >>
   \layout { indent = 50 \mm }
}

Arnold (from the German user forum)

___
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: Accidental Placement and Tie

[Simon Albrecht]

On 14.05.2018 16:07, foxfanfare wrote:

Simon Albrecht-2 wrote

Of course it is, but that’s beside the point. Lily has to properly omit
the accidental by herself.
Best, Simon

I didn't know Lily was a she? :D


Legend has it that the name was inspired by a girl crush of one of the 
LilyPond founders, so somewhat jokingly we continue to write ‘she’  ;-)


Best, Simon

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

Re: Accidental Placement and Tie

[Simon Albrecht]

On 14.05.2018 14:38, foxfanfare wrote:

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


It’s very easy to find in the manuals. I searched for ‘lilypond 
accidentalstyle’ on the web and the first result is this page:


Now you hit the node for ‘Automatic accidentals’ and there you are.

Best, Simon

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

Re: Accidental Placement and Tie

[Simon Albrecht]

Please don’t move communication off-list in general.


On 14.05.2018 13:04, Étienne PERRINE wrote:

With "\omit Accidental", it's better :


Of course it is, but that’s beside the point. Lily has to properly omit 
the accidental by herself.

Best, Simon


\version "2.19.80"

\relative c'' {
   \key c \minor
   \override Staff.TextScript.self-alignment-X = #0
   << { b1 c-"OK" \bar "||"
b b-"OK" \bar "||"
b ~ \omit Accidental b-"BETTER" \bar "|." } \\
  { s <gis, e'>
s 
s  } >>
}

-Message d'origine-----
De : bug-lilypond
[mailto:bug-lilypond-bounces+etienneperrine=yahoo...@gnu.org] De la part de
Simon Albrecht
Envoyé : lundi 14 mai 2018 12:52
À : foxfanfare; bug-lilypond@gnu.org
Objet : Re: Accidental Placement and Tie

On 14.05.2018 12:31, foxfanfare wrote:

Hi everyone,

This seems like a bug to me, no?

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

Best, Simon


\version "2.19.81"

\relative c'' {
\key c \minor
\override Staff.TextScript.self-alignment-X = #0
<< { b1 c-"OK" \bar "||"
 b b-"OK" \bar "||"
 b ~ b-"WRONG" \bar "|." } \\
   { s <gis, e'>
 s 
 s  } >>
}

When an accidental note has to be tied, LilyPond seems to hide the
accidental in the following note instead of omit it. Resulting is wrong
placement of the accidentals column order.

Accidentals.PNG
<http://lilypond.1069038.n5.nabble.com/file/t5604/Accidentals.PNG>



--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

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

Re: Accidental Placement and Tie

[Simon Albrecht]

On 14.05.2018 12:31, foxfanfare wrote:

Hi everyone,

This seems like a bug to me, no?


Yes, it does. Looks like 
.


Best, Simon



\version "2.19.81"

\relative c'' {
   \key c \minor
   \override Staff.TextScript.self-alignment-X = #0
   << { b1 c-"OK" \bar "||"
b b-"OK" \bar "||"
b ~ b-"WRONG" \bar "|." } \\
  { s 
s 
s  } >>
}

When an accidental note has to be tied, LilyPond seems to hide the
accidental in the following note instead of omit it. Resulting is wrong
placement of the accidentals column order.

Accidentals.PNG




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
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: 2.19.81 aborts on many .ly files when compiled with gcc8 -Wp, -D_GLIBCXX_ASSERTIONS

[Simon Albrecht]

On 09.05.2018 13:53, David Kastrup wrote:

Bug squad?  It might make sense to attach references to the reports in
the mailing list archives to this issue.

Done.
Best, Simon

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

Re: misplacement note head version 2.19

[Simon Albrecht]

Hi Eric,

thanks a lot for the report, that is a serious regression. I can confirm 
the issue and have added 
.


For future requests: Please include minimal working examples according 
to . In this case: a close-paren 
) was missing, and there is no need for more than one chord to 
demonstrate the bug. Also, code formatting could be improved – along 
with LilyPond’s own code base the Frescobaldi auto-formatting is the 
best guideline we currently have on that. Always surround { and } with 
spaces, and indent properly by two spaces per level.


Best, Simon


On 11.04.2018 20:28, Éric wrote:

Hello,
short exemple follow.
Using Lilybin version 2.18.2 doesn't create the problem.
The problem seems to occur only with staff-size set to 19, no other sizes.

\score{
{ 2 q4  }
  \layout { #(layout-set-staff-size 19 }
}

\score{
{ 2 q4  }
   \layout { #(layout-set-staff-size 18) }
}


all my best
Éric




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
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: Long compile times with many empty bars

[Simon Albrecht]

On 07.04.2018 13:42, Andrew Bernard wrote:

given that when there are
non-empty objects present it does not appear to arise. is it simply an
'academic' corner case of purely theoretical interest?


It happens in intermediary stages of work. I stumbled upon the problem 
when I started engraving a new piece by setting up this:


global = {
  \time 3/8
  \key f \major
  s4.*438
  \bar "||"
  \time 2/2
  \set Timing.currentBarNumber = 1
  s1*170
  \bar "|."
}

and then combining it with the first couple bars of music, to be 
surprised by the extraordinarily long compile time.
So I don’t think it’s a contrived example, and since I do think this is 
a useful workflow, it would certainly help to make LilyPond compile this 
faster.


Best, Simon
PS. Bonus points for guessing the piece ;-)

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

Long compile times with many empty bars

[Simon Albrecht]

Hello everybody,

I was a bit surprised that this snippet took so long to compile, and the 
time increases somewhat exponentially with the number of bars:


%
\version "2.19.80"
{
  \time 3/8
  s4.*500
}
%

The compile times on my machine were:
for 100 bars: 1.5"
  *200:   10.0"
  *300:   40.9"
  *400: 1'49"
  *500: 2'50"

Does that maybe warrant raising an issue?

Best, Simon


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

Re: Redundancy in the LM regarding \omit and \hide

[Simon Albrecht]

<https://sourceforge.net/p/testlilyissues/issues/5285/>

Best, Simon


On 01.03.2018 17:15, Simon Albrecht wrote:

Hello,

the Learning Manual explains about controlling the visibility of 
objects, including the differences between \omit and \hide (and the 
underlying overrides), in section 4.3.1. Section 4.7.1.ii ‘Simulating 
a fermata in MIDI’ 
<http://lilypond.org/doc/v2.19/Documentation/learning/other-uses-for-tweaks#simulating-a-fermata-in-midi> 
then repeats some of this explanation.


I’ll register an issue when sourceforge is back up.

Best, Simon


___
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

Redundancy in the LM regarding \omit and \hide

[Simon Albrecht]

Hello,

the Learning Manual explains about controlling the visibility of 
objects, including the differences between \omit and \hide (and the 
underlying overrides), in section 4.3.1. Section 4.7.1.ii ‘Simulating a 
fermata in MIDI’ 
 
then repeats some of this explanation.


I’ll register an issue when sourceforge is back up.

Best, Simon


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

Re: tuplet and tie

[Simon Albrecht]

On 22.02.2018 19:37, Jean-Marie Mouchel wrote:

\times 2/3


This command has been replaced by
\tuplet 3/2
a long time ago and is now deprecated.

Best, Simon

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

Re: Bug report: U+3000 IDEOGRAPHIC SPACE isn't treated as whitespace

[Simon Albrecht]

On 15.02.2018 21:09, Marnen Laibow-Koser wrote:

David Kastrup wrote:

\lyricmode does not mean "Paste arbitrary text here".

How is this relevant to anything I wrote?


It means that lyricmode entry has a syntax governed by specific rules, 
like that a_e is treated like "a e", or that –– creates a HyphenEvent. 
And another of those rules is that syllables must be delimited by ASCII 
whitespace.



LilyPond intentionally uses exclusively the ASCII character range for syntactic 
purposes.

...except it doesn't, as stated.


Nobody understands LilyPond syntax and parser issues better than David K.


Everything else can be part of identifiers or
words.


Any character can be part of a word, including {, }, \, space, and all the
rest.  That's why we have quoting constructs: "this is a syllable with { }
in it".


David was speaking of ‘words’ in the sense of LilyPond’s grammar.

Best, Simon

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

Re: MetronomeMark.break-align-symbols not heeded in custom context

[Simon Albrecht]

On 14.02.2018 17:17, Kieren MacMillan wrote:

\consists "Time_signature_engraver"
 \omit TimeSignature


Of course. Sorry for going to the bug list too soon.

Best, Simon

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

MetronomeMark.break-align-symbols not heeded in custom context

[Simon Albrecht]

Hi Peter, hello bug-list,

I distilled the example some more:

%
\version "2.19.80"

\layout {
  \context {
    \name "MarkLine"
    \type "Engraver_group"
    \consists Output_property_engraver
    \consists Axis_group_engraver
    \consists Metronome_mark_engraver
    \override MetronomeMark.break-align-symbols = #'(time-signature)
    \override VerticalAxisGroup.staff-staff-spacing =
    #'((basic-distance . 0)
   (minimum-distance . 0)
   (padding . 1)
   (stretchability . 3))
    \override MetronomeMark.font-shape = #'italic
  }
  \context {
    \Score
    \accepts MarkLine
    %\override MetronomeMark.break-align-symbols = #'()
  }
}

global = \tempo "Largo"

<<
  \new MarkLine \global
  \new Staff << \global { 1 } >>
>>
%
(output attached)

The tempo mark in MarkLine behaves like one in Staff with no 
break-align-symbols (uncomment the override to test). I think they 
should both be aligned to the time signature.
As a perhaps unrelated side note: With that override uncommented, the 
vertical order of the marks is flipped.


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

Re: Special characters in filenames using "\lilypondfile" in lilypond-book

[Simon Albrecht]

On 13.02.2018 14:36, André Rohrbach wrote:

Just tried to use special characters (mostly spaces and single quotes)
in filenames while working with \lilypondfile.


I’m pretty sure this is an issue with LaTeX syntax, not with LilyPond.
Also, it’s good advice anyway to not use spaces in file names, in case 
you’ll share them with different file systems.


Best, Simon

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

Re: Bug?? ChoirStaff including a tablature

[Simon Albrecht]

On 22.01.2018 18:29, David Kastrup wrote:

Well, uhm.  Sounds like accepting TabStaff by default might be sensible
to do?


Why would anyone need a TabStaff within a ChoirStaff? That doesn’t make 
sense and I’m sure the TabStaff should be above or below the ChoirStaff, 
or if in an exceptional score one had to put a tabulature instrument 
between choir groups for whatever reason, one should use two 
ChoirStaffs, one above and one below.


Best, Simon

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

Re: Staff spacing behaviour changed in 2.19

[Simon Albrecht]

Hi Paul,

truly a bad regression. Registered as 
.


Thanks for reporting,
Simon


On 17.01.2018 14:52, Paul Hodges wrote:

In the example on the documentation page

http://lilypond.org/doc/v2.19/Documentation/learning/building-a-score-from-scratch
the command
\override VerticalAxisGroup.staff-staff-spacing.stretchability = 5
is used to modify the spacing of the pedal staff in an organ score.


The result shown on the documentation page (which I also get at home
with 2.19.80) does not match the result on the corresponding page for
2.18, and is clearly wrong.


I cannot find any documentation suggesting that the usage should have
changed.


Regards,
Paul




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

Re: Grammar rules in Contributor Guide summary are fragmented

[Simon Albrecht]

On 13.01.2018 22:04, Robin Bannister wrote:
Getting up to a reasonable speed with that CG stuff looks to me like a 
steeper learning curve than for LilyPond itself.  But I won't get 
involved with that until the Google prerequisite no longer applies.


It isn’t complicated at all, and you just need a Google account for the 
rietveld code review tool – no gmail address needed, you can even use a 
throwaway e-mail address for signing up.

Basically, all you need to do is:
– set up a sourceforge account and request write access to the issue tracker
– commit your changes locally
– upload to Rietveld using git-cl 

– create a sf issue with Status:Started, yourself as owner and a link to 
the Rietveld review.


When review is finished, you can send your patch(es) in the final state 
to the devel list or directly to someone with push access to the 
LilyPond source.


I say this in the friendliest way possible, understanding your doubts: 
Come on, just do it ;-)


Best, Simon

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

Re: Grammar rules in Contributor Guide summary are fragmented

[Simon Albrecht]

Hi Robin,

it seems you are quite well-versed in this. It would be great if you 
could upload a patch for review yourself: the process is explained in 
the Contributor’s Guide; if you create a sourceforge account and send 
your username to the devel list, we can give you write access to the 
issue tracker as well.


Please let us know if you’d be willing to do this.

Best, Simon


On 07.01.2018 22:04, Robin Bannister wrote:

Hallo,


The Contributor Guide appendix 'LilyPond grammar' displays a summary 
(ly-grammar.txt) which is derived from a summary produced by bison.


In the first section a production rule has a label on the left which 
introduces the alternatives listed on the right. Or rather, _most_ 
rules are like that, but for a few of them the label occurs twice. So 
if you are looking for a rule and find it, you may overlook some of 
its alternatives.


This is OK by bison (and maybe a practised eye) but not by me.
So I propose a readability enhancement where there is only one label 
per rule and submit a revised yyout2grammar.py which caters for this.


While testing it I noticed and corrected several errors:
  - the elimination of @-items in the alternatives is inaccurate
  - in the second section, continuation lines pile up at the top
  - in the third section, more than 30 nonterminals are missing and
    @-rules are included

In the script, the production rule part is completely rewritten and the
rest is extensively refactored. See yyout2g_robin_A.py

I worked with bison-2.4.1 (GnuWin32) and obtained parser.yy and 
yyout2grammar.py from git a few days ago, i.e post 2.19.80.

The following summaries are generated from that snapshot:
  - before: ly-grammar.txt
  - after:  ly-g_robin_A.txt


  Cheers,
  Robin



___
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: Segfault with midi and \new StaffGroup

[Simon Albrecht]

Hello again,

this is now <https://sourceforge.net/p/testlilyissues/issues/5234/>.

Best, Simon


On 07.11.2017 23:49, Simon Albrecht wrote:

Hello everybody,

this code generates a segfault using 2.19.80 (Ubuntu 16.04, 64-bit):

\version "2.19.80"
\score {
  \new StaffGroup {}
  \midi {}
}

$ lilypond debug.ly
GNU LilyPond 2.19.80
Processing `debug.ly'
Parsing...
Interpreting music...
warning: no music found in score
MIDI output to `debug.midi'...Segmentation fault (core dumped)

.ly source and MIDI ‘output’ attached.

Best, Simon



___
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

Segfault with midi and \new StaffGroup

[Simon Albrecht]

Hello everybody,

this code generates a segfault using 2.19.80 (Ubuntu 16.04, 64-bit):

\version "2.19.80"
\score {
  \new StaffGroup {}
  \midi {}
}

$ lilypond debug.ly
GNU LilyPond 2.19.80
Processing `debug.ly'
Parsing...
Interpreting music...
warning: no music found in score
MIDI output to `debug.midi'...Segmentation fault (core dumped)

.ly source and MIDI ‘output’ attached.

Best, Simon

\version "2.19.80"

\score {
  \new StaffGroup {}
  \midi {}
}


debug.midi
Description: MIDI audio
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: tabs with lyrics

[Simon Albrecht]

On 03.10.2017 16:27, bb wrote:

One more silly question, tabs with lyrics.

I did not find any help in the archives.

I tried it this way:

\version "2.19.2"


This does not, for several reasons, belong on the bug list.  When in 
doubt, ask on -user.


Best, Simon

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

Re: \lyricsto ruins sequential lyrics

[Simon Albrecht]

On 02.09.2017 23:11, Dan Eble wrote:

[copying the bug list this time—sorry]

David wrote:

Putting different lyrics in sequence to each other does not make a lot of sense,

Isn’t it fundamental to performing a multi-stanza song?


Different lyrics _contexts_ in sequence don’t make a lot of sense.


and a \lyricsto-governed context in
particular has no well-defined ending where another context could
follow.

OK, how would you classify that?  A bug?  A deficiency of the design?


A property of the design that will force you to find a solution without 
\lyricsto, as in many non-standard cases.


Best, Simon

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

Re: Default repeat type

[Simon Albrecht]

On 28.08.2017 01:58, Christopher Heckman wrote:

From: Dan Eble 
Subject: Default repeat type

It would be convenient if both of these did the same thing:

  A. \lyricmode { Ah __ \repeat unfold 7 _ }
  B. \lyricmode { Ah __ \repeat 7 _ }

Maybe the user should be able to set the default repeat type? After
all, someone typesetting sheet music might ask for the default to be
volta.

And/or a default type for each mode.


IIUC, Dan’s point was that in \lyricmode, almost all instances of 
\repeat are \repeat unfold.  I didn’t read it as concerning any other modes.


Sorry for repeating myself: For the sake of list subscribers and 
archiving, please keep your reply inside the correct thread – most mail 
programs automatically set the correct internal headers when simply 
replying to e-mail – only this is one of the best reasons for turning 
digest mode off.


Best, Simon

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

Re: Stem duration

[Simon Albrecht]

On 05.07.2017 15:33, David Kastrup wrote:

Interesting. Noteheads of different duration attached to a single stem?
I don't remember to have seen something like that, and google does not
really help. Which instrument uses such a notation, could you give an
example?

I've seen it in the solo partitas and sonatas for violin from Bach and
would assume that they are also to be found in the cello suites.


Both Bach and Mozart wrote this using more than one voice, even for non 
divisi violins. However, later centuries introduced the notation with 
different durations on one stem; this is commonly achieved in LilyPond 
by overriding duration-log on note-heads, not by actual duration.


Best, Simon

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

\hideNotes hides too many dots

[Simon Albrecht]

Hello,

this is an exemplary use case for \hideNotes:

%
\version "2.19.55"

\new Staff <<
  \new Voice {
\voiceOne
c''16 e''16~
\hideNotes
e''4.
  }
  \new Voice {
\voiceTwo
c''8~ \oneVoice 4.
  }
>>
%

However, \hideNotes also manages to hide the dot on the second e'', 
which I don’t quite know why, since it should be printed from the second 
voice.


Best, Simon

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

Re: NR 4.2.2, table column should be called "glyph name"?

[Simon Albrecht]

On 12.06.2017 12:06, Federico Bruni wrote:

Not in my opinion.  The font is feta11 (the font family is feta).  The
staff height is 11.22 pt.  The staff height is 3.9 mm.


Hi Carl, are you sure?
The context of my report was:

commit 18d03fa6a724b0102ccc47d194209802cea02f2e
Author: James Lowe
Date: Sun Mar 5 16:34:39 2017 +

   Doc - NR + CG: Clarify Emmentaler is the 'font' and Feta/Parmesan 
are glyphs


   Issue 4966

   Distinguish between Emmentaler
   the 'font' and Feta/Parmesan
   glyphs that make up the
   Emmentaler font family.


That is quite imprecise wording: Feta and Parmesan are subsets of the 
Emmentaler font, not individual glyphs.
Whether ‘font name’ in that NR table is also imprecise is a matter of 
little importance IMO – it’s the least confusing choice of words and I 
don’t see any need to change it.


Best, Simon

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

Re: midi2ly: Fraction Reduction + 2 minor issues

[Simon Albrecht]

Dear fellow Bug Squad members,

unfortunately I can’t access my sourceforge account right now. Could 
anyone please open tracker issues for this (I think three separate ones 
would be in order)?



Am 14.04.2017 um 02:18 schrieb Christopher Heckman:

(1) When midi2ly is run, it will print fractions with large numerators
and denominators,

[…]

I have written a patch to fix this.


[…]

Am 15.04.2017 um 12:10 schrieb Simon Albrecht:

Am 14.04.2017 um 02:18 schrieb Christopher Heckman:


(2) In line 181 of midi2ly.py, the authors talk about how the 7th of a
minor scale should be raised, but this is not notated. The real issue
is that there are two types of minor scale involved, the harmonic
minor (1 2 b3 4 5 b6 7) and the natural minor (1 2 b3 4 5 b6 b7). The
reason that "C# is not put in the key signature of D minor" is that
the minor scale is the natural minor, not the harmonic minor.


I’d rather say that all these musicotheoretical musings don’t belong 
there at all. Instead one could just say:

# induce correct spelling of 7th scale degree in minor keys




(3) At line 677, there's a cryptic comment

# urg, this will barf at meter changes


i.e. an enhancement request to fix this

Best, Simon

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

Re: midi2ly: Fraction Reduction + 2 minor issues

[Simon Albrecht]

Hi Chris,

we use to keep communication on-list apart from special cases where 
privacy is required.



Am 16.04.2017 um 10:45 schrieb Christopher Heckman:

On Sat, Apr 15, 2017 at 3:10 AM, Simon Albrecht <simon.albre...@mail.de> wrote:

Hi Chris,

thanks for your analyses and code.


Am 14.04.2017 um 02:18 schrieb Christopher Heckman:

(1) When midi2ly is run, it will print fractions with large numerators
and denominators

I have written a patch to fix this.


Could you provide this as a git-formatted patch, please?
(In case of doubt, see
<http://lilypond.org/doc/v2.19/Documentation/contributor/working-with-source-code>)

I tried to do it. I'm not 100% sure it was submitted; I haven't used
git or anything like it before.


Well, there’s basically two options for how to proceed. Both require 
that you clone the git repository, add and commit your changes. (All of 
that should be explained in the CG <Contributor’s Guide>, ‘Basic Git 
usage’ or so).

The first option is to then use
git format-patch HEAD
(or HEAD~1, HEAD~2… if you have made two or more commits)
and send the patch to the bug list, to be appended to a tracker issue.
(<http://lilypond.org/doc/v2.19/Documentation/contributor/patches>)

Somewhat preferable is uploading the patch for review on Rietveld, as is 
done for all LilyPond development work. (see 
<http://lilypond.org/doc/v2.19/Documentation/contributor/uploading-a-patch-for-review>)


If getting acquainted with Git is too much overhead for you for now, you 
could use the lily-git user interface intended exactly for that. (CG 2.2)



(3) At line 677, there's a cryptic comment

# urg, this will barf at meter changes

Is there a brief explanation of the problem available?

Well, apparently this particular code isn’t prepared to deal with meter
changes in the input. What exactly is unclear about that?

Best, Simon

First question: Is the exact problem known, or did midi2ly crash (or
whatever -- that's another question), and someone said, "Oops, better
not do that"? Or ... did someone recognize that the bug would occur,
and put this here instead of trying to fix it?


I haven’t been involved in coding this at all, but to me the comment 
sounds like the author saw this limitation but didn’t want to fix it 
right away.



Are there meter changes where midi2ly does not crash?


That would be up to the person tackling the limitation to figure out.


Has anyone tried to fix it?


Probably not. If there is not already a tracker issue at 
<https://sourceforge.net/p/testlilyissues/issues/>, definitely not.


We’d certainly welcome your contributions and fixes to these bugs!

Best, Simon

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

Re: midi2ly: Fraction Reduction + 2 minor issues

[Simon Albrecht]

Hi Chris,

thanks for your analyses and code.


Am 14.04.2017 um 02:18 schrieb Christopher Heckman:

(1) When midi2ly is run, it will print fractions with large numerators
and denominators

…

I have written a patch to fix this.


Could you provide this as a git-formatted patch, please?
(In case of doubt, see 
)



(2) In line 181 of midi2ly.py, the authors talk about how the 7th of a
minor scale should be raised, but this is not notated. The real issue
is that there are two types of minor scale involved, the harmonic
minor (1 2 b3 4 5 b6 7) and the natural minor (1 2 b3 4 5 b6 b7). The
reason that "C# is not put in the key signature of D minor" is that
the minor scale is the natural minor, not the harmonic minor.


I’d rather say that all these musicotheoretical musings don’t belong 
there at all. Instead one could just say:

# induce correct spelling of 7th scale degree in minor keys


(3) At line 677, there's a cryptic comment

# urg, this will barf at meter changes

Is there a brief explanation of the problem available?


Well, apparently this particular code isn’t prepared to deal with meter 
changes in the input. What exactly is unclear about that?


Best, Simon

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

Re: \alterBroken syntax

[Simon Albrecht]

Am 02.04.2017 um 01:26 schrieb David Kastrup:

Dan Eble  writes:

David wrote:

It would seem more sensible to change overrides to have
tweak syntax and forego the gratuitous equals sign.

That would be an improvement.

It would be sort of a drastic change.


Well, somewhere far down the TODO-list there’s still the GLISS… this 
seems like an idea for that.


Best, Simon

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

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 18:41 schrieb David Kastrup:

So I’d consider it
sensible to additionally allow_only_  numbers in the form \tempo 4 =
123.45…  (there should be no point in restricting the number of
‘post-point digits’) (sorry, I’m not familiar with English
mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.09997 or similar.  There is absolutely no
issue with letting LilyPond_accept_  non-integers.  But I don't see a
plan how it could or should then go about formatting them.


Sorry I can’t comment on techniques of implementation, but for user’s 
sake we should allow input like

\tempo 2 = 86.83
and have Lily output exactly that number, as it was input.

Adapting this to a ‘locale’ or ‘output language’ would be a different 
issue: ideally, if it is specified as german,

\tempo 4 = 92.01
would be printed with 92,01 as the number. But LilyPond doesn’t have 
such a feature anyway (cf. 
…), so that need 
not be considered right now, does it?


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

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 18:41 schrieb David Kastrup:

So I’d consider it
sensible to additionally allow_only_  numbers in the form \tempo 4 =
123.45…  (there should be no point in restricting the number of
‘post-point digits’) (sorry, I’m not familiar with English
mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.09997 or similar.  There is absolutely no
issue with letting LilyPond_accept_  non-integers.  But I don't see a
plan how it could or should then go about formatting them.


Sorry I can’t comment on techniques of implementation, but for user’s 
sake we should allow input like

\tempo 2 = 86.83
and have Lily output exactly that number, as it was input.

Adapting this to a ‘locale’ or ‘output language’ would be a different 
issue: ideally, if it is specified as german,

\tempo 4 = 92.01
would be printed with 92,01 as the number. But LilyPond doesn’t have 
such a feature anyway (cf. 
…), so that need 
not be considered right now, does it?

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

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 17:47 schrieb David Kastrup:

Urs Liska  writes:


As discussion onhttps://github.com/wbsoft/python-ly/pull/90  shows
floating point metronome numbers are surely something LilyPond should
provide.

\tempo 4 = 60.0
=> error: syntax error, unexpected REAL

So what do you expect to see here as the markup?  "♩ = 60.0" ?  And for
\tempo 4 = #190/7
what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ = 190/7"?

What for
\tempo 4 = #(/ 190.0 7) ?

I know how to format an integer.  But I have no way to guess what a
composer will want to see for some rational or floating-point number.

If LilyPond "should surely provide", the question is_what_  should it
provide?


I don’t think there is any reason to allow Scheme expressions or usecase 
for doing so. But in modern music it certainly occurs to have metronome 
marks with one or two (maybe more) digits behind the point. So I’d 
consider it sensible to additionally allow _only_ numbers in the form

\tempo 4 = 123.45…
(there should be no point in restricting the number of ‘post-point 
digits’) (sorry, I’m not familiar with English mathematical terminology)


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

Re: \alterBroken syntax

[Simon Albrecht]

Am 27.03.2017 um 23:32 schrieb Dan Eble:

This is the current syntax:

 \alterBroken property-name #’(before after) GrobName

This would be more consistent with other things:

 \alterBroken GrobName.property-name #’(before after)


\alterBroken in that respect is not to be compared with \override or 
\tweak, but with \shape or \offset.


Best, Simon

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

Re: setting font size affects previous breathe

[Simon Albrecht]

Am 28.02.2017 um 13:31 schrieb Maarten Hijzelendoorn:

Changing the font size after a breathe, also changes the size of the breathe
symbol, which is wrong (when things are processed linearly).


Things aren’t processed linearly. Rather, the \set command takes effect 
at the same _timestep_ at which the breathing-event happens, so it’s 
already taken into account independently of the order in the source 
code. If you want the breathing sign to have the previous font-size, you 
need to use \once\override BreathingSign.font-size = 6 (or similar).


Best, Simon

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

Re: Italic numbers for fingerings (feature request)

[Simon Albrecht]

On 16.02.2017 23:29, Urs Liska wrote:

the feature request would be to have built-in italics with
an italic shape that matches the upright numbers of Emmentaler (well,
any alternative notation font should actually be updated to that as
well, I think).


Agreed: 
:-)

Good night,
Simon

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

Re: Italic numbers for fingerings (feature request)

[Simon Albrecht]

On 16.02.2017 23:27, tisimst wrote:

On Thu, Feb 16, 2017 at 3:08 PM, Urs Liska wrote:


if I'm not mistaken (and a very recent post in the German forum
http://www.lilypondforum.de/index.php?topic=2465.0  seems to confirm
that) LilyPond doesn't have built-in support for italics in fingerings.

As using italics for fingerings is a regular use case (e.g. to
differentiate between editor's and composer's fingerings) I would like
to see native support for italics in fingerings.

So there would have to be a) glyphs for italics numbers in Emmentaler
and b) a way to choose between upright and italics for fingerings.


The default mechanism uses the 'fetaText encoding to get the numbers. If
you

\override Fingering.font-encoding = 'latin1

you should then be able to change the font to any normal text font and turn
on Italics.


I gave it a try, and using

\version "2.19.54"
{
  1-\tweak font-encoding #'latin1 \tweak font-name "Ubuntu" \tweak 
font-size 6 \tweak font-shape #'italic -3

}

I can get the correct font and font size, but not the correct font shape 
(nor series).


Don’t know why…

Best, Simon

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

Re: Error in printing ff

[Simon Albrecht]

Dear Friedrich,

thanks for reporting. It seems to be an issue with the ligature.

We absolutely require bug reports to be made using _minimal_ examples, 
see . Please create one.


Best, Simon


On 15.02.2017 22:07, Friedrich Kink wrote:

Dear Developers,

I noticed an issue which I consider a bug. I tried with latest lilypond
version  2.19.55.

The following lyrics 'un -- er -- schaff -- nen' prints 'un - er scha
nen' from a Latex file including  lilypond source with

\documentclass[a4paper, twocolumn, landscape, DIV=17]{scrreprt}%{article}
\usepackage[utf8]{inputenc}
\usepackage[a4paper,landscape,margin=15mm,columnsep=30mm]{geometry}
\usepackage{lettrine}
\usepackage[neveradjust]{paralist} % fuer liedertextlist
\usepackage{graphics,color}
\usepackage[german]{babel}
\usepackage[full]{textcomp}
\pagestyle{empty}
\begin{document}

\begin{compactenum}[\normalfont\sffamily\bfseries 1]
\item
\lilypondfile[line-width=112\mm,staffsize=15]{Gesangbuch\450.ly}
\end{compactenum}

whereas if the lyrics look like 'un -- er -- schaf -- nen' prints 'un -
er - schaf - nen' (note the missing double f). If needed below complete
lilypond source.

kind regards,
Fritz

\include "lilypond-book-preamble.ly"
\paper{
   indent=0\mm
%  line-width=120\mm
   oddFooterMarkup=##f
   oddHeaderMarkup=##f
%  bookTitleMarkup = ##f
%  scoreTitleMarkup = ##f
}
\version "2.19.55"
global = {
\key c \major
\time 2/2
}
\header{
   title = "Morgenglanz der Ewigkeit"
   composer = "Text: Christian Knorr von Rosenroth"
   poet = "Melodie: Johann Rudolf Ahle 1662"
}

melodie = \relative c' {
 \global
 %\tempo 2 = 1
 \override Staff.TimeSignature.style = #'mensural
 \override Score.PaperColumn.keep-inside-line = ##t
 \override Score.LyricText.font-shape = #'italic
 \set midiInstrument = #"church organ"
 \repeat volta 2 {\partial 4*2 e4 c g' a f4. e8 e2 \breathe c'4 b
a b c b8 c a4.( g8) g2 }
 \partial 4*2 g4 g a g f e8 d d2 \breathe e4 d c2 \bar "|."
}

texta =\lyricmode { Mor -- gen -- glanz der E -- wig -- keit, Licht
vom un -- er -- schaff -- nen _ Lich -- te, }
textb =\lyricmode { schick uns die -- se Mor -- gen -- zeit dei --
ne Strah -- len zu Ge -- _ sich -- te}
textc =\lyricmode { und ver -- treib durch dei -- ne _ Macht uns --
re Nacht. }

\score {
 \new Staff <<
   \new Voice = m \melodie
   \new Lyrics \lyricsto m { \texta }
   \new Lyrics \lyricsto m { \textb \textc }
 >>
 \layout {
   \context {
 \Lyrics
   \consists "Bar_engraver"
   %\consists "Separating_line_group_engraver"
   \override BarLine.transparent = ##t
   }
 }
 \midi {
   \context {
   \Staff
   \remove "Staff_performer"
   }
 \context {
   \Voice
   \consists "Staff_performer"
 }
 \tempo 4. = 90
 }
}

  



___
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: Non-music variables seem not to work in Lilypond 2.19.54-1

[Simon Albrecht]

On 05.02.2017 09:45, Tom Campbell wrote:

I'm not top posting

% Lilypad version required for non-music variables
\version "2.19.54"


% I believe one should now be able to create non-music variables, at least
according to:
%
http://lilypond.org/doc/v2.19/Documentation/learning/organizing-pieces-with-variables
% I am attempting to create style sheet-like thingies for book publishing.
% This gives the error "Ignoring non-music expression" in Lilypond 2.19.54-1


More importantly, before that it gives the error ‘unknown escaped 
string: `\fontsize'’.
That’s because \fontsize is a markup command and you are using it in a 
music expression.

Please refer to  for help on your use case.

Best, Simon

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

Re: Bug

[Simon Albrecht]

On 01.02.2017 18:08, Mike Solomon wrote:

Yeah, just checked it out, you can remove the spurious if (brain fart).
I don’t have time to propose a patch today but I can do that on Monday if no 
one else can get around to it (I haven’t set up git-cl yet on this machine).
Alternatively, I can just push the change to master if people are OK with that.


Shouldn’t at least the normal patch testing be done?
Best, Simon

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

Re: Vertical spacing titles and highest staff in LilyPond version 2.18.2.

[Simon Albrecht]

No reply, see previous feedback to your posts.


On 22.12.2016 19:33, Mirosław Doroszewski wrote:

Vertical spacing titles and highest staff in LilyPond version 2.18.2.

1. When some files are included to main file, not within \book block
but just added with \include command outside any block, there is put
too much vertical space between titles and "piece" title.
2. I tried in a template of main file and added files to one: override
bookTitleMarkup and scoreTitleMarkup but with improper effect: titles
disapeared except "piece" title.
3. I tried in default "titling-init.ly" remove "hspace #1" in
scoreTitleMarkup, but without permission of operating system
(windows).

___
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: Word hyphenation in LilyPond version 2.18.2.

[Simon Albrecht]

On 22.12.2016 19:32, Mirosław Doroszewski wrote:

lilypond does not do word hyphenation in \marklist. It implies
that the software cannot public long and small song books with meny
pieces.


That is true. Your message would be received more favourably if you said 
something like


‘It would be great if LilyPond offered a possibility to auto-hyphenate 
text in markup. There doesn’t seem to be an issue in the tracker yet.’


It’s a known issue that this is not possible to do in LilyPond, which is 
why (almost?) everybody to typeset such large projects with LilyPond has 
used LilyPond only for the music itself and embedded the output in *TeX 
or other word-processing/publishing software.
Since we indeed don’t seem to have this feature request listed, I 
created a tracker: 


Best, Simon

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

Re: Slurs and ties — most difficult to make: developer has to think about them before his work.

[Simon Albrecht]

Hi Miroslaw,

again: this is not a very good bug report as described on our website: 
. Please be specific, report one 
well-defined problem and not a major rant of seven items. As Thomas 
already said – code examples are quasi-mandatory, except for very 
special cases.


On 21.12.2016 00:24, Mirosław Doroszewski wrote:

4. Why the image from main web site of LilyPond has correct shaping
ties after breaking in two systems and my work accordingly to manuals
creats ugly shaping of slurs and ties?


LilyPond’s automatic formatting is very good, but it doesn’t work 
equally well in every possible case. For that, tweaks are available, 
like \shape. (You’ll find that in the manuals.)



5. When developer thinks to make project of music notation software,
he has to decide, what interface will be using by future software.


I can assure you that a lot of thought has gone into the development of 
LilyPond… and some really good thought, as well, I daresay.



  He
has to be sure that his future software will do with beautiful slurs
and ties.


I don’t think LilyPond needs to hide from its competition, even in that 
respect.



6. I think that LilyPond is not "music notation for everyone" but only
for specialists.


Well, if you don’t like it, nobody forces you to keep with it…

Best, Simon

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