Re: git-cl upload issues

[Urs Liska]

Am 12.12.2013 11:48, schrieb David Kastrup:

Urs Liska lilyli...@googlemail.com writes:


Hi,

trying to upload a patch through git-cl I encounter two issues (one
merely being a documentation issue):

- I'm asked about my Google mail address and password.

No.  You are asked about your Google account name, the one you use in
the issue tracker, and its corresponding password.


   Providing the credentials of my lilypond googlemail address returns
invalid username or password.

I don't even _have_ a Googlemail address.


   But I _can_ login to codereview.appspot.com with these credentials

No idea about that one, but codereview and issue tracker might be
different.


Sorry for this. But when I noticed I couldn't send my message here I 
noticed that I had somehow managed to change my password recently ...


So this one is obsolete. Patch uploaded ;-)




- When the editor fires up to edit the review message I was first
completely lost
   and had to read through the git-cl script to determine that it was
vi I was faced.

You should likely configure your EDITOR variable.


Yes, that's it.
Then this should be mentioned in the CG.
See https://codereview.appspot.com/41310043

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

Re: Spacing/collision behaviour of NullVoice

[Urs Liska]

Am 17.12.2013 11:16, schrieb Trevor Daniels:


Urs Liska wrote Tuesday, December 17, 2013 9:01 AM


However I noticed a behaviour I wouldn't have expected:

Try out the following snippet:

soprano = \relative c' { c e g c }
verse = \lyricmode { This is my song }

\score {
   \new Staff 
  %\soprano
  { \oneVoice r4. r4 r4. }
 \new NullVoice = aligner \soprano
 \new Lyrics \lyricsto aligner \verse
   
   \layout {}
}

The rests are placed wrongly, obviously avoiding _something_.


NullVoice has had a checkered history, and has never worked
perfectly in all situations.  The current implementation is the best
so far, but still has a restriction which I quote from the NR:

The NullVoice context must be inside a Staff context, and should
only contain notes that are already being displayed in that staff, and
in the same octave. Otherwise the NullVoice may interact with the
printed voices in unexpected ways. For example, arbitrary notes in
the NullVoice may cause accidentals to appear (or disappear) on the
staff.

and implied, I think, at the same musical moment.

See 
http://www.lilypond.org/doc/v2.17/Documentation/notation/techniques-specific-to-lyrics#index-NullVoice

It looks like you have found a further restriction relating to rests.

Trevor



What about changing that to
For example, arbitrary notes in the NullVoice may arbitrarily move 
rests or cause accidentals to appear (or disappear) on the staff.

?

Urs



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

Re: Spacing/collision behaviour of NullVoice

[Urs Liska]

Am 17.12.2013 12:09, schrieb Trevor Daniels:


Urs, you wrote Tuesday, December 17, 2013 10:50 AM


What about changing that to
For example, arbitrary notes in the NullVoice may arbitrarily move
rests or cause accidentals to appear (or disappear) on the staff.
?


I see David's already had some thoughts about this and has raised
an issue.  Let's wait a little.

Trevor


OK

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

\parenthesize collision with dots

[Urs Liska]

If I parentesize a dotted note with

