Re: Strange beaming error

[Urs Liska]

Am 07.01.2016 um 10:16 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Do you also have subdivideBeams = ##t somewhere?
>> If so please show the result with both 2.19.28 and .35..
>>
>> And if that's the case you should maybe send me (privately?) the full
>> piece so I could test with several builds before and after several
>> recent changes.
> It's not the first time the subdivision fixes had to be overhauled.  And
> if we keep up the way of dealing with them, I rather doubt it will be
> the last time.

Maybe I should clarify something about this history.

Beam subdivision wasn't ever correct in so far that at any subdivision
(only) one beam was left, and I reported this as a bug last April.
As issue 4355 this was fixed (not by me).

In November I noticed a new issue and realized it was an unnoticed side
effect of 4355.
I fixed this as issue 4664, only to notice that the behavior introduced
in 4355 didn't work anymore.

As it turned out this wasn't my fault in 4664, but a few weeks after
4355 the behavior had been partially reverted (in
0382ed88b53cb24e76a1935e18df32cc87174428 "Adjust beam subdivision to
only occur at baseMoment", without further explanation and seemingly
without a tracker item.

So I gave the issue more thought and hoped to fix the issue properly.

>
> I suggest that you write down the rules, _all_ rules, that are supposed
> to be governing subdivision.  On paper.  As a simple recipe of the "if
> this condition is met, do this, else if that condition is met, do that,
> else ... otherwise ..." kind.

Basically this is what I did, but there were cases I couldn't imagine.
One of them is when baseMoment equals the actual note duration.

The obvious issue of the OP was a case where this is actually improper
LilyPond coding:

\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/16)
c16 c c c

just makes no sense. And this is why I didn't give that case more thought.
But with

\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/16)
c16 c c64 c c c c32 c

It *does* make sense to have beam subdivision points at every note (the
first three ones).

The other case that deserves further attention is when the beam is
shortened, but not at the end but at the beginning (i.e. r32 c c c).

So I think I'll follow your suggestions above and below, considering
these cases and do my best to identify other (corner) cases.

>
> _Then_ you check the examples making problems.  On paper.  Does LilyPond
> follow the rules?  If so, the rules may need changing.  Where the rules
> cannot sensibly changed to accommodate conflicting but equally valid
> cases, we'll have to introduce manual intervention methods that are to
> be used for a well-defined and humanly recognizable subset of cases.
>
> If LilyPond does _not_ follow the rules on paper however, the
> implementation is broken.  How did it manage to escape scrutiny several
> times?  Perhaps a rewrite is required where the logic of the code can
> trace the human-accessible rules so closely that there is no doubt about
> the code matching the rules.
>
> Oh, and that paper with the rules?  Once the code follows it, the
> content of the paper belongs in code comments and possibly a manual.

Well, I think I have covered *most* rules, and these are documented
pretty extensively in the code comments and the regtests.

Urs

>


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

Re: Strange beaming error

[Urs Liska]

Hi Chris,

OK, I've now compiled your score (thanks for the gist, looks nice BTW)
and went through the beaming issues I could see.

First of all I must say that the new subdivision logic (introduced in
2.19.35) seems to do what I wanted and is actually an improvement:
Compare 01.png to 02.png and 03.png and tell me which one gives you a
more immediate idea of the music ...
(and just in case anyone is in doubt: 01 is the new one and how it
should be done, 02 is 2.19.34, and 03 is 2.19.19 (and any older version).

###

First issue I saw is shown in 04.png (m. 21)
Note that the music is in 6/8.
I'm not sure this qualifies as a bug as it is actually wrongly coded with
\set Timing.baseMoment = (ly:make-moment 1/16)
\set Timing.beatStructure = #'(6 6)

You should change that to
\set baseMoment = (ly:make-moment 1/8)
\set beatStructure = #'(3 3)
, then the result is correct as per 05.png.
But I suggest you don't subdivide here at all (as you have correctly do
in the l.h.) - or if you would consider subdivisions as the way to go
then at least do it in both hands.

###

However, a possible issue is shown in 06.png.
Here it may be wrong that the first beam has a beamlet instead of two
beams. This is a case for David's suggestion to write down *all* rules.
The issue is that the durations are the same as baseMoment - but here it
is used correctly (other than with the first example). This notation is
very useful if you have a single trailing note on a beam after a
subdivision, but here it seems slightly strange.

###

I couldn't reproduce the issue shown in your initial message, though.

###

Is there any issue I overlooked?

Best
Urs

Am 07.01.2016 um 00:53 schrieb Chris Yate:
> Hi, 
>
> I'm wondering whether anyone can shed some light on the attached image.
>
> LH of the piano here is:
>
> {
>  bf,16 (ef g8) r8
>   c,16 g' c, g' bf, g'
>   \clef bass
> }
>
> I have a suspicion this may have something to do with the Timing /
> beat moment and beat structure, but it's inconclusive. This section of
> the music has:
>
>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>   \set Timing.beatStructure = #'( 6 6 )
>
> There are no barline errors, but I'm seeing this in the output quite a
> lot: 
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 105.654382
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
>
>
> Previously I was getting a similar issue where I had bars of 6
> quavers, which were grouped in 3's -- and the middle of the second
> group was getting a spurious semiquaver beam. I seem to fixed it,
> though I'm not sure what the cause was.
>
> Thanks in advance,
>
> Chris
>
> Inline images 1
>
>
> ___
> 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: Strange beaming error

[Urs Liska]

Am 07.01.2016 um 18:24 schrieb Chris Yate:
> On 7 January 2016 at 17:12, Mark Stephen Mrotek  > wrote:
>
> Chris,
>
>  
>
> As I mentioned in a previous reply, make sure that identical “\set
> Timining” instructions are in both the upper and lower staff.
>
> Once this is done, recompile and check for accuracy.
>
>  
>
> Mark
>
>
>
> Thanks for the suggestion - I tried that but it didn't help. 
>
> In a general case I wouldn't always want the same beaming in each
> hand, so if the output is sensitive to that it's probably a bug... 
>
> Anyway, Urs Liska has a Gist with my current code on this project, and
> I gather is going to do a regression test in case there's a recent bug
> in Lilypond.

I've nearly tracked it down to input coding, but couldn't finish it
before having to leave ...

I'll send something later tonight.

Urs

>
> Chris
>
>
> ___
> 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: Strange beaming error

[Chris Yate]

On 7 January 2016 at 17:12, Mark Stephen Mrotek 
wrote:

> Chris,
>
>
>
> As I mentioned in a previous reply, make sure that identical “\set
> Timining” instructions are in both the upper and lower staff.
>
> Once this is done, recompile and check for accuracy.
>
>
>
> Mark
>
>
>
Thanks for the suggestion - I tried that but it didn't help.

In a general case I wouldn't always want the same beaming in each hand, so
if the output is sensitive to that it's probably a bug...

Anyway, Urs Liska has a Gist with my current code on this project, and I
gather is going to do a regression test in case there's a recent bug in
Lilypond.

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

RE: Strange beaming error

[Chris Yate]

On 7 Jan 2016 1:31 am, "Mark Stephen Mrotek"  wrote:

>
> Chris:
>
>
> What is the time signature? 6/8?
>
> Or is it 2/4 grouped as if in tuplets?
> Mark

Mark,

Yes, it's 6/8.
Although it changes to 4/4 for one movement - the one before this problem
occurs (that may or may not be coincidental), and there's partial bars at
the beginning and end of most of the movements

Chris

---
On 7 January 2016 at 09:05, David Kastrup  wrote:

> Chris Yate  writes:
> > Are inlined images not OK here? ...or were you just being pedantic?
> > ;-)
>
> They were inlined into the HTML part only rather than attached as a
> separate MIME part with an inline disposition.
>
> As a result, a number of readers will not be able to see them (for
> example, I had to switch my default viewing modes around after being
> made aware by Thomas that there was supposed to be an included graphic)
> and the list archives are not likely to offer them either since they
> tend to trash the HTML parts.
>
> So your method of attachment is not likely to work well for a lot of
> purposes (probably the only worse way would be to make it a background
> image of the mail).  I would strongly suggest that you try to figure out
> one that would be more likely to work with the bulk of readers.


OK, noted, thanks.  I'm now rather accustomed to using webmail, and it's
arguably a failing of the webmail client if it doesn't attach a
drag-dropped file properly.  Whilst I don't want to start a holy war on
this point, I'd hazard a guess that the *bulk* of readers nowadays, by
which I mean email clients designed for humans to read, are perfectly
capable of reading HTML emails.

The main exception I can see (and it's a good one) is a list archive. Would
attachments be archived too? Inline replies vs top posting is the same
argument IMO.

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

Re: Strange beaming error

[David Kastrup]

Urs Liska  writes:

> Before testing further I assume the current issue is due to *not*
> using the latest state (which isn't in a release yet).

Why are there different states?  Did the original plan fail on paper or
did it never reach paper?  Or was it not correctly implemented?

> But of course I'll test with the material and with all iterations of
> the code once I have it.

"Iterations of the code" makes me queasy.  It suggests that there is no
plan but instead one pokes the code until it happens to work most of the
time.  Then it cannot be documented, maintained, or changed because
nobody really knows the reason that it works.

I am aware that large amounts of code come into being in that manner,
partly because of resource limitations.

And there is some justification for it in the "reaping" phase of a
product, where the main issue is selling it while investing the least
amount of work (Sibelius anyone?).

LilyPond is not due for the reaper yet.

-- 
David Kastrup

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

Re: Strange beaming error

[Urs Liska]

Am 7. Januar 2016 10:16:29 MEZ, schrieb David Kastrup :
>Urs Liska  writes:
>
>> Do you also have subdivideBeams = ##t somewhere?
>> If so please show the result with both 2.19.28 and .35..
>>
>> And if that's the case you should maybe send me (privately?) the full
>> piece so I could test with several builds before and after several
>> recent changes.
>
>It's not the first time the subdivision fixes had to be overhauled. 
>And
>if we keep up the way of dealing with them, I rather doubt it will be
>the last time.
>
>I suggest that you write down the rules, _all_ rules, that are supposed
>to be governing subdivision.  On paper.  As a simple recipe of the "if
>this condition is met, do this, else if that condition is met, do that,
>else ... otherwise ..." kind.
>
>_Then_ you check the examples making problems.  On paper.  Does
>LilyPond
>follow the rules?  If so, the rules may need changing.  Where the rules
>cannot sensibly changed to accommodate conflicting but equally valid
>cases, we'll have to introduce manual intervention methods that are to
>be used for a well-defined and humanly recognizable subset of cases.
>
>If LilyPond does _not_ follow the rules on paper however, the
>implementation is broken.  How did it manage to escape scrutiny several
>times?  Perhaps a rewrite is required where the logic of the code can
>trace the human-accessible rules so closely that there is no doubt
>about
>the code matching the rules.
>
>Oh, and that paper with the rules?  Once the code follows it, the
>content of the paper belongs in code comments and possibly a manual.


Before testing further I assume the current issue is due to *not* using the 
latest state (which isn't in a release yet).

But of course I'll test with the material and with all iterations of the code 
once I have it.

Urs
-- 
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: Strange beaming error

[David Kastrup]

Urs Liska  writes:

> Do you also have subdivideBeams = ##t somewhere?
> If so please show the result with both 2.19.28 and .35..
>
> And if that's the case you should maybe send me (privately?) the full
> piece so I could test with several builds before and after several
> recent changes.

It's not the first time the subdivision fixes had to be overhauled.  And
if we keep up the way of dealing with them, I rather doubt it will be
the last time.

I suggest that you write down the rules, _all_ rules, that are supposed
to be governing subdivision.  On paper.  As a simple recipe of the "if
this condition is met, do this, else if that condition is met, do that,
else ... otherwise ..." kind.

_Then_ you check the examples making problems.  On paper.  Does LilyPond
follow the rules?  If so, the rules may need changing.  Where the rules
cannot sensibly changed to accommodate conflicting but equally valid
cases, we'll have to introduce manual intervention methods that are to
be used for a well-defined and humanly recognizable subset of cases.

If LilyPond does _not_ follow the rules on paper however, the
implementation is broken.  How did it manage to escape scrutiny several
times?  Perhaps a rewrite is required where the logic of the code can
trace the human-accessible rules so closely that there is no doubt about
the code matching the rules.

Oh, and that paper with the rules?  Once the code follows it, the
content of the paper belongs in code comments and possibly a manual.

-- 
David Kastrup

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

Re: Strange beaming error

[David Kastrup]

Chris Yate  writes:

> On 7 January 2016 at 00:49, Thomas Morley  wrote:
>
>> Btw, your images are inline _not_ attached.
>>
>
> Are inlined images not OK here? ...or were you just being pedantic?
> ;-)

They were inlined into the HTML part only rather than attached as a
separate MIME part with an inline disposition.

As a result, a number of readers will not be able to see them (for
example, I had to switch my default viewing modes around after being
made aware by Thomas that there was supposed to be an included graphic)
and the list archives are not likely to offer them either since they
tend to trash the HTML parts.

So your method of attachment is not likely to work well for a lot of
purposes (probably the only worse way would be to make it a background
image of the mail).  I would strongly suggest that you try to figure out
one that would be more likely to work with the bulk of readers.

-- 
David Kastrup

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

Re: Strange beaming error

[Urs Liska]

Do you also have subdivideBeams = ##t somewhere?
If so please show the result with both 2.19.28 and .35..

And if that's the case you should maybe send me (privately?) the full piece so 
I could test with several builds before and after several recent changes.

Urs 

Am 7. Januar 2016 01:16:43 MEZ, schrieb Chris Yate :
>Further problems. I commented out the Time settings and here's more,
>this
>time in the RH (note paired semiquavers in LH here, which would be in
>sixes).
>
>This is now built with revision 35 (the latest).
>[image: Inline images 1]
>
>On 6 January 2016 at 23:59, Chris Yate  wrote:
>
>>
>> On 6 January 2016 at 23:53, Chris Yate  wrote:
>>
>>> Hi,
>>>
>>> I'm wondering whether anyone can shed some light on the attached
>image.
>>>
>>> LH of the piano here is:
>>>
>>> {
>>>  bf,16 (ef g8) r8
>>>   c,16 g' c, g' bf, g'
>>>   \clef bass
>>> }
>>>
>>> I have a suspicion this may have something to do with the Timing /
>beat
>>> moment and beat structure, but it's inconclusive. This section of
>the music
>>> has:
>>>
>>>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>>>   \set Timing.beatStructure = #'( 6 6 )
>>>
>>> There are no barline errors, but I'm seeing this in the output quite
>a
>>> lot:
>>>
>>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>>
>>> continuing, cross fingers
>>>
>>> programming error: mis-predicted force, 108.120472 ~= 105.654382
>>>
>>> continuing, cross fingers
>>>
>>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>>
>>> continuing, cross fingers
>>>
>>>
>>>
>>> Previously I was getting a similar issue where I had bars of 6
>quavers,
>>> which were grouped in 3's -- and the middle of the second group was
>getting
>>> a spurious semiquaver beam. I seem to fixed it, though I'm not sure
>what
>>> the cause was.
>>>
>>> Thanks in advance,
>>>
>>> Chris
>>>
>>
>> P.S. Using Lilypond 2.19.28.
>>
>>
>>
>>>
>>> [image: Inline images 1]
>>>
>>
>>
>
>
>
>
>___
>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: Strange beaming error

[Mark Stephen Mrotek]

Chris:

 

What is the time signature? 6/8?

Or is it 2/4 grouped as if in tuplets?

 

Mark

 

From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org 
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of Chris 
Yate
Sent: Wednesday, January 06, 2016 5:21 PM
To: Thomas Morley 
Cc: Lilypond-User Mailing List 
Subject: Re: Strange beaming error

 

 

On 7 January 2016 at 00:49, Thomas Morley mailto:thomasmorle...@gmail.com> > wrote:

 

2016-01-07 0:53 GMT+01:00 Chris Yate mailto:chrisy...@gmail.com> >:

Hi, 

 

I'm wondering whether anyone can shed some light on the attached image.

LH of the piano here is:

 

{

 bf,16 (ef g8) r8

  c,16 g' c, g' bf, g'

  \clef bass

}

 

I have a suspicion this may have something to do with the Timing / beat moment 
and beat structure, but it's inconclusive. This section of the music has:

 

  \set Timing.baseMoment = #(ly:make-moment 1/16)

  \set Timing.beatStructure = #'( 6 6 )

 

There are no barline errors, but I'm seeing this in the output quite a lot: 

programming error: mis-predicted force, 108.120472 ~= 101.465263

continuing, cross fingers

programming error: mis-predicted force, 108.120472 ~= 105.654382

continuing, cross fingers

programming error: mis-predicted force, 108.120472 ~= 101.465263

continuing, cross fingers

 

 

Previously I was getting a similar issue where I had bars of 6 quavers, which 
were grouped in 3's -- and the middle of the second group was getting a 
spurious semiquaver beam. I seem to fixed it, though I'm not sure what the 
cause was.

 

Thanks in advance,

 

Chris

 

 

 Hi Thomas, 

 

Without tiny example everyone can guess only.

 

Yes, I appreciate that -- I wasn't  able to get a minimal working example. I 
was hoping for any general suggestions to fix or known bugs that might cause 
this.

 

It's ~200 bars of music, over 5 files, so if necessary I'll put it up on a 
Gist. 

 

Btw, your images are inline _not_ attached.

 

Are inlined images not OK here? ...or were you just being pedantic? ;-)

 

Chris

 

 

 

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

Re: Strange beaming error

[Chris Yate]

On 7 January 2016 at 00:49, Thomas Morley  wrote:

>
> 2016-01-07 0:53 GMT+01:00 Chris Yate :
>
>> Hi,
>>
>> I'm wondering whether anyone can shed some light on the attached image.
>>
>> LH of the piano here is:
>>
>> {
>>  bf,16 (ef g8) r8
>>   c,16 g' c, g' bf, g'
>>   \clef bass
>> }
>>
>> I have a suspicion this may have something to do with the Timing / beat
>> moment and beat structure, but it's inconclusive. This section of the music
>> has:
>>
>>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>>   \set Timing.beatStructure = #'( 6 6 )
>>
>> There are no barline errors, but I'm seeing this in the output quite a
>> lot:
>>
>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>
>> continuing, cross fingers
>>
>> programming error: mis-predicted force, 108.120472 ~= 105.654382
>>
>> continuing, cross fingers
>>
>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>
>> continuing, cross fingers
>>
>>
>>
>> Previously I was getting a similar issue where I had bars of 6 quavers,
>> which were grouped in 3's -- and the middle of the second group was getting
>> a spurious semiquaver beam. I seem to fixed it, though I'm not sure what
>> the cause was.
>>
>> Thanks in advance,
>>
>> Chris
>>
>>
 Hi Thomas,


> Without tiny example everyone can guess only.
>

Yes, I appreciate that -- I wasn't  able to get a minimal working example.
I was hoping for any general suggestions to fix or known bugs that might
cause this.

It's ~200 bars of music, over 5 files, so if necessary I'll put it up on a
Gist.

Btw, your images are inline _not_ attached.
>

Are inlined images not OK here? ...or were you just being pedantic? ;-)

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

Re: Strange beaming error

[Thomas Morley]

2016-01-07 0:53 GMT+01:00 Chris Yate :

> Hi,
>
> I'm wondering whether anyone can shed some light on the attached image.
>
> LH of the piano here is:
>
> {
>  bf,16 (ef g8) r8
>   c,16 g' c, g' bf, g'
>   \clef bass
> }
>
> I have a suspicion this may have something to do with the Timing / beat
> moment and beat structure, but it's inconclusive. This section of the music
> has:
>
>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>   \set Timing.beatStructure = #'( 6 6 )
>
> There are no barline errors, but I'm seeing this in the output quite a
> lot:
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 105.654382
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
>
>
> Previously I was getting a similar issue where I had bars of 6 quavers,
> which were grouped in 3's -- and the middle of the second group was getting
> a spurious semiquaver beam. I seem to fixed it, though I'm not sure what
> the cause was.
>
> Thanks in advance,
>
> Chris
>
> [image: Inline images 1]
>

Without tiny example everyone can guess only.
Btw, your images are inline _not_ attached.

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

RE: Strange beaming error

[Mark Stephen Mrotek]

Chris:

 

My experience in setting piano music is that the “\set Timing” instruction must 
be in both voices. If you have not done so, that might be the cause.

 

Mark

 

From: lilypond-user-bounces+carsonmark=ca.rr@gnu.org 
[mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of Chris 
Yate
Sent: Wednesday, January 06, 2016 4:17 PM
To: Lilypond-User Mailing List 
Subject: Re: Strange beaming error

 

Further problems. I commented out the Time settings and here's more, this time 
in the RH (note paired semiquavers in LH here, which would be in sixes).

This is now built with revision 35 (the latest).



 

On 6 January 2016 at 23:59, Chris Yate mailto:chrisy...@gmail.com> > wrote:

 

On 6 January 2016 at 23:53, Chris Yate mailto:chrisy...@gmail.com> > wrote:

Hi, 

 

I'm wondering whether anyone can shed some light on the attached image.

LH of the piano here is:

 

{

 bf,16 (ef g8) r8

  c,16 g' c, g' bf, g'

  \clef bass

}

 

I have a suspicion this may have something to do with the Timing / beat moment 
and beat structure, but it's inconclusive. This section of the music has:

 

  \set Timing.baseMoment = #(ly:make-moment 1/16)

  \set Timing.beatStructure = #'( 6 6 )

 

There are no barline errors, but I'm seeing this in the output quite a lot: 

programming error: mis-predicted force, 108.120472 ~= 101.465263

continuing, cross fingers

programming error: mis-predicted force, 108.120472 ~= 105.654382

continuing, cross fingers

programming error: mis-predicted force, 108.120472 ~= 101.465263

continuing, cross fingers

 

 

Previously I was getting a similar issue where I had bars of 6 quavers, which 
were grouped in 3's -- and the middle of the second group was getting a 
spurious semiquaver beam. I seem to fixed it, though I'm not sure what the 
cause was.

 

Thanks in advance,

 

Chris

 

P.S. Using Lilypond 2.19.28.

 

 



 

 

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

Re: Strange beaming error

[Chris Yate]

Further problems. I commented out the Time settings and here's more, this
time in the RH (note paired semiquavers in LH here, which would be in
sixes).

This is now built with revision 35 (the latest).
[image: Inline images 1]

On 6 January 2016 at 23:59, Chris Yate  wrote:

>
> On 6 January 2016 at 23:53, Chris Yate  wrote:
>
>> Hi,
>>
>> I'm wondering whether anyone can shed some light on the attached image.
>>
>> LH of the piano here is:
>>
>> {
>>  bf,16 (ef g8) r8
>>   c,16 g' c, g' bf, g'
>>   \clef bass
>> }
>>
>> I have a suspicion this may have something to do with the Timing / beat
>> moment and beat structure, but it's inconclusive. This section of the music
>> has:
>>
>>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>>   \set Timing.beatStructure = #'( 6 6 )
>>
>> There are no barline errors, but I'm seeing this in the output quite a
>> lot:
>>
>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>
>> continuing, cross fingers
>>
>> programming error: mis-predicted force, 108.120472 ~= 105.654382
>>
>> continuing, cross fingers
>>
>> programming error: mis-predicted force, 108.120472 ~= 101.465263
>>
>> continuing, cross fingers
>>
>>
>>
>> Previously I was getting a similar issue where I had bars of 6 quavers,
>> which were grouped in 3's -- and the middle of the second group was getting
>> a spurious semiquaver beam. I seem to fixed it, though I'm not sure what
>> the cause was.
>>
>> Thanks in advance,
>>
>> Chris
>>
>
> P.S. Using Lilypond 2.19.28.
>
>
>
>>
>> [image: Inline images 1]
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange beaming error

[Chris Yate]

On 6 January 2016 at 23:53, Chris Yate  wrote:

> Hi,
>
> I'm wondering whether anyone can shed some light on the attached image.
>
> LH of the piano here is:
>
> {
>  bf,16 (ef g8) r8
>   c,16 g' c, g' bf, g'
>   \clef bass
> }
>
> I have a suspicion this may have something to do with the Timing / beat
> moment and beat structure, but it's inconclusive. This section of the music
> has:
>
>   \set Timing.baseMoment = #(ly:make-moment 1/16)
>   \set Timing.beatStructure = #'( 6 6 )
>
> There are no barline errors, but I'm seeing this in the output quite a
> lot:
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 105.654382
>
> continuing, cross fingers
>
> programming error: mis-predicted force, 108.120472 ~= 101.465263
>
> continuing, cross fingers
>
>
>
> Previously I was getting a similar issue where I had bars of 6 quavers,
> which were grouped in 3's -- and the middle of the second group was getting
> a spurious semiquaver beam. I seem to fixed it, though I'm not sure what
> the cause was.
>
> Thanks in advance,
>
> Chris
>

P.S. Using Lilypond 2.19.28.



>
> [image: Inline images 1]
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user