Re: Notes on wrong side of stem in triads

[Davide Liessi]

2016-10-17 3:46 GMT+02:00 DJF :
> Unfortunately, I can’t reproduce the enclosed problem in a minimal example 
> because the same code works fine in a file by itself.

"Minimal example" means that if you remove anything the problem is
gone, so if the code works in what you call a minimal example, that
was *not* a minimal example for your problem: sometimes bugs are
encountered only in long scores.

See http://lilypond.org/tiny-examples.html, especially where it says
"When trying to create an example, try commenting out (% or %{ … %})
sections of your file. If you can comment something while still
demonstrating the main idea, then remove the commented-material."
It is a tedious process, but it is actually how you can understand
where the problem is: preparing minimal examples to post to this lists
often leads me to solving problems on my own.

Anyway, if you need help with this, at least share your code
(privately, if there are copyright issues), since it is impossible to
debug an image.

Best wishes.
Davide

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

Re: No readline in scheme-sandbox

[David Sumbler]

On Sun, 2016-10-16 at 23:09 +0200, David Kastrup wrote:
> 
> David Sumbler  writes:
> 
> > 
> > On Sun, 2016-10-16 at 21:19 +0200, David Kastrup wrote:
> > > 
> > > 
> > > David Sumbler  writes:
> > > 
> > > > 
> > > > 
> > > > 
> > > > Further to the above, I find that if I type
> > > > 
> > > > /usr/local/lilypond/usr/bin/guile
> > > > 
> > > > then readline works just fine.
> > > Guile 2.0
> > > 
> > > > 
> > > > 
> > > > 
> > > >  But not when guile is invoked with
> > > > 
> > > > lilypond scheme-sandbox
> > > Guile 1.8
> > Sorry, this hasn't helped me.
> > 
> > True, if I type 'guile' it runs /usr/bin/guile-2.0, but if I type
> > /usr/bin/guile-1.8 readline also works.
> That's the system installation of Guile, not the one used in
> LilyPond.
> 
> > 
> > 
> > Presumably when I type 'lilypond scheme-sandbox' it runs the guile
> > at
> > /usr/local/lilypond/usr/bin/guile, rather than the one in
> > /usr/bin/.
> LilyPond doesn't run any Guile executable.  It just loads the Guile
> REPL
> and runs it in LilyPond as LilyPond is linked with libguile.
I don't quite understand that, but may be it's not important for me to
understand.

> 
> > 
> >  As Lilypond seems to have readline files in
> > /usr/local/lilypond/usr/lib/ and
> > /usr/local/lilypond/usr/share/guile/1.8/ice-9/
> > I would have expected readline to work.  Why are the files there if
> > they can't be used?
> Probably you don't have the necessary libraries installed.  Wrong
> architecture?  Is your LilyPond a 64bit version?
Yes, I'm running the 64-bit version of Lilypond 2.19.40.

David

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

Re: Notes on wrong side of stem in triads

[Pierre Perol-Schneider]

Hi Dan,
At least you'll find a workaround here:
http://lsr.di.unimi.it/LSR/Item?id=861

HTH.
Cheers,
Pierre

2016-10-17 9:48 GMT+02:00 Davide Liessi :

> 2016-10-17 3:46 GMT+02:00 DJF :
> > Unfortunately, I can’t reproduce the enclosed problem in a minimal
> example because the same code works fine in a file by itself.
>
> "Minimal example" means that if you remove anything the problem is
> gone, so if the code works in what you call a minimal example, that
> was *not* a minimal example for your problem: sometimes bugs are
> encountered only in long scores.
>
> See http://lilypond.org/tiny-examples.html, especially where it says
> "When trying to create an example, try commenting out (% or %{ … %})
> sections of your file. If you can comment something while still
> demonstrating the main idea, then remove the commented-material."
> It is a tedious process, but it is actually how you can understand
> where the problem is: preparing minimal examples to post to this lists
> often leads me to solving problems on my own.
>
> Anyway, if you need help with this, at least share your code
> (privately, if there are copyright issues), since it is impossible to
> debug an image.
>
> Best wishes.
> Davide
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Phrasing slurs shortened when broken

