Re: Documentation error in PDF files

[James Lowe]

Hello Peter,

On Sat, 17 Feb 2018 10:26:05 +, Peter Toye  wrote:

> The indexes in the PDF versions of the learning and notation manuals (and 
> maybe others) do not have the alphabetical "jump to" headers, which makes 
> scrolling a pain. They're in the HTML versions, so I can only assume this is 
> a bug in the translation from the info format.
> 
>  
> Best regards,
> 
> Peter


Thank you I have created

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

Regards

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

Re: Why is an explicit footnote mark not printed in the footnote?

[James Lowe]

Urs,

On Tue, 19 Jun 2018 08:27:05 +0200, Urs Liska  wrote:

> As per NR 3.2.4 it is possible to specify an explicit footnote mark as 
> opposed to the automatic number. However, in this case the mark is *not* 
> repeated in the footnote itself. The examples in the section show that 
> this is not a bug but known behaviour:
> 
> \footnote "*" #'(0.5 . -2) \markup { \italic "* The first note" } a'4
> 
> But I'd like to ask if there's a reasoning behind that. I can't think of 
> a case where you'd not want to have matching marks in the annotation and 
> the footnote. Wouldn't it be better to have that automatically, like 
> with automatic numbers?
> 
> Urs
> 

You already know my development skills (i.e non-existant) but I recall that 
Mike Solomon did a lot of work with the footnote code and I had to go back and 
forth with him to doc it 'properly'. You may find something in his code or his 
past dev emails

E.g

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=181366ec566a338c265ff4960724202d0d55ef79

Regards

James


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

Re: Two issue with Measure_grouping_engraver

[James Lowe]

Hello


On 03/08/18 13:32, Thomas Morley wrote:

Hi,

while playing with the Measure_grouping_engraver
see:
http://lilypond.1069038.n5.nabble.com/changing-symbols-used-by-Measure-grouping-engraver-td215283.html
I noticed two things which may qualify as bugs.

(1) A documentation issue

I tried to get MeasureGrouping in default 4/4-time, but nothing happened.
One has to set beatStructure and baseMoment accordingly. The current
docs make it sound it should work out of the box, though.

\version "2.19.82"

\new Staff \with { \consists "Measure_grouping_engraver" }
   {
   %% to get MeasureGrouping, next two lines need to be uncommented
 %\set Timing.beatStructure = 4,4
 %\set Score.baseMoment = #(ly:make-moment 1/8)
 \repeat unfold 8 a'8
   }


Is this just a documentation issue though?

*should* it work out of the box (to use your phrase) and so 
documentation is correct and the bug is in the code?


We don't document bugs after all.

James

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

Re: Two issue with Measure_grouping_engraver

[James Lowe]

Harm,


On 03/08/18 16:03, Thomas Morley wrote:

2018-08-03 16:51 GMT+02:00 James Lowe :

Hello


On 03/08/18 13:32, Thomas Morley wrote:

Hi,

while playing with the Measure_grouping_engraver
see:

http://lilypond.1069038.n5.nabble.com/changing-symbols-used-by-Measure-grouping-engraver-td215283.html
I noticed two things which may qualify as bugs.

(1) A documentation issue

I tried to get MeasureGrouping in default 4/4-time, but nothing happened.
One has to set beatStructure and baseMoment accordingly. The current
docs make it sound it should work out of the box, though.

\version "2.19.82"

\new Staff \with { \consists "Measure_grouping_engraver" }
{
%% to get MeasureGrouping, next two lines need to be uncommented
  %\set Timing.beatStructure = 4,4
  %\set Score.baseMoment = #(ly:make-moment 1/8)
  \repeat unfold 8 a'8
}


Is this just a documentation issue though?

*should* it work out of the box (to use your phrase) and so documentation is
correct and the bug is in the code?

We don't document bugs after all.

James

Hi James,

this is not a bug in the code, afaik.

But the functionality of MeasureGrouping relies on appropriate
settings for beatStructure and baseMoment.
This should be documented, that's all.


In my example the default settings for 4/4-time prevent any output
from Measure_grouping_engraver.
The user should be told about the need to adjust those settings in
certain cases.

The IR states Measure_grouping_engraver is reading following context-properties:
   baseMoment (moment)
   beatStructure (list)
   currentMusicalColumn (graphical (layout) object)
   measurePosition (moment)

Imho, we should explain in the NR how to use them for MeasureGrouping.

Cheers,
   Harm


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

for the doc issue.

James

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

Re: Two issue with Measure_grouping_engraver

[James Lowe]

On 03/08/18 13:32, Thomas Morley wrote:

while playing with the Measure_grouping_engraver
see:
http://lilypond.1069038.n5.nabble.com/changing-symbols-used-by-Measure-grouping-engraver-td215283.html
I noticed ...




(2) ugly behaviour at line-break, if other items occur

With

\version "2.19.82"

musII = {
   \time 9/8
   \repeat unfold 33 a'8
   a'4.
}

\new Staff \with { \consists "Measure_grouping_engraver" }
   { \musII \break \musII }

the last NoteColumn of the first line is moved to the left, so the gap
between the NoteColumn and the BarLine is far too small.

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

For the ugly output.

James

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

Re: Two issue with Measure_grouping_engraver

[James Lowe]

Hello,


On 05/08/18 08:38, James Lowe wrote:

Harm,


On 03/08/18 16:03, Thomas Morley wrote:

2018-08-03 16:51 GMT+02:00 James Lowe :

Hello


On 03/08/18 13:32, Thomas Morley wrote:

Hi,

while playing with the Measure_grouping_engraver
see:

http://lilypond.1069038.n5.nabble.com/changing-symbols-used-by-Measure-grouping-engraver-td215283.html 


I noticed two things which may qualify as bugs.

(1) A documentation issue

I tried to get MeasureGrouping in default 4/4-time, but nothing 
happened.

One has to set beatStructure and baseMoment accordingly. The current
docs make it sound it should work out of the box, though.

\version "2.19.82"

\new Staff \with { \consists "Measure_grouping_engraver" }
    {
    %% to get MeasureGrouping, next two lines need to be 
uncommented

  %\set Timing.beatStructure = 4,4
  %\set Score.baseMoment = #(ly:make-moment 1/8)
  \repeat unfold 8 a'8
    }


Is this just a documentation issue though?

*should* it work out of the box (to use your phrase) and so 
documentation is

correct and the bug is in the code?

We don't document bugs after all.

James

Hi James,

this is not a bug in the code, afaik.

But the functionality of MeasureGrouping relies on appropriate
settings for beatStructure and baseMoment.
This should be documented, that's all.


I don't know how this cannot be a bug in the code or perhaps I don't 
understand how this should work but giving an example for 4/4 with the 
one example doesn't help anyone either.


For instance in an attempt to edit the existing snippet, I played about 
with different \time settings to see if I could show the differences - 
it's always good to show a negative before showing a positive I find.


Why would using using \time values of 6/8, 5/8, 4/8 engrave something 
(triangles) and 3/8 not?


Playing about with the form

\score {
{
  \time X/Y
  \repeat unfold 16 a'4
}
  \layout {
    \context {
  \Staff
  \consists "Measure_grouping_engraver"
    }
  }
}

Where X and Y change I cannot figure out why I get some engraving with 
some values and not other


I've attached a screenshot of some random output values.

Why do I get something for 4/8 and not 7/8 is it because of the value of 
the note and how we define a group? I cannot work out the logic to it.


So explaining it for 4/4 makes no sense in that there has to be 
something more fundamental in the explanation or it is a bug.


Can you or anyone help?

James




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

Re: UNC file names

[James Lowe]

Hello Knute,


On 24/04/18 16:50, Knute Snortum wrote:


> My tests on Windows 10 indicate that lilypond.exe can't handle UNC
> notation.  This is true even of a local file.
>
> First I "type" the file and it works fine with UNC.  Then I try
to launch
> LilyPond with the same file name and it can't find the file.
>
> Bug or future feature?
>

We had a few Windows-related issue - I think they are still
needing some documentation in the 'running' doc - where some
commands needed double quotes around the 'path to file name' and
some single quotes.

Could you try that and see if that helps?


No combination of slash or quote types worked for me.

C:\Users\Knute\Desktop
>lilypond "//KNUTE-HP/Users/Knute/Desktop/test.ly "
GNU LilyPond 2.19.81
warning: cannot find file: `//KNUTE-HP/Users/Knute/Desktop/test.ly 
'
fatal error: failed files: "//KNUTE-HP/Users/Knute/Desktop/test.ly 
"


C:\Users\Knute\Desktop
>lilypond '//KNUTE-HP/Users/Knute/Desktop/test.ly '
GNU LilyPond 2.19.81
warning: cannot find file: `'//KNUTE-HP/Users/Knute/Desktop/test.ly 
''
fatal error: failed files: "'//KNUTE-HP/Users/Knute/Desktop/test.ly 
'"