{ \parenthesize f'2. }

the right paren collides with the dot.

Urs
attachment: document.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \parenthesize collision with dots

[Urs Liska]

Am 18.12.2013 07:15, schrieb Mike Solomon:

On Dec 18, 2013, at 1:00 AM, Urs Liska lilyli...@googlemail.com wrote:


If I parentesize a dotted note with

{ \parenthesize f'2. }

the right paren collides with the dot.

Urs

Do you want the dot to shift to avoid the collision or the parenthesis to 
encompass the dot?

Cheers,
MS


Hm, from the example itself it would seem better to shift the dot, but 
I'm not sure about the tradeoffs when you have a more complex situation, 
i.e. with more than one dot, e.g.


{  \parenthesize f'2. a' }

Urs

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

Re: \parenthesize collision with dots

[Urs Liska]

Am 20.12.2013 21:25, schrieb James:

On 18/12/13 06:18, Urs Liska wrote:

Am 18.12.2013 07:15, schrieb Mike Solomon:

On Dec 18, 2013, at 1:00 AM, Urs Liska lilyli...@googlemail.com wrote:


If I parentesize a dotted note with

{ \parenthesize f'2. }

the right paren collides with the dot.

Urs

Do you want the dot to shift to avoid the collision or the
parenthesis to encompass the dot?

Cheers,
MS


Hm, from the example itself it would seem better to shift the dot, but
I'm not sure about the tradeoffs when you have a more complex
situation, i.e. with more than one dot, e.g.

{  \parenthesize f'2. a' }

Urs

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


Well there was

http://code.google.com/p/lilypond/issues/detail?id=155

Is this applicable? If so we could change the subject to reflect dots
and accidentals - I don't know if dots and accidentals are the same
'family' of attached objects or if it warrants a separate tracker.

James


From a user's perspective I'd say it is _one_ issue that \parenthesize 
should take care of what to enclose. However, I don't know if these are 
two different things from the implementation POV (i.e. if the two 
problems can/should be solved together).



Urs


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

Re: Double transpose when in tags within music function

[Urs Liska]

Am 09.01.2014 12:55, schrieb Ole V. Villumsen:

Expected behaviour of the example below: engrave a d (transpose the c to d).
Actual behaviour: engraved an f. Seems to have done both of the
transpositions described in the two different tags in the music function
(transposed c to d, then to f, or the other way around).

\version 2.18.0

myTranspose =
   #(define-music-function(parser location theMusic) (ly:music?)
  #{
 \tag #'cd { \transpose c d #theMusic }
 \tag #'df { \transpose d f #theMusic }
  #})

{ \keepWithTag #'cd { \myTranspose { c'1 } } }

The problem seems to be only when the tags are inside a music function (if
this is not supposed to work, an appropriate error message should be given).
The problem seems to be only with transposition; other music I put inside
the tags gets filtered as expected.





If you replace

#theMusic

with

$theMusic

it works as expected.

But I'm sure David can explain you why.

Urs

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

Define custom/new \accidentalStyles (dodecaphonic minus repeated notes)

[Urs Liska]

Hi,

searching the docs and the lilypond-user archive I couldn't find any 
relevant information.


I am looking for a custom \accidentalStyle. Actually I think this is 
quite commonly used, so it would also seem like a useful addition to 
LilyPond proper.


a)
Every note gets an explicit accidental (including a natural),
as in the 'dodecaphonic style,
_except_ when a note is repeated immediately in the same voice.

That is:
{ c fis c c fis } should be printed as in the attached image, like
{ c! fis! c! c fis! } (note the missing ! after the last c

The only reference to a similar (same?) request I found was this:
http://lists.gnu.org/archive/html/lilypond-user/2007-02/msg00667.

###

When looking into music-functions.scm and its set-accidental-style I see

 ((equal? style 'dodecaphonic)
  (set-accidentals-properties #f
  `(Staff ,(lambda (c p bn mp) '(#f . #t)))
  '()
  context))


So it seems the way to go to make a copy of that definition (e.g. with 
comparing against 'dodecaphonic-no-repeat) and modifying the definition.


Unfortunately I don't have a clue how to proceed. Any trials are simply 
anwered by errors, so I'd prefer not to _try_ but to do at least 
_informed guesses_ ;-)


I assume that the
`(Staff
expression returns the
context pitch barnumber measureposition
arguments for
set-accidental-properties
so this seems the place to define the right arguments.

Unfortunately I haven't _fully_ understood lambda expressions and 
_barely_ understood quoting and unquoting.


So I'd be glad about hints/explanations/solutions to

a)
create a differing but valid argument list at all and
b)
determining which '(#f . #t) combinations to use for my purpose.

TIA
Urs
attachment: document.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Default padding of portato dashes

[Urs Liska]

Hi,

I'm so often adjusting the padding of portato dashes (increasing the 
padding) that I'd like to ask if we should change the built-in default 
values for that.


Opinions?

Urs

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

Re: Slur padding on dotted notes

[Urs Liska]

Am 12.02.2014 12:48, schrieb James:

On 12/02/14 00:06, Jay Anderson wrote:

\score {
   \new Staff \relative c''' {
 %non-dotted
 \time 4/4
 g4( f) g( a) |
 g4~ g a~ a |

 %dotted
 \time 12/8
 g4.( f) g( a) | %Slurs pushed further away than necessary.
 g4.~ g a~ a | %Ties look ok to me.
   }
}

Hmm..

Looks OK to me.

Attached is a png file for others to comment.

James



I agree with Jay, the slurs in the first bar of the second system are 
too far away from the notes.


Urs

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

Re: Support german notation

[Urs Liska]

Thomas Scharkowski t.scharkow...@t-online.de schrieb:
Sorry,

his and hisis do work, as opposed to heses, which does not.
There is no hes :-)


Yeah, _if_ one would consider this a bug then it would be in the German naming 
conventions outside of LilyPond :-)


 Original-Nachricht 

 \language deutsch
 {h his hisis asas}


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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: treble clef looks horrible in sizes smaller than 20

[Urs Liska]

Am 24.02.2014 22:36, schrieb Karol Majewski:

\version 2.19.2

#(set-global-staff-size 18)

\clef treble



For the sake of reference: The source of the problem seems to have been 
identified:

http://lists.gnu.org/archive/html/lilypond-devel/2014-02/msg00238.html

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

Re: dodecaphonic-first accidental style

[Urs Liska]

Am 25.03.2014 11:59, schrieb James:

On 24/03/14 14:45, Rutger Hofman wrote:
On 03/24/2014 01:50 PM, Gilberto Agostinho wrote: Gilberto Agostinho 
wrote

The correct syntax is with the s [...]


I meant without without the s, as in repeat and NOT repeats
Rutger Hofman-2 wrote

[...]
As a fix, I made a small addition to music-functions.scm to add a
dodecaphonic-first accidental style. Patch against 2.17.18-1 attached.
[...]
Using dodecaphonic-first and adding ! here and there works fine for 
me.


I already apologize for replying to an old post (almost 1 year 
old!), but I

am really interested in this dodecaphonic-first accidental style. The
problem is I do not know how to deal with this .patch file!


Right, so there is a new style dodecaphonic-no-repeat from 2.19.3 
onwards. But it does something else than the style dodecaphonic-first 
that I wrote about, long ago. dodecaphonic-no-repeat suppresses 
accidentals for immediately repeated notes. dodecaphonic-first 
suppresses accidentals for any notes that already occurred earlier in 
the bar. My opinion is that there is still good use for 
dodecaphonic-first; the main reason is that wiping out undesired 
accidentals leaves visible traces because it consumes horizontal 
space, whereas adding occasional forced accidentals works fully as 
desired.


I would love it if the dodecaphonic-first style can be patched into 
lilypond; not only for the Greater Good, but also to relieve me from 
applying it to each and every lilypond release, and maintaining it 
across changes...


I renewed the patch for versions from 2.19.3 upwards. It is attached 
(pre-2.19.3 and 2.19.3 onwards; it used to be a reverse-patch, no 
longer now). It is extremely small. I also keep it in my github repo 
for lilypond additions, in the patches/ dir:


https://github.com/rfhh/lily-contribs

That repo currently also contains my converter from NIFF to lilypond 
(and the NIFF sdk, with 64-bit patch), and an upgraded version of 
Han-Wen's pmx2ly converter that I used to prepare an edition of 
Bach's BWV 146/1052a (on IMSLP).


Rutger






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/dodecaphonic-first-accidental-style-tp141907p160773.html

Sent from the User mailing list archive at Nabble.com.

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





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

adding 'bug'

I've created http://code.google.com/p/lilypond/issues/detail?id=3889

However if you want a proper review/test can you upload to reitveld as 
per our process else this won't get the review it might.


If you need help on doing this let us know.


That's timing, isn't it?



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: dodecaphonic-first accidental style

[Urs Liska]

Am 25.03.2014 11:59, schrieb James:

On 24/03/14 14:45, Rutger Hofman wrote:
On 03/24/2014 01:50 PM, Gilberto Agostinho wrote: Gilberto Agostinho 
wrote

The correct syntax is with the s [...]


I meant without without the s, as in repeat and NOT repeats
Rutger Hofman-2 wrote

[...]
As a fix, I made a small addition to music-functions.scm to add a
dodecaphonic-first accidental style. Patch against 2.17.18-1 attached.
[...]
Using dodecaphonic-first and adding ! here and there works fine for 
me.


I already apologize for replying to an old post (almost 1 year 
old!), but I

am really interested in this dodecaphonic-first accidental style. The
problem is I do not know how to deal with this .patch file!


Right, so there is a new style dodecaphonic-no-repeat from 2.19.3 
onwards. But it does something else than the style dodecaphonic-first 
that I wrote about, long ago. dodecaphonic-no-repeat suppresses 
accidentals for immediately repeated notes. dodecaphonic-first 
suppresses accidentals for any notes that already occurred earlier in 
the bar. My opinion is that there is still good use for 
dodecaphonic-first; the main reason is that wiping out undesired 
accidentals leaves visible traces because it consumes horizontal 
space, whereas adding occasional forced accidentals works fully as 
desired.


I would love it if the dodecaphonic-first style can be patched into 
lilypond; not only for the Greater Good, but also to relieve me from 
applying it to each and every lilypond release, and maintaining it 
across changes...


I renewed the patch for versions from 2.19.3 upwards. It is attached 
(pre-2.19.3 and 2.19.3 onwards; it used to be a reverse-patch, no 
longer now). It is extremely small. I also keep it in my github repo 
for lilypond additions, in the patches/ dir:


https://github.com/rfhh/lily-contribs

That repo currently also contains my converter from NIFF to lilypond 
(and the NIFF sdk, with 64-bit patch), and an upgraded version of 
Han-Wen's pmx2ly converter that I used to prepare an edition of 
Bach's BWV 146/1052a (on IMSLP).


Rutger






--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/dodecaphonic-first-accidental-style-tp141907p160773.html

Sent from the User mailing list archive at Nabble.com.

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





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

adding 'bug'

I've created http://code.google.com/p/lilypond/issues/detail?id=3889

However if you want a proper review/test can you upload to reitveld as 
per our process else this won't get the review it might.


If you need help on doing this let us know.



We now have issue
https://code.google.com/p/lilypond/issues/detail?id=3889
and patch
https://code.google.com/p/lilypond/issues/detail?id=3890

What is the correct way to deal with this?
3889 should be closed, marked as duplicate or merged in 3890.
I'd like to learn how to do that and do it myself rather than simply 
asking someone to do it.


Urs


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

Re: dodecaphonic-first accidental style

[Urs Liska]

Am 26.03.2014 11:16, schrieb Phil Holmes:

What is the correct way to deal with this?
3889 should be closed, marked as duplicate or merged in 3890.
I'd like to learn how to do that and do it myself rather than simply 
asking someone to do it.


Urs


Change the status to duplicate.  There will then be a box asking which 
issue to merge with.


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

\voiceOne rest positioning

[Urs Liska]

Hi,

I've just updated an example on the German Wikipedia
http://de.wikipedia.org/wiki/Notensatzprogramm#Text

and noticed that the position of the initial \voiceOne rest is suboptimal.
Compare LilyPond's output with that of Score and Amadeus which are both 
better.
I have no clue about the Score input but that of Amadeus is definitely 
default placement.


Of course it is trivial to write a pitched rest here, but I think the 
default placement should be improved. This is also in the context of 
Daniel Spreadbury's recent post about their rest positioning algorithm.


If I write a \voiceOne rest it will be placed that far to the top, even 
if there are only spacer rests in the other voice.
I don't know how that positioning is realized, but I think the rest 
should be placed much lower by default, just with the option to move 
upwards to avoid collisions.


I think that's the current behaviour anyway, so the solution might be 
one of the following:
- place \voiceXXX rest exactly as \oneVoice, just define the direction 
where they move for collision handling.
  (this would also eliminate the problem of having to switch to 
\oneVoice for a single common rest).
- try to determine the pitches before and after the rest and place it in 
the middle (if collision handling allows).


Urs

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

Re: \voiceOne rest positioning

[Urs Liska]

Am 08.04.2014 11:13, schrieb Phil Holmes:
Urs Liska lilyli...@googlemail.com wrote in message 
news:5343080e.4060...@googlemail.com...

Hi,

I've just updated an example on the German Wikipedia
http://de.wikipedia.org/wiki/Notensatzprogramm#Text

and noticed that the position of the initial \voiceOne rest is 
suboptimal.
Compare LilyPond's output with that of Score and Amadeus which are 
both better.
I have no clue about the Score input but that of Amadeus is 
definitely default placement.


Of course it is trivial to write a pitched rest here, but I think the 
default placement should be improved. This is also in the context of 
Daniel Spreadbury's recent post about their rest positioning algorithm.


If I write a \voiceOne rest it will be placed that far to the top, 
even if there are only spacer rests in the other voice.
I don't know how that positioning is realized, but I think the rest 
should be placed much lower by default, just with the option to move 
upwards to avoid collisions.


I think that's the current behaviour anyway, so the solution might be 
one of the following:
- place \voiceXXX rest exactly as \oneVoice, just define the 
direction where they move for collision handling.
  (this would also eliminate the problem of having to switch to 
\oneVoice for a single common rest).
- try to determine the pitches before and after the rest and place it 
in the middle (if collision handling allows).


Urs


I'd tend to agree.  If you look at the attached, you'll see that the 
placement algorithm is rest-length sensitive.


Yes. Basically it does what it should, only the default position 
should start considerably lower, perhaps equal to the \oneVoice position.


What is missing from your example are rests that have spacers in the 
other voice (the situation of merged rests).


Urs

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

Re: \voiceOne rest positioning

[Urs Liska]

Am 08.04.2014 13:15, schrieb Phil Holmes:
Urs Liska lilyli...@googlemail.com wrote in message 
news:5343d37c.4070...@googlemail.com...

Am 08.04.2014 11:13, schrieb Phil Holmes:
Urs Liska lilyli...@googlemail.com wrote in message 
news:5343080e.4060...@googlemail.com...

Hi,

I've just updated an example on the German Wikipedia
http://de.wikipedia.org/wiki/Notensatzprogramm#Text

and noticed that the position of the initial \voiceOne rest is 
suboptimal.
Compare LilyPond's output with that of Score and Amadeus which are 
both better.
I have no clue about the Score input but that of Amadeus is 
definitely default placement.


Of course it is trivial to write a pitched rest here, but I think 
the default placement should be improved. This is also in the 
context of Daniel Spreadbury's recent post about their rest 
positioning algorithm.


If I write a \voiceOne rest it will be placed that far to the top, 
even if there are only spacer rests in the other voice.
I don't know how that positioning is realized, but I think the rest 
should be placed much lower by default, just with the option to 
move upwards to avoid collisions.


I think that's the current behaviour anyway, so the solution might 
be one of the following:
- place \voiceXXX rest exactly as \oneVoice, just define the 
direction where they move for collision handling.
  (this would also eliminate the problem of having to switch to 
\oneVoice for a single common rest).
- try to determine the pitches before and after the rest and place 
it in the middle (if collision handling allows).


Urs


I'd tend to agree.  If you look at the attached, you'll see that the 
placement algorithm is rest-length sensitive.


Yes. Basically it does what it should, only the default position 
should start considerably lower, perhaps equal to the \oneVoice 
position.


What is missing from your example are rests that have spacers in 
the other voice (the situation of merged rests).


Urs


I've not done it, but I would expect rests in voiceOne to be 
positioned the same, whether voiceTwo has notes or spacers.




Yes it does. I just thought that this could be added for the image to be 
used as an example.


Best
Urs


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

Re: add lilypondblog.org to contact page?

[Urs Liska]

Am 22.04.2014 18:48, schrieb Federico Bruni:

In this page:
http://lilypond.org/contact.html

we currently have a link to news.lilynet.net, which have been down for
months.
I've already opened an issue about lilynet.net links:
http://code.google.com/p/lilypond/issues/detail?id=3903

This is to propose to replace that section (Stay informed) with
http://lilypondblog.org/, which in almost an year has proven to be a
serious project (regular posts, website working, etc.).


My efforts to review lilypond.org has been slowed down considerably. But 
I still intend to go through the rest of the site, and then I'll also 
come to the Community section which deserves some considerable 
restructuring anyway. I'll surely make a suggestion about including the 
blog then.


Best
Urs

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

Re: lilypond-book on Windows needs LaTeX?

[Urs Liska]

Am 21.05.2014 13:44, schrieb Federico Bruni:

I'm trying to verify issue 3874. I'm not a Windows user but I have the
chance to use a Windows machine at work.

When I try to compile the musicological example in Usage, I get a warning
about pdflatex being a command not detected. I guess that LaTeX is not
bundled and should be installed separately. What about saying it explicitly
here?
http://lilypond.org/doc/v2.19/Documentation/usage/lilypond_002dbook

Please add also a link to the recommended website where you can download
LaTeX. First result of google is:
http://miktex.org/about

I never had this problem on Linux because LaTeX is a dependency of lilypond.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Does lilypond-book run latex also when dealing with HTML files?
Of course the text could be clarified, but basically I'd say that anyone 
wanting to insert pictures in latex documents should know that he needs 
latex for that ...

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

Website language selection

[Urs Liska]

Hi,

I'm not sure if that has been discussed before (I think it has), but I'm 
quite annoyed with the automatic language selection on lilypond.org.
I don't know how this function is realized, but I would strongly prefer 
if clicking on a link would always open a page in the same language.


As it stands, it falls back to my browser language for each new page.

If someone points me in the right direction I _might_ be able to look 
into it myself and create a patch. But that depends on which direction 
this actually is (i.e. if I'm proficient enough in the area).


Best
Urs

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

Re: Website language selection

[Urs Liska]

Am 30.05.2014 10:38, schrieb Phil Holmes:
Urs Liska lilyli...@googlemail.com wrote in message 
news:53883f91.6000...@googlemail.com...

Hi,

I'm not sure if that has been discussed before (I think it has), but 
I'm quite annoyed with the automatic language selection on lilypond.org.
I don't know how this function is realized, but I would strongly 
prefer if clicking on a link would always open a page in the same 
language.


As it stands, it falls back to my browser language for each new page.

If someone points me in the right direction I _might_ be able to look 
into it myself and create a patch. But that depends on which 
direction this actually is (i.e. if I'm proficient enough in the area).


Best
Urs


Have you read http://www.lilypond.org/website/misc/browser-language ?



Yes, and I find it inacceptable to base the website language on the 
browser language.
Concretely: I am German, and naturally my browser is set to German. But 
I want to read lilypond.org or its manuals in English, and for that I 
would have to set my browser language to a different one each time 
before visiting lilypond.org. Or clicking on the manual page language 
each time.


Personally I don't like at all that way of the service thinking for 
me, guessing what is best for me. But I'd be content with the 
possibility to switch the functionality off manually, i.e. by explicitly 
selecting a language which should then be remembered at least for the 
time of my current visit.


Best
Urs

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

Re: Possible bug with \oneVoice involving rests

[Urs Liska]

Am 02.06.2014 09:33, schrieb Brian Eve:

{
\clef bass
\compressFullBarRests
\override Rest #'staff-position = #0
   R1*6

{
   \voiceOneg4. f e4 }
   \new Voice {
   \voiceTwo e4. d d4 }



\oneVoice  a1
   R1*6

{
   \voiceOneb8 }
   \new Voice {
   \voiceTwo e8 }



   r8 r4 r2
   R1*6
   R1
   r
   R
}


No, it's because in that form of temporary polyphonc section the first 
of the parallel voices is continued after the 


In your example that's \voiceOne.

So you have to provide a \oneVoice after the 
That's intended and documented behaviour.

Best
Urs

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

Re: Possible bug with \oneVoice involving rests

[Urs Liska]

Am 02.06.2014 09:51, schrieb Brian Eve:

\version 2.18.2-1

{
\clef bass
\compressFullBarRests
\override Rest #'staff-position = #0
   R1*6
g4. e   f d  e4 d 
   a1
   R1*6
b8 e8 
   r8 r4 r2
   R1*6
   R1
   r
   R
}


No, that's very wrong code.

With these   you are actually telling LilyPond to print independent 
voices while you want to write chords.
This may work in your example but you would definitely run into problems 
very soon.



\version 2.18.2-1


{

\clef bass

\compressFullBarRests

R1*6

g e 4.  f d  e d 4

a1

R1*6

b e 8

r8 r4 r2

R1*6

R1

r

R

}


Is the correct way to write your example.
But I assume this is not what you _want_ - you will want to have the 
polyphonic part with independent stems.



This is the smartest way to write what you want because it makes the 
voicing right automatically:



\version 2.18.2-1


{

\clef bass

\compressFullBarRests

R1*6



{

g4. f e4

} \\

{

e4. d d4

}



a1

R1*6



{

b8

} \\

{

e8

}



r8 r4 r2

R1*6

R1

r

R

}


This construct (with the \\) creates \voiceOne, \voiceTwo etc. implicitly.


Read
http://lilypondblog.org/2013/07/voice-contexts-in-temporary-polyphonic-sections/
and particularly the chapter from the Notation Reference that is linked 
in that article.



HTH
Urs

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

Re: typo in LM 2.18/2.19 (Contributor's guide)

[Urs Liska]

Am 22.06.2014 12:51, schrieb Federico Bruni:

Thanks Pierre
There's already a patch:
https://codereview.appspot.com/109140043/


And it's already pushed to staging :-)


  Il 22/giu/2014 00:13 Pierre Perol-Schneider 
pierre.schneider.pa...@gmail.com ha scritto:


I'm not top posting.

Hi Squad,

See :

http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-suggestions

Go to :
Contributions that contain examples using overrides

3rd paragraph :
[...] Snippets that don’t have the “docs” tage [...]

Cheers,
Pierre
___
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: accidentalStyle dodecaphonic-no-repeat

[Urs Liska]

Am 05.07.2014 15:50, schrieb Jean-Charles Malahieude:

Hi all,

On my way in updating translations, I notice that this style seems to 
not do what it claims.


Look at the two successive examples in NR-1.1.3 Automatic accidentals, 
both styles dodecaphonic and dodecaphonic-no-repeat: there is no 
difference at all.


That's right, this is a bug, and I will look into it. I'm not on the 
right PC to check right now, but I strongly assume it's an issue with 
the doc example and not with the accidental style.


Urs



Cheers,
Jean-Charles

___
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: accidentalStyle dodecaphonic-no-repeat

[Urs Liska]

Am 05.07.2014 16:49, schrieb Urs Liska:

Am 05.07.2014 15:50, schrieb Jean-Charles Malahieude:

Hi all,

On my way in updating translations, I notice that this style seems to 
not do what it claims.


Look at the two successive examples in NR-1.1.3 Automatic 
accidentals, both styles dodecaphonic and dodecaphonic-no-repeat: 
there is no difference at all.


That's right, this is a bug, and I will look into it. I'm not on the 
right PC to check right now, but I strongly assume it's an issue with 
the doc example and not with the accidental style.


Urs


It seems this accidental-style is actually broken.
The doc example is coded correctly, and testing the accidentalstyle in a 
document turns out the same result.


I know that it worked correctly when we added it, so it must have been 
broken later.

So it should be added as a bug.

To avoid misunderstandings:

cis d cis cis d

should print as

cis! d! cis! \once \omit Accidental cis d!


Urs

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

Re: unclear topic

[Urs Liska]

Am 07.07.2014 23:23, schrieb Federico Bruni:

2014-07-07 21:40 GMT+02:00 Michael Gabor i...@elala.de:


Dear Lilypond-Team,

In LM 2.18.2 german version under 2.7.3 Generalbaß at the end of the page
is an example on \bassFigureExtendersOn and -Off (as shown in the attached
PNG).

However, the lilypond output shows twice the same where there should be a
difference.
For the time being therefore I consider the example worthless.


You mean Notation Reference 2.7.3:
http://www.lilypond.org/doc/v2.18/Documentation/notation/figured-bass#entering-figured-bass

It seems that german manual 2.18.2 is not updated. But latest version is:
http://www.lilypond.org/doc/v2.19/Documentation/notation/figured-bass.de.html#entering-figured-bass




So this should be considered a bug in the German translation?

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

Problematic example in LM (was: Re: Multiple voices tie across barline into single voice?)

[Urs Liska]

Am 14.09.2014 17:34, schrieb Mark Stephen Mrotek:


Joey,

Tying notes across voices located at

http://www.lilypond.org/doc/v2.18/Documentation/learning/other-uses-for-tweaks

would be a good place to start.



Oh, looking at this I find the example is actually _wrong_.
The second image shows the side-effect of setting transparent = ##f to 
the tie formatting.

This is exactly why you should use Stem.stencil = ##f and Flag.stencil = ##f
(or \omit for both).

(CCing to bug-lilypond)

Best
Urs


Mark

*From:*lilypond-user-bounces+carsonmark=ca.rr@gnu.org 
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] *On Behalf 
Of *Joey Di Nardo

*Sent:* Sunday, September 14, 2014 8:23 AM
*To:* lilypond-u...@gnu.org
*Subject:* Multiple voices tie across barline into single voice?

Looking for a solution to something like the following:

{

%measure 1

\time 1/4



{\voiceOne r16 c8.~}

\\

{\voiceTwo  r8 e8~}



|

%measure 2

c e4

}

Anyone have any leads?

Thanks,

Joey



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


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

Fwd: Isolated durations and \pageBreak

[Urs Liska]

 Original-Nachricht 
Betreff:Isolated durations and \pageBreak
Datum:  Wed, 24 Sep 2014 19:50:33 +0200
Von:Davide Liessi davide.lie...@gmail.com
An: lilypond-u...@gnu.org lilypond-u...@gnu.org



Hi all.

Isolated durations don't behave well with \pageBreak.
The following example gives a failed barcheck warning and wrong output.

%
\version 2.19.13
\score {
  \new RhythmicStaff {
R1 |
\pageBreak
1~ |
8 r r4 r2 |
  }
}
%

Either commenting \pageBreak, adding an explicit pitch to 1~ or adding
an explicitly pitched note *after* the \pageBreak result in no
barcheck warnings and correct output.
Adding an explicitly pitched note *before* the \pageBreak still gives
the barcheck warning and wrong output.

Best wishes.
Davide

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



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

Re: Fwd: Isolated durations and \pageBreak

[Urs Liska]

Am 24.09.2014 22:11, schrieb David Kastrup:

Urs Liska lilyli...@googlemail.com writes:


 Original-Nachricht 
Betreff:Isolated durations and \pageBreak
Datum:  Wed, 24 Sep 2014 19:50:33 +0200
Von:Davide Liessi davide.lie...@gmail.com
An: lilypond-u...@gnu.org lilypond-u...@gnu.org



Hi all.

Isolated durations don't behave well with \pageBreak.
The following example gives a failed barcheck warning and wrong output.

%
\version 2.19.13
\score {
   \new RhythmicStaff {
 R1 |
 \pageBreak
 1~ |
 8 r r4 r2 |
   }
}
%

This example is actually problematic since there is no pitched note
anywhere before 1~.  The visuals will likely be ok but Midi, if any,
will have no pitch to go by.


OK, I can understand that it is a similar situation as with the 
ambiguous midi volume warnings. But then I'd expect a warning (or a 
misbehaviour) in that domain and not a change in the timing structure.


Urs



However, \pagebreak indeed disrupts the pitch/chord copying when one
corrects this, for example by replacing R1 with c1.


Either commenting \pageBreak, adding an explicit pitch to 1~ or adding
an explicitly pitched note *after* the \pageBreak result in no
barcheck warnings and correct output.
Adding an explicitly pitched note *before* the \pageBreak still gives
the barcheck warning and wrong output.

Yup.




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

Ugly collision between dynamics and crossStaff stem

[Urs Liska]

Hi bug-squad,

attached you'll find source and image of an ugly collision between 
dynamics and a cross-staff stem.

The image is from current master but the issue is the same with 2.18.2.

Thanks for adding an issue report.

Urs
\version 2.19.14

\layout {
  \context {
\PianoStaff
\consists #Span_stem_engraver
  }
}

\score {
  \new PianoStaff 
\new Staff {
  \voiceTwo
  \crossStaff e'8 \p
}
\new Staff {
  \clef bass
  e8
}
  
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Incorrect example in Vocal Music documentation

[Urs Liska]

I think it's the other way round. This syntax changed between 2.16 an 2.18.
So I assume he is usong 2.16 and reading 2.18 or 2.19.

HTH
Urs

Am 24. Oktober 2014 14:27:45 MESZ, schrieb pkx166h pkx1...@gmail.com:
On 24/10/14 13:10, Greg Swinford wrote:
 There is an error in the example given on the following documentation
page:

http://lilypond.org/doc/v2.18/Documentation/notation/opera-and-stage-musicals#dialogue-over-music

 \override LyricText.self-alignment-X = #LEFT should read
 \override LyricText #'self-alignment-X = #LEFT

 otherwise the following error occurs:

 error: syntax error, unexpected '.', expecting SCM_FUNCTION or
 SCM_IDENTIFIER or SCM_TOKEN
\with { \override LyricText
   .self-alignment-X = #LEFT }

 I presume the same error would occur with the font-shape definition
above
 this too, but I haven't tested this.

 Thanks,
 Greg.

What version of LilyPond are you using here?

If you are using 2.19 then the example is different in that version's 
documentation (as far as I can tell).

http://lilypond.org/doc/v2.19/Documentation/notation/opera-and-stage-musicals#dialogue-over-music


Any example in the documention where we show both the output AND the 
input that created that output, implies that the version of LilyPond 
that was used to create the example is the same as the documentation is

for and used the same input.

I.e. the example you refer to was generated by LilyPond 2.18.2 for the 
2.18 documentation. That's how we build the doc.

So I can only guess you are using a later version of LP than these 
documents were built from and that can only be if you are using 2.19.

I think.

Could you clarify this?

James

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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Segfault from unusual time signatures

[Urs Liska]

Am 26.10.2014 21:19, schrieb Dan Eble:

% This input caused a segfault on OS X Yosemite with Lilypond 2.19.15.
\version 2.19.0
\new Staff {
   \relative d' {
 \time 8/1024 d128 |
 \time 9/1 d1
   }
}




Compiled without problem on a build from current master (Debian Linux)

Urs

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

Re: Segfault from unusual time signatures

[Urs Liska]

Am 26.10.2014 21:39, schrieb David Kastrup:

Urs Liska lilyli...@googlemail.com writes:


Am 26.10.2014 21:19, schrieb Dan Eble:

% This input caused a segfault on OS X Yosemite with Lilypond 2.19.15.
\version 2.19.0
\new Staff {
\relative d' {
  \time 8/1024 d128 |
  \time 9/1 d1
}
}



Compiled without problem on a build from current master (Debian Linux)

You are both omitting the most relevant detail: 32bit or 64bit system?


Sorry. In my case: 32bit.






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

\partcombine, trill spanner and acciaccatura

[Urs Liska]

Hi all,

I'm experiencing an issue with \partcombine.

Consider the attached snippet and image.
When there is an acciaccatura in one of the voices the trill spanner 
doesn't stop in the \partcombine-d voice.


It doesn't matter in which voice the acciaccatura is. \appoggiatura has 
the same effect while \grace works well.


Is there anything wrong with the code or is this a bug?

Any ideas?

Urs
\version 2.19.16

one = \relative c'' {
  c2 \startTrillSpan
  c2 \stopTrillSpan
}

two = \relative c' {
  c2 
  \acciaccatura { b16 c d }
  c2 
}

\score {
  
\new Staff \one
\new Staff \two
\new Staff \partcombine \one \two
  
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \partcombine, trill spanner and acciaccatura

[Urs Liska]

Am 28.10.2014 04:33, schrieb Dan Eble:

Urs Liska ul at openlilylib.org writes:


Hi all,

I'm experiencing an issue with \partcombine.

Consider the attached snippet and image.
When there is an acciaccatura in one of the voices the trill spanner
doesn't stop in the \partcombine-d voice.

It doesn't matter in which voice the acciaccatura is. \appoggiatura has
the same effect while \grace works well.

Looks like it has something to do with the part combiner state.

\version 2.19.15

one = \relative c'' {
   c2 \startTrillSpan
   c2 \stopTrillSpan
}

two = \relative c' {
   c2
   \partcombineApart c2
}

\score {
   
 \new Staff \one
 \new Staff \two
 \new Staff \partcombine \one \two
   
}


Thank you.

I don't see through that completely yet, but for now it helps me get the 
score in a state to be proof-read at least (partcombining will be 
treated thoroughly at a later point).


Best
Urs

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

Re: Pitched rest bug [was: A pause in 3/4 measure]

[Urs Liska]

Am 1. November 2014 21:55:01 MEZ, schrieb Trevor Daniels 
t.dani...@treda.co.uk:

Thomas Morley wrote Saturday, November 01, 2014 12:05 PM

 Using d1*3/4\rest has a draw-back:
 The rest will change it's position, if \transpose is used.

Copying to bug list.  This seems like a bug to me.  Do others agree?  I
can't see a relevant issue in the tracker.

Trevor

Is it not desired behaviour that a pitched rest is affected by transposition? 
I find thst very plausible. 

Urs

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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Time signature position broken

[Urs Liska]

With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)

compiling

\version 2.19.16

{
  c'1
}

results in the attached output. This is not related to the concrete 
example but a general issue: The time signature is printed completely at 
the left edge of the staff. I suspect it has something to do with recent 
time signature code changes?


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

Re: Issue 4205: Improve part combiner's rest analysis (issue 174610043 by nine.fierce.ball...@gmail.com)

[Urs Liska]

I don't know how to properly review this, but I checked against a 
current score I'm working on, and I see it removes one of the most 
annoying issues I had so far.


Consider this snippet:

\version 2.19.16
one = \relative c'' {
  c2 c
  \voiceOne
  r8 c b a g f e d
  c1
}

two = \relative c' {
  c2 c
  R1*2
}

\score {
  \new Staff \partcombine \one \two
}

This previously (incl. current master) resulted in the attached 
partcombine-fail-merge-rests.png, which is musical nonsense.

With the patch applied it results in partcombine-merge-rests.png.
So I think the patch does what it says (and helps me very much), so LGTM.

However, there's an issue with this example. I'm sure it's not related 
to the patch but an independent issue - but maybe you could try to fix 
that along with your patch?


When the partcombiner deals with a section that starts with different 
rests (the situation you improve in your patch) it fails to set the 
Voice number correctly. I even have the impression it actively sets it 
wrongly. The attached image shows that
- at the first moment of the measure the voices are set correctly: The 
quaver rest is \voiceOne, the full measure rest is \voiceTwo.

But the notes starting with the second quaver are obviously \oneVoice.

It is clear that the partcombiner actively sets the upper voice to 
\oneVoice because


\voiceOne r8 c b a g f e d


doesn't change the output while


r8 \voiceOne c b a g f e d


or


c8 c b a g f e d


both produce the correct result.


So:

Do you think you could tackle that in the context of your current patch?
Otherwise could please someone open a new issue for that (CCing to 
bug-lilypond)



Urs


Am 24.11.2014 06:12, schrieb nine.fierce.ball...@gmail.com:

Reviewers: ,

Description:
Issue 4205: Improve part combiner's rest analysis

Rests must begin and end simultaneously to be merged into the shared
voice.

Rests, skips, and multi-measure rests are kept apart even if they
begin and end simultaneously.

This does not produce ideal output in every case, but it avoids
producing musical nonsense.

Please review this at https://codereview.appspot.com/174610043/

Affected files (+131, -4 lines):
  A input/regression/part-combine-mmrest-shared.ly
  A input/regression/part-combine-silence.ly
  A input/regression/part-combine-silence-mixed.ly
  M scm/part-combiner.scm



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


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

Re: Issue 4205: Improve part combiner's rest analysis (issue 174610043 by nine.fierce.ball...@gmail.com)

[Urs Liska]

Am 25.11.2014 02:45, schrieb Dan Eble:

On Nov 24, 2014, at 04:11 , Urs Liska u...@openlilylib.org wrote:

I don't know how to properly review this, but I checked against a current score 
I'm working on, and I see it removes one of the most annoying issues I had so 
far.

I’m glad to hear that.  I still need to check my own scores.


When the partcombiner deals with a section that starts with different rests 
(the situation you improve in your patch) it fails to set the Voice number 
correctly. I even have the impression it actively sets it wrongly. The attached 
image shows that
- at the first moment of the measure the voices are set correctly: The quaver 
rest is \voiceOne, the full measure rest is \voiceTwo.
But the notes starting with the second quaver are obviously \oneVoice.

This is outside the scope of this patch.


OK, then I'll write another proper bug report for this.



The following might help work around some frustrating issues.  You can put 
whatever you like into the same voice the part combiner uses for solos.  It’s 
not pretty, but it removes uncertainty.

\version 2.19.15

one = \relative c'' {
  c2 c
  \voiceOne
  r8 c b a g f e d
  c1
}

two = \relative c' {
  c2 c
  R1*2
}

\score {
   \new Staff 
 \new Voice = solo {
   \override Stem.direction = #UP
   s1 s2 \override NoteHead.color = #red s2 \revert NoteHead.color
 }
 \partcombine \one \two
   
}
—
Dan


Is the following assumption correct?

At the beginning of m.2 the partcombiner treats the crotchet and the 
full measure rests as two voices.
At the second crotched, when \one begins to play notes this is 
considered solo because \two doesn't play at that moment.
When I explicitly instantiate a solo voice in the \score block this 
will be somehow merged with the voice implicitly created by the 
partcombiner.


OK. It seems this may be a way to fix all issues with the output but as 
you say it's not pretty. Actually I'd say it's inacceptably ugly. In my 
concrete score this would mean I'd have to write such a dummy voice for 
the 800 measure piece, for all partcombined instruments.


Best
Urs

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

partcombiner should not set solo when a rest is printed in the other voice

[Urs Liska]

Hi all,

consider the following \partcombine situation:
- voices are merged to a given point
- then voices start with different rests,
  followed by notes in one voice

\version 2.19.16

one = \relative c'' {
  c2 c
  \voiceOne % this doesn't affect the solo section at all
  r8
%\voiceOne % uncommenting this will make the voice look right
c b a g f e d
  c1
}

two = \relative c' {
  c2 c
  R1*2
}

\score {
  \new Staff \partcombine \one \two
}

Here part \two prints a full measure rest. Part \one would *currently* 
print nothing and will print a crotchet rest when issue 4205 has been 
pushed (the attached image is created with that patch applied).
When the crotchets in \one start, the partcombiner sets the upper voice 
to solo because \two isn't playing at that moment. But it should be 
set to the upper voice instead:


- We don't want to read Solo when there's *something* (i.e. the rest) 
printed in the other voice
- the line should be \voiceOne and not \oneVoice because there *is* the 
rest in \voiceTwo.


Please add this to the tracker (after a second pair of eyes has gone 
over it.


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

Re: Issue 4205: Improve part combiner's rest analysis (issue 174610043 by nine.fierce.ball...@gmail.com)

[Urs Liska]

Am 25.11.2014 14:50, schrieb Dan Eble:

On Nov 25, 2014, at 04:21 , Urs Liska u...@openlilylib.org wrote:

Is the following assumption correct?

At the beginning of m.2 the partcombiner treats the crotchet and the full 
measure rests as two voices.

Yes.  The part combiner directs those rests into voices “one” and “two”.


At the second crotched, when \one begins to play notes this is considered 
solo because \two doesn't play at that moment.

Yes.


OK. Thanks for confirming.
In the meantime I've already sent a new bug report to bug-lilypond:
http://lists.gnu.org/archive/html/bug-lilypond/2014-11/msg00071.html


When I explicitly instantiate a solo voice in the \score block this will be 
somehow merged with the voice implicitly created by the partcombiner.

Yes.  You could do the same with voices “one”, “two”, and “shared”.


Ah, yes, that's something I had intended to ask but forgot.
Maybe this may help me solving a few other issues in our score.


OK. It seems this may be a way to fix all issues with the output but as you say 
it's not pretty. Actually I'd say it's inacceptably ugly. In my concrete score 
this would mean I'd have to write such a dummy voice for the 800 measure piece, 
for all partcombined instruments.

In a work of that scale, I agree.


The scale of the score just makes it inacceptably impractical to use. 
But of course this is generally an area where one seems to need quite 
hacky approaches. And probably not one I'll write a glorifying blog post 
about ...




For my own work, which is mostly vocal and mostly short, I have modified the 
part combiner never to create solo sections.  When one part rests, both parts 
are engraved; when both parts rest, they are combined into one.  It sounds like 
this is probably not what you need, but if it would help you, I could give you 
a patch.  I do not know when I will be able to contribute it to Lilypond 
because I am trying to find a more general solution to part combiner 
limitations.


On first sight this sounds like a viable solution for my case, so I'd 
gladly try out the patch.
The problem is that I won't get (all) the contributors to run custom 
builds, so I'd have to direct them at patching their installation 
(assuming it's a Scheme-only patch), and I'm not so sure if that's 
something everybody would like ...


Best
Urs


—
Dan




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

Fwd: 3 new lilypond issues

[Urs Liska]

forwarding ...


 Ursprüngliche Nachricht 
Von: Jan Hakenberg jan.hakenb...@gmail.com
Gesendet: 6. Dezember 2014 07:35:15 MEZ
An: James pkx1...@gmail.com
CC: Urs Liska u...@openlilylib.org
Betreff: 3 new lilypond issues

Hi,

I briefly searched the open issues, but did not find the below
suggestions/observations listed.

My Platform: Windows 7
LilyPond: 2.19.15


1) 

In the docs
LilyPond Application Usage  1.2 Command-line usage
the command line parameter -dclip-systems
is explained by
Generate cut-out snippets of a score.

I think it would be helpful to add a remark that this parameter has no
effect unless
clip-regions are specified in the ly file.

Also, it might be worth mentioning that for the export to happen, the status
-dprint-pages is required (as opposed to -dno-print-pages)
The requirement is not necessarily intuitive since -dpreview works fine
with -dno-print-pages.

Testing command was for instance:
lilypond.exe -dno-print-pages -dclip-systems --png bwv0853_2.ly



2) 

no warning message is given if true or false values are replaced by
anything.
In the example below, the default value #t is chosen internally.

 =

c:\Program Files (x86)\LilyPond\usr\bin\lilypond.exe
-dinclude-book-title-preview=ANYTHING -dpreview --png bwv0853_2.ly
GNU LilyPond 2.19.15
Processing `bwv0853_2.ly'
Parsing...
Interpreting music...[8][16][24][32][40][48][56][64][72][80][88][88]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 2 or 3 pages...
Drawing systems...
Layout output to `bwv0853_2.ps'...
Converting to PNG...
Layout output to `bwv0853_2.preview.eps'...
Converting to PNG...
Success: compilation successfully completed

 =


3) 

-danti-alias-factor=1 works fine, but -danti-alias-factor=2
does not convert the output to the high quality images.
I think this might be a familar topic on Windows.

 =

c:\Program Files (x86)\LilyPond\usr\bin\lilypond.exe
-danti-alias-factor=2 --png bwv0853_2.ly
GNU LilyPond 2.19.15
Processing `bwv0853_2.ly'
Parsing...
Interpreting music...[8][16][24][32][40][48][56][64][72][80][88][88]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 2 or 3 pages...
Drawing systems...
Layout output to `bwv0853_2.ps'...
Converting to PNG...'pngtopnm' is not recognized as an internal or external
comm
and,
operable program or batch file.

fatal error: GS exited with status: 255

 =


thank you!
many greetings,
Jan
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Glyph fallback (Fwd: Re: Alternative fonts glyph support)

[Urs Liska]

Dear bug squad,

I second Davide's suggestion to add below point 2. as a feature request.

Urs

 Weitergeleitete Nachricht 
Betreff:Re: Alternative fonts glyph support
Datum:  Sat, 03 Jan 2015 11:19:32 +0100
Von:Davide Liessi davide.lie...@gmail.com
An: tisimst tisimst.lilyp...@gmail.com, lilypond-u...@gnu.org



Dear Abraham,

I think that a font should not contain glyphs from another font.
I also think that Emmentaler should be the fallback font in LilyPond, no
matter which font you choose in your document.
So the best solution in my opinion is:

1. For the time being, you should keep including Emmentaler glyphs in
your fonts.
2. LilyPond should be changed so that if it cannot find a glyph in the
selected font it uses the corresponding glyph from Emmentaler.
3. Once this is in place, you should remove all Emmentaler glyphs from
alternative fonts.

Can someone add point 2. as a feature request?

Best wishes.
Davide

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



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

Re: Retrieving information about breaks

[Urs Liska]

Hi David,

thanks, that works great.
It did *not* write to a file, but that's not the issue here.
The main point is that it listens to implicit break events.

Probably the page breaks are even irrelevant for my case: finding a way 
to recompile individual systems.


what it doesn't do yet is handle mid-measure breaks, but I know where I 
can look that up ;-)


So this isn't a feature request anymore ...

Best
Urs

Am 23.01.2015 um 17:42 schrieb David Nalesnik:

Hi Urs,

On Fri, Jan 23, 2015 at 9:33 AM, Urs Liska u...@openlilylib.org 
mailto:u...@openlilylib.org wrote:


Picking up that old thread seems better than starting a new one ...

By now I've reached a different state and would like to come back
to this issue with a very concrete question:
Is it possible to determine at which positions (in terms of
barnumber and measure-position) the final line breaks, page breaks
and page turns have been placed in LilyPond?
I'm sure this information has to be present at one point, but
someone (I think it may have been David Nalesnik) expressed the
opinion that engravers could only access explicit \break-s.

I would like to write out a log file containing all break points
of a given LilyPond run.


Here's a routine which will write the line breaks to a file.  Have to 
look into page breaks/turns.  (It may be that you need explicit page 
breaks/turns--then it's possible to read 'page-break-permission and 
'page-turn-permission.)


 \version 2.19.15

%% breaks

#(define out (open-output-file line-breaks.txt))

#(define (display-breaks grob)
   (if (and (grob::has-interface grob 'paper-column-interface)
(eq? #t (ly:grob-property grob 'non-musical)))
   (if (eq? 1 (ly:item-break-dir grob))
   (let* ((location (ly:grob-property grob 'rhythmic-location))
  (m (car location)))
 (format out Line beginning at measure ~a~% m)))
   (ly:message Need NonMusicalPaperColumn grob to determine line 
breaks.)))


\relative c'' {
  \override Score.NonMusicalPaperColumn.after-line-breaking = 
#display-breaks

  \repeat unfold 30 { c d e f }
}

Hope this helps--

David


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

Re: How to pack notes very tightly?

[Urs Liska]

Forwarding to bug-lilypond.
Could someone please verify this and create a tracker entry?

(It's not my code BTW)

Am 20. Januar 2015 08:20:25 MEZ, schrieb Steve Lacy sl...@slacy.com:
Thanks, Urs.

Reading your code, seems like it was just a convenience function for
setting SpacingSpanner.common-shortest-duration

Adding a simple:

  \override Score.SpacingSpanner #'common-shortest-duration =
#(ly:make-moment 1 4)

Got me to the density I was looking for.  (http://lilybin.com/qukbs5/3)

It's interesting (frustrating?) that the documentation on changing
horizontal spacing mentions setting base-shortest-duration to adjust
horizontal spacing (
http://www.lilypond.org/doc/v2.16/Documentation/notation/changing-horizontal-spacing),
but in fact, it seems as though common-shortest-duration is the
variable
that really needs to be tweaked.

Steve


On Mon, Jan 19, 2015 at 11:07 PM, Urs Liska u...@openlilylib.org wrote:



 Am 20. Januar 2015 07:47:20 MEZ, schrieb Steve Lacy
sl...@slacy.com:
 I'm transcribing a Mendelssohn score, and am trying to get Lilypond
to
 pack
 notes about as densely as they are in the original score.  For
example,
 trying to fit a snippet like this onto a single line:
 
 \version 2.16.2
 \language english
 \relative c''' {
   \key e \minor
   \mark \default
   \time 2/2
   b2-\f\(\times 2/3 { b8\!)[fs8-1(g8] a8[g8-3 fs8] } |
 \times 2/3 { g8-)[ds-1(e8]  fs8[e8 ds8] e8)[as,-1(b-2] c-3[b-2
as-1] |
   b8-1-)[fs(g]  a[g fs] } g-) e\(g) b_- |
   e8---4 e---0 g-- b-- e4.---0\sf(e8-.) |
   e2(\sf\ \times 2/3 { e8\!)[b8-2(c8] d8[c8 b8] } |
 }
 
 (http://lilybin.com/qukbs5/2)
 
 I've tried adding:
 
 \override SpacingSpanner #'base-shortest-duration = #(ly:make-moment
1
 1)
 
 But this seems to have no or only very little effect on the default
 spacing, even with make-moment up to 2/1 or higher.  For reference
I'd
 like
 the formatting to match something like this:
 
 [image: Inline image 1]
 
 I can get the desired result by adding a \noBreak at the end of
every
 bar
 but that's very laborious and makes the .ly file quite a bit uglier.
 (even using an alias like nb = { \noBreak })
 
 Are there other tricks for very densely formatted scores?
 
 Steve

 Have a look at

https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/adjust-horizontal-spacing
 and see if it helps.

 Urs
 
 


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


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

Re: How to pack notes very tightly?

[Urs Liska]

Am 20. Januar 2015 13:25:25 MEZ, schrieb James p...@gnu.org:
On 20/01/15 07:29, Urs Liska wrote:
 Forwarding to bug-lilypond.
 Could someone please verify this

Verify what precisely?

If what the NR states is wrong. Or if it needs enhancement by the other 
property.


James

and create a tracker entry?

 (It's not my code BTW)

 Am 20. Januar 2015 08:20:25 MEZ, schrieb Steve Lacy
sl...@slacy.com:
 Thanks, Urs.

 Reading your code, seems like it was just a convenience function for
 setting SpacingSpanner.common-shortest-duration

 Adding a simple:

   \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 1 4)

 Got me to the density I was looking for. 
(http://lilybin.com/qukbs5/3)

 It's interesting (frustrating?) that the documentation on changing
 horizontal spacing mentions setting base-shortest-duration to adjust
 horizontal spacing (

http://www.lilypond.org/doc/v2.16/Documentation/notation/changing-horizontal-spacing),
 but in fact, it seems as though common-shortest-duration is the
 variable
 that really needs to be tweaked.

 Steve


 On Mon, Jan 19, 2015 at 11:07 PM, Urs Liska u...@openlilylib.org
wrote:



 Am 20. Januar 2015 07:47:20 MEZ, schrieb Steve Lacy
 sl...@slacy.com:
 I'm transcribing a Mendelssohn score, and am trying to get
Lilypond
 to
 pack
 notes about as densely as they are in the original score.  For
 example,
 trying to fit a snippet like this onto a single line:

 \version 2.16.2
 \language english
 \relative c''' {
   \key e \minor
   \mark \default
   \time 2/2
   b2-\f\(\times 2/3 { b8\!)[fs8-1(g8] a8[g8-3 fs8] } |
 \times 2/3 { g8-)[ds-1(e8]  fs8[e8 ds8] e8)[as,-1(b-2] c-3[b-2
 as-1] |
   b8-1-)[fs(g]  a[g fs] } g-) e\(g) b_- |
   e8---4 e---0 g-- b-- e4.---0\sf(e8-.) |
   e2(\sf\ \times 2/3 { e8\!)[b8-2(c8] d8[c8 b8] } |
 }

 (http://lilybin.com/qukbs5/2)

 I've tried adding:

 \override SpacingSpanner #'base-shortest-duration =
#(ly:make-moment
 1
 1)

 But this seems to have no or only very little effect on the
default
 spacing, even with make-moment up to 2/1 or higher.  For reference
 I'd
 like
 the formatting to match something like this:

 [image: Inline image 1]

 I can get the desired result by adding a \noBreak at the end of
 every
 bar
 but that's very laborious and makes the .ly file quite a bit
uglier.
 (even using an alias like nb = { \noBreak })

 Are there other tricks for very densely formatted scores?

 Steve

 Have a look at


https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/adjust-horizontal-spacing
 and see if it helps.

 Urs






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


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




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

wish: ly:cheapest-breaking (or whatever name)

[Urs Liska]

Hi list,

following up on a thread that I started some time ago 
(http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html) 
I'd like to draw the conclusions from that and ask for an additional 
breaking algorithm.


It would be nice to have a compilation mode that doesn't care about 
optimizing page layout through calculating good line and page breaks 
(or page turns) but that rather fills a line until it's full and then 
inserts a break at the latest allowed moment. The line can then be 
spread out to fill the line width or not, depending on the ragged setting.


The idea behind it is: While working on the *content* of a score one 
doesn't necessarily have to care about the beauty of the page layout at 
all, and so it would make sense to speed up compilation by not having 
LilyPond to care about it either.


There is another idea behind it which is related to another wish I'll 
post separately. Such a compilation mode would make it less likely that 
small changes in the input cause changes in the line (and page) 
breaking. These would only occur when the current system actually 
becomes longer or shorter by half a measure (in a simplified view).


I can't imagine that this should be too hard to implement, but I don't 
have a clue where this would have to start, presumably in the C++ part?


Urs

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

Problem with enharmonic tie in partcombine (can let LilyPond crash)

[Urs Liska]

Hi,

I encountered a strange crash that is related to enharmonic ties.

I'm using an engraver that is passed a grob.

One particular snippet of input code lets now crash LilyPond.
I can't easily produce a compiling (i.e. crashing) example because it's 
quite intertwined with project specific libraries.
So I can't fully rule out some dependencies with the project code but I 
still have the feeling that it's more related to a recent LilyPond patch.


The relevant output from the log is

scm/lily.scmBacktrace:
In 
/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/lily.scm:
1040: 10* [ly:parse-file 
/home/uliska/git/bfsc/fried/das-trunkne-lied/score/fullscore.ly]
In 
/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/ly/init.ly:
  56: 11* (let* ((book-handler #)) (cond (# #) (# #)))
  59: 12  (cond (# #) (# #))
In 
/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/lily-library.scm:
...
 259: 13  [ly:book-process #Book # Output_def # Output_def fullscore]
In unknown file:
   ?: 14* [#procedure #f (trans) #Translator Scheme_engraver ]
In 
/home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/functions/annotate.ily:
 247: 15* (begin (for-each # #) (for-each # annotations) (if log-annotations #))
 250: 16* [for-each #procedure #f (g) ((# # # ...) (# # # ...) (# # # ...) 
...)]
In unknown file:
   ?: 17* [#procedure #f (g) (#Grob Tie  (12 . 8) #Mom 3/2 ...)]
In 
/home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/functions/annotate.ily:
 252: 18* (let* (#) (set! annotation #) (set! annotation #) ...)
 258: 19* (set! annotation (assoc-set! annotation rhythmic-location ...))
 258: 20* [assoc-set! (# # # # ...) rhythmic-location ...
 258: 21* [location #Grob Tie ]
  98: 22  (let* ((col #)) (ly:grob-property col (quote rhythmic-location)))
  98: 23* [get-paper-column #Grob Tie ]
  90: 24  (if (grob::has-interface grob (quote paper-column-interface)) grob 
...)
In unknown file:
...
   ?: 25  [get-paper-column {()}]
In 
/home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/functions/annotate.ily:
  90: 26  (if (grob::has-interface grob (quote paper-column-interface)) grob 
...)
  90: 27* [grob::has-interface {()} paper-column-interface]
In 
/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/output-lib.scm:
  24: 28  [memq paper-column-interface ...
  24: 29* [ly:grob-interfaces {()}]

/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/output-lib.scm:24:15:
 In procedure ly:grob-interfaces in expression (ly:grob-interfaces grob):
/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/output-lib.scm:24:15:
 Wrong type argument in position 1 (expecting Grob): ()

If I see correctly at one point the #Grob Tie  gets lost along the way.

I determined the offending input to be an instance of

fis ~ ges

with the Tie being passed to the engraver.
Irritatingly the crash only happens when partcombined. When compiling 
the individual part it works well.


So is there anything in the patch that allows to enter such enharmonic 
ties that smells like producing such an issue?


TIA
Urs

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

Output break positions (question or feature request)

[Urs Liska]

Hi,

as asked on the -user list I am looking for a way to collect the 
positions of all breaks in a LilyPond score.
http://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00185.html 
suggests that at the time engravers are doing their work the line and 
page breaking hasn't been performed so engravers can't help with that. 
But I'm quite sure LilyPond *has* a way to produce this information somehow.


The goal is to find a way to recompile just a certain page or system 
using the skipTypesetting property, which works well for entering or 
editing music as long as the changes don't require changed breakings 
(which would then require a complete recompilation, resulting in a new 
list of breaks.


So I have
a) the question if there already *is* a way to retrieve the moments 
(barnumber plus measure-position) of all explicit and implicit breaks in 
a score and write them to a log file?
b) if it's confirmed that currently there is no way to do so please add 
this as a feature request to the tracker.


I hope to make this an editing option (in Frescobaldi, but it could be 
adapted to other editing environments as well) that can dramatically 
reduce waiting times while editing the *content* of a LilyPond score, 
making the overall user experience significantly smoother. I hope that 
this may significantly increase acceptance of LilyPond with potential users.


Best
Urs

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

Re: Typo in NR example (vocal music)

[Urs Liska]

Am 09.01.2015 um 16:00 schrieb Ralph Palmer:
On Wed, Jan 7, 2015 at 4:50 AM, Urs Liska u...@openlilylib.org 
mailto:u...@openlilylib.org wrote:


Hi all,

on

http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music.html

there's a typo in the example about special characters (with the
text Schad' um das schöne grüne Band).
The sixth note should read es' instead of e'.

I'd fix that myself but I have problems accessing the Git
repository right now. Therefore I write this email so it won't be
forgotten.

Urs


Thanks, Urs. Submitted as issue 4254 : 
https://code.google.com/p/lilypond/issues/detail?id=4254

Ralph



Hi Ralph,

thanks for reminding me through that issue.
Now that I've Git access again I could quickly fix it and upload the patch.
Actually that's why I wrote my bug report :-)

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

Typo in NR example (vocal music)

[Urs Liska]

Hi all,

on
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music.html

there's a typo in the example about special characters (with the text 
Schad' um das schöne grüne Band).

The sixth note should read es' instead of e'.

I'd fix that myself but I have problems accessing the Git repository 
right now. Therefore I write this email so it won't be forgotten.


Urs

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

Re: cadence font and lilypond-book

[Urs Liska]

Am 17.03.2015 um 11:20 schrieb Marc Hohl:

Am 17.03.2015 um 10:57 schrieb Urs Liska:



Am 17.03.2015 um 10:53 schrieb Marc Hohl:

Am 17.03.2015 um 10:27 schrieb Urs Liska:
[...]


does not help here, lilypond-book has ceased to work, obviously.



I checked the contents of lilypond-book in a number of 
installations and

have the impression there's a quite serious bug (if I'm not completely
mistaken) as all paths seem to be hardcoded in the script, 
independently

from the path where LilyPond is actually installed:

2.18.2 (binary release)
installation root: /shared/software/lilyponds/lilypond-stable
appends to sys.path:
- /usr/share/lilypond/2.18.2/python
- /usr/lib/lilypond/2.18.2/python
lilypond_binary: /usr/bin/lilypond

2.19.16 (binary release)
installations root: /shared/software/lilyponds/lilypond-devel
appends to sys.path:
- /usr/share/lilypond/2.19.16/python
- /usr/lib/lilypond/2.19.16/python
lilypond_binary: /usr/bin/lilypond

2.19.18 (build from current master)
build root: ~/git/lilypond/lilypond-builds/current
appends to sys.path:
- / usr/local/share/lilypond/2.19.18/python
- /usr/local/lib/lilypond/2.19.18/python
lilypond_binary: /usr/local/bin/lilypond


THanks for checking! I think that there is something fishy with the
paths here...


Yes, as I've written on the bug-lilypond thread (forgot to add the
lilypond-user to CC ...) I think
the paths should be determined relative to the realpath of the
lilypond-book script and not use these
arbitrary hardcoded values.

Could you please provide me with a small example .lytex file so I can
test it and try to make a patch?


Ok, see the attachments. I cannot test whether cadencetest.lytex 
compiles, since my lilypond-book does not work anymore.


Hmm.

uliska@debian-laptop:~/aktuell/lily-bugs/lilypond-book$ lilypond-book 
cadencetest.lytex

lilypond-book (GNU LilyPond) 2.19.16
Reading cadencetest.lytex...
Running `latex' on file `/tmp/tmprrYBzN.tex' to detect default page 
settings.


Dissecting...
Writing snippets...
Processing...
Running lilypond...
GNU LilyPond 2.19.16
»./snippet-map-1299016167.ly« wird verarbeitet
Analysieren...
»./d7/lily-dbf6a28c.ly« wird verarbeitet
Analysieren...
Eingabe in »cadencesong.ly« umbenannt
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...
Zeilenumbrüche werden berechnet...
Systeme erstellen...
Layout nach »./d7/lily-dbf6a28c.eps« ausgeben...
Layout nach »./d7/lily-dbf6a28c-1.eps« ausgeben...
./d7/lily-dbf6a28c-systems.texi wird geschrieben...
./d7/lily-dbf6a28c-systems.tex wird geschrieben...
./d7/lily-dbf6a28c-systems.count wird geschrieben...
Kompilation erfolgreich beendet
Linking files...
Compiling /home/uliska/aktuell/lily-bugs/lilypond-book/cadencetest.tex...
Writing `/home/uliska/aktuell/lily-bugs/lilypond-book/cadencetest.tex'...

and compiling with lualatex afterwards also gives the expected results.

So it seems my interpretation of the code is somehow wrong, and it seems 
the problem is somewhere else in your installation.


Sorry, I don't know more ATM
Urs


Marc



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


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

Re: cadence font and lilypond-book

[Urs Liska]

Am 17.03.2015 um 09:57 schrieb Marc Hohl:

Am 17.03.2015 um 09:36 schrieb Urs Liska:



Am 17.03.2015 um 09:32 schrieb Marc Hohl:

Hi list, hi Abraham,

I asked about this subject before, but now I think I did everything
right, but still ...

I use the self-compiled lilypond and install it after complilation:

sudo make install

After that, there is

/usr/local/share/lilypond/2.19.18/

on my system (Ubuntu 14.04 LTS, by the way).

I put the cadence font files in the directories

/usr/local/share/lilypond/2.19.18/fonts/otf
/usr/local/share/lilypond/2.19.18/fonts/svg

as stated in the docs for the cadence font.

Now, if I compile a score that uses the cadence font, everything is
ok, and acroread shows that the cadence font is embedded.

If I include the same .ly file in my LaTeX-file by using
\lilypondfile{...}
and process this by lilypond-book, I got errors like the following:

Layout nach »./3f/lily-c4c745f6.eps« ausgeben...
Warnung: cadence-20=cadence-20 kann nicht eingebettet werden
Konvertierung nach »./3f/lily-c4c745f6.pdf«...
Layout nach »./3f/lily-c4c745f6-1.eps« ausgeben...
Warnung: cadence-20=cadence-20 kann nicht eingebettet werden
Layout nach »./3f/lily-c4c745f6-2.eps« ausgeben...
Warnung: cadence-20=cadence-20 kann nicht eingebettet werden
Layout nach »./3f/lily-c4c745f6-3.eps« ausgeben...
Warnung: cadence-20=cadence-20 kann nicht eingebettet werden
Layout nach »./3f/lily-c4c745f6-4.eps« ausgeben...
Warnung: cadence-20=cadence-20 kann nicht eingebettet werden

Is there anybody having experience with the alternative fonts in
combination with lilypond-book?



Unfortunately not, but I'd be interested in the subject too.
Do you know how lilypond-book actually invokes LilyPond?


Hey, good point!

$ lilypond-book --version
2.19.18

$ which lilypond-book
/usr/local/bin/lilypond-book

$ more /usr/local/bin/lilypond-book
[...]
for d in ['/usr/local/share/lilypond/2.19.17',
  '/usr/local/lib/lilypond/2.19.17']:
sys.path.insert (0, os.path.join (d, 'python'))
[...]

That's strange.

If I call lilypond-book, I got
[...]
lilypond-book (GNU LilyPond) 2.19.17
Sieben_Prinzessinnen.lytex lesen...
»lualatex« für Datei »/tmp/tmpWFcTPG.tex« aufrufen, um 
Standardseiteneinstellungen zu ermitteln.


Zerlegen...
Auszüge werden geschrieben...
Verarbeiten...
lilypond wird ausgeführt...
GNU LilyPond 2.19.18
[...]

That's even more strange, I think.

I just copied the otf/woff/svg files into the 2.19.17 directory (just 
in case), but the error message persists.


Now I deleted every version directory (there were 2.19.16 and 2.19.17)
in /usr/local/share/lilypond/

Now I get

$ which lilypond-book
/usr/local/bin/lilypond-book

$ lilypond-book --version
Traceback (most recent call last):
  File /usr/local/bin/lilypond-book, line 81, in module
import lilylib as ly
ImportError: No module named lilylib

Another call of
$ sudo make install

does not help here, lilypond-book has ceased to work, obviously.



I checked the contents of lilypond-book in a number of installations and 
have the impression there's a quite serious bug (if I'm not completely 
mistaken) as all paths seem to be hardcoded in the script, independently 
from the path where LilyPond is actually installed:


2.18.2 (binary release)
installation root: /shared/software/lilyponds/lilypond-stable
appends to sys.path:
- /usr/share/lilypond/2.18.2/python
- /usr/lib/lilypond/2.18.2/python
lilypond_binary: /usr/bin/lilypond

2.19.16 (binary release)
installations root: /shared/software/lilyponds/lilypond-devel
appends to sys.path:
- /usr/share/lilypond/2.19.16/python
- /usr/lib/lilypond/2.19.16/python
lilypond_binary: /usr/bin/lilypond

2.19.18 (build from current master)
build root: ~/git/lilypond/lilypond-builds/current
appends to sys.path:
- / usr/local/share/lilypond/2.19.18/python
- /usr/local/lib/lilypond/2.19.18/python
lilypond_binary: /usr/local/bin/lilypond

Of course in all these places there isn't anything LilyPond related.
So it seems clear that lilypond-book can't work on either binary or 
custom-build version, isn't it?
I can't test it because I don't have any .lytex files available, but 
obviously there should be some point in the build/installation process 
that determines the correct paths relative to the installation directory.


(CCing to bug-lilypond)

Urs



Marc





Marc




Urs


TIA,

Marc

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



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



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


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

Re: cadence font and lilypond-book

[Urs Liska]

Am 17.03.2015 um 10:53 schrieb Marc Hohl:

Am 17.03.2015 um 10:27 schrieb Urs Liska:
[...]


does not help here, lilypond-book has ceased to work, obviously.



I checked the contents of lilypond-book in a number of installations and
have the impression there's a quite serious bug (if I'm not completely
mistaken) as all paths seem to be hardcoded in the script, independently
from the path where LilyPond is actually installed:

2.18.2 (binary release)
installation root: /shared/software/lilyponds/lilypond-stable
appends to sys.path:
- /usr/share/lilypond/2.18.2/python
- /usr/lib/lilypond/2.18.2/python
lilypond_binary: /usr/bin/lilypond

2.19.16 (binary release)
installations root: /shared/software/lilyponds/lilypond-devel
appends to sys.path:
- /usr/share/lilypond/2.19.16/python
- /usr/lib/lilypond/2.19.16/python
lilypond_binary: /usr/bin/lilypond

2.19.18 (build from current master)
build root: ~/git/lilypond/lilypond-builds/current
appends to sys.path:
- / usr/local/share/lilypond/2.19.18/python
- /usr/local/lib/lilypond/2.19.18/python
lilypond_binary: /usr/local/bin/lilypond


THanks for checking! I think that there is something fishy with the 
paths here...


Yes, as I've written on the bug-lilypond thread (forgot to add the 
lilypond-user to CC ...) I think
the paths should be determined relative to the realpath of the 
lilypond-book script and not use these

arbitrary hardcoded values.

Could you please provide me with a small example .lytex file so I can 
test it and try to make a patch?


Urs



Marc


Of course in all these places there isn't anything LilyPond related.
So it seems clear that lilypond-book can't work on either binary or
custom-build version, isn't it?
I can't test it because I don't have any .lytex files available, but
obviously there should be some point in the build/installation process
that determines the correct paths relative to the installation 
directory.


(CCing to bug-lilypond)

Urs



Marc





Marc




Urs


TIA,

Marc

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



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



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




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




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



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

Re: cadence font and lilypond-book

[Urs Liska]

Am 17.03.2015 um 10:27 schrieb Urs Liska:
I can't test it because I don't have any .lytex files available, but 
obviously there should be some point in the build/installation process 
that determines the correct paths relative to the installation directory.


Oops, no.
Of course the include and lilypond paths should be determined relative 
to the actualy lilypond-book file instead of by using hardcoded paths.


Urs


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

Re: website: new screenshots for Denemo and Frescobaldi?

[Urs Liska]

Am 14.03.2015 um 13:21 schrieb Federico Bruni:

Hi all

What about adding new screenshots for Denemo and Frescobaldi?


Good idea.

They are on top of the easier editing page and the images are very 
out-of-date.


I've uploaded some here:
http://sixbarsjail.it/tmp/lily/

I did not put too much effort on it, as I don't know if there's any 
requirement.

If you have or can do better screenshots, please submit yours.

AFAIK these should be added to the lilypond-extra repository on 
github, so I don't think we need any issue or review, just someone who 
can push it to github after we've agreed on the new images.


I just looked at the Frescobaldi one and have a few ideas for making it 
even better:


One could use a part of the space of the Music View to show one more 
tool in a floating panel, e.g. the Quick Insert.
It would be nice to see some point-and-click, e.g. selecting a range in 
the editor and see the highlighted items in the Music view.
If that is possible (and doesn't interfere with the previous): have 
something displayed through the magnifier.


Urs



Thanks
Federico




___
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

Retrieving information about breaks (was: Partial compilation (again))

[Urs Liska]

Picking up that old thread seems better than starting a new one ...

By now I've reached a different state and would like to come back to 
this issue with a very concrete question:
Is it possible to determine at which positions (in terms of barnumber 
and measure-position) the final line breaks, page breaks and page turns 
have been placed in LilyPond?
I'm sure this information has to be present at one point, but someone (I 
think it may have been David Nalesnik) expressed the opinion that 
engravers could only access explicit \break-s.


I would like to write out a log file containing all break points of a 
given LilyPond run.


If that's not currently accessible I'd like to add that as a feature 
request.


Urs


Am 21.11.2014 um 14:44 schrieb Urs Liska:


Am 21.11.2014 13:33, schrieb David Kastrup:

Urs Liska u...@openlilylib.org writes:


Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup d...@gnu.org:


So I don't see this going anywhere fast.  To get a hook into cloning
internal engraver states, you'd probably want to create a more
object-oriented frame work for them.

Ok, I see. Thank you for the explanation.

I'll try if I can get *somewhere* with an external approach as
outlined on -user.

TeX, in contrast to LilyPond, works in a pipeline-like manner, producing
output all the time.  In that case, a semi-external approach might work
when you have a good idea what kind of input is subject to editing: you
just fork off a copy of the executable when it gets to the place before
the editing region.  And then you run that forked copy on the changed
input from that point on.

However, LilyPond first consumes all input and then starts processing,
so the input file pointer into an unchanged part of the input is just
not a useful indicator of LilyPond's progress and this kind of low-level
approach does not look workable.



OK. I will try around anyway.
If I knew where a given system starts in terms of barnumbers I can try:

- setting suitable skipTypesettings commands one measure before and 
one measure after the range
- check for open spanners and optionally inject corresponding 
starts/ends in the respective preroll measure

- add manual breaks before and after the line
- compile this threeline document to three temporary files (with 
lilypond-book-preamble)

- replace the respective previous system's pdf with the new one.

setting system-count to 3 will result in the right document in any 
case, and in warnings when the system gets too full (so the 
recompilation doesn't work anymore).


Of course this isn't intended for the part of bringing a score to 
publication quality but rather for the stage when you're only dealing 
with the content. And I don't know how complicated things will become. 
But I think it is worth a try.


Urs

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



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

Re: wish: ly:cheapest-breaking (or whatever name)

[Urs Liska]

Am 23.01.2015 um 13:35 schrieb Ralph Palmer:
On Mon, Jan 19, 2015 at 9:33 AM, Urs Liska u...@openlilylib.org 
mailto:u...@openlilylib.org wrote:


Hi list,

following up on a thread that I started some time ago
(http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html)
I'd like to draw the conclusions from that and ask for an
additional breaking algorithm.


Hi, Urs and List - At the risk of creating noise, but hoping to help 
keep it from getting lost, I've submitted this as a feature request : 
Issue 4271 https://code.google.com/p/lilypond/issues/detail?id=4271. 
Please let me know if this was impertinent or unnecessary.

Ralph


??
No, that was the intention of my post ;-)

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

Issue with symbol-list? and ly:parser-include-string

[Urs Liska]

As this thread suggested
https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00193.html

there is an issue with the parser when a symbol-list? predicate is used 
as a function argument and ly:parser-include-string in that function.
As it turned out the problem is reproducible with very little effort, as 
you can see with the attached two files.


Obviously the symbol-list? predicate doesn't play well with 
ly:parser-include-string.


Some observations:

- it is not related to the \include command
  as you can see from the two alternative strings passed to 
ly:parser-include-string
- The error messages are very different depending on what comes after 
the function call
- Obviously the problem is in determining when the symbol-list? is 
completed, i.e. in the look-ahead
- In the (more complex) original context there are even other error 
messages.
- when there is any Scheme expression (the #(display ) in the example, 
but a #(define foo 'bar) works
  just the same) parsing works properly but LilyPond statements cause 
the parser to fail
\version 2.19.18

testDotListInclude =
#(define-void-function (parser location path)(symbol-list?)
   (ly:parser-include-string parser
 \\include \included.ily\))
% #(ly:message \\nThis message is done with ly:parser-include-string\n\n\)))


\testDotListInclude path.to.whatever
% Use a proper list notation and everything is OK
%\testDotListInclude #'(path to whatever)

% Uncomment the following line and everything is OK
%#(display )

% Uncomment any of the following (when the above is commented out)
% to get different (weird) errors
\markup Anything
%\relative c' { c }
%\transpose c e { c d e }
\version 2.19.18

#(ly:message This is from the included file)
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: compile failure - parsed object should be dead in 2.19.20

[Urs Liska]

Am 28.04.2015 um 21:52 schrieb Thomas Morley:


Can't confirm with a build from latest master in LilyDev (Ubuntu 10.04)
All works as expected.

Cheers,
   Harm


That's consistent with my experience from 2.19.18 on. It works with 
self-compiled versions (on Debian stable) but not with binary releases. 
It is related to calling a system vs. a packaged Ghostscript.


At least it doesn't seem to be an issue with my personal configuration ...

Urs

--
Urs Liska
www.openlilylib.org

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

Re: my favorite bug :-)

[Urs Liska]

Am 01.05.2015 um 13:53 schrieb Masamichi HOSODA:

The bug would be fixed if lilypond would make ghostscript use a
complete path to the intermediate lines.ps file for the ps to pdf
conversion.

Does anyone know how to convert from any path (relative and absolute path)
to absolute path in scheme (guile) ?


Maybe the functions in this file help you?
https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm

Urs


___
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: Ghostscript problem in 2.19.18

[Urs Liska]

Am 14.04.2015 um 16:22 schrieb Masamichi HOSODA:

OK.

Compiling a file with  lilypond-2.19.18-1.linux-x86.sh ends with

Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
-fdocument.ps'...


gs: Interpreter revision (905) does not match gs_init.ps revision
(915).

warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
-fdocument.ps)' failed (256)



while compiling with a self-built version ends with

Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
-fdocument.ps'...

GPL Ghostscript 9.05 (2012-02-08)

Copyright (C) 2010 Artifex Software, Inc. All rights reserved.

This software comes with NO WARRANTY: see the file PUBLIC for details.

]/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/lily.scm


Success: compilation successfully complete


Here we obviously call Ghostscript 9.05 also (which seems to be the
current version on Debian stable) but without conflicting with
gs_init.ps.


So what is wrong here?
If it is simply an issue with my personal installation I'd consider
ignoring it, but somehow this looks like an issue. So it would be good
to have a confirmation that either I'm the only one experiencing it or
not.

How do you install lilypond-2.19.18-1.linux-x86.sh?


I execute the script as user to install it to ~/lilypond (with the 
wrappers in ~/bin).
Then (and that's maybe where the problem starts) I move the ~/lilypond 
folder to the location on /shared and create a symlink at ~/lilypond.

This is what I've always done and what has always worked.



In your system, does
/shared/software/lilypond/current-devel/usr/bin/gs
exist?

Is it executable?


Yes:
-rwxr-xr-x 1 uliska uliska4936 Apr  5 16:13 gs


gs requires its resource files (gs_init.ps etc.).
It finds them by environment variable GS_LIB or its built in search path.


echo $GS_LIB doesn't return anything.


lilypond-2.19.18-1.linux-x86.sh includes gs-9.15 executable
and its resource files.

I think that this issue is as following.

In your environments, the case of lilypond-2.19.18-1.linux-x86.sh,
lilypond invokes system's gs-9.10 instead of included gs-9.15.


If I run gs --version on the gs file inside the lilypond-2.19.18-1 
installation it returns 9.05!



But, GS_LIB indicates included resource files for gs-9.15.
The versions of gs executable and gs resource files are different.
Then, it fails.

In the case of your self-built, lilypond invokes system's gs-9.10
(self-built lilypond doesn't include gs executable),
GS_LIB is maybe unset
(self-built lilypond doesn't include gs resource files),
and gs finds system's gs resource files for gs-9.10.
The versions of gs executable and gs resource files are same gs-9.10.
Then, it succeeds.

In my environments, the case of lilypond-2.19.18-1.linux-x86.sh,
lilypond invokes included gs-9.15,
and GS_LIB indicates included resource files for gs-9.15.
The versions of gs executable and gs resource files are same gs-9.15.
Then, it succeeds.

I think the problem of your system is
why lilypond invokes system's gs instead of included gs.


I just installed 2.19.18-1 again and left it in its default location 
~/lilypond.

Now everything works.

Can it be that there's some hardcoded path anywhere, so the included gs 
isn't found anymore?
But if that's the case I think it should be fixed because I should be 
able to move around the actual lilypond installation - and it did work 
up to 2.19.17


Urs


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

Ghostscript problem in 2.19.18

[Urs Liska]

Hi,

just trying out the binary releases again, and I notice that with 
2.19.18 all documents fail with the following message:


Layout output to `document.ps'...

Converting to `./document.pdf'...

warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite 
-fdocument.ps)' failed (256)



This is on Debian with the linux-386 binary and applies to _any_ file, even
{ c }
.

Compiling with the 2.19.17 binary works.
Compiling with the 2.19.18 binary fails.
Compiling with a custom build from current master works.

As there are no relevant commits between the 2.19.18 tag and current 
master I assume this is due to the binary build (i.e. recent GUB changes).


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

Re: Ghostscript problem in 2.19.18

[Urs Liska]

Am 13.04.2015 um 16:04 schrieb Masamichi HOSODA:

I have just installed lilypond-2.19.18-1.linux-x86.sh on another
machine running Debian 7 stable with latest updates. And the error is
identical. Maybe (this is a big maybe) I'll have a chance to test it
on another (different) 32bit Linux installation later today, but
that's not sure at all.

What kind of dependencies could I look for that could be handled by
GUB or documented as requirements?

Would you try like following command?

$ lilypond --verbose foo.ly

And, would you show me the whole output of the command?


Starting lilypond 2.19.18 [gs.ly]...

Log level set to 287

Relocation: is absolute: 
argv0=/shared/software/lilypond/current-devel/usr/bin/lilypond


PATH=/shared/software/lilypond/current-devel/usr/bin (prepend)

Setting PATH to 
/shared/software/lilypond/current-devel/usr/bin:/home/uliska/git/3rdParty/git-cl:/shared/software/thunderbird:/shared/software/texlive/2013/bin/i386-linux:/home/uliska/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


Relocation: compile datadir=, new 
datadir=/shared/software/lilypond/current-devel/usr/share/lilypond//current


Relocation: 
framework_prefix=/shared/software/lilypond/current-devel/usr/bin/..


Setting INSTALLER_PREFIX to 
/shared/software/lilypond/current-devel/usr/bin/..


Relocation file: 
/shared/software/lilypond/current-devel/usr/bin/../etc/relocate//fontconfig.reloc


Setting FONTCONFIG_FILE to 
/shared/software/lilypond/current-devel/usr/bin/../etc/fonts/fonts.conf


Setting FONTCONFIG_PATH to 
/shared/software/lilypond/current-devel/usr/bin/../etc/fonts


Relocation file: 
/shared/software/lilypond/current-devel/usr/bin/../etc/relocate//guile.reloc


GUILE_LOAD_PATH=/shared/software/lilypond/current-devel/usr/bin/../share/guile/1.8 
(prepend)


Setting GUILE_LOAD_PATH to 
/shared/software/lilypond/current-devel/usr/bin/../share/guile/1.8


Relocation file: 
/shared/software/lilypond/current-devel/usr/bin/../etc/relocate//pango.reloc


Setting PANGO_RC_FILE to 
/shared/software/lilypond/current-devel/usr/bin/../etc/pango/pangorc


Setting PANGO_PREFIX to /shared/software/lilypond/current-devel/usr/bin/../

Setting PANGO_MODULE_VERSION to 1.6.0

Relocation file: 
/shared/software/lilypond/current-devel/usr/bin/../etc/relocate//gs.reloc


warning: no such directory: 
/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/fonts 
for GS_FONTPATH


warning: no such directory: 
/shared/software/lilypond/current-devel/usr/bin/../share/gs/fonts for 
GS_FONTPATH


GS_LIB=/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource 
(prepend)


Setting GS_LIB to 
/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource


GS_LIB=/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource/Init 
(prepend)


Setting GS_LIB to 
/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource/Init:/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource


PATH=/shared/software/lilypond/current-devel/usr/bin/../bin (prepend)

Setting PATH to 
/shared/software/lilypond/current-devel/usr/bin/../bin:/shared/software/lilypond/current-devel/usr/bin:/home/uliska/git/3rdParty/git-cl:/shared/software/thunderbird:/shared/software/texlive/2013/bin/i386-linux:/home/uliska/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


Setting GUILE_MIN_YIELD_1 to 65

Setting GUILE_MIN_YIELD_2 to 65

Setting GUILE_MIN_YIELD_MALLOC to 65

Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760

Setting GUILE_MAX_SEGMENT_SIZE to 104857600


LILYPOND_DATADIR=/usr/share/lilypond/2.19.18

LOCALEDIR=/usr/share/locale


Effective prefix: 
/shared/software/lilypond/current-devel/usr/share/lilypond/current


FONTCONFIG_FILE=/shared/software/lilypond/current-devel/usr/bin/../etc/fonts/fonts.conf

FONTCONFIG_PATH=/shared/software/lilypond/current-devel/usr/bin/../etc/fonts

GS_LIB=/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource/Init:/shared/software/lilypond/current-devel/usr/bin/../share/ghostscript/9.15/Resource

GUILE_LOAD_PATH=/shared/software/lilypond/current-devel/usr/bin/../share/guile/1.8

PANGO_RC_FILE=/shared/software/lilypond/current-devel/usr/bin/../etc/pango/pangorc

PANGO_PREFIX=/shared/software/lilypond/current-devel/usr/bin/../

PATH=/shared/software/lilypond/current-devel/usr/bin/../bin:/shared/software/lilypond/current-devel/usr/bin:/home/uliska/git/3rdParty/git-cl:/shared/software/thunderbird:/shared/software/texlive/2013/bin/i386-linux:/home/uliska/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

[]

Guile 1.8

[/shared/software/lilypond/current-devel/usr/share/lilypond/current/scm/lily-library.scm]

[/shared/software/lilypond/current-devel/usr/share/lilypond/current/scm/output-lib.scm]

[/shared/software/lilypond/current-devel/usr/share/lilypond/current/scm/markup-macros.scm]

Re: Ghostscript problem in 2.19.18

[Urs Liska]

Am 13.04.2015 um 14:19 schrieb Masamichi HOSODA:

This is on Debian with the linux-386 binary and applies to _any_ file,
even
{ c }
.

Compiling with the 2.19.17 binary works.
Compiling with the 2.19.18 binary fails.
Compiling with a custom build from current master works.

As there are no relevant commits between the 2.19.18 tag and current
master I assume this is due to the binary build (i.e. recent GUB
changes).

I've tested official binary lilypond-2.19.18-1.linux-x86.sh
on both Ubuntu 32 bit and Ubuntu 64 bit.

It is fine for my both environments.


I have just installed lilypond-2.19.18-1.linux-x86.sh on another machine 
running Debian 7 stable with latest updates. And the error is identical. 
Maybe (this is a big maybe) I'll have a chance to test it on another 
(different) 32bit Linux installation later today, but that's not sure at 
all.


What kind of dependencies could I look for that could be handled by GUB 
or documented as requirements?


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

Re: Ghostscript problem in 2.19.18

[Urs Liska]

Am 13.04.2015 um 16:47 schrieb Masamichi HOSODA:

gs: Interpreter revision (905) does not match gs_init.ps revision
(915).

lilypond-2.19.18-1.linux-x86.sh includes gs-9.15.
However, lilypond seems to be invoking the external gs-9.05
instead of included gs-9.15.

My ubuntu 64 bit environment have been installed gs-9.10.
However, lilypond invokes included gs-9.15 instead of system's gs-9.10.
My ubuntu 32 bit environment have not been installed gs.


OK.

Compiling a file with  lilypond-2.19.18-1.linux-x86.sh ends with

Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite 
-fdocument.ps'...



gs: Interpreter revision (905) does not match gs_init.ps revision (915).

warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite 
-fdocument.ps)' failed (256)




while compiling with a self-built version ends with

Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
-r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite 
-fdocument.ps'...


GPL Ghostscript 9.05 (2012-02-08)

Copyright (C) 2010 Artifex Software, Inc. All rights reserved.

This software comes with NO WARRANTY: see the file PUBLIC for details.

]/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/lily.scm 



Success: compilation successfully complete


Here we obviously call Ghostscript 9.05 also (which seems to be the 
current version on Debian stable) but without conflicting with 
gs_init.ps.



So what is wrong here?
If it is simply an issue with my personal installation I'd consider 
ignoring it, but somehow this looks like an issue. So it would be good 
to have a confirmation that either I'm the only one experiencing it or not.


Urs


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

Re: musicxml2ly doesn't handle nested tuplets

[Urs Liska]

Am 5. Juni 2015 13:55:04 MESZ, schrieb Ralph Palmer ralphbugl...@gmail.com:
On Tue, Jun 2, 2015 at 10:54 AM, Urs Liska u...@openlilylib.org wrote:

 When dealing with export of nested tuplets to MusicXML (
 https://github.com/wbsoft/python-ly/issues/25) I realized that the
 exported MusicXML can be properly read by Finale but not be
reimported
 through musicxml2ly.

 https://github.com/wbsoft/python-ly/issues/25#issuecomment-107363569
 shows how nested tuplets are rendered after importing into lilypond.

 Urs


I can't tell from the LilyPond documentation whether MusicXML - either
import, export, or both - is explicitly supported by LilyPond. Before I
submit this as an issue, can someone please confirm for me that
LilyPond
does support MusicXML?

Well, the musicxml2ly script ships with LilyPond just like lilypond-book, isn't 
it?

I appreciate your time and help,

Ralph


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

\tempo collision with cross staff beam

[Urs Liska]

Hi bug squad,

I ran into a collision bug.

With a cross-staff beam present \tempo doesn't take any objects above 
the staff into account.
If you comment out the beam in the following example the \tempo is 
correctly shifted upwards to accomodate the dynamic. Result is identical 
with 2.18.2 and 2.19.22.


This may be related to 3778, but strangely so:

- With cross-staff beam:
  Wrong output in PDF and SVG
- With beam commented out:
  PDF: correct spacing
  SVG: Same error as with beam

Urs

\version 2.18.2

music = {
  \tempo 8 = 72
  % Also works with articulations that are placed above the staff by 
default

  d''8 ^\p
  % Comment out beam to see correct engraving
  [
  \change Staff = 2
  d''
  ]
}

\score {
  \new StaffGroup 
\new Staff = 1 \music
\new Staff = 2 { s4 }
  
}

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

musicxml2ly doesn't handle nested tuplets

[Urs Liska]

When dealing with export of nested tuplets to MusicXML 
(https://github.com/wbsoft/python-ly/issues/25) I realized that the 
exported MusicXML can be properly read by Finale but not be reimported 
through musicxml2ly.


https://github.com/wbsoft/python-ly/issues/25#issuecomment-107363569
shows how nested tuplets are rendered after importing into lilypond.

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

Re: Accidentals tied over a system break

[Urs Liska]

Am 8. Oktober 2015 19:59:57 MESZ, schrieb Sven :
>Sorry, I didn't know this is a known issue.
>
>And thanks for correcting me on how to actually remove the second
>sharp,
>Urs: \once \omit Accidental get's rid of the bugger, while \once \hide
>Accidental makes it transparent, leaving its space in tact.

Well, it's "correct", but still it is a hack. Maybe you inferred it from he 
discussion: you get rid of the redindant accidental - but if your line breaking 
should ever cjange it won't automatically come back.

Urs
>
>Sven
>
>2015-10-08 19:14 GMT+02:00 David Kastrup :
>
>> Simon Albrecht  writes:
>>
>> > On 08.10.2015 16:38, Trevor Daniels wrote:
>> >> Furthermore, if the tie is removed the sharp on the final fis
>> >> is also removed.  The issue is, without the \break the final fis
>> >> needs the sharp as the second fis doesn't have one, being tied
>> >> to the first fis.  Adding the \break causes the second fis to
>> >> need (and get) a sharp, but the sharp on the third fis, which is
>> >> now redundant, is not removed.  Seems to be a bug to me.
>> >
>> > And, just as David said, one that is long known and being tracked:
>> > . There has
>been
>> > some discussion, but at any rate it’s nonsense to have both
>> > accidentals, and IMO the second should be left out.
>>
>> I don't think there's much of a disagreement on that.  It's just that
>> it's quite tricky to do.  The "remove tied accidental unless after
>line
>> break" is somewhat easy to do: the accidental in its final phase of
>> typesetting checks whether there is a tie leading to it and whether
>that
>> tie is just a broken-off part of a tie.  If it is, the accidental is
>> killed.
>>
>> However, keeping track of the complex relation between this kind of
>> line-break related killed accidental and the following one is rather
>> harder to pin down since the following one needs to have no vicinity
>to
>> either tie or line break.
>>
>> --
>> David Kastrup
>>
>>
>
>
>
>
>___
>lilypond-user mailing list
>lilypond-u...@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Remove old News entry from home page

[Urs Liska]

Hi,

I've just stumbled over it again: The first thing you see on
lilypond.org after the latest release informations is the news item
about the Fried edition prize.
I really think this should be either removed or pushed downward by new
news. Isn't there anything worthwile that can be added here? Would be
frustrating if not ...

Urs

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

Re: PDF Links in Windows

[Urs Liska]

Am 05.10.2015 um 11:18 schrieb Federico Bruni:
> Il giorno lun 5 ott 2015 alle 10:57, Federico Bruni
> <f...@inventati.org> ha scritto:
>> Il giorno lun 5 ott 2015 alle 9:54, Urs Liska <u...@openlilylib.org> ha
>> scritto:
>>> I think what he wants is the following:
>>> - view the PDF in Acrobat Reader (for its better resolution or
>>> whatever reason,
>>>   I think he knows how to do that (as it's where he's coming from)
>>> - Click on the note in Acrobat Reader and have Frescobaldi open the
>>> input file
>>>   at the correct location.
>>>
>>> I don't know how to do it but it's a valid request IMHO, and I
>>> wanted to make it clear.
>>>
>>> Once you figured that out could someone please consider writing a
>>> tutorial for Scores of Beauty?
>>
>> I made a try but could not find any setting in Adobe Reader DC in my
>> virtualized Windows guest. Adobe reader thinks that textedit URIs
>> should be opened in a browser..
>>
>> I found this question with a wrong answer:
>> https://forums.adobe.com/thread/305151
>>
>> and this discussion:
>> http://forums.fofou.org/sumatrapdf/topic?id=934325
>>
>> I have the feeling that trying to achieve this with a Free (as in
>> freeedom) PDF reader for Windows, like Sumatra, would be a better idea.
>>
>
> "Custom protocol handlers aren't supported by Adobe Reader X and later
> for security reasons."
> https://forums.adobe.com/message/5593888#5593888

Is this definitive?

Then this should be added to the documentation somewhere (CCing to
bug-lilypond).

Urs

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

Re: PDF Links in Windows

[Urs Liska]

Am 05.10.2015 um 15:04 schrieb Henning Hraban Ramm:
> On OSX, my old Acrobat Pro 9 as well as Adobe Reader 11 try to open 
> LilyPond’s "textedit://" links with LilyPad, after asking if they may or 
> should block such attempts. So the "security reasons" seem to apply only on 
> Windows (I don’t believe that, there are enough security issues open on OSX).

No, it is clearly stated that "Custom protocol handlers aren't supported
by Adobe Reader X and later for security reasons."
In AR 9 it was possible to set up point-and-click.

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

Re: Another beam subdivision issue

[Urs Liska]

I've now discussed this with Carl, and we came to the conclusion that I
can partially revert 0382ed88.
But I would like to fix what Carl tried to fix with that commit,
although it seems more complex than he thought.

Beam subdivisions should reflect the longest conceivable subsequent group:

{
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1 32)
  c''64^\markup{"baseMoment 1/32"}[ \repeat unfold 14 {c''64} c''64]
}

should result in a sequence of 3-2-3-1-3-2-3 subdivision beams, like in
the first attachment.

However, the implementation currently doesn't take into account whether
the subsequent group is actually complete:

\relative c' {
  \set subdivideBeams = ##t
  \set baseMoment = #(ly:make-moment 1/32)
  c64  \repeat unfold 11 c r16  r8
}

produces a single beam at the second-to-last subdivision (see second
attachment). However, as there is only a 16th worth of actual notes in
the last group we think this second-to-last one should have two beams.

The current code in beaming-pattern.cc seems to only reflect the current
position in the rhythmic pattern and not to be aware of how long the
remaining beam really is.
I have tried to get somewhere in Beaming_pattern::beamify, but I have to
admit it's over my head to understand and modify that code. I have the
impression the necessary information should be present, though.

What I think should be calculated is:

  * Get the total duration between the current moment and the end of the
beam:
infos_[infos_.size () - 1].start_moment_ - infos_[i].start_moment_
was what I came up with, but that gives the duration until the start
of the last not under the beam (???)
  * Apply the number of beams that would be applicable if the next group
was that long.
  * In the above example the length of the remaining actual group is
1/16, so it should return two beams
  * If the remaining groups were 3/32 it should also return two beams


So if someone could help me to retrieve that information from the
variables that are around within that function I would be happy to give
it a try. Of course ready-made solutions are OK too, but I'd be willing
to learn ...

Best
Urs

Am 25.11.2015 um 16:34 schrieb Urs Liska:
> After completing my patch for #4664 I tested beam subdivision with
> another example and was unpleasantly surprised that the other example
> produced a wrong result.
>
> This example should render the subdivisions with a regular alternation
> of two and one beams. Instead all beam subdivisions show two beams
> (first attachment):
>
> \relative c' {
>   \set baseMoment = #(ly:make-moment 1/16)
>   \set subdivideBeams = ##t
>   c64 [ \repeat unfold 30 c c ] 
> }
>
> After initial shock I investigated and found out that this is *not* due
> to my patch but to commit 0382ed88 where Carl modified some behaviour of
> his patch for #4355 in 8fa2d858.
>
> After partially reverting 0382ed88 the example renders correctly as in
> the second attachment. There I have two groups, one with a manual beam
> exposing the new behaviour of my current patch.
>
> ###
>
> Carl, can you tell me what you intended with that adjustment? I can see
> two possible purposes:
> - you thought the behaviour with alternating beam numbers is wrong
> - something else I can't see from here.
>
> If it is the first one I would like to partially revert that change to
> the behaviour of your original patch for 4355. In the other case please
> tell me what you were after.
>
> Urs

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

Re: Fontmap entry for Fontmap.local ends prematurely!

[Urs Liska]

Am 07.12.2015 um 00:24 schrieb Karl Berry:
> We have no plans for any more 2.18.x releases, so ca you confirm if you
> still get the same problem when using the lastest development (2.19.x)
> available download?
>
> The old version is working ok for my (minimal) purposes for the moment.
> If I have a problem with the dev version (I don't expect so), sure, I'll
> report it.
>
> But meanwhile, anyone who (like me) goes to lilypond.org and follows the
> path of least resistance to install and do the first test, exactly as
> stated on the web site, will get an unexpected failure -- that was more
> or less the point of my report.
>
> So unless switching the stable version to 2.19.x is imminent (clearly
> that would be ideal), I suggest adding something to
> http://www.lilypond.org/unix.html that either admits the failure
> ("sadly, direct pdf output does not work with the current stable
> download, use --ps instead") or change the example to output .ps and
> running ps2pdf.  Since that is, in fact, what is necessary, so far as I
> can tell anyway.
>
> Best,
> Karl

Hi Karl,

just noticed this thread now.
Errors at this stage of processing may also indicate some kind of
version conflict between packages provided by the OS and LilyPond's own
versions.

Could you please repeat the execution with the --verbose option and post
(the end of) the log output?

Urs

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

Command line option to have barcheck failures cause errors instead of warnings

[Urs Liska]

Hi,

there was the request for a way to have barcheck failures cause errors
instead of warnings:
http://lists.gnu.org/archive/html/lilypond-user/2015-12/msg00074.html

I think this is a valid use case as very often you don't actually want
to have the compiled score when it contains barcheck failures, erroring
out with a useful message pointing to the input location can be a
time-saver.

This could be controlled by a command line option (e.g.
-derror-on-barcheck).

Before giving it a try and preparing a patch I would like to get some
feedback if this idea seems good.

Best
Urs

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

Re: Noteheads slightly too large

[Urs Liska]

Am 12.12.2015 um 00:02 schrieb Simon Albrecht:
> Thanks for the report.
> 

This *may* be intended, which should be checked - if someone recalls any
discussion.
At least I recall speaking someone from a major publishing house about
how they created their own music font, and specifically made it do what
the OP reported.

Urs

>
> On 11.12.2015 12:37, Gilberto Agostinho wrote:
>> Hi bug squad,
>>
>> This one is really nitpicking, but by zooming in on a note located in
>> between two staff lines, we can notice that the noteheads always
>> extend a
>> little tiny bit beyond the top staff. See:
>>
>> 
>>
>> Elaine Gould, in her book /Behind Bars/, states that "[t]he notehead
>> fills
>> the space, touching the stave-line on each side of it, but without
>> extending
>> beyond either line" (p. 10).
>>
>> Cheers,
>> Gilberto
>>
>>
>>
>> -- 
>> View this message in context:
>> http://lilypond.1069038.n5.nabble.com/Noteheads-slightly-too-large-tp184659.html
>> Sent from the Bugs mailing list archive at Nabble.com.
>>
>> ___
>> 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: Noteheads slightly too large

[Urs Liska]

Am 12.12.2015 um 11:11 schrieb Simon Albrecht:
> On 12.12.2015 00:43, Urs Liska wrote:
>>
>> Am 12.12.2015 um 00:02 schrieb Simon Albrecht:
>>> Thanks for the report.
>>> <https://sourceforge.net/p/testlilyissues/issues/4693/>
>> This *may* be intended, which should be checked - if someone recalls any
>> discussion.
>> At least I recall speaking someone from a major publishing house about
>> how they created their own music font, and specifically made it do what
>> the OP reported.
> 
> Interesting – I couldn’t imagine a reason to do so, but I’d be curious
> to learn.

I'm sorry, my recollection is too vague. But if I should give a guess
I'd say it is to achieve more boldness in appearance.

Urs

> Yet there’s also the quote from Elaine Gould, confirming the ‘common
> sense’ of: it shouldn’t protrude at all beyond the staff line.
> Discussion in the tracker welcome :-)
> 
> Yours, Simon
> 

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

Another beam subdivision issue

[Urs Liska]

After completing my patch for #4664 I tested beam subdivision with
another example and was unpleasantly surprised that the other example
produced a wrong result.

This example should render the subdivisions with a regular alternation
of two and one beams. Instead all beam subdivisions show two beams
(first attachment):

\relative c' {
  \set baseMoment = #(ly:make-moment 1/16)
  \set subdivideBeams = ##t
  c64 [ \repeat unfold 30 c c ] 
}

After initial shock I investigated and found out that this is *not* due
to my patch but to commit 0382ed88 where Carl modified some behaviour of
his patch for #4355 in 8fa2d858.

After partially reverting 0382ed88 the example renders correctly as in
the second attachment. There I have two groups, one with a manual beam
exposing the new behaviour of my current patch.

###

Carl, can you tell me what you intended with that adjustment? I can see
two possible purposes:
- you thought the behaviour with alternating beam numbers is wrong
- something else I can't see from here.

If it is the first one I would like to partially revert that change to
the behaviour of your original patch for 4355. In the other case please
tell me what you were after.

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

Ugly collision when acciaccatura is followed by downward stem

[Urs Liska]

I encountered a rather ugly rendering of an acciaccatura.
As you can see in the first attachment the slurs is colliding pretty
hard with the beam.

In addition, it seems that an acciaccatura's slur always crosses the
stem of the following note if that happens to be downwards, see the
second attachment of a more common configuration.

I still don't have a copy of Gould but searching the net for references
seem to indicate that in old editions the slur does *not* cross the
downward stem but stop to the left of it, see for example
http://www.oldflutes.com/articles/kurze/

The original hand-engraving I copied from also does this (see third
attachment), and I'll follow that (last attachment).

The question is: Shouldn't LilyPond do that by default?

Urs

PS: A non-bug question: I tweaked that slur using \shape, but could
someone give me a hint as to use other properties to override, so the
slur doesn't cross the stem but rather goes *to* it?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Ugly collision when acciaccatura is followed by downward stem

[Urs Liska]

Am 26.11.2015 um 12:16 schrieb lilyp...@maltemeyn.de:
> Am 2015-11-26 10:33, schrieb Urs Liska:
>> PS: A non-bug question: I tweaked that slur using \shape, but could
>> someone give me a hint as to use other properties to override, so the
>> slur doesn't cross the stem but rather goes *to* it?
>
> If you set Slur.positions so that slur is below the end of the stem it
> will horizontally align to it. 

Unfortunately that doesn't work, at least not in my case (maybe an
acciaccatura's slur behaves differently from a normal one?).

In the attachment you can see that the slur still aligns to the center
of the note head. Moreover I feel that the override doesn't work as
expected: First attachment is overriding positions to #'(0 . -4.466),
second to #'(0 . -4.467). Suddenly there's a "leap", and it isn't
possible to get a horizontal slur that way (also the first position
doesn't seem to matter).

> But this ist what I suggested elsewhere some days ago: I would like
> the possibility to offset the endpoints of a slur without having to
> find correct values for the other bezier control points.

That seems like a nice idea. Did you look into \shapeII for that? I
don't know if it provides such a feature directly, but it will surely
offer you functions to significantly improve the user experience,
specifically I'd look for the "polar coordinates" approach.

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

Re: slurs with more than 2 control points

[Urs Liska]

Am 27.11.2015 um 03:14 schrieb tisimst:
> Malte,
> 
> On Thursday, November 26, 2015, lilypond-7 [via Lilypond] <
> ml-node+s1069038n184151...@n5.nabble.com> wrote:
> 
>> Hi list,
>>
>> how complicated would it be to get slurs with more than 2 control
>> points?
> 
> 
> With the current code? Nothing automatic, but you could definitely create a
> function that could take an arbitrary number of control points, but I
> can see that taking effect as a direct postscript drawing routine. I have
> done quite a few curve routines for other projects in the past so I know
> it's possible.
> 
> Slurs with an S shape often have very flat ends and slurs with
>> more than one "direction change" (sometimes used in
>> romantic/impressionistic piano music) aren't possible at all, are they?
> 
> 
> Current slurs can take the S shape, but only to an extent. By definition,
> since the slurs are defined as 3rd-order Bézier curves, they mathematically
> can only have a single inflection point. It would take a higher order curve
> to change directions more than one time. They aren't mathematically
> complex, but beyond the scope of the current code infrastructure.
> 
> In short, are they possible at the moment? No. Are they impossible? No, but
> it requires some new code. I might consider tackling that in the near
> future.

That would be a great addition, be it as an includable function or
(better) in LilyPond's code base.

Urs

> 
> Best,
> Abraham
> 
> 
> 
> 
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/slurs-with-more-than-2-control-points-tp184151p184186.html
> Sent from the Bugs mailing list archive at Nabble.com.
> _______
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 


-- 
Urs Liska
www.openlilylib.org

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

SubdivideBeam gives undesired result when beaming over more than a quarter note

[Urs Liska]

Since the fix for #4355, respectively commits 8fa2d858 and 0382ed88, it
is not possible anymore to subdivide beams that are longer than a
quarter note.

\version "2.19.32"

{
  \set subdivideBeams = ##t
  % This is correctly subdivided
  \set baseMoment = #(ly:make-moment 1 8)
  \repeat unfold 16 c'16
 
  % This should always keep one beam
  \set baseMoment = #(ly:make-moment 1 4)
  c' 16 [ \repeat unfold 14 c' c' ]
 
}

The behaviour is consistent with the feature request for #4355, namely:
the dividing beam should reflect the length of the following group,
which is 1/4 and results in no beam.

However, I think that this behaviour should be changed once more in that
subdivideBeam leaves *at least* one beam.

I admit I don't understand the modified code as per 0382ed88:

  // Set the count on each side of the stem
  // We need to run this code twice to make both the
  // left and the right counts work properly
  for (int i = 0; i < 2; i++)
for (vsize i = 1; i < infos_.size () - 1; i++)
  {
Direction non_flag_dir = other_dir (flag_directions[i]);
if (non_flag_dir)
  {
int importance = infos_[i + 1].rhythmic_importance_;
int count = (importance < 0 && options.subdivide_beams_)
? subdivide_beam_count
: min (min (infos_[i].count (non_flag_dir),
infos_[i + non_flag_dir].count
(-non_flag_dir)),
   infos_[i - non_flag_dir].count
(non_flag_dir));

infos_[i].beam_count_drul_[non_flag_dir] = count;
  }
  }

so I don't know whether it would be better to
- only consider values smaller than 1/4 in the calculation or
- ensure (in the last line?) that at least one beam is left.

I hope this is an easy fix.

Urs

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

Re: Problem understanding subdivided beam

[Urs Liska]

Hi Jan-Peter

Am 19.11.2015 um 10:16 schrieb Jan-Peter Voigt:
> Hi Urs,
>
> I don't have a solution, but a hint:
> in 2.18.2 stable, the beaming is correct - maybe its a bug in 2.19.x?

Thank you for that hint, which is indeed valuable.
This is quite likely a side-effect of the fix for #4355 that explicitly
changed the behaviour of the subdivisions (upon my request BTW).

In that perspective the current behaviour is actually consistent
(although undesirable IMO): Subdividing beams should respect the length
of the previous and following groups. In my example this is a quarter
note -> no beam.

I've written a feature request/bug report to bug-lilypond.
Urs

>
> Cheers,
> Jan-Peter
>
> Am 19.11.2015 um 09:42 schrieb Urs Liska:
>> Hi,
>>
>> I have a problem getting a beam subdivision right, and I can't seem to
>> find a solution in the manual:
>>
>> I have this group of 16th notes:
>>
>> \relative b {
>>\time 6/4
>>b16 [ d b' g  d g d' b  g b g' d ]  r2.
>> }
>>
>> and I want to have the secondary beam divided in three parts with one
>> quarter note each.
>>
>> However
>> \set subdivideBeams = ##t
>>
>> breaks the beam in three groups altogether, and no combination of
>> baseMoment and beatStructure I could think of produced the expected
>> result.
>>
>> Any suggestion?
>>
>> TIA
>> Urs
>>
>> ___
>> lilypond-user mailing list
>> lilypond-u...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

dynamics-barline collision

[Urs Liska]

Hi list,

I am somewhat surprised that dynamics can still collide with barlines as
shown in the attached image. I thought this kind of issue had been quite
long overcome.

The \pp is defined in a Dynamics context, and of course I can work
around the collision by overriding self-alignment-X. But is there a
proper way to let LilyPond avoid that kind of collision automatically?

Best

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

Irregularity in horizontal spacing

[Urs Liska]

Hi,

one more question.
I am right now experiencing an irregularity in the horizontal spacing
that is very small but still pretty annoying.

In the attached image you can see how the quavers are spaced out
irregularly. It is most obvious in the melody staff but you can also see
it in the piano left hand.

I have the impression that LilyPond takes the right hand figurations
into account and spaces the downward notes more closely because a
notehead can somewhat "slip" below the previous one.
This leads to the semiquavers being spaced out pretty good but the other
voices having ugly side effects.

a)
I think this is a suboptimal spacing (so a bug report). Although it's
quite tiny it is absolutely inacceptable for a publication.

b)
Is there a way to work around this without specifying offsets manually
(totally out of question for a three-page piece)?

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

Re: Irregularity in horizontal spacing

[Urs Liska]

Am 20.11.2015 um 17:09 schrieb tisimst:
> Are you referring to the final 16ths in each of the beamed groups in the
> center stave?
> 

What I mean is: These final 16ths look pretty good, but they cause the
corresponding 8th notes in the top and bottom staff to be spaced pretty
irregularly. And in effect inacceptably.

As I have to get that score ready ASAP I can't wait for a proper fix (if
it should be considered a bug) but need a workaround that works better
than having to space the notes in all measures manually.

Urs

> - Abraham
> 
> On Friday, November 20, 2015, Urs Liska [via Lilypond] <
> ml-node+s1069038n183851...@n5.nabble.com> wrote:
> 
>> Hi,
>>
>> one more question.
>> I am right now experiencing an irregularity in the horizontal spacing
>> that is very small but still pretty annoying.
>>
>> In the attached image you can see how the quavers are spaced out
>> irregularly. It is most obvious in the melody staff but you can also see
>> it in the piano left hand.
>>
>> I have the impression that LilyPond takes the right hand figurations
>> into account and spaces the downward notes more closely because a
>> notehead can somewhat "slip" below the previous one.
>> This leads to the semiquavers being spaced out pretty good but the other
>> voices having ugly side effects.
>>
>> a)
>> I think this is a suboptimal spacing (so a bug report). Although it's
>> quite tiny it is absolutely inacceptable for a publication.
>>
>> b)
>> Is there a way to work around this without specifying offsets manually
>> (totally out of question for a three-page piece)?
>>
>> TIA
>> Urs
>>
>> ___
>> bug-lilypond mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node=183851=0>
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>> *schwan.png* (33K) Download Attachment
>> <http://lilypond.1069038.n5.nabble.com/attachment/183851/0/schwan.png>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851.html
>> To start a new topic under Bugs, email
>> ml-node+s1069038n58488...@n5.nabble.com
>> <javascript:_e(%7B%7D,'cvml','ml-node%2bs1069038n58488...@n5.nabble.com');>
>> To unsubscribe from Lilypond, click here
>> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=2=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=>
>> .
>> NAML
>> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
> 
> 
> 
> 
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851p183853.html
> Sent from the Bugs mailing list archive at Nabble.com.
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 


-- 
Urs Liska
www.openlilylib.org

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

Re: Irregularity in horizontal spacing

[Urs Liska]

 Weitergeleitete Nachricht 
Betreff: Re: Irregularity in horizontal spacing
Datum: Fri, 20 Nov 2015 23:04:42 +0100
Von: Urs Liska <u...@openlilylib.org>
An: bug-lilypond@gnu.org

Am 20.11.2015 um 17:09 schrieb tisimst:
> Are you referring to the final 16ths in each of the beamed groups in the
> center stave?
> 

What I mean is: These final 16ths look pretty good, but they cause the
corresponding 8th notes in the top and bottom staff to be spaced pretty
irregularly. And in effect inacceptably.

As I have to get that score ready ASAP I can't wait for a proper fix (if
it should be considered a bug) but need a workaround that works better
than having to space the notes in all measures manually.

Urs

Well, a more abstract and minimal example is

\version "2.18.2"

\score {
  <<
\new Staff {
  \repeat unfold 4 { e'16 g' c'' g' }
}
\new Staff {
  \repeat unfold 8 c''8
}
  >>
}

resulting in the attached image.

I think the irregularity of the lower staff's eight notes is more
important than the nice "optical" spacing of the 16ths above.

Urs


> - Abraham
> 
> On Friday, November 20, 2015, Urs Liska [via Lilypond] <
> ml-node+s1069038n183851...@n5.nabble.com> wrote:
> 
>> Hi,
>>
>> one more question.
>> I am right now experiencing an irregularity in the horizontal spacing
>> that is very small but still pretty annoying.
>>
>> In the attached image you can see how the quavers are spaced out
>> irregularly. It is most obvious in the melody staff but you can also see
>> it in the piano left hand.
>>
>> I have the impression that LilyPond takes the right hand figurations
>> into account and spaces the downward notes more closely because a
>> notehead can somewhat "slip" below the previous one.
>> This leads to the semiquavers being spaced out pretty good but the other
>> voices having ugly side effects.
>>
>> a)
>> I think this is a suboptimal spacing (so a bug report). Although it's
>> quite tiny it is absolutely inacceptable for a publication.
>>
>> b)
>> Is there a way to work around this without specifying offsets manually
>> (totally out of question for a three-page piece)?
>>
>> TIA
>> Urs
>>
>> ___
>> bug-lilypond mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node=183851=0>
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>> *schwan.png* (33K) Download Attachment
>> <http://lilypond.1069038.n5.nabble.com/attachment/183851/0/schwan.png>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851.html
>> To start a new topic under Bugs, email
>> ml-node+s1069038n58488...@n5.nabble.com
>> <javascript:_e(%7B%7D,'cvml','ml-node%2bs1069038n58488...@n5.nabble.com');>
>> To unsubscribe from Lilypond, click here
>> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=2=dGlzaW1zdC5saWx5cG9uZEBnbWFpbC5jb218Mnw4MzU3Njg3MDU=>
>> .
>> NAML
>> <http://lilypond.1069038.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
> 
> 
> 
> 
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/Irregularity-in-horizontal-spacing-tp183851p183853.html
> Sent from the Bugs mailing list archive at Nabble.com.
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 


-- 
Urs Liska
www.openlilylib.org

___
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: Irregularity in horizontal spacing

[Urs Liska]

Just to finish this thread up (apart from the opened issue) I'll report
how I finally dealt with the issue in my score.

It turns out that
\override SpacingSpanner.uniform-stretching = ##t
is what I need to make the overall appearance of the score much better
than default. This completely suppresses the optical spacing of the
semiquavers but that is much less an issue than the default look.

However, this leads to a number of cases where the last semiquaver of a
beat is too close to the next item (see first
attachment for an example). I found that
\once \override NoteHead.extra-spacing-width = #'(0 . 2)
seems the way to work around this for an individual instance (see second
attachment).

In order to make that manageable I wrote the following function (using
the edition-engraver)

extraSpace =
#(define-void-function (extra-space measure beat)((pair?) integer? integer?)
   (let* ((semiquaver (- (* beat 4) 1))
  (measurepos (cons semiquaver 16))
  (space (or extra-space (cons 0 2
 #{ \editionMod fullscore #measure #measurepos the.swan.Staff.B
\once \override NoteHead.extra-spacing-width = #space #}))

which allows me to simply write
\extraSpace 3 3
to apply the tweak to beat 3 in measure 3
or
\extraSpace #'(0 . 5) 3 6
to apply the tweak to beat 6 in measure 3, but with a custom value.

To make that even more manageable I wrote the wrapper function

extraSpaces =
#(define-void-function (spaces)(list?)
   (for-each
(lambda (space)
  #{ \extraSpace #(car space) #(cdr space) #})
 spaces))

which now allows me to write

\extraSpaces #'((3 . 3)
(3 . 6))

etc.

Best
Urs

Am 21.11.2015 um 01:06 schrieb Urs Liska:
>
> Am 21.11.2015 um 00:01 schrieb Simon Albrecht:
>> On 20.11.2015 23:19, Urs Liska wrote:
>>>  Weitergeleitete Nachricht 
>>> Betreff: Re: Irregularity in horizontal spacing
>>> Datum: Fri, 20 Nov 2015 23:04:42 +0100
>>> Von: Urs Liska <u...@openlilylib.org>
>>> An: bug-lilypond@gnu.org
>>>
>>> Am 20.11.2015 um 17:09 schrieb tisimst:
>>>> Are you referring to the final 16ths in each of the beamed groups in
>>>> the
>>>> center stave?
>>>>
>>> What I mean is: These final 16ths look pretty good, but they cause the
>>> corresponding 8th notes in the top and bottom staff to be spaced pretty
>>> irregularly. And in effect inacceptably.
>>>
>>> As I have to get that score ready ASAP I can't wait for a proper fix (if
>>> it should be considered a bug) but need a workaround that works better
>>> than having to space the notes in all measures manually.
>> Well, I agree that this is a grave problem, and all the more grave
>> since it’s difficult to work around. 
> +1
> Not spectacular but a serious issue (although probably rather low in
> LilyPond's issue categorization ...)
>
>> I now see Trevor could come up with two ways, but both seem to turn
>> off optical spacing altogether.
> Yes, both are not fully satisfactory. But for my cause the looks with
> uniform-stretch is usually significantly better.
>
> Although in some situations the default spacing is actually better.
> I've attached another measure where uniform-stretching (first
> attachment) causes the stems in the right hand to look really awkward
> while the default (second attachment) is way superior but still leaves
> the quavers in an acceptable shape.
>
> I have the impression I can't change this along the way by overriding in
> the music itself, so I think I'll settle for the uniform-stretch as a
> default and tweak individually if necessary.
>
>> It seems like the spacing engine just does not take the quavers into
>> account, which would mean making some sort of a compromise between
>> optimal spacing for the semiquavers and the quavers. 
> I'm not sure if we can even hope to have a machine do that decision in a
> reliable manner. So maybe it would be more likely to be successful if we
> could provide a property that for example sets an affinity (or whatever
> it should be called) to a certain duration. I.e. sth like "prefer
> quavers over semiquavers for nice (optical) spacing.
>
>> This is really deep down in the spacing engine and I’m pretty sure
>> that it’s unconfigurable. The question is: whom do we have that might
>> be able to provide a fix? :-( Jan? Han-Wen? (they’ve rather completely
>> left the project, haven’t they?) Mike? Graham? Or David K., are you
>> somewhat acquainted with that area of the source?
> Maybe Keith would be willing to give a look? (see
> http://lilypondblog.org/2014/02/massive-improvement-in-lilyponds-horizontal-spacing/
> and the massive improvement Keith achieved in that area)
>

Re: Irregularity in horizontal spacing

[Urs Liska]

Am 23.11.2015 um 09:57 schrieb Simon Albrecht:
> On 23.11.2015 09:49, Urs Liska wrote:
>> Just to finish this thread up (apart from the opened issue) I'll report
>> how I finally dealt with the issue in my score.
>>
>> It turns out that
>>  \override SpacingSpanner.uniform-stretching = ##t
>> is what I need to make the overall appearance of the score much better
>> than default. This completely suppresses the optical spacing of the
>> semiquavers but that is much less an issue than the default look.
>>
>> However, this leads to a number of cases where the last semiquaver of a
>> beat is too close to the next item (see first
>> attachment for an example). I found that
>>  \once \override NoteHead.extra-spacing-width = #'(0 . 2)
>> seems the way to work around this for an individual instance (see second
>> attachment).
>>
>> In order to make that manageable I wrote the following function (using
>> the edition-engraver)
>>
>> extraSpace =
>> #(define-void-function (extra-space measure beat)((pair?) integer?
>> integer?)
>> (let* ((semiquaver (- (* beat 4) 1))
>>(measurepos (cons semiquaver 16))
>>(space (or extra-space (cons 0 2
>>   #{ \editionMod fullscore #measure #measurepos the.swan.Staff.B
>>  \once \override NoteHead.extra-spacing-width = #space #}))
>
> I like staying in Scheme for such things, which David K. recently made
> possible:
> (editionMod 'fullscore measure measurepos '(the swan Staff B)
>   (once (propertyOverride '(NoteHead extra-spacing-width) space)))
>
>>
>> which allows me to simply write
>>  \extraSpace 3 3
>> to apply the tweak to beat 3 in measure 3
>> or
>>  \extraSpace #'(0 . 5) 3 6
>> to apply the tweak to beat 6 in measure 3, but with a custom value.
>>
>> To make that even more manageable I wrote the wrapper function
>>
>> extraSpaces =
>> #(define-void-function (spaces)(list?)
>> (for-each
>>  (lambda (space)
>>#{ \extraSpace #(car space) #(cdr space) #})
>
> (extraSpace (car space) (cdr space)), consequently.
> Nice, isn’t it?
>

Indeed, thank you for pointing me to that.
I had taken notice of this improvement but obviously didn't internalize
sufficiently so I didn't realize I can do it like this.

Urs

>>   spaces))
>>
>> which now allows me to write
>>
>> \extraSpaces #'((3 . 3)
>>  (3 . 6))
>>
>> etc.
>
> Yours, Simon


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

Re: SubdivideBeam gives undesired result when beaming over more than a quarter note

[Urs Liska]

I've implemented a fix for this (hey, my first working C++ patch :-) )
but now I'm stumbling over the new git-cl workflow (sorry, when that was
set up I didn't have the time to follow closely enough, and the CG
section on uploading patches doesn't seem to be updated yet).

I manage to do the web authentication and upload the patch to Rietveld,
but got stuck at

```
Issue created. URL: http://codereview.appspot.com/278060043
Uploading base file for lily/beaming-pattern.cc
This has been identified with issue 4355.
Is this correct? [y/n (y)]n
4355 will not be used as a google tracker number.
Please enter a valid google tracker issue number
(or enter nothing to create a new issue):
Command "git config allura.token" failed.
You must configure your review setup by running "git cl config".
uliska@uliska-lmde-laptop:~/git/lilypond/source$ git cl config
Rietveld server (host[:port]) [codereview.appspot.com]:
Allura server []:
You must provide the address of the Allura tracker server:
```

What should I do now?

Urs


Am 19.11.2015 um 10:43 schrieb Urs Liska:
> Since the fix for #4355, respectively commits 8fa2d858 and 0382ed88, it
> is not possible anymore to subdivide beams that are longer than a
> quarter note.
>
> \version "2.19.32"
>
> {
>   \set subdivideBeams = ##t
>   % This is correctly subdivided
>   \set baseMoment = #(ly:make-moment 1 8)
>   \repeat unfold 16 c'16
>  
>   % This should always keep one beam
>   \set baseMoment = #(ly:make-moment 1 4)
>   c' 16 [ \repeat unfold 14 c' c' ]
>  
> }
>
> The behaviour is consistent with the feature request for #4355, namely:
> the dividing beam should reflect the length of the following group,
> which is 1/4 and results in no beam.
>
> However, I think that this behaviour should be changed once more in that
> subdivideBeam leaves *at least* one beam.
>
> I admit I don't understand the modified code as per 0382ed88:
>
>   // Set the count on each side of the stem
>   // We need to run this code twice to make both the
>   // left and the right counts work properly
>   for (int i = 0; i < 2; i++)
> for (vsize i = 1; i < infos_.size () - 1; i++)
>   {
> Direction non_flag_dir = other_dir (flag_directions[i]);
> if (non_flag_dir)
>   {
> int importance = infos_[i + 1].rhythmic_importance_;
> int count = (importance < 0 && options.subdivide_beams_)
> ? subdivide_beam_count
> : min (min (infos_[i].count (non_flag_dir),
> infos_[i + non_flag_dir].count
> (-non_flag_dir)),
>infos_[i - non_flag_dir].count
> (non_flag_dir));
>
> infos_[i].beam_count_drul_[non_flag_dir] = count;
>   }
>   }
>
> so I don't know whether it would be better to
> - only consider values smaller than 1/4 in the calculation or
> - ensure (in the last line?) that at least one beam is left.
>
> I hope this is an easy fix.
>
> Urs
>
> ___
> 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: Can't download Lilypond(!)

[Urs Liska]

Am 04.06.2016 um 15:33 schrieb Mike:
> Hi there, I'm using the link offered on your webpage
> http://download.linuxaudio.org/lilypond/binaries/linux-64/lilypond-2.18.2-1.linux-64.sh
> but it's not working, is the server down? I've been trying since this 
> morning...
>
> Unable to connect
> Firefox can't establish a connection to the server at download.linuxaudio.org.

See
http://www.downforeveryoneorjustme.com/http://download.linuxaudio.org

for such a request.

Urs
> Thanks
>
>
> ___
> 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: Wrongly combined note heads

[Urs Liska]

Am 23.06.2016 um 09:19 schrieb Andrew Bernard:
> Fixing lilypond would presumably
> mean adopting one particular style that may not be what everybody wants.

or rather: setting *a default* that not everybody wants.
But having to override the default because it's not your preferred way
is clearly better than having to override the default because it's wrong.

Urs

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

ly:one-line-breaking doesn't properly handle indent value/side margins

[Urs Liska]

Hi,

while testing the new #ly:one-line-auto-height-breaking I noticed some
issues with the already available #ly:one-line-breaking.

It seems the left and right margins are not properly handled in that mode:

The right margin is way too large to my eyes, which you can see when
setting right-margin to 0\cm.

The left margin is too small and doesn't respond to setting the indent
variable.
Quite the contrary, increasing the indent doesn't move the system to the
right but the instrument name to the left.

You can see both in the attached file. The image shows the unclipped
left/right/top margins compiled from the settings in the attached .ly file.

Urs
\version "2.19.36"

\paper {
  page-breaking = #ly:one-line-breaking
  right-margin = 0\cm
  ragged-last = ##f % doesn't have any effect
  indent = 1.5\cm
  %indent = 2.5\cm
}

\score {
  <<
\new Staff \with {
  instrumentName = "Voice"
} {
  c'' c'' c'' c''
}
\new PianoStaff \with {
  instrumentName = "Piano"
}
<<
  \new Staff { c' c' c' c' }
  \new Staff { c' c' c' c' }
>>
  >>
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: ly:one-line-breaking doesn't properly handle indent value/side margins

[Urs Liska]

Am 18.01.2016 um 17:04 schrieb Urs Liska:
> Hi,
>
> while testing the new #ly:one-line-auto-height-breaking I noticed some
> issues with the already available #ly:one-line-breaking.
>
> It seems the left and right margins are not properly handled in that mode:
>
> The right margin is way too large to my eyes, which you can see when
> setting right-margin to 0\cm.
>
> The left margin is too small and doesn't respond to setting the indent
> variable.
> Quite the contrary, increasing the indent doesn't move the system to the
> right but the instrument name to the left.
>
> You can see both in the attached file. The image shows the unclipped
> left/right/top margins compiled from the settings in the attached .ly file.

Update: You can make the instrument names visible by increasing left-margin.
But it still seems like there's something fishy about the right margin
and the indent.

Urs

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

git-cl traceback (timeout?)

[Urs Liska]

When uploading a patch git-cl failed with the transcript below:

I'm not sure if that's caused by git cl (I had just pulled the newest
version) or if it's a simple time-out on my side, but:

a)
If it's a git-cl issue it should be fixed
b)
If it's a time-out such an error should be handled by git-cl
c)
This left me unclear of whether the issue had been created on Allura
(I can see that it did through the website but see b) )

Best
Urs


uliska@uliska-lmde-laptop:~/git/lilypond/source$ git cl upload master
 scm/lily.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Upload server: codereview.appspot.com (change with -s/--server)
Your browser has been opened to visit:

https://codereview.appspot.com/get-access-token?port=8001

If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter

  --no_oauth2_webbrowser

Issue created. URL: http://codereview.appspot.com/286820043
Uploading base file for scm/lily.scm
We were not able to associate this patch with a tracker issue.
Please enter a valid tracker issue number
(or enter nothing to create a new issue):
Traceback (most recent call last):
  File "/home/uliska/git/lilypond/git-cl/git-cl", line 628, in 
sys.exit(main(sys.argv))
  File "/home/uliska/git/lilypond/git-cl/git-cl", line 622, in main
return func(argv[2:])
  File "/home/uliska/git/lilypond/git-cl/git-cl", line 341, in CmdUpload
issueId = projecthosting_upload.upload(issue, patchset, subject,
desc, issueId)
  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
182, in upload
status = patchy.upload(issue, patchset, subject, description, issue_id)
  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
175, in upload
issue_id = allura_issues.create_issue(subject, description)
  File "/home/uliska/git/lilypond/git-cl/allura_issues.py", line 25, in
create_issue
allura_result = urllib.urlopen (allura_api + "/new", data_encoded)
  File "/usr/lib/python2.7/urllib.py", line 89, in urlopen
return opener.open(url, data)
  File "/usr/lib/python2.7/urllib.py", line 215, in open
return getattr(self, name)(url, data)
  File "/usr/lib/python2.7/urllib.py", line 460, in open_https
data)
  File "/usr/lib/python2.7/urllib.py", line 379, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
  File "/usr/lib/python2.7/urllib.py", line 641, in http_error_302
data)
  File "/usr/lib/python2.7/urllib.py", line 667, in redirect_internal
return self.open(newurl)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 997, in endheaders
self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 850, in _send_output
self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 812, in send
self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1204, in connect
HTTPConnection.connect(self)
  File "/usr/lib/python2.7/httplib.py", line 793, in connect
self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
raise err
IOError: [Errno socket error] [Errno 110] Connection timed out



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

Re: git-cl traceback (timeout?)

[Urs Liska]

Am 19.01.2016 um 12:29 schrieb Trevor Daniels:
> Hi Urs
>
> What did you enter in response to the query?

I pressed ENTER (to create a new issue item)
Urs

>
> Trevor
>
> - Original Message - 
> From: "Urs Liska" <u...@openlilylib.org>
> To: <bug-lilypond@gnu.org>; "Phil Holmes" <m...@philholmes.net>
> Sent: Tuesday, January 19, 2016 9:49 AM
> Subject: git-cl traceback (timeout?)
>
>
>> When uploading a patch git-cl failed with the transcript below:
>>
>> I'm not sure if that's caused by git cl (I had just pulled the newest
>> version) or if it's a simple time-out on my side, but:
>>
>> a)
>> If it's a git-cl issue it should be fixed
>> b)
>> If it's a time-out such an error should be handled by git-cl
>> c)
>> This left me unclear of whether the issue had been created on Allura
>> (I can see that it did through the website but see b) )
>>
>> Best
>> Urs
>>
>>
>> uliska@uliska-lmde-laptop:~/git/lilypond/source$ git cl upload master
>> scm/lily.scm | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> Upload server: codereview.appspot.com (change with -s/--server)
>> Your browser has been opened to visit:
>>
>>https://codereview.appspot.com/get-access-token?port=8001
>>
>> If your browser is on a different machine then exit and re-run
>> upload.py with the command-line parameter
>>
>>  --no_oauth2_webbrowser
>>
>> Issue created. URL: http://codereview.appspot.com/286820043
>> Uploading base file for scm/lily.scm
>> We were not able to associate this patch with a tracker issue.
>> Please enter a valid tracker issue number
>> (or enter nothing to create a new issue):
>> Traceback (most recent call last):
>>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 628, in 
>>sys.exit(main(sys.argv))
>>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 622, in main
>>return func(argv[2:])
>>  File "/home/uliska/git/lilypond/git-cl/git-cl", line 341, in CmdUpload
>>issueId = projecthosting_upload.upload(issue, patchset, subject,
>> desc, issueId)
>>  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
>> 182, in upload
>>status = patchy.upload(issue, patchset, subject, description, issue_id)
>>  File "/home/uliska/git/lilypond/git-cl/projecthosting_upload.py", line
>> 175, in upload
>>issue_id = allura_issues.create_issue(subject, description)
>>  File "/home/uliska/git/lilypond/git-cl/allura_issues.py", line 25, in
>> create_issue
>>allura_result = urllib.urlopen (allura_api + "/new", data_encoded)
>>  File "/usr/lib/python2.7/urllib.py", line 89, in urlopen
>>return opener.open(url, data)
>>  File "/usr/lib/python2.7/urllib.py", line 215, in open
>>return getattr(self, name)(url, data)
>>  File "/usr/lib/python2.7/urllib.py", line 460, in open_https
>>data)
>>  File "/usr/lib/python2.7/urllib.py", line 379, in http_error
>>result = method(url, fp, errcode, errmsg, headers, data)
>>  File "/usr/lib/python2.7/urllib.py", line 641, in http_error_302
>>data)
>>  File "/usr/lib/python2.7/urllib.py", line 667, in redirect_internal
>>return self.open(newurl)
>>  File "/usr/lib/python2.7/urllib.py", line 213, in open
>>return getattr(self, name)(url)
>>  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
>>h.endheaders(data)
>>  File "/usr/lib/python2.7/httplib.py", line 997, in endheaders
>>self._send_output(message_body)
>>  File "/usr/lib/python2.7/httplib.py", line 850, in _send_output
>>self.send(msg)
>>  File "/usr/lib/python2.7/httplib.py", line 812, in send
>>self.connect()
>>  File "/usr/lib/python2.7/httplib.py", line 1204, in connect
>>HTTPConnection.connect(self)
>>  File "/usr/lib/python2.7/httplib.py", line 793, in connect
>>self.timeout, self.source_address)
>>  File "/usr/lib/python2.7/socket.py", line 571, in create_connection
>>raise err
>> IOError: [Errno socket error] [Errno 110] Connection timed out
>>
>>
>>
>> ___
>> 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: Fwd: lilypond-book/pdflatex: LaTeX Error: Environment lilypond undefined.

[Urs Liska]

I *think* it's wrong usage, but I didn't have the time to inspect too
closely.

The error message about the undefined \lilypond environment indicates
that LaTeX tries to compile the original file and not the one processed
by lilypond-book.

The OP should check the *actual* result of the lilypond-book invocation.
That is: which new file is produced and in which directory is it in?
Then: Which file is it that is compiled by pdflatex?

HTH
Urs


Am 07.02.2016 um 13:44 schrieb Dave Plater:
> Unfortunately I'm only subscribed to this list and just wondered if
> somebody could tell me if this is actually a bug or the wrong usage of
> lilypond-book. Lilypond-2.18.2 being very mature I would have expected
> there to have been a bug report already but I can't find any.
> Thanks
> Dave Plater
>
> On 07/02/2016 14:16, Simon Albrecht wrote:
>> This would rather be a case for the bug list.
>>
>> Best, Simon
>>
>>
>>  Forwarded Message 
>> Subject: lilypond-book/pdflatex: LaTeX Error: Environment
>> lilypond undefined.
>> Date: Sun, 7 Feb 2016 11:58:51 +0200
>> From: Dave Plater 
>> To: lilypond-de...@gnu.org
>>
>>
>>
>> Hi, I maintain lilypond in openSUSE and while I'm good at building and
>> packaging I'm far from competent as a lilypond user. A user has filed a
>> bug with the title listed in this messages subject. Could somebody
>> please have a quick look and maybe offer a hint as to what is causing
>> it. See :
>> https://bugzilla.opensuse.org/show_bug.cgi?id=964357
>> Thanks
>> Dave Plater
>>
>> ___
>> lilypond-devel mailing list
>> lilypond-de...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>>
>>
>
>
> ___
> 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