[David Kastrup]

Javier Ruiz-Alma  writes:

>>> In a piece I'm working on, and only from bar 146 on, slurs which are
>>> broken across systems, the first broken slur will be typeset short for
>>> a reason I can't figure out.What could exclusively affect the length
>>> of the first segment of broken slurs?Changing from PhrasingSlur to
>>> Slur makes no difference.I'm stumped.The version is 2.18.2.
>>Looks like the clef change in the lower system has something to do with
>>it.
>>David Kastrup
>
> I confirm, the offending instances have the clef change in the bass.
> The concern with fixing the first segment via \shape is the correction
> would be useful when the slur is broken, but undesirable when not.  We
> typeset the same source with different paper sizes, so there's a real
> chance fix, or no fix, one of the versions will show an undesirable
> slur shape.  Forcing or preventing a system break is non-ideal either.
> Interestingly enough, I'm updating the piece from LilyPond 2.1.  LP
> v2.1 slur in this situation was not as affected by this (see
> attached).
> Below is a minimal example that causes the issue/bug:
>
> \version "2.18.2"\score {  <<     { c''2 c''4 c''\(  \break c''1\) } 
>   { c''1 \clef bass c' }    >>}

Can it be

 (2.15.21) ?

I also distinctly remember one issue with some overlap due to a key
signature (though in line rather than at a line break) but cannot find
it right now.

-- 
David Kastrup

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

RE: Long compile times on Windows 10 status

[Andrew Bernard]

Hi Steven,

 

With 2.19.48 your suggestion did not work for me. With 2.19.49, it does.

 

Since this is going to hit everybody, presumably, should it be documented in
the manual somewhere folks?

 

Can the Windows installer do something like this?

 

I'm new to Windows, having previously led a trouble free life with Linux.

 

Andrew

 

 

 

From: Steven Weber [mailto:pant...@hotmail.com] 
Sent: Monday, 17 October 2016 10:45 AM
To: 'Andrew Bernard' ; lilypond-user@gnu.org
Subject: RE: Long compile times on Windows 10 status

 

I've found that whenever I install a new font on my computer, I wind up in
this state.

 

That being said, I can recover back to normal speeds by deleting the
C:\Users\\.lilypond-fonts.cache-2 folder.  The first build after doing
this will be slow (because it's rebuilding the font cache), but after that,
speeds are back to normal.

 

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

Trouble Combining Repeats and Closing Bars in tunes

[Ben Beeson]

Hi,

I am looking at a 4 - part tune where the first and third parts are
repeated and the second and fourth parts are not repeated. Try as I
may, I cannot get Lilypond to put  the repeats and closing bars in the
right place when engraving the tune. The following is just about as
simple as I can get it and still show the issue.  

% BarExample.ly 
\version "2.19.48"

example = {   \time 2/4
  \relative c''{
 \repeat volta 2 { a8 a8 a8 a8 | a8 a8 a8
a8 | \break  }  
  \bar ".|" d8 d8 d8 d8
|  d8 d8 d8 d8 | \bar "|." \break
 \repeat volta 2 { a8 a8 a8 a8 | a8 a8 a8
a8 | \break } 
  \bar ".|"  d8 d8 d8 d8 |
d8 d8 d8 d8 | \bar "|." \break }
}
 

\score   
{
\new Staff <<

\new Voice {
\example
}   
>>   
}
% end BarExample.ly 

This produces the following which is clearly not what I intended since
the first and third lines should be repeated and the second and fourth
lines are not repeated. 


 What am I doing wrong and what is the best way to fix it short of
using separate score blocks for each part? 

Thanks in advance for your help,

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

Re: Phrasing slurs shortened when broken

[Vaughan McAlley]

On 17 October 2016 at 13:00, Javier Ruiz-Alma  wrote:
>
> The concern with fixing the first segment via \shape is the correction would 
> be useful when the slur is broken, but undesirable when not.  We typeset the 
> same source with different paper sizes, so there's a real chance fix, or no 
> fix, one of the versions will show an undesirable slur shape.  Forcing or 
> preventing a system break is non-ideal either.
>

The second set of control points in \shape has to do double duty
depending on whether it is at the end of the slur or at a line break.
Perhaps more useful would be \shape taking the first point of the
first group and the last point of the last group if the slur is not
broken.

Even better would be the ability to apply a totally
different set of points depending on the line breaking. This would be
trickier as a slur spanning three bars could potentially break in two
different places. It would potentially make things
quite complicated.

Vaughan

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

Re: Phrasing slurs shortened when broken

[Urs Liska]

Am 18. Oktober 2016 06:57:46 MESZ, schrieb Vaughan McAlley 
:
>On 17 October 2016 at 13:00, Javier Ruiz-Alma 
>wrote:
>>
>> The concern with fixing the first segment via \shape is the
>correction would be useful when the slur is broken, but undesirable
>when not.  We typeset the same source with different paper sizes, so
>there's a real chance fix, or no fix, one of the versions will show an
>undesirable slur shape.  Forcing or preventing a system break is
>non-ideal either.
>>

If you are dealing with a fixed set of alternative breaks you can use either 
manual breaks wrapped in \tag or work with the page-layout package 
(https://github.com/openlilylib/page-layout).

Having a function like \ifAtBreak would of course very useful, not only for 
slurs. Maybe someone has already done such a thing?

Urs

>
>The second set of control points in \shape has to do double duty
>depending on whether it is at the end of the slur or at a line break.
>Perhaps more useful would be \shape taking the first point of the
>first group and the last point of the last group if the slur is not
>broken.
>
>Even better would be the ability to apply a totally
>different set of points depending on the line breaking. This would be
>trickier as a slur spanning three bars could potentially break in two
>different places. It would potentially make things
>quite complicated.
>
>Vaughan
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

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

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

Re: lrouble Combining Repeats and Closing Bars in tunes

[Cynthia Karl]

> --
> 
> Message: 2
> Date: Mon, 17 Oct 2016 23:24:51 -0400
> From: Ben Beeson 
> To: lilypond-user 
> Subject: Trouble Combining Repeats and Closing Bars in tunes
> 
> Hi,
> 
> I am looking at a 4 - part tune where the first and third parts are
> repeated and the second and fourth parts are not repeated. Try as I
> may, I cannot get Lilypond to put ?the repeats and closing bars in the
> right place when engraving the tune. The following is just about as
> simple as I can get it and still show the issue. 

> % BarExample.ly 
> \version "2.19.48"
> 
> example = {   \time 2/4
>   \relative c''{
>  \repeat volta 2 { a8 a8 a8 a8 | a8 a8 a8 a8 | 
> \break  }  
>   \bar ".|" d8 d8 d8 d8 |  d8 d8 
> d8 d8 | \bar "|." \break
>  \repeat volta 2 { a8 a8 a8 a8 | a8 a8 a8 a8 | 
> \break } 
>   \bar ".|"  d8 d8 d8 d8 | d8 d8 
> d8 d8 | \bar "|." \break }
> }
>  
> 
> \score   
> {
>   \new Staff <<
>   
>   \new Voice {
>   \example
>   }   
>   >>   
> }
> % end BarExample.ly 
> 
> This produces the following which is clearly not what I intended since
> the first and third lines should be repeated and the second and fourth
> lines are not repeated.?
> 
> 
> ?What am I doing wrong and what is the best way to fix it short of
> using separate score blocks for each part??

Try:



BarExample.ly
Description: Binary data

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

Re: Trouble Combining Repeats and Closing Bars in tunes

[Marc Hohl]

Am 18.10.2016 um 05:24 schrieb Ben Beeson:

Hi,

I am looking at a 4 - part tune where the first and third parts are
repeated and the second and fourth parts are not repeated. Try as I
may, I cannot get Lilypond to put  the repeats and closing bars in
the right place when engraving the tune. The following is just about
as simple as I can get it and still show the issue.


If you use \repeat volta 2 { ... }
and then put a \bar "..." command afterwards, this bar command overrides
the repeat bar line – so in fact, the line is repeated internally for
lilypond, but you can't see it.

In this case, you'll have to define your own repeat bar line at the
beginning of your document:

#(define-bar-line ":|.-.|" ":|." ".|" "|.")

and use it like this:

\repeat volta 2 { ... }

\bar ":|.-.|"   \bar "|."


The way lilypond deals internally with repeats versus explicitly given
barlines is not optimal yet :-(

HTH,

Marc


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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear when padded

[David Kastrup]

Rutger Hofman  writes:

> P.S. Building lilypond on my (up-to-date-ish but certainly not
> killer-class) PC take some minutes, not those tens of hours that the
> list spoke about lately.

Do you want to volunteer for building our distributions and installers
then?  I suspect that would take a few more minutes...

-- 
David Kastrup

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

Re: accidentalStyle modern

[sailfox]

Thank you very much for your hint! I will try to change laziness variable.

Markus

> David Wright  hat am 15. Oktober 2016 um 05:29 
> geschrieben:
> 
> 
> On Fri 14 Oct 2016 at 06:32:11 (+0200), Pierre Perol-Schneider wrote:
> > e.g. :
> > http://lilypond.1069038.n5.nabble.com/Custom-accidental-styles-td190776.html
> > 
> > 2016-10-13 23:51 GMT+02:00 Simon Albrecht :
> > 
> > > On 12.10.2016 18:49, sail...@mailbox.org wrote:
> > >>
> > >> the following remark is written in the lilypond docu for accidentalStyle
> > >> modern:
> > >> "after temporary accidentals, cancellation marks are printed also in the
> > >> following measure".
> > >> Is it possible to change the number of following measures where
> > >> cancellation marks are written to more than one?
> > >>
> > >
> > > I’m afraid there is no easy solution; you’d have to create a custom
> > > accidental style, and even by that would be unusually difficult to achieve
> > > what you want, IIRC. You should be able to find an example of custom
> > > accidental style on the archives to this list.
> 
> Looking at, eg,
> lilypond-2.19.44-1/lilypond/usr/share/lilypond/current/scm/music-functions.scm
> I read:
> 
> "The @var{laziness} is the number of measures
> for which reminder accidentals are used (i.e., if @var{laziness} is zero,
> only cancel accidentals in the same measure; if @var{laziness} is three,
> we cancel accidentals up to three measures after they first appear."
> 
> which seems to imply that setting laziness > 1 will do what the OP
> wants and is all that's required.
> 
> I have no idea how one would do this nor where laziness gets its
> default value from.
> 
> Cheers,
> David.

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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear when padded

[David Nalesnik]

On Mon, Oct 17, 2016 at 8:26 AM, Rutger Hofman  wrote:
> Thanks for all the help! First I post some rationale, then my real question,
> which is targeted at the developers I guess.
>
> The behaviour I am after is a thing I really do want: it is visually
> confusing if the 'a tempo' comes halfway the 'poco rit.)' when it is clearly
> meant to be after it.
>
> I am afraid that solutions involving staff-padding are not general enough;
> if I try to move the \markup{a tempo} in my example to the beginning of its
> bar, there is no value for right.text padding or staff-padding that lets it
> be both visible and at the same vertical position. And even then I am unsure
> if it will work for all 14 instrument parts (the tempo indications are
> needed in all), the skyline can be wildly different.

I'm having difficulty understanding exactly what it is that you want
or why the solutions presented are insufficient.  Is it possible to
provide some sort of mockup--if if hand-drawn--to show exactly how
you'd like this to look?

> OK... Now for the real question.
>
> I am really unenlightened why the right.text (or for that matter, both
> left.text and right.text if the padding is chosen sufficiently large)
> disappears for largish values of padding. After all, the padding is intended
> to stretch outside the texts, isn't that correct?
>
> For a quick attempt to see if things crash or whatever if this test is
> disabled, I cloned git and built on my Ubuntu, verified quickly that the
> unmodified install works, then commented out that test (line 329 in
> lily/line-spanner.cc) and ran again. Lo and behold, everything looks OK in
> my first quick tests.
>
> I am not familiar with Lilypond internals, so this raises my question: what
> is this test for? What problems does it guard against? Should it only hold
> for other spanners than text spanners? Or for right-broken text spanners?
> Etc. Or is it just a bug/feature silently living on from the past?

When I fiddled around this a few days ago, the dashed line would
disappear when doing this.  Modifying the code to show the dashed line
again (another condition) shows the line superimposed on the right
text.

I can't investigate this further/pass along my test code for you to
investigate, b/c unfortunately I'm having a file permissions disaster
on my Win10 system.

David

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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear whenpadded

[Phil Holmes]

- Original Message - 
From: "Rutger Hofman" 

To: "lilypond-user" 
Sent: Monday, October 17, 2016 2:26 PM
Subject: Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear 
whenpadded



P.S. Building lilypond on my (up-to-date-ish but certainly not 
killer-class) PC take some minutes, not those tens of hours that the list 
spoke about lately.


Building the lilypond executable on my Ubuntu build machine takes me just 
over a minute.  Building the full set of release executables and documents 
(a Gub build) took 12 hours yesterday.  Uploading the set is still 
proceeding, but I started over six hours ago.


--
Phil Holmes 



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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear when padded

[Rutger Hofman]

Thanks for all the help! First I post some rationale, then my real 
question, which is targeted at the developers I guess.


The behaviour I am after is a thing I really do want: it is visually 
confusing if the 'a tempo' comes halfway the 'poco rit.)' when it is 
clearly meant to be after it.


I am afraid that solutions involving staff-padding are not general 
enough; if I try to move the \markup{a tempo} in my example to the 
beginning of its bar, there is no value for right.text padding or 
staff-padding that lets it be both visible and at the same vertical 
position. And even then I am unsure if it will work for all 14 
instrument parts (the tempo indications are needed in all), the skyline 
can be wildly different.


OK... Now for the real question.

I am really unenlightened why the right.text (or for that matter, both 
left.text and right.text if the padding is chosen sufficiently large) 
disappears for largish values of padding. After all, the padding is 
intended to stretch outside the texts, isn't that correct?


For a quick attempt to see if things crash or whatever if this test is 
disabled, I cloned git and built on my Ubuntu, verified quickly that the 
unmodified install works, then commented out that test (line 329 in 
lily/line-spanner.cc) and ran again. Lo and behold, everything looks OK 
in my first quick tests.


I am not familiar with Lilypond internals, so this raises my question: 
what is this test for? What problems does it guard against? Should it 
only hold for other spanners than text spanners? Or for right-broken 
text spanners? Etc. Or is it just a bug/feature silently living on from 
the past?


Rutger

P.S. Building lilypond on my (up-to-date-ish but certainly not 
killer-class) PC take some minutes, not those tens of hours that the 
list spoke about lately.


On 10/12/2016 09:56 PM, David Nalesnik wrote:

On Wed, Oct 12, 2016 at 2:04 PM, Rutger Hofman  wrote:

On 10/12/2016 06:17 PM, David Nalesnik wrote:


On Wed, Oct 12, 2016 at 8:48 AM, David Nalesnik
 wrote:


Harm,

On Wed, Oct 12, 2016 at 8:13 AM, Thomas Morley 
wrote:



in this thread

http://lilypond.1069038.n5.nabble.com/Alternate-scheme-text-spanner-ignores-spacers-td195195.html
you researched the cause for problems while attaching TextSpanner to
spacers using custom-scheme-engravers.

May it be possible the problem is present in the original .cc-coded as
well?

At least I don't see any problem with attached TextSpanners as soon as
I change a spacer to a real note-event in Rutger's code:



It appears to be related to the X-position of the right-bound text:
if it's too far to the left, it won't be printed.

Change the right-padding override in your example to 10, and the text
will also disappear.



ly:line-spanner::print considers the properties left-bound-info and
right-bound-info.  It returns '() if the sum of left.padding and
right.padding is greater than the distance between the left and right
ends of the spanner (as determined from "X" and "Y" stored in
bound-details).  I can't say I follow the thinking, but that's what
causes nothing to be printed when right.padding is set too high.

(The variable for padding is confusingly named "gaps" in the code, by the
way.)

David



For starters: thanks to you all for thinking along, and searching for an
analysis (and hopefully fix).

The 'solution' of suppressing the spanner under these conditions doesn't
sound immediately logical to me. And this suppression only struck my eye for
spanners that cross a line break; which doesn't imply that it cannot occur
otherwise of course.



The point I'm making is that the spanner was only suppressed in your
original example because the value you chose for right.padding was too
large -- large enough to put the right text before the left endpoint,
which roughly is why the program gave you nothing.  If you use

\override TextSpanner.bound-details.right.padding = #2

the text is moved out from under the TextScript.  You can then
override TextScript.staff-padding and TextSpanner.staff-padding to
force an alignment.  As far as I know, you will have to align them
yourself this way because the TextSpanner and TextScript are not
grouped.  The inner-texts enhancement does offer a grouping of sorts.

David




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

Programming error mis-predicted force

[Andrew Bernard]

Hello all,

 

Revisiting a score that used to compile fine some time ago with 2.19.12,
running the unmodified file with 2.19.39 I get a list of programming errors
the like of which I have not seen before:

 

Preprocessing graphical objects...

programming error: mis-predicted force, 143.970945 ~= 144.861828

continuing, cross fingers

programming error: mis-predicted force, 143.970945 ~= 143.595608

continuing, cross fingers

programming error: mis-predicted force, 143.970945 ~= 142.301732

continuing, cross fingers

programming error: mis-predicted force, 143.970945 ~= 149.851675

continuing, cross fingers

programming error: mis-predicted force, 143.970945 ~= 167.877936

continuing, cross fingers

programming error: mis-predicted force, 143.970945 ~= 144.271730

continuing, cross fingers

 

Sadly, there are no locations associated with these errors (I know this is
problematical in lilypond, yes), and I have no idea where they arise from,
and no idea what mis-predicted force could possibly mean. Anybody able to
explain?

 

Andrew

 

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

Re: Programming error mis-predicted force

[Phil Holmes]

Possibly https://sourceforge.net/p/testlilyissues/issues/4975/

--
Phil Holmes


  - Original Message - 
  From: Andrew Bernard 
  To: lilypond-user@gnu.org 
  Sent: Monday, October 17, 2016 12:29 PM
  Subject: Programming error mis-predicted force


  Hello all,

   

  Revisiting a score that used to compile fine some time ago with 2.19.12, 
running the unmodified file with 2.19.39 I get a list of programming errors the 
like of which I have not seen before:

   

  Preprocessing graphical objects...

  programming error: mis-predicted force, 143.970945 ~= 144.861828

  continuing, cross fingers

  programming error: mis-predicted force, 143.970945 ~= 143.595608

  continuing, cross fingers

  programming error: mis-predicted force, 143.970945 ~= 142.301732

  continuing, cross fingers

  programming error: mis-predicted force, 143.970945 ~= 149.851675

  continuing, cross fingers

  programming error: mis-predicted force, 143.970945 ~= 167.877936

  continuing, cross fingers

  programming error: mis-predicted force, 143.970945 ~= 144.271730

  continuing, cross fingers

   

  Sadly, there are no locations associated with these errors (I know this is 
problematical in lilypond, yes), and I have no idea where they arise from, and 
no idea what mis-predicted force could possibly mean. Anybody able to explain?

   

  Andrew

   



--


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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear when padded

[David Nalesnik]

On Mon, Oct 17, 2016 at 9:35 AM, David Nalesnik
 wrote:
> On Mon, Oct 17, 2016 at 8:26 AM, Rutger Hofman  wrote:
>> Thanks for all the help! First I post some rationale, then my real question,
>> which is targeted at the developers I guess.
>>
>> The behaviour I am after is a thing I really do want: it is visually
>> confusing if the 'a tempo' comes halfway the 'poco rit.)' when it is clearly
>> meant to be after it.
>>
>> I am afraid that solutions involving staff-padding are not general enough;
>> if I try to move the \markup{a tempo} in my example to the beginning of its
>> bar, there is no value for right.text padding or staff-padding that lets it
>> be both visible and at the same vertical position. And even then I am unsure
>> if it will work for all 14 instrument parts (the tempo indications are
>> needed in all), the skyline can be wildly different.
>
> I'm having difficulty understanding exactly what it is that you want
> or why the solutions presented are insufficient.  Is it possible to
> provide some sort of mockup--if if hand-drawn--to show exactly how
> you'd like this to look?
>
>> OK... Now for the real question.
>>
>> I am really unenlightened why the right.text (or for that matter, both
>> left.text and right.text if the padding is chosen sufficiently large)
>> disappears for largish values of padding. After all, the padding is intended
>> to stretch outside the texts, isn't that correct?
>>
>> For a quick attempt to see if things crash or whatever if this test is
>> disabled, I cloned git and built on my Ubuntu, verified quickly that the
>> unmodified install works, then commented out that test (line 329 in
>> lily/line-spanner.cc) and ran again. Lo and behold, everything looks OK in
>> my first quick tests.
>>
>> I am not familiar with Lilypond internals, so this raises my question: what
>> is this test for? What problems does it guard against? Should it only hold
>> for other spanners than text spanners? Or for right-broken text spanners?
>> Etc. Or is it just a bug/feature silently living on from the past?
>
> When I fiddled around this a few days ago, the dashed line would
> disappear when doing this.  Modifying the code to show the dashed line
> again (another condition) shows the line superimposed on the right
> text.
>
> I can't investigate this further/pass along my test code for you to
> investigate, b/c unfortunately I'm having a file permissions disaster
> on my Win10 system.
>
> David

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

Re: [Spam] Re: [Spam] Re: Spanner right-hand text may disappear when padded

[David Nalesnik]

On Mon, Oct 17, 2016 at 9:35 AM, David Nalesnik
 wrote:
> On Mon, Oct 17, 2016 at 8:26 AM, Rutger Hofman  wrote:
>> Thanks for all the help! First I post some rationale, then my real question,
>> which is targeted at the developers I guess.
>>
>> The behaviour I am after is a thing I really do want: it is visually
>> confusing if the 'a tempo' comes halfway the 'poco rit.)' when it is clearly
>> meant to be after it.
>>
>> I am afraid that solutions involving staff-padding are not general enough;
>> if I try to move the \markup{a tempo} in my example to the beginning of its
>> bar, there is no value for right.text padding or staff-padding that lets it
>> be both visible and at the same vertical position. And even then I am unsure
>> if it will work for all 14 instrument parts (the tempo indications are
>> needed in all), the skyline can be wildly different.
>
> I'm having difficulty understanding exactly what it is that you want
> or why the solutions presented are insufficient.  Is it possible to
> provide some sort of mockup--if if hand-drawn--to show exactly how
> you'd like this to look?
>
>> OK... Now for the real question.
>>
>> I am really unenlightened why the right.text (or for that matter, both
>> left.text and right.text if the padding is chosen sufficiently large)
>> disappears for largish values of padding. After all, the padding is intended
>> to stretch outside the texts, isn't that correct?
>>
>> For a quick attempt to see if things crash or whatever if this test is
>> disabled, I cloned git and built on my Ubuntu, verified quickly that the
>> unmodified install works, then commented out that test (line 329 in
>> lily/line-spanner.cc) and ran again. Lo and behold, everything looks OK in
>> my first quick tests.
>>
>> I am not familiar with Lilypond internals, so this raises my question: what
>> is this test for? What problems does it guard against? Should it only hold
>> for other spanners than text spanners? Or for right-broken text spanners?
>> Etc. Or is it just a bug/feature silently living on from the past?
>
> When I fiddled around this a few days ago, the dashed line would
> disappear when doing this.  Modifying the code to show the dashed line
> again (another condition) shows the line superimposed on the right
> text.
>
> I can't investigate this further/pass along my test code for you to
> investigate, b/c unfortunately I'm having a file permissions disaster
> on my Win10 system.
>

Sorry about the empty email!

I've attached a Scheme rewrite of ly:text-spanner::print which allows
for easy demonstration of the problems I mention above.

I've removed the padding check.  This only brings back the right text.
The line is suppressed b/c the endpoint of the right side is actually
LEFT of the endpoint of the left side

Removing the check (line 161) draws the line, and you can see the consequences.

You could experiment with finding a way to set the X of the broken
second-half of the spanner to some value under 0.  I don't have a
rewrite of that C++ stuff, so it will mean messing with the source.

Sorry I can't be of more help.

David
\version "2.19.25"

#(define (offset-subtract a b)
   (cons (- (car b) (car a))
 (- (cdr b) (cdr a

#(define (offset-mul a b)
   (cons (* (car a) (car b))
 (* (cdr a) (cdr b

#(define (offset-direction o)
   (cond
((and (inf? (car o)) (not (inf? (cdr o
 (cons (if (> (car o) 0.0) 1.0 -1.0)
   0.0))
((inf? (cdr o))
 (cons 0.0
   (if (> (cdr o) 0.0) 1.0 -1.0)))
((and (= (car o) 0.0) (= (cdr o) 0.0))
 o)
(else
 (let ((len (sqrt (+ (* (car o)(car o)) (* (cdr o)(cdr o))
   (cons (/ (car o) len) (/ (cdr o) len))


#(define (line-spanner::print grob)
   (let* (; Triggers simple-Y calculations
   (simple-y
(and (eq? #t (ly:grob-property grob 'simple-Y))
 (not (eq? #t (ly:grob-property grob 'cross-staff)
   (bound-info-L (ly:grob-property grob 'left-bound-info))
   (bound-info-R (ly:grob-property grob 'right-bound-info))
   (commonx (ly:grob-common-refpoint
 (ly:spanner-bound grob LEFT)
 (ly:spanner-bound grob RIGHT)
 X))
   (commonx (ly:grob-common-refpoint grob commonx X))
   (span-points
(list
 (cons (assoc-get 'X bound-info-L 0.0)
   (assoc-get 'Y bound-info-L 0.0))
 (cons (assoc-get 'X bound-info-R 0.0)
   (assoc-get 'Y bound-info-R 0.0
   ; For scaling of 'padding and 'stencil-offset
   (magstep (expt 2 (/ (ly:grob-property grob 'font-size 0.0) 6)))
   (gaps
(cons (assoc-get 'padding bound-info-L 0.0)
  (assoc-get 'padding bound-info-R 0.0)))
   ;; not supported in Scheme yet
   (arrows
(cons (assoc-get 'arrow bound-info-L #f)
  (assoc-get 'arrow bound-info-R 

mac unstable 2.19.49

[Stan Sanderson]

 
Many thanks to all who worked on the problem and found the solution. v2.19.49 
seems faster than v2.19.46!
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user