C:\Users\Knute\Desktop
>lilypond '\\KNUTE-HP\Users\Knute\Desktop\test.ly '
GNU LilyPond 2.19.81
warning: cannot find file: `'\\KNUTE-HP\Users\Knute\Desktop\test.ly 
''
fatal error: failed files: 
"'KNUTE-HP\\Users\\Knute\\Desktop\\test.ly '"


C:\Users\Knute\Desktop
>lilypond "\\KNUTE-HP\Users\Knute\Desktop\test.ly "
GNU LilyPond 2.19.81
warning: cannot find file: `\\KNUTE-HP\Users\Knute\Desktop\test.ly 
'
fatal error: failed files: 
"KNUTE-HP\\Users\\Knute\\Desktop\\test.ly "


---
Knute Snortum
(via Gmail)



Sorry this took so long for me to get back to you.

More research tells me that it is not lilypond that is at fault here but 
Windows.


Windows cmd does not support UNC paths.

Also see:

https://web.archive.org/web/20150312195558/https://support.microsoft.com/en-us/kb/156276

I tried the registry edit mentioned here too but on my 8.1 OS it didn't 
seem to change anything.


You can use the pushd/popd commands - example:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\jlowe>lilypond x:\test.ly
GNU LilyPond 2.19.82
warning: cannot find file: `x:\test.ly'
fatal error: failed files: "x:\\test.ly"

C:\Users\jlowe>pushd x:\

x:\>lilypond test.ly
GNU LilyPond 2.19.82
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `./tmp-lilypond-sOMY4M'...
Converting to `test.pdf'...
Deleting `./tmp-lilypond-sOMY4M'...
Success: compilation successfully completed

x:\>popd

C:\Users\jlowe>

I hope this helps.

James

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

Re: UNC file names

[James Lowe]

Hello,


On 10/08/18 19:03, Aaron Hill wrote:

On 2018-08-10 10:29, Aaron Hill wrote:

On 2018-08-10 08:52, James Lowe wrote:

Here are some procmon csv logs

Three of them (zipped)

1. Where I ran it from a local dir - success
2. Where I ran it on a UNC share - fail
3. Where I pushd the UNC share (mounts on W:) and then run - success

Hope this is useful.


Hi James,

Thanks for taking the time to capture this data!  This confirms
LilyPond is not passing the expected path to CreateFile.  *Why* it is
not, I will do more research and see if I can track down the
underlying cause.


flower/file-name.cc:57
  replace_all (_name, string ("//"), "/");

There's the likely culprit there.  The `slashify` function first 
forces backslashes to forward slashes.  While Windows does permit some 
use of forward slashes where backslashes are the standard, there is 
most definitely a difference between `\\` and `\`, when it is at the 
beginning of a file path.  And the problem is that `slashify` 
collapses double slashes to single ones, thereby changing the 
intention of the input path.


`lilypond \\server\folder\file` results in a file path of 
`/server/folder/file`, which then results in looking at 
`C:\server\folder\file` (if the current working directory is the C: 
drive).  If the original path were preserved as `\\server\folder\file` 
(or possibly even mildly mutilated as `//server/folder/file`), then 
CreateFile should see the path as absolute, not relative, and attempt 
to read the from the specific network path.


So the logic for detecting an absolute path needs some updating for 
Windows.  An explicit drive letter is one option but a leading `\\` 
(or `\\?\`) should be recognized and preserved.


I went digging through the tracker and came up with an old issue that we 
could tack this thread onto


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

I'll update that and change the title of the issue.

There is another related tracker (I think) that is also still open

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

James







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

Re: \override ClefModifier.text has no effect

[James Lowe]

Hello,


On 15/08/18 11:19, Malte Meyn wrote:

Hi list,

I’m not sure: Is this a bug? According to the Internals Reference, 
ClefModifier has ly:text-interface::print as a stencil and should use 
the 'text property. But the following doesn’t show “8va” as expected 
but “8”:


\version "2.21.0" % same for 2.19.82, 2.18.2
{
  % make sure the correct grob is targeted
  \override Staff.ClefModifier.color = #red
  % nothing happens:
  \override Staff.ClefModifier.text = "8va"
  \clef "treble^8"
  R1
}

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


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

Cheers,
Malte


We mention (something related to) this in our NR

http://lilypond.org/doc/v2.19/Documentation/notation-big-page.html#clef

Known Issues and warnings - where we actually use a coloured example.

Is this kind of what David was talking about or do we need to improve 
what we state there?


James

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

Re: Two issue with Measure_grouping_engraver

[James Lowe]

Harm,


On 05/08/18 22:05, Thomas Morley wrote:

2018-08-05 13:26 GMT+02:00 James Lowe :

Hello,



On 05/08/18 08:38, James Lowe wrote:

Harm,


On 03/08/18 16:03, Thomas Morley wrote:

2018-08-03 16:51 GMT+02:00 James Lowe :

Hello


On 03/08/18 13:32, Thomas Morley wrote:

Hi,

while playing with the Measure_grouping_engraver
see:


http://lilypond.1069038.n5.nabble.com/changing-symbols-used-by-Measure-grouping-engraver-td215283.html
I noticed two things which may qualify as bugs.

(1) A documentation issue

I tried to get MeasureGrouping in default 4/4-time, but nothing
happened.
One has to set beatStructure and baseMoment accordingly. The current
docs make it sound it should work out of the box, though.

\version "2.19.82"

\new Staff \with { \consists "Measure_grouping_engraver" }
 {
 %% to get MeasureGrouping, next two lines need to be
uncommented
   %\set Timing.beatStructure = 4,4
   %\set Score.baseMoment = #(ly:make-moment 1/8)
   \repeat unfold 8 a'8
 }


Is this just a documentation issue though?

*should* it work out of the box (to use your phrase) and so
documentation is
correct and the bug is in the code?

We don't document bugs after all.

James

Hi James,

this is not a bug in the code, afaik.

But the functionality of MeasureGrouping relies on appropriate
settings for beatStructure and baseMoment.
This should be documented, that's all.


I don't know how this cannot be a bug in the code or perhaps I don't
understand how this should work but giving an example for 4/4 with the one
example doesn't help anyone either.

For instance in an attempt to edit the existing snippet, I played about with
different \time settings to see if I could show the differences - it's
always good to show a negative before showing a positive I find.

Why would using using \time values of 6/8, 5/8, 4/8 engrave something
(triangles) and 3/8 not?

Playing about with the form

\score {
{
   \time X/Y
   \repeat unfold 16 a'4
}
   \layout {
 \context {
   \Staff
   \consists "Measure_grouping_engraver"
 }
   }
}

Where X and Y change I cannot figure out why I get some engraving with some
values and not other

I've attached a screenshot of some random output values.

Why do I get something for 4/8 and not 7/8 is it because of the value of the
note and how we define a group? I cannot work out the logic to it.

So explaining it for 4/4 makes no sense in that there has to be something
more fundamental in the explanation or it is a bug.

Can you or anyone help?

James





Hi James,

If I understand correctly:

In general the time-signature says about a measure:
how many beats are present and how long are those beats.
P.e. in 3/8 there are 3 beats, each a 8th note long

In LilyPond we add a structure (`beatStructure`) to those beats (`baseMoment`),
reflecting the most common accents and determine the auto-beaming.
p.e. 9/8 is structered as three groups of three 8th-notes.
For beamings not according to `beatStructure` we set `beamExceptions`,
p.e. for 3/8

Now, MeasureGrouping may annotate groups of beats, _if_ groups are defined by
`beatStructure`, see 9/8. Single beats will not cause any MeasureGrouping,
see 3/8.

Here some test-code:

displaySomeContextPoperties =
\context Timing
\applyContext
   #(lambda (ctx)
 (newline)
 (format #t
   "timeSignatureFraction: ~a\n\tbeatStructure: ~a\n\tbaseMoment: ~a
   \tbeamExceptions: ~a\n"
   (ly:context-property ctx 'timeSignatureFraction)
   (ly:context-property ctx 'beatStructure)
   (ly:context-property ctx 'baseMoment)
   (ly:context-property ctx 'beamExceptions)))

\new Staff \with { \consists "Measure_grouping_engraver" }
{
   \time 3/8 \displaySomeContextPoperties \repeat unfold 3 { a'8 }
   \time 4/8 \displaySomeContextPoperties \repeat unfold 4 { a'8 }
   \time 5/8 \displaySomeContextPoperties \repeat unfold 5 { a'8 }
   \time 6/8 \displaySomeContextPoperties \repeat unfold 6 { a'8 }
   \time 7/8 \displaySomeContextPoperties \repeat unfold 7 { a'8 }
   \time 8/8 \displaySomeContextPoperties \repeat unfold 8 { a'8 }
   \time 9/8 \displaySomeContextPoperties \repeat unfold 9 { a'8 }
   \time 1/4 \displaySomeContextPoperties \repeat unfold 2 { a'8 }
   \time 2/4 \displaySomeContextPoperties \repeat unfold 4 { a'8 }
   \time 3/4 \displaySomeContextPoperties \repeat unfold 6 { a'8 }
   \time 4/4 \displaySomeContextPoperties \repeat unfold 8 { a'8 }
}

Terminal-output:
timeSignatureFraction: (3 . 8)
 beatStructure: (1 1 1)
 baseMoment: #
   beamExceptions: ((end (1/8 3)))

timeSignatureFraction: (4 . 8)
 beatStructure: (2 2)
 baseMoment: #
   beamExceptions: ()

timeSignatureFraction: (5 . 8)
 beatStructure: (3 2)
 baseMoment: #
   beamExceptions: ()

timeSignatureFraction: (6 . 8)
 beatStructure: (3 3)
 baseMoment: #
   beamExceptions: ()

timeSignatureFraction: (7 . 8)
 

Re: UNC file names

[James Lowe]

Hello,


On 09/08/18 19:02, Aaron Hill wrote:

On 2018-08-09 08:41, James Lowe wrote:

Sorry this took so long for me to get back to you.

More research tells me that it is not lilypond that is at fault here
but Windows.

Windows cmd does not support UNC paths.


That should not be relevant, though.  That at most limits the ability 
for the current working directory to be a UNC path, without first 
mapping it to a drive letter.  But it really should not affect the 
ability to invoke LilyPond and pass in a UNC path for the input file.


Possibly but I would guess that would only matter if you were running 
the command in cmd rather than a ps environment.


As an aside, PowerShell does not have the same working directory 
limitation, and you can `cd` to a UNC path as you wish.


Yes this is true and also of note I could not get LP to use UNC paths 
even when run from Powershell, so perhaps your previous paragraph is 
making this point?




But back to the issue, if LilyPond is ultimately calling CreateFile 
passing in the file path as specified in the command-line arguments, 
it should be able to open a UNC-based path providing there are no 
permissions issues.  What I would suspect is some quirkiness with 
MinGW/MSYS and Posix paths such that LilyPond is not generating the 
correct API call.


Yes, although that is well beyond my ken.



As such, what would be interesting is to get a Process Monitor capture 
of the failing case.  That way, we can see which specific file I/O 
calls failed and with which errors.  Unfortunately, I no longer use 
the Windows version of LilyPond, so I cannot immediately test this on 
my setup without having to set up a VM first.  If it is possible to 
run LilyPond in a portable mode without installation, then that would 
save significant time getting a test environment.


I can do that perhaps - although I haven't used proc mon for a while.

James

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

Re: UNC file names

[James Lowe]

Knute,


On 09/08/18 18:30, Karlin High wrote:

On 8/9/2018 10:41 AM, James Lowe wrote:

Windows cmd does not support UNC paths.


Does it work if the UNC path gets mapped as a network drive? That 
could even be automated on the command line with the NET USE command.


That is effectively, as far as I can tell, what the pushd and popd 
commands do.


James


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

Re: TimeSignature and magnifyStaff

[James Lowe]

Hello,

On Tue, 17 Jul 2018 06:05:13 -0700 (MST), foxfanfare  wrote:

> As a new LilyPond user, I never opened an issue for signaling a bug. Could
> someone please do it, or explain me how to proceed? Thx

We're still establishing if it is a bug or an enhancement (see thread).

However, for now I have created

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

James




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

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

[James Lowe]

Hello,

On Sun, 15 Jul 2018 08:59:01 +0200, "Jaap de Wolff"  wrote:

> Hello,
> 
> About a week ago I did sent the bug report below.
> There was a comment on it on which I replied.
> At this moment it is still not on the bug list, while younger reports are.
> No one told me it was not a proper bug report, or it was not accepted.
> Possible it was not clear that it was intended to be a bug report, so I do
> send it again.
> 
> Jaap de Wolff

> 
> 
> Van: Jaap de Wolff  
> Verzonden: maandag 9 juli 2018 13:30
> Aan: 'bug-lilypond@gnu.org' 
> Onderwerp: Problems in gregorian style lyrics with combination of episem and
> melisma 
> 
> In gregorian lyrics the combination of episem with melisma must follow a
> strict order:
> 
> \episemInitium \melisma xxx \episemFinis \melismaEnd  is the only working
> order
> 
> The orders 
> 
> \episemInitium \melisma xxx \melismaEnd \episemFinis 
> 
> \melisma \episemInitium xxx \melismaEnd \episemFinis 
> 
> \melisma \episemInitium xxx \episemFinis \melismaEnd 
> 
> will result in an  unexpected EVENT_IDENTIFIER error
> 
> ===
> 
> \version "2.19.62"
> 
> \include "gregorian.ly"
> 
> \new VaticanaVoice {
> 
>   a  \melisma \episemInitium g \melismaEnd \episemFinis 
> 
> }
> 
> ===
> 
> Result in error:
> 
> syntax error, unexpected EVENT_IDENTIFIER
>   a  \melisma 
>   \episemInitium g \melismaEnd \episemFinis
> 
> The expected behaviour is that any order is accepted.
> 
> Cheers,
> 
> Jaap


I suppose that it would be helpful if there are any other Ancient Music 
afficionadoes on the list that can comment if 'any order' is really expected to 
work or if this is not just a 'better documentation' issue.

@Jaap

Are there any other valid combinations that *do* work apart from the one you 
gave?

It may give the developers more to work with.

Thank you.

James

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

Re: Crash with simultaneous-duplicating music function and onceoffset

[James Lowe]

Hello,

On Sun, 15 Jul 2018 20:09:52 -0700, Aaron Hill  wrote:

> On 2018-07-15 18:21, Simon Albrecht wrote:
> > 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 }
> > 
> 
> Seems the custom music function is not needed to reproduce a crash.
> 
> 
>\version "2.19.82"
>music = { \once \offset length 5 Stem 4 4 }
><< \music \music >>
> 
> 
> This also results in:
> 
> > GNU LilyPond 2.19.82
> > Processing `crash.ly'
> > Parsing...
> > Interpreting music...
> > Preprocessing graphical objects...
> > fish: “lilypond crash.ly” terminated by signal SIGSEGV (Address 
> > boundary error)

...

> 
> -- Aaron Hill

I created https://sourceforge.net/p/testlilyissues/issues/5383/ for this crash 
report.


James
___
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

[James Lowe]

Hello,

On Sun, 15 Jul 2018 09:24:22 +0200, Malte Meyn  wrote:

> Hi list,
> 
> it’s possible to write something like
> 


> 
> Cheers,
> Malte

I created https://sourceforge.net/p/testlilyissues/issues/5382/ for this 
request.

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

Re: TimeSignature and magnifyStaff

[James Lowe]

On Sun, 15 Jul 2018 08:05:05 +0200, Malte Meyn  wrote:

> 
> Am 14.07.2018 um 23:40 schrieb foxfanfare:
> > I found a strange bug when using the magnifyStaff tool. In this example, you
> > can see a collusion between the clef and the time signature occurs when the
> > lowest staff is smaller (and not otherwise).
> > 
> > Sounds like a bug to me, what do you think? Is there a way to avoid this?
> 
> Yes, that’s a bug. IMHO horizontal spacing in general is crap with 
> magnifyStaff and differently sized staves. Look f. e. at the clef 
> position in your second example, at the note spacing of the second and 
> third example and at the ending bar line in the following cases:

So is this a bug or is it really an enhancement request/feature (i.e. is the 
code expected to do this or is it just a poorly chosen name for a function)?

Regards

James



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

Re: Partcombine Documentation: Example Error

[James Lowe]

Hello,

On Thu, 19 Jul 2018 08:44:56 +0200, Thomas Morley  
wrote:



...


> 
> Hi James,
> 
> I've no clue why it happens, so I'd go for the symptom. Something like
> "partcombine warns erroneously for unterminated slur".
> 
> Cheers,
>   Harm


Many thanks

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

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

Re: enable OpenType features globally

[James Lowe]

hello

On Thu, 12 Jul 2018 07:59:22 +0200 (CEST), Werner LEMBERG  wrote:

> 
> >  #:roman "Vollkorn:liga=0"
> > 
> > This would set Vollkorn as roman font, disable liga (for example ff
> > ligature), and enable dlig (for example st ligature) and slashed
> > zero.  The suggested syntax using : and & is how it’s done in
> > LibreOffice.
> 
> +1
> 
> In your suggestion, spaces should not be significant after the `:'.
> 
>   #:roman "Vollkorn:liga = 0 & dlig & zero"
> 
> 

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

James


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

Re: Partcombine Documentation: Example Error

[James Lowe]

Hello,

On Wed, 18 Jul 2018 09:09:15 +0200, Thomas Morley  
wrote:

> 2018-07-17 11:55 GMT+02:00 Ben :
> > Good morning,
> >
> > I've been reading up on partcombine recently and I wanted to try out a few
> > examples from the documentation to help me really understand the command,
> > however I get this error with one example:
> >
> > From:
> >
> > http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#automatic-part-combining
> >
> > Error:
> >
> > warning: unterminated slur r2 g'4( f8 e) |
> >
> > ---
> >
> > I have not modified the code at all, just copy and paste.
> >
> > I thought it was due to some voice-issue but I can't figure out how to fix.
> > Thanks for any help.
> >
> >
> > Code:
> >
> > musicUp = \relative c'' {
> >   \time 4/4
> >   a4 c4.( g8) a4 |
> >   g4 e' g,( a8 b) |
> >   c b a2.
> > } % begin verbatim
> >
...

> 
> As Torsten already stated, it's a bug.
> 
> First bad commit:
> 
> commit b357d2084d1ae252a890e92019e62aa8ccbfdafc
> Author: Dan Eble 
> Date:   Wed May 27 20:56:37 2015 -0400
> 
> Issue 4423: eliminate part combiner's array of context handles (3/4)
> 
> Use NullVoice instead of Devnull for the "null" context.  This makes
> all outlets a kind of Voice.
> 
> 
> Introduced in 2.19.22
> 
> cc-ing Dan and the bug-list
> 
> Cheers,
>   Harm

Can you give me a technically-meaningful title for the tracker?

I cannot think of anything.

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

Re: [LSR] multi-measure-rest-length-control.ly snippet should not use \compressFullBarRests

[James Lowe]

Federico


On 30/08/18 10:54, Federico Bruni wrote:

Hi folks

Bug Squad, this does not require a new issue in the tracker, but just 
someone who can fix the snippet on the LSR website.


There's a recent snippet file imported from LSR which contains 
\compressFullBarRests.


$ git grep \compressFullBarRests Documentation/snippets
Documentation/snippets/multi-measure-rest-length-control.ly:25: 
\compressFullBarRests
Documentation/snippets/new/multi-measure-rest-length-control.ly:17: 
\compressFullBarRests



Given this commit:

commit ba9a8dc730bb3a681455150bc0a3eef0976523af
Author: Trevor Daniels 
Date: Fri May 1 22:56:47 2015 +0100

   Issue 3687 (part 2): Amend docs to use \compressMMRests

 Amend the examples in the LM and NR to use the \compressMMRests
 music function rather than the predefs \compressFullBarRests and
 \expandFullBarRests to avoid advocating the use of techniques
 which may have undesirable side effects.


we should replace it with \compressMMRests.
Who can do this change in the LSR?

I cannot find this on the LSR.

It is in LilyPond's own Snippets (but that is not the same thing) so a 
change to this would require a change in git.


Also

grep -r "compressFullBarRests" * | wc -l

gives a count of 38 (of which 14 are *.po files) so we might as well 
change it for those files too right?


In which case a tracker would be best.

Let me know.

James





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

Re: X-aligning problems with chords containing unisons

[James Lowe]

Hello,

On 02/09/18 11:13, Torsten Hämmerle wrote:

Hi all,

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

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

for those that don't follow 'dev'

This is

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

James

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

Re: musicxml2ly produces unexpected EOF in .ly file

[James Lowe]

Knut


On 27/08/18 16:14, Federico Bruni wrote:



Il giorno dom 26 ago 2018 alle 16:12, David Kastrup  ha 
scritto:

Victor Rouanet  writes:


 Le 26/08/2018 à 15:15, Victor Rouanet a écrit :

 Same result for me. According to Phil Homes in the lilypond-user
 topic, the shlex module (used by musicxml2ly in utilities.py) didn't
 support unicode input prior to Python 2.7.3.

 According to David Wright*
 I misread.


So we should upgrade Python in GUB?



https://github.com/gperciva/gub/pull/6

I hope more people will be able to run GUB successfully. Only Phil can 
run it at the moment?

I look forward to Knut's patch.



Your GUB patch has been sitting on the 'to push' list for a few weeks now.

Can you make the pull request please to https://github.com/gperciva/gub 
so that Phil can merge your changes into GUB?


Thanks

James

___
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

[James Lowe]

Hello Simon,


On 11/09/18 11:03, Simon Albrecht wrote:

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


Added as https://sourceforge.net/p/testlilyissues/issues/5416/

James

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

Re: Possible bug: avoid-slur and TrillSpanners

[James Lowe]

Knute

On Sat, 21 Apr 2018 06:26:50 -0700, Knute Snortum  wrote:

>  In this example...
> 
> %%% Start
> \version "2.19.81"
> \language "english"
> 
> {
>   \override TrillSpanner.avoid-slur = #'inside
>   \override TrillSpanner.outside-staff-priority = ##f
>   c''1( | c''2. \startTrillSpan c''4 \stopTrillSpan | c''1) |
> }
> %%% End
> 
> ...the slur doesn't avoid the trill spanner.
> 
> 

Is this https://sourceforge.net/p/testlilyissues/issues/397  ?

Regards

James

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

Re: balloonGrobText for ledger lines

[James Lowe]

Werner,

On Sat, 14 Apr 2018 23:10:08 +0200 (CEST), Werner LEMBERG  wrote:

> 
> > [lilypond be08490329a22423bb2a723eea7a5cd33f3a42d8]
> > 
> > I was just about asking on the user list how to get a balloon text
> > for a ledger line (apparently, it's not possible); while preparing a
> > MWE I found out that the following crashes lilypond:
> > 
> >   \new Staff \with {
> > \consists "Balloon_engraver"
> >   } {
> > \balloonGrobText #'LedgerLineSpanner #'(1 . 0.5)
> >   \markup "ledger line"
> > a''16
> >   }
> 
> Exactly the same happens if I replace `LedgerLineSpanner' with `Beam'.
> 
> 
> Werner

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

Thanks

James

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

Re: crash during musicxml2ly

[James Lowe]

Hello Frederic,

On Sat, 14 Apr 2018 09:42:20 +, Frédéric Gohier  
wrote:

> hello,
> 
> I face a crash when run the command line :
> /usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m 
> MusicXMLV2_from_sibelius7.xml
> 
> the traceback is :
> Traceback (most recent call last):
>   File "/usr/local/bin/musicxml2ly", line 3277, in 
> main()
>   File "/usr/local/bin/musicxml2ly", line 3271, in main
> voices = convert(filename, options)
>   File "/usr/local/bin/musicxml2ly", line 3157, in convert
> update_score_setup(score, part_list, voices, parts)
>   File "/usr/local/bin/musicxml2ly", line 3027, in update_score_setup
> score_structure.set_part_information(part_id, staves_info)
>   File "/usr/local/share/lilypond/2.21.0/python/musicexp.py", line 2351, in 
> set_part_information
> self.contents.set_part_information (part_id, staves_info)
>   File "/usr/local/share/lilypond/2.21.0/python/musicexp.py", line 2135, in 
> set_part_information
> c.set_part_information (part_name, staves_info)
> AttributeError: PartGroupInfo instance has no attribute 'set_part_information'
> 
> I correct this issue by modifying
> 
>   *   in file git/python/musicexp.py :
>   *   in class StaffGroup :
>   *   in function set_part_information :
> 
> def set_part_information (self, part_name, staves_info):
> if part_name == self.id:
> self.part_information = staves_info
> else:
> for c in self.children:
> +if hasattr(c, 'set_part_information'):
> +c.set_part_information (part_name, staves_info)
> -c.set_part_information (part_name, staves_info)
> 
> 
> I don't know the process to validate and don't remember the process to push a 
> modification on git server.
> please can you help me ?
> 
> 

I can.

You cannot push a modification directly to our git repo until the LilyPond 
developers have reviewed and tested your patch. We use Rietveld for patch 
review and we always need an issue for any patch submitted via Source Forge 
that does not already have an issue against the problem you are trying to fix - 
Allura is our Issue Tracker.

A high level summary is here

http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#summary-for-experienced-developers

If you intend on contributing more I suggest you read the relevant information 
in the Contributor's Guide which tells you how the entire process works.

If you do not want to follow the process, you can at least submit a git 
formatted patch against current master to the bug email list. Current master is 
found here:

https://git.savannah.gnu.org/gitweb/?p=lilypond.git

One of us may be able to start the process of testing and submit the patch for 
review to the rest of the development team.

But we would prefer it if you did try to at least submit your own patch via 
Rietveld if nothing else. 

Thank you.

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

Re: Invisible bar line and wide lyric produces "mis-predicted force" error.

[James Lowe]

Hello,

On Wed, 18 Apr 2018 15:42:42 -0700, Aaron Hill  wrote:

> I encountered this when typesetting a piece that needs fairly wide 
> stanza markings.  One piece worked fine, while another failed with 
> "mis-predicted force" errors.  While reducing the repro, it seemed the 
> main difference was the presence of an invisible bar line (i.e. \bar "") 
> earlier in the score along with some wide lyrics.  Without that bar line 
> present or by narrowing the stanza marking, the piece that had failed no 
> longer reported any errors.
> 
> For reference, I am using version 2.19.80 (MinGW) on Windows 10 Pro 
> 64-bit (16299.371).
> 
> Here is a minimal repro using a simple lyric instead of a stanza 
> marking:
> 
> 
> % The combination of an invisible bar line and a wide lyric produces:
> % "programming error: mis-predicted force, 108.120472 ~= 108.482555"
> \version "2.19.80"
> { r2 \bar "" c'2 } \addlyrics { "mm" }
> 
> 
> The only references I could find to "mis-predicted force" are in 
> relation to an issue regarding grace notes and possible floating-point 
> arithmetic issues in the Windows/MinGW build.  Presuming this is 
> related, here is hoping this repro can help shed some light on the 
> underlying issue.

While not very helpful to you personally, it maybe a useful point of reference 
for the other devs in that I can compile this without issue using latest 
current master (2.21.0) on Ubuntu 16.10.

Regards

James

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

Re: Two issues: crash and build problem.

[James Lowe]

Hello Gwyn,

On Thu, 19 Apr 2018 08:51:41 -0500, Gwyn Ciesla  wrote:

> Hi! Gwyn Ciesla, Fedora lilypond maintainer.
> 
> First, we have a crash I'm having trouble debugging:
> https://bugzilla.redhat.com/show_bug.cgi?id=1568274

I am not a developer so can only add that compiling that 'test' file provided 
in that bugzilla did not crash when using current master (2.21.0) - Ubuntu 
16.10 LTS.  Note also that both my 'current master' version and that referenced 
on the bugzilla (2.19.x)  are using 'unstable' versions of LilyPond.

While unstable is 'mostly' OK there are obviously going to be problems.

I suppose the issue here is that the version he  (or she) is using is the most 
current 'unstable' version you can download, this is mainly because we're in 
between getting a stable 2.20 ready and have already moved on to a 2.21. dev 
branch.

Maybe one of the other devs can chime in here but if your user can build from 
the most current git master and see if they get the issue, we may be chasing an 
already-fixed issue.

> 
> Second, I can't build lilypond on Fedora 28 or newer. It fails with a
> Python warning:

I have to stand aside here at this point as I have no knowledge to help with 
this question..

Regards

James

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

Re: Possible bug: avoid-slur and TrillSpanners

[James Lowe]

Hello,

On Sat, 21 Apr 2018 06:26:50 -0700, Knute Snortum  wrote:

>  In this example...
> 
> %%% Start
> \version "2.19.81"
> \language "english"
> 
> {
>   \override TrillSpanner.avoid-slur = #'inside
>   \override TrillSpanner.outside-staff-priority = ##f
>   c''1( | c''2. \startTrillSpan c''4 \stopTrillSpan | c''1) |
> }
> %%% End
> 
> ...the slur doesn't avoid the trill spanner.
> 
> 
> ---
> Knute Snortum
> (via Gmail)

Added as https://sourceforge.net/p/testlilyissues/issues/5313/

James


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

Re: Key cancellation, position bug

[James Lowe]

Hello,

On Mon, 23 Apr 2018 10:23:38 -0700 (MST), Torsten Hämmerle 
 wrote:

> foxfanfare wrote
> > As you can see, the naturals aren't spaced correctly when using the bass
> > clef.
> 
> 
> Hi Fox,
> 
> This has nothing to do with the bass clef, as far as I can see (by
> exchanging clefs, not changing clefs at all, or using alto clefs etc.), but
> it definitively has to do with the cancelled key signature: when cancelling
> flats, the naturals stick together, when cancelling sharps, everything looks
> OK.
> Confirmed in 14.2, 16.2, 18.2, 19.81, 2.21.0 so this has been around for
> quite a while.
> 
> I'd call it a bug (type "ugly"), because this should work without tweaking.
> 
> All the best,
> Torsten


Thanks.

Added as https://sourceforge.net/p/testlilyissues/issues/5312/

James__
> 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 alternativeRestores

[James Lowe]

Hello,

On Thu, 29 Mar 2018 19:53:05 +, Steven Weber  wrote:

> AlternativeRestores seem to work fine as long as your metadata & notes are in 
> the same block.  If you separate them into a metadata variable and a notes 
> variable, the second alternative is always in the same time signature as the 
> first alternative.
> 
> This is against lilypond 2.19.81 on Windows.
> 
> --Steven

Your example is giving me barcheck errors for those entries using the \skip 
values.

Is this just a problem with your example?

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

Re: Type LM 3.1.1 File structure

[James Lowe]

Hello Joseph,

On Thu, 25 Jan 2018 08:47:34 -0500, Joseph Austin <drtechda...@gmail.com> wrote:

> The example LM 3.1.1 is inconsistent.
> The shorthand music used "d" as the second note;
> \relative c'' {
>   c4 a d c
> }
> 
> while the expanded version (and subsequent examples) has "b":
> 
>  \relative c'' {
>   c4 a b c
> }
> Joe Austin

Thank you this has now been fixed.

@dev team

I didn't create an issue for this trivial typo

--snip--

Doc: LM fix typo in 3.1 staging
author  James Lowe <pkx1...@runbox.com> 
Mon, 23 Apr 2018 20:04:11 +0100 (20:04 +0100)
committer   James Lowe <pkx1...@runbox.com> 
Mon, 23 Apr 2018 20:06:42 +0100 (20:06 +0100)
commit  a334d48b6b3fd2f310369609eed9ef9fe6540636

--snip--

Regards

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

Re: Bug with alternativeRestores

[James Lowe]

Hello Steven

On Mon, 23 Apr 2018 19:33:34 +, Steven Weber <pant...@hotmail.com> wrote:

> No, that is the problem.  If you look at the file, you'll see in the first 
> example, I switch the time from 2/2 to 3/4 in the first alternative, and then 
> Lilypond automatically returns the second alternative to 2/2 time.  However, 
> when I do the metadata/notes in separate variables, the automatic switch from 
> 3/4 back to 2/2 does not occur (and hence, you get all the barcheck errors).
> 
> --Steven
> 
> On 4/23/18, 11:59 AM, "James Lowe" <pkx1...@runbox.com> wrote:
> 
> Hello,
> 
> On Thu, 29 Mar 2018 19:53:05 +, Steven Weber <pant...@hotmail.com> 
> wrote:
> 
> > AlternativeRestores seem to work fine as long as your metadata & notes 
> are in the same block.  If you separate them into a metadata variable and a 
> notes variable, the second alternative is always in the same time signature 
> as the first alternative.
> > 
> > This is against lilypond 2.19.81 on Windows.
> > 
> > --Steven
> 
> Your example is giving me barcheck errors for those entries using the 
> \skip values.
> 
> Is this just a problem with your example?
> 
> James
> 
> 

We also had this reported by another user last year - something was nagging me 
at the back of my brain that I'd seen this recently, and so I dug back through 
the bug list emails and found it:

https://lists.gnu.org/archive/html/bug-lilypond/2017-09/msg00022.html

(not so recent I guess)

and I didn't see any reply/confirmation of this being a bug by those that know 
about development.

The workaround from the other user is to explicitly put the time signature 
directly in the alternate's construct .

e.g

metadata =
{
\time 2/2
\clef bass

\repeat volta 2 { \skip 1*2/2*1 | }
\alternative
{
{ \time 3/4 \skip 1*3/4*1 | }
{ \time 2/2 \skip 1*2/2*1 | } % < add the \time 2/2 here
}
\skip 1*2/2*1 |
}

notes = 
{
\repeat volta 2 { c2 e | }
\alternative
{
{ f4 e d | }
{ \time 2/2 f2 d | } % < add the \time 2/2 here
}
g1 |
}

Then it compiles (without bar check warnings) OK as far as I can tell.

I think that LilyPond is just not able to cope with the ambiguity of the mix of 
time signatures in the alternate repeats when you use a << >> construct. 

So the issue is (again I think I am not qualified to say for certain) not with 
the alternate restores but the simultaneous construct but I don't think this is 
a bug but a feature.

Maybe others in the dev team can comment and perhaps we can add something to 
the doc (if it is not a bug) as a 'Known issue'.

Regards

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

Re: Bug with alternativeRestores

[James Lowe]

David

On Tue, 24 Apr 2018 14:10:28 +0200, David Kastrup <d...@gnu.org> wrote:

> "James Lowe" <pkx1...@runbox.com> writes:
> 
> > We also had this reported by another user last year - something was nagging 
> > me at the back of my brain that I'd seen this recently, and so I dug back 
> > through the bug list emails and found it:
> >
> > https://lists.gnu.org/archive/html/bug-lilypond/2017-09/msg00022.html
> >
> > (not so recent I guess)
> >
> > and I didn't see any reply/confirmation of this being a bug by those that 
> > know about development.
> 
> Enough so that it's keeping 2.20 from being released.  This needs to be
> fixed in a reasonable manner or reverted

I am inferring that there is no Tracker for this (i.e. I couldn't find one and 
there was no apparent follow up to the email sent last year)?

If so I can at least create one..

James

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

Re: Ski Emoji Error

[James Lowe]

Hello,

On Tue, 24 Apr 2018 14:13:29 +0200, David Kastrup  wrote:

> Jay Anderson  writes:
> 
> > Minimal Example:
> >
> > =
> > \version "2.19.80"
> >
> > \markup "⛷"
> > =
> 
> [...]
> > fatal error: failed files: "ski.ly"
> > =
> >
> > Other emojis seem to work fine. What does the above error mean? If the font
> > doesn't include this emoji that's fine, but that isn't obvious from the
> > above.
> 
> Probably depends on the Ghostscript version?  Looks fine here:
> 

Well it looks OK but I get the same 'error' with gs version 9.22 so I compiled 
and installed 9.23 and I no longer get this 'failed files' message.

James




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

Re: UNC file names

[James Lowe]

Knute

On Tue, 24 Apr 2018 05:56:04 -0700, Knute Snortum  wrote:

> My tests on Windows 10 indicate that lilypond.exe can't handle UNC
> notation.  This is true even of a local file.
> 
> First I "type" the file and it works fine with UNC.  Then I try to launch
> LilyPond with the same file name and it can't find the file.
> 
> Bug or future feature?
> 

We had a few Windows-related issue - I think they are still needing some 
documentation in the 'running' doc - where some commands needed double quotes 
around the 'path to file name' and some single quotes.

Could you try that and see if that helps?

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

Re: Request PATCH to ensure LilyPond SVG compatibility with Scribus

[James Lowe]

Hello,

(cc-ing the bug list)

On 11/10/2018 2:56 pm, d_l wrote:

I have joined this list today just for the purpose of facilitating a link
between Scribus and LilyPond  forums and posting one PATCH suggestion before
next imminent release of lilypond.

Over at the Scribus forum a small issue prevents svg output from lilypond
commandline being rendered in Scribus the desktop publishing tool.   PNG
output works.

The Scribus issue refers to SVG fill attribute "currentColor" being used
instead of "black".

Perhaps at this 11th hour before next release this might be looked at?
LilyPond printing through Scribus would make a nice team.

References:

https://bugs.scribus.net/view.php?id=15454

http://lilypond.1069038.n5.nabble.com/rsvg-view-can-t-display-SVG-files-created-by-lilypond-tc191462.html#a191496

Here is a quote from a Scribus forum snr. member:

"the lillypond authors seem to know about the issue but (probably) wrongly
decided to do nothing...

can somebody who uses lillypond try to post a bug report for this issue with
jean's explanation from the bug tracker and telling them that this shortcut
makes hard to import the svg in scribus?
(i mean, they could keep track of the color used and always set it
explicitly, instead of relying on a default value that seems not to be 100%
standardized)."


I have created

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

Regards


James



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

Re: Articulate script plus grace notes following multiple voices results in timing errors

[James Lowe]

Hello,

On 24/10/2018 11:35 am, David Baptista wrote:
Thank you, I reckon it might not be a bug encountered often, but since 
it is a consistently reproducible issue, it seemed worth of listing in 
the issue tracker.


Best regards,
David Baptista


Added as:

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

Thank you.

James






James Lowe mailto:pkx1...@runbox.com>> escreveu 
no dia quarta, 24/10/2018 à(s) 11:28:


David,

On 24/10/2018 10:53 am, David Baptista wrote:

I think it is a single issue, but because it happens at the music
expression level, it can manifest itself in both engraving and
midi "rendering". Essentially the articulate script introduces
wrong musical content, that is not present at the input, under
certain conditions (an hypothetical parallel to help categorize
the issue would be if articulate always added a whole bar full of
C#'s to the music - it would be a glich present in both midi and
engraving output). In this case we are talking about adding extra
time/pause/rests to the music when articulate processes a music
expression where grace notes follow the use of multiple voices.
Examples:

http://lilybin.com/97o636/2 - Here you cannot see the glitch
visually because the articulate output is not engraved, only used
for midi output. But you can hear from the midi output that extra
time has been added to the top staff after the grace note,
resulting in that staff being out of sync with the staff below.

http://lilybin.com/97o636/1 - Here you can see the glitch
visually because I rendered the articulate output (I understand
no one in their right mind would do this in a normal scenario,
but I believe it is helpful here because we can visualize the
extra time that has been added, confirming that this is not a
midi rendering problem, but a problem with articulate script
introducing wrong musical content not present at the input).

(Because GNU's mailing lists archives aren't always easy to
follow, an easy to follow thread archive with the previous
discussion of this issue is available at

http://lilypond.1069038.n5.nabble.com/Articulate-script-plus-grace-notes-following-multiple-voices-results-in-timing-errors-td212650.html)

Where does this manifest in regular use? Essentially in piano and
orchestral scores, where use of multiple voices within a staff
are common and grace notes are relatively common. Users with this
use case relying on articulate to produce "better than bland"
midi output will suffer from midi output with timing issues
(essentially resulting in wrong playback with some staves being
out of time with the rest of the music). The workaround as of now
requires rewriting the music to avoid having grace notes
following multiple voices (in my case this forced me to have
different musical expressions for engraving and for midi output).

Best regards,
David Baptista


Thank you for that.

I'll take what you have written here and us it to create a new
tracker for this and send an email to the list with the URL/number.

Jamess





James Lowe mailto:pkx1...@runbox.com>>
escreveu no dia quarta, 24/10/2018 à(s) 09:16:

Hello,

On 22/10/2018 5:57 pm, David Baptista wrote:
> Did this bug end up being materialized on the tracker? (I
was looking if
> there had been any follow-up on the sourceforge bug tracker
but was unable
> to find it there).
>
> Best regards,
> David Baptista

No it does not look like anything was added to the tracker
based on the
date of this thread.

However I am having a struggle understanding what the
'concise' request
is here, to be able to add something - i.e. is it an output /
engraving
issue or an 'audio' / midi-specific issue or both (in which
case we
probably need two trackers).

Thank you.

James


> Torsten Hämmerle mailto:torsten.haemme...@web.de>> escreveu no dia sexta,
> 4/05/2018 à(s) 14:01:
>
>> David Baptista wrote
>>> Thank you for the speedy reply.
>> Ok, I admit it was too speedy...
>> Yes, you are right, I confirm to have the same effect here.
>>
>> That, indeed, calls for a tracker issue.
>>
>> All the best and thanks for the hint,
>> Torsten
>>
>>
>>
>> --
>> Sent from:
http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org

Re: Articulate script plus grace notes following multiple voices results in timing errors

[James Lowe]

David,

On 24/10/2018 10:53 am, David Baptista wrote:
I think it is a single issue, but because it happens at the music 
expression level, it can manifest itself in both engraving and midi 
"rendering". Essentially the articulate script introduces wrong 
musical content, that is not present at the input, under certain 
conditions (an hypothetical parallel to help categorize the issue 
would be if articulate always added a whole bar full of C#'s to the 
music - it would be a glich present in both midi and engraving 
output). In this case we are talking about adding extra 
time/pause/rests to the music when articulate processes a music 
expression where grace notes follow the use of multiple voices. Examples:


http://lilybin.com/97o636/2 - Here you cannot see the glitch visually 
because the articulate output is not engraved, only used for midi 
output. But you can hear from the midi output that extra time has been 
added to the top staff after the grace note, resulting in that staff 
being out of sync with the staff below.


http://lilybin.com/97o636/1 - Here you can see the glitch visually 
because I rendered the articulate output (I understand no one in their 
right mind would do this in a normal scenario, but I believe it is 
helpful here because we can visualize the extra time that has been 
added, confirming that this is not a midi rendering problem, but a 
problem with articulate script introducing wrong musical content not 
present at the input).


(Because GNU's mailing lists archives aren't always easy to follow, an 
easy to follow thread archive with the previous discussion of this 
issue is available at 
http://lilypond.1069038.n5.nabble.com/Articulate-script-plus-grace-notes-following-multiple-voices-results-in-timing-errors-td212650.html)


Where does this manifest in regular use? Essentially in piano and 
orchestral scores, where use of multiple voices within a staff are 
common and grace notes are relatively common. Users with this use case 
relying on articulate to produce "better than bland" midi output will 
suffer from midi output with timing issues (essentially resulting in 
wrong playback with some staves being out of time with the rest of the 
music). The workaround as of now requires rewriting the music to avoid 
having grace notes following multiple voices (in my case this forced 
me to have different musical expressions for engraving and for midi 
output).


Best regards,
David Baptista


Thank you for that.

I'll take what you have written here and us it to create a new tracker 
for this and send an email to the list with the URL/number.


Jamess





James Lowe mailto:pkx1...@runbox.com>> escreveu 
no dia quarta, 24/10/2018 à(s) 09:16:


Hello,

On 22/10/2018 5:57 pm, David Baptista wrote:
> Did this bug end up being materialized on the tracker? (I was
looking if
> there had been any follow-up on the sourceforge bug tracker but
was unable
> to find it there).
>
> Best regards,
> David Baptista

No it does not look like anything was added to the tracker based
on the
date of this thread.

However I am having a struggle understanding what the 'concise'
request
is here, to be able to add something - i.e. is it an output /
engraving
issue or an 'audio' / midi-specific issue or both (in which case we
probably need two trackers).

Thank you.

James


> Torsten Hämmerle mailto:torsten.haemme...@web.de>> escreveu no dia sexta,
> 4/05/2018 à(s) 14:01:
>
>> David Baptista wrote
>>> Thank you for the speedy reply.
>> Ok, I admit it was too speedy...
>> Yes, you are right, I confirm to have the same effect here.
>>
>> That, indeed, calls for a tracker issue.
>>
>> All the best and thanks for the hint,
>> Torsten
>>
>>
>>
>> --
>> Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org <mailto:bug-lilypond@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org <mailto: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: Articulate script plus grace notes following multiple voices results in timing errors

[James Lowe]

Hello,

On 22/10/2018 5:57 pm, David Baptista wrote:

Did this bug end up being materialized on the tracker? (I was looking if
there had been any follow-up on the sourceforge bug tracker but was unable
to find it there).

Best regards,
David Baptista


No it does not look like anything was added to the tracker based on the 
date of this thread.


However I am having a struggle understanding what the 'concise' request 
is here, to be able to add something - i.e. is it an output / engraving 
issue or an 'audio' / midi-specific issue or both (in which case we 
probably need two trackers).


Thank you.

James



Torsten Hämmerle  escreveu no dia sexta,
4/05/2018 à(s) 14:01:


David Baptista wrote

Thank you for the speedy reply.

Ok, I admit it was too speedy...
Yes, you are right, I confirm to have the same effect here.

That, indeed, calls for a tracker issue.

All the best and thanks for the hint,
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


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

Re: obstacles to installation

[James Lowe]

Hello Devon.

On Sat, 6 Oct 2018 14:31:23 -0400, Devon Sean McCullough  
wrote:

> These instructions lead nowhere, making it hard to install:
> 
> http://lilypond.org/doc/v2.19/Documentation/topdocs/INSTALL.html
>   404 http://lilypond.org/doc/v2.19/Documentation/topdocs/web#download
> 
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>   404 
> http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs
> 
>   Peace
>   --Devon

That's not really much information for me to be of any help to you.

However if all you want is a download (binary)

Try here:

http://lilypond.org/download.html

The link you gave:

http://lilypond.org/doc/v2.19/Documentation/topdocs/INSTALL.html

Works for me but this is really if you want to compile the source.

If you *do* want to do that and are having problems compiling or getting 
source, then give us some more details and we'll do what we can to help.

James


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

Re: Failed assertion in tremolos with beamed notes

[James Lowe]

Hello,


On Thu, 7 Feb 2019 10:30:20 +0100, Hendrik Fuß  wrote:

> Hi,
> 
> attached is a minimal example that causes a crash in lilypond 2.19.82.
> 
> Output:
> 
> GNU LilyPond 2.19.82
> »assertion_test.ly« wird verarbeitet
> Analysieren...
> Interpretation der Musik...
> Vorverarbeitung der grafischen 
> Elemente.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh:227:
>  failed assertion `!is_empty ()'
> Abort trap: 6
> 
> Hope this is helpful.
> 
> Best
> Hendrik

Using Ubuntu 16.0.4 with current master - 2.21.0

Same crash.

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

Re: NR 2.9 Ancient Notation

[James Lowe]

Hello

On Thu, 20 Jun 2019 09:08:20 +0200, Federico Bruni  wrote:

> Hi folks
> 
> I think this chapter in general would need some review from someone who 
> knows well the best practices for writing docs in LilyPond.
> 
> This snippet here should have the verbatim option:
> http://lilypond.org/doc/v2.19/Documentation/notation/ancient-notation_002d_002dcommon-features#custodes

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

Thanks.

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

Re: caps and fontCaps don’t work as expected

[James Lowe]

Hello,

sorry for multiple posts

On Thu, 04 Jul 2019 00:18:13 -0700, Aaron Hill  wrote:

> On 2019-07-04 12:04 am, Malte Meyn wrote:
> > Hi list,
> > 
> > \caps doesn’t work if unless it’s the very last markup command before
> > the actual text.
> > 
> > \fontCaps seems to have no effect at all. Shouldn’t it enable the smcp 
> > feature?
> 
> \caps is basically just an alias for \smallCaps which is the so-called 
> "poor man's" small caps.  It appears to require the immediately 
> following argument to be a string in order to work.  It will not be able 
> to traverse to the string behind a \bold for instance.
> 
> \fontCaps sets the font-shape to 'caps, which means you need a font 
> installed that supports that font-shape.  This is not the same thing as 
> OpenType caps, from what I can tell.
> 
> \override #'(font-features . ("smcp")) is the (only?) way to use 
> OpenType features to select small caps.
> 
> 

Also see:

https://lists.gnu.org/archive/html/lilypond-devel/2017-06/msg00152.html

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

Re: caps and fontCaps don’t work as expected

[James Lowe]

hello,

On Thu, 04 Jul 2019 00:18:13 -0700, Aaron Hill  wrote:

> On 2019-07-04 12:04 am, Malte Meyn wrote:
> > Hi list,
> > 
> > \caps doesn’t work if unless it’s the very last markup command before
> > the actual text.
> > 
> > \fontCaps seems to have no effect at all. Shouldn’t it enable the smcp 
> > feature?
> 
> \caps is basically just an alias for \smallCaps which is the so-called 
> "poor man's" small caps.  It appears to require the immediately 
> following argument to be a string in order to work.  It will not be able 
> to traverse to the string behind a \bold for instance.
> 
> \fontCaps sets the font-shape to 'caps, which means you need a font 
> installed that supports that font-shape.  This is not the same thing as 
> OpenType caps, from what I can tell.
> 
> \override #'(font-features . ("smcp")) is the (only?) way to use 
> OpenType features to select small caps.
> 
> 
> -- Aaron Hill

Also see https://sourceforge.net/p/testlilyissues/issues/1482/

?

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

Re: glyph-path-regexp in SVG output is overly strict

[James Lowe]

@bug

On 20/02/2020 18:33, Simon Tatham wrote:

A user of my notation font Gonville reported to me this week that they
had tried to use the Lilypond SVG backend with Gonville, and had found
that everything worked fine except that the sharp signs were
mysteriously missing from the output.

I debugged the problem and found that this happened because Fontforge
had generated the SVG path string for that glyph in a way that happened
to include the floating-point literal "9.91821e-05", written in
scientific notation, and that the 'glyph-path-regexp' definition in
output-svg.scm was failing to match the path string as a result, because
it doesn't permit the letter 'e'.

I was able to work around the issue by editing my SVG font file to
re-express that number as 0.991821, without the 'e'. But as far as I
can see, scientific notation of that form is legal per the SVG spec:
https://www.w3.org/TR/2011/REC-SVG11-20110816/paths.html#PathDataBNF

Applying the attached patch against output-svg.scm also solved the
problem for me, and I think it's a better fix.

Cheers,
Simon


I created https://sourceforge.net/p/testlilyissues/issues/5779/ for this 
issue.


James


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

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

[James Lowe]

On 05/05/2020 16:12, Pierre Perol-Schneider wrote:

Hi Bug squad,
Typo here:
http://lilypond.org/doc/v2.21/Documentation/notation/other#index-_005cfootnote-2
The code should be:

\markup {
   \footnote a b
   \override #'(padding . 0.2)
   \footnote c d
}

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


Thanks, I'll fix this - I don't think it needs a tracker issue (I'll fix 
it in the other translations too and make sure it compiles before I 
push, obviously).


James


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

Re: cannot find Voice `uniqueContext0' with \context Staff

[James Lowe]

On 08/09/2020 20:15, Thomas Morley wrote:

Hi,

this came up in the german forum:

\context Staff { b1 }
\addlyrics { foo }

results in not printed lyrics and the warning:

warning: cannot find Voice `uniqueContext0'
\addlyrics
{ foo }

It worked up to 2.18.2 but fails for 2.20.0 and upstream

Changing the code to use
\context Voice or \new Voice or \new Staff
works.

Cheers,
   Harm


It seems it occurred somewhere in those builds that we can no longer 
compile by default. Also see: 
https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg01024.html


i.e. 2.19.12 does NOT have the warning and I cannot compile another 
build until 2.19.38 where the warning is already manifest.


I tried to do what David suggested in that email thread above but was 
unsuccessful with cherry picking (more my skills than David's 
instructions though), so this is going to be tedious to bisect I expect.


James



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

Re: Old completion engraver bug

[James Lowe]

On 17/08/2020 21:41, Jon Arnold wrote:

Yes, this works well! Thanks very much.

On Sat, Aug 15, 2020 at 3:10 PM Thomas Morley 
wrote:


Am Sa., 15. Aug. 2020 um 18:49 Uhr schrieb Jon Arnold
:

Hi all-

I'm working on 14 pieces for my dissertation that use the completion
engravers heavily. I've just noticed a problem with lyrics alignment,

which

is documented in this old bug:
https://sourceforge.net/p/testlilyissues/issues/1928/

Is there any more current work around or hope of getting this fixed? It
shows up all over my pieces, and I am really hoping not to have to fix it
manually.

Thanks!

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

Hi,

probably below.
Please report back if it's a sufficient workaround worth adding to the
issue


#(define lyric-text-at-splitted-notes
;; Left-align LyricText if the NoteHead is splitted by
Completion_heads_engraver
   (lambda (grob)
 (let* (;; x-parent is usually NoteColumn
(x-parent (ly:grob-parent grob X))
;; NoteHeads (as array)
(x-parent-nhds-array (ly:grob-object x-parent 'note-heads))
;; NoteHeads (as list or #f)
(x-parent-nhds
  (if (ly:grob-array? x-parent-nhds-array)
  (ly:grob-array->list x-parent-nhds-array)
  #f)))
   ;; If NoteHeads are splitted by Completion_heads_engraver, the
   ;; 'autosplit-end prob-property is true
   (if x-parent-nhds
   (for-each
 (lambda (nhd)
   (let* ((cause (ly:grob-property nhd 'cause))
  (splitted? (ly:prob-property cause 'autosplit-end
#f)))
 (if splitted?
 (ly:grob-set-property! grob 'self-alignment-X LEFT
 x-parent-nhds)

\layout {
   \context {
   \Lyrics
   \override LyricText.before-line-breaking =
#lyric-text-at-splitted-notes
   }
}

mel = \relative c'' {
   c2 d1 c1 c2
}

lyr = \lyricmode {
   One -- two __ three -- four.
}

\score {
   <<
 \new Staff \new Voice = "normal" \mel
 \new Lyrics \lyricsto "normal" \lyr

 \new Staff <<
   \new Voice = "completion"
 \with {
   \remove "Note_heads_engraver"
   \consists "Completion_heads_engraver"
 }
   \mel
 >>
 \new Lyrics \lyricsto "completion" \lyr

 \new Staff \new Voice = "revisited" \relative c'' { c2 c~ c c~ c c }
 \new Lyrics \lyricsto "revisited" \lyr
   >>
}

Cheers,
   Harm


I've added this to

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

Note that we no longer use sourceforge to track our issues.

Regards

James


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

Re: Tie over barline, different stem directions, wrong default tie direction

[James Lowe]

On 21/08/2020 04:50, Owain Evans wrote:

% Ties over barline should have
% automatic behaviour of being up
% (if 1st note stemDown, 2nd note stemUp).
% works as expected in bar but not over barline
\version "2.20.0"

\relative c'' {

  b2 b4 b~ | % undesired behaviour
  b8 g g g g2 |
  b4 b~ b8 g g g % in bar works
  
  % e2 e8 g a b_~ | % this works

  % b b b b b2 |
  
  % g'2 g8 g g, g~ | % undesired behaviour

  % g g g g g2 |
}

Note after first seven bars uncommented, the first undesired behaviour goes 
away!


Thank you.

I have created

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

James


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

Re: Broken link in "Usage" manual

[James Lowe]

On 21/07/2020 08:52, Carlo Stemberger wrote:

line 777 has to be replaced by

@uref{https://github.com/jperon/lyluatex/blob/master/README.md,lyluatex}.

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=Documentation/usage/external.itely;h=6ccbffc8fea3d38cfbf2dcb6ce4d4db94c2c2f7b;hb=HEAD#l777


Thank you Carlo.

I have created a new issue for this;

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

James


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

Re: How to shift trill to below phrasing slur?

[James Lowe]

On 01/12/2020 21:42, Lukas-Fabian Moser wrote:

Hi Harm,


avoid-slur is the correct method:

%#(ly:set-option 'debug-skylines #t)

\score {
   {
 \time 12/8
 \relative c' {
   a8 b\( c a b c d e f d e f
   g a b g a b c2.
   \once \override Script.avoid-slur = #'inside
   d2.\trill \grace { c16 d }
   e2.\)
 }
   }
}

Though, for unrelated reasons I had enabled 'debug-skylines and
noticed the last part of the PhrasingSlur is not recognized from
skylines. See attached image (done with current master).
A bug?

Thus, cc-ing -devel.


sending to Bug (while there is overlap between dev and bug, it is better 
it be there than here I think - if nothing else, for historical purposes.



James



That happened with:

6d76be6462d3595851b0fe3c13ba238b5cdbbddf is the first bad commit
commit 6d76be6462d3595851b0fe3c13ba238b5cdbbddf
Author: Han-Wen Nienhuys 
Date:   Fri May 1 09:09:24 2020 +0200

    Build slur skyline out of segments rather than boxes.

    This provides more precise skylines. The regtest shows 11 images that
    changed, with tighter formatting for files involving slurs.

    https://sourceforge.net/p/testlilyissues/issues/5936
    http://codereview.appspot.com/577820043

Lukas





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

Re: Bad slur shape at line break with change of clef

[James Lowe]

On 13/12/2020 15:29, Jonas Hahnfeld via bug-lilypond wrote:

Hi all, Harm,

Am Sonntag, dem 13.12.2020 um 13:53 +0100 schrieb Thomas Morley:

Am Sa., 12. Dez. 2020 um 21:07 Uhr schrieb Timothy Lanfear :

The part of the slur before the line break is badly shaped when another
staff has a clef change.

\version "2.20.0"

<<
    \new Staff {
  R1*2
  r2 r4 r8 r16 r32 e''32( |
  \break
  d''8) r r4 r2 |
  R1*3
    }

    \new Staff {
  R1*3
  \clef "bass"
  R1*4
    }
  >>


--
Timothy Lanfear, Bristol, UK.

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

As far as I can tell it was introduced with

commit 16a328617e867892e8d5608f95bd6127196e03a2
Author: Keith OHara 
Date:   Sun Jun 17 21:45:26 2012 -0700

 Consistent bounds for slurs; issue 427 and 379

in 2.15.41.
[...]

I attach images with and without the revert.
While the revert fixes the reported problem, issues 427 and 379 are
present again.

Hopefully somebody with more knowledge, chimes in.

Could you create a GitLab issue for the bug report and transfer your
findings? This will make it easier to find the details in the future.


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

James



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

Re: Web site bug? -- OOoLilyPond

[James Lowe]

On 05/12/2020 11:16, Klaus Blum wrote:

Dear List members,


Hello,

In the “Easier editing” page [1], OOoLilyPond is listed in the “Other 
programs
no longer being actively developed” section but I think that it is 
active

again. Is this considered as a documentation bug?

1.http://lilypond.org/easier-editing.html 



Jun Tamura (he/him/his)


I am the current maintainer of the OOoLilyPond extension, and I can 
confirm that it is actively developed again.

All downloads and a verbose documentation can be found here:
https://github.com/OOoLilyPond

I would really be happy if the information on

http://lilypond.org/easier-editing.html 



could be updated to reflect the actual state of the extension.

Thanks in advance!

Best wishes,
Klaus Blum



Issue https://gitlab.com/lilypond/lilypond/-/issues/6072

has been created.


James


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