Re: Augmentation dot positioning

[Werner LEMBERG]

> Fortunately, it was much easier than I feared it might be.
> 
> Here's a revised version.

Now all examples look fine.  Halleluja :-)


Werner

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 10/27/16 1:49 PM, "Carl Sorensen"  wrote:
>>
>>Mhmm, 22b, and 24b are not correct IMHO: The lowest dot should be
>>above the ledger line, not below.  Or am I missing something?
>
>Oh, yes.  I missed those being low on my low-resolution monitor.
>
>Back to the drawing board on that part of the algorithmŠ


Fortunately, it was much easier than I feared it might be.

Here's a revised version.

Thanks,

Carl



dots[3].pdf
Description: dots[3].pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 10/27/16 1:21 PM, "werner.lemb...@gmx.de on behalf of Werner LEMBERG"
 wrote:

>
>> Anyway, I've run through all the tests, and I think that the default
>> algorithm works exactly according to the Powell algorithm, as I
>> understand it.
>
>Mhmm, 22b, and 24b are not correct IMHO: The lowest dot should be
>above the ledger line, not below.  Or am I missing something?

Oh, yes.  I missed those being low on my low-resolution monitor.

Back to the drawing board on that part of the algorithmŠ

Thanks,

Carl


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

Re: Augmentation dot positioning

[Werner LEMBERG]

[Note that currently the descriptions are sometimes incorrect in the
 tests.]

> Anyway, I've run through all the tests, and I think that the default
> algorithm works exactly according to the Powell algorithm, as I
> understand it.

Mhmm, 22b, and 24b are not correct IMHO: The lowest dot should be
above the ledger line, not below.  Or am I missing something?

> Please let me know if you find anything that is different from what
> you would like to see, even if it's minor.

Everything else looks fine, thanks!


Werner

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

Re: Augmentation dot positioning

[tisimst]

On Thursday, October 27, 2016, Carl Sorensen-3 [via Lilypond] <
ml-node+s1069038n195779...@n5.nabble.com> wrote:

> OK, I got my preferred algorithm working right as the default positioning
> algorithm now.
>
> The algorithm puts dots for notes in spaces in the same space, and then
> tries to put dots for notes on lines in adjacent spaces, working its way
> out until it finds a space or exceeds chords-dot-limit staff positions.
>
> As expected, with this algorithm there is no difference between
> chord-dots-limit = 1 and chord-dots-limit = 2, because dots for notes on
> spaces never move, and they are the only dots that can have an offset of
> 2.
>
> Anyway, I've run through all the tests, and I think that the default
> algorithm works exactly according to the Powell algorithm, as I understand
> it.
>
> All of the test cases with chord-dots-limit 1 or 2 provide the desired
> output, as far as I can see.
>

Thanks for doing this, Carl! This is great!

I assume it works the same in a polyphonic setting, but I wonder if it
would be helpful to add some of those into the suite of test cases, just to
double-check.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Augmentation-dot-positioning-tp194462p195781.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

OK, I got my preferred algorithm working right as the default positioning
algorithm now.

The algorithm puts dots for notes in spaces in the same space, and then
tries to put dots for notes on lines in adjacent spaces, working its way
out until it finds a space or exceeds chords-dot-limit staff positions.

As expected, with this algorithm there is no difference between
chord-dots-limit = 1 and chord-dots-limit = 2, because dots for notes on
spaces never move, and they are the only dots that can have an offset of 2.

Anyway, I've run through all the tests, and I think that the default
algorithm works exactly according to the Powell algorithm, as I understand
it.

All of the test cases with chord-dots-limit 1 or 2 provide the desired
output, as far as I can see.

Please let me know if you find anything that is different from what you
would like to see, even if it's minor.

Thanks,

Carl



dots[2].pdf
Description: dots[2].pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 10/26/16 3:28 AM, "David Kastrup"  wrote:

>
>Su why is a symbol needed?  Symbols always require some secret lookup
>mechanism.  Why not just use a list here?  When the list needs to be
>calculated, it can be a callback, right?

That was my hope, but I couldn't make it work.

The reason I couldn't make it work is because the dot calculation (as
presently implemented) requires the properties of multiple grobs.  So I
couldn't do a callback on a single grob to make it work.  Instead, I
needed two arguments to my function.  Hence, the use of a symbol, which
is, I admit, a bit of a hack.

I haven't yet got the code in final form for doing a full code review, but
here is a patch from origin/master.

If you could give me some ideas about how this could be refactored or done
better, I'd be really grateful.  I'm not really happy with the way the
scheme functions get called, but I could't figure a better way to do it.

Thanks,

Carl




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

Re: Augmentation dot positioning

[David Kastrup]

Carl Sorensen  writes:

> On 10/25/16 8:57 AM, "Chris Yate"  wrote:
>
>>Hi Carl,
>>Firstly, thanks for your work on this!
>>At a quick glance, the only two situations that need dots-limit =2 are
>>#11 and #23.
>
> Yes, those were my two cases as well.
>
>>A side issue:
>>An idea I've just had: would it be useful to have a more flexible
>>positioning system similar to that for rests? (e.g. "f4/rest"). It might
>>be useful to have the option of custom dot placement for special cases.
>>I'm sure there's already a way to achieve this, but it's probably not
>>easy. If anyone thinks it worthwhile, I will think more about a suggested
>>syntax... Maybe something for the LSR rather than core functionality.
>
> As far as I can see in the existing code (not including my changes) there
> is no way to do this.
>
> But, this could be easily added onto my current architecture. I had
> actually planned for it earlier, but my planned architecture didn't work
> out.  Butn now I can add it back in.
>
> The grob property that defines which algorithm is to be used to determine
> dot locations is currently a symbol.  I can change it to symbol or list,
> and if it's a list, it's just a list of staff positions that should have
> dots.  The Scheme code returns such a list, and it would be easy to check
> in the C++ code for it being a list, and then do the right thing with the
> list.

Su why is a symbol needed?  Symbols always require some secret lookup
mechanism.  Why not just use a list here?  When the list needs to be
calculated, it can be a callback, right?

-- 
David Kastrup

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 10/25/16 8:57 AM, "Chris Yate"  wrote:

>Hi Carl,
>Firstly, thanks for your work on this!
>At a quick glance, the only two situations that need dots-limit =2 are
>#11 and #23.

Yes, those were my two cases as well.

>A side issue:
>An idea I've just had: would it be useful to have a more flexible
>positioning system similar to that for rests? (e.g. "f4/rest"). It might
>be useful to have the option of custom dot placement for special cases.
>I'm sure there's already a way to achieve this, but it's probably not
>easy. If anyone thinks it worthwhile, I will think more about a suggested
>syntax... Maybe something for the LSR rather than core functionality.

As far as I can see in the existing code (not including my changes) there
is no way to do this.

But, this could be easily added onto my current architecture. I had
actually planned for it earlier, but my planned architecture didn't work
out.  Butn now I can add it back in.

The grob property that defines which algorithm is to be used to determine
dot locations is currently a symbol.  I can change it to symbol or list,
and if it's a list, it's just a list of staff positions that should have
dots.  The Scheme code returns such a list, and it would be easy to check
in the C++ code for it being a list, and then do the right thing with the
list.

I don't think there's any new syntax needed.

Thanks for the good input!

Carl






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

Re: Augmentation dot positioning

[Werner LEMBERG]

Thanks, Carl!


> At a quick glance, the only two situations that need dots-limit =2
> are #11 and #23.

Seconded.  I also think that #13 also looks better with value 2 – the
nearer the number of dots to the number of noteheads, the better.

What about #24/2?  Why is the lowest dot below the a's ledger line and
not above?


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

Re: Augmentation dot positioning

[Chris Yate]

On 25 Oct 2016 3:36 p.m., "Carl Sorensen"  wrote:
>
>
>
>
> At any rate, I have some results from Chris's test file.  I have adjusted
> the text to contain my assessment of the results.  Please let me know if
> you disagree with any of my assessments.
>
> chord-dots-limit = 1 is better in most circumstances.  It is also
> consistent with Powell.
>
> chord-dots-limit = 2 is better in a few circumstances.
>
> Feedback would be appreciated.
>
> Thanks,
>
> Carl
>

Hi Carl,

Firstly, thanks for your work on this!

At a quick glance, the only two situations that need dots-limit =2 are #11
and #23.

I think both of these point to an inconsistency/bug in the algorithm -

I think #11 should have the B space dot (I'm guessing this is a case of the
algorithm not allowing a downward dot movement from the C).

#23 definitely should have the B dot, since it's a space-note.

It's looking pretty close to optimal though.

A side issue:
An idea I've just had: would it be useful to have a more flexible
positioning system similar to that for rests? (e.g. "f4/rest"). It might be
useful to have the option of custom dot placement for special cases.

I'm sure there's already a way to achieve this, but it's probably not easy.
If anyone thinks it worthwhile, I will think more about a suggested
syntax... Maybe something for the LSR rather than core functionality.

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/19/16 7:50 AM, "Carl Sorensen"  wrote:
>
>I agree with all of these points, and am working on an improved algorithm.
>
>Once I get the algorithm solidified, I know how to implement it.
>
>But I haven't got the algorithm solidified yet.
>
>Thanks,
>
>Carl


OK, I have now made a change (not yet submitted for review) to move the
dot-positioning algorithms into Scheme.

And I have implemented a new default algorithm, which tries to do what
Chris and Werner liked, rather than strictly implementing the Gould
algorithm.

I am also working on a Gould algorithm that is user-selectable.

At any rate, I have some results from Chris's test file.  I have adjusted
the text to contain my assessment of the results.  Please let me know if
you disagree with any of my assessments.

chord-dots-limit = 1 is better in most circumstances.  It is also
consistent with Powell.

chord-dots-limit = 2 is better in a few circumstances.

Feedback would be appreciated.

Thanks,

Carl



dots[1].pdf
Description: dots[1].pdf
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/19/16 2:53 AM, "Chris Yate"  wrote:

>Looking at the results, I suspect the positioning algorithm should try to
>place dots on the space-notes first, then work the line-notes around them.
>
>
>Additionally, chord-dots-limit might be used to limit how far away the
>dots can be 'shifted' during the calculation process, rather than pruning
>the excess dots after the fact.
>
>
>I'm not sure how best to change the rather complicated calc_positioning
>function to achieve that (and more importantly have to go to work now!)
>:-) 
>


I agree with all of these points, and am working on an improved algorithm.

Once I get the algorithm solidified, I know how to implement it.

But I haven't got the algorithm solidified yet.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Chris Yate]

On Mon, 19 Sep 2016 at 09:38 Chris Yate  wrote:

> On 9/18/16 4:00 PM, "Carl Sorensen"  wrote:
>>> >Chris,
>>> >
>>> >Here's a patch.  But as Werner pointed out, it's not quite done yet.  I
>>> >think I need to improve the badness scoring in order to get better
>>> >configurations from which to remove excess dots.
>>
>>
Carl,

I'm beginning to understand the code, mainly thanks to reading your
changes.

The problems with example #23 seem to be due to the dots being pushed
further and further away from their noteheads.

Looking at the results, I suspect the positioning algorithm should try to
place dots on the space-notes first, then work the line-notes around them.

Additionally, chord-dots-limit might be used to limit how far away the dots
can be 'shifted' during the calculation process, rather than pruning the
excess dots after the fact.

I'm not sure how best to change the rather complicated calc_positioning
function to achieve that (and more importantly have to go to work now!) :-)

cheers,

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

Re: Augmentation dot positioning

[Chris Yate]

On Mon, 19 Sep 2016 at 02:31 Carl Sorensen  wrote:

> On 9/18/16 4:00 PM, "Carl Sorensen"  wrote:
> >Chris,
> >
> >Here's a patch.  But as Werner pointed out, it's not quite done yet.  I
> >think I need to improve the badness scoring in order to get better
> >configurations from which to remove excess dots.
>
> There are two comments in the code that are wrong.
>

That's why I try to avoid writing _any_ comments in my coding ;)

As for the results, it seems there's some strange results with
chord-dots-limit = 0. #3 and #4 for example -- it seems it's ignoring notes
on a line.

Whilst I understand the zero in your new logic would strictly mean removing
those, I think the "dot distance" for a note on a line should be counted
from the adjacent space. Either that, or throw an exception on setting the
value to zero...?

There's another strange situation for dots-limit 0 in #9, where the D
inexplicably has no dot.

thanks!

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/18/16 4:00 PM, "Carl Sorensen"  wrote:
>Chris,
>
>Here's a patch.  But as Werner pointed out, it's not quite done yet.  I
>think I need to improve the badness scoring in order to get better
>configurations from which to remove excess dots.

There are two comments in the code that are wrong.

In a Dot_configuration, the index to the map is the staff position of the
dot.
The pos_ element of the Dot_position is the staff position of the notehead.

The comments reverse those two.

Sorry for the mistake,

Carl


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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/18/16 10:37 AM, "werner.lemb...@gmx.de on behalf of Werner LEMBERG"
 wrote:

>
>This looks very good, but there are two glitches, namely 13b and 23b,
>which can't be right.  23c looks wrong, too.

Clearly 23 is wrong.  I need to investigate further.  I'll submit my work
again when I have it fixed.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/18/16 11:09 AM, "Chris Yate"  wrote:
>Hi Carl, thanks! I'll take a look later today. Would you be happy to send
>me a patch for the current source code HEAD?  (Or just the modified file).
>I was looking at the current code on Friday to try and understand it, so
>it would be good to see what you've changed. Also to have a local build
>with the fix in!!


Chris,

Here's a patch.  But as Werner pointed out, it's not quite done yet.  I
think I need to improve the badness scoring in order to get better
configurations from which to remove excess dots.

The maze of data structures involved in the process made it challenging
for me to figure out what to do, but once I had the data structure down,
the fix was relatively straightforward.

Anyway, you're welcome to experiment with different approaches and/or
changes.  I'd love to see how you might do it differently.

Thanks,

Carl



0001-Change-the-algorithm-for-placing-dots-next-to-chords.patch
Description: 0001-Change-the-algorithm-for-placing-dots-next-to-chords.patch
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Chris Yate]

On 18 Sep 2016 17:37, "Werner LEMBERG" <w...@gnu.org> wrote:
>
>
> > OK, I have rewritten the code for augmentation dot positioning.
>
> Great, and thanks a lot!
>
> > Personally, I like the results of this code better than the Gould
> > recommendations.  I would use this code, and make the default value
> > of chord-dots-limit be 1.
>
> I agree.
>
> > I'm attaching a copy of Dots.pdf created with the new code.  I have
> > not updated any of the markups describing the results, because this
> > allows you to better see the differences, I think.
>
> This looks very good, but there are two glitches, namely 13b and 23b,
> which can't be right.  23c looks wrong, too.
>
>
> Werner

Hi Carl, thanks! I'll take a look later today. Would you be happy to send
me a patch for the current source code HEAD?  (Or just the modified file).

I was looking at the current code on Friday to try and understand it, so it
would be good to see what you've changed. Also to have a local build with
the fix in!!

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

Re: Augmentation dot positioning

[Werner LEMBERG]

> OK, I have rewritten the code for augmentation dot positioning.

Great, and thanks a lot!

> Personally, I like the results of this code better than the Gould
> recommendations.  I would use this code, and make the default value
> of chord-dots-limit be 1.

I agree.

> I'm attaching a copy of Dots.pdf created with the new code.  I have
> not updated any of the markups describing the results, because this
> allows you to better see the differences, I think.

This looks very good, but there are two glitches, namely 13b and 23b,
which can't be right.  23c looks wrong, too.


Werner

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 5:17 PM, "Chris Yate"  wrote:

>Oh yeah, these examples are a case in point! The first seems to suggest
>dots should stay within the area of the chord, while the second suggests
>it's ok to have dots extending the chord as long as they're balanced
>vertically.

The first follows her rule that says "If a dot is 2 spaces or more away
from the limit of the chord, trim all the dots to the space occupied by
the chord."

The second has no dot two spaces or more away, so the dots stay, even
though they extend beyond the chord.  Both are exactly consistent with her
words, as I read them.  There is no inconsistency between her examples and
her rules that I can see.

I'm now home and have checked my other references.  Read does not address
cases that would move dots beyond the span of the chord. Neither does Ross.

Powell (Music Engraving Today) is consistent with your examples.  The rule
he gives is "If there are too many notes for the number of spaces, leave
off a dot.  Never put a dot a third away from a note, and never try to put
two dots in one space."

In another place he says "Never put the dot more than a second away from
any note."

Thus, I think your preferences follow Powell's rules.  Now if I can just
figure out how to implement them (but I have some ideasŠ).

Thanks,

Carl


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

Re: Augmentation dot positioning

[Chris Yate]

Oh yeah, these examples are a case in point! The first seems to suggest
dots should stay within the area of the chord, while the second suggests
it's ok to have dots extending the chord as long as they're balanced
vertically.

Fundamentally the only difference between these situations is the size of
the chord. I'm not yet convinced that Gould has a hard and fast rule.

It's probably irrelevant, but a very small sample of my musician friends
suggests that dots shouldn't be placed further away than the next space
above/below the top/bottom of the chord. When I posted a picture of the
five-note tone cluster with five dots, the overall reaction was "WTF?!
Yuck!". IMO that should tell us all we need to know...

But for the scope of this software, being able to easily get the result
*you* want is the important thing.

On 15 Sep 2016 23:43, "Carl Sorensen"  wrote:

>
>
> On 9/15/16 4:15 PM, "Chris Yate"  wrote:
>
> >
> >Please note I'm working without her examples,  but I disagree about
> >[Lilypond's interpretation of] Gould's rules, because they appear to be
> >in contradiction with **every piece of published music I've ever seen**.
> >Given just her text, I think she has possibly not worded things as
> >clearly as possible. And if it is correct to have five dots on a chord
> >spanning a ninth == five spaces, then why is it incorrect to have three
> >dots for a chord spanning three spaces?
> >The place that her rules stop making sense is this inconsistency:
> >1. It's ok to have a dot a full two staff positions away from the top or
> >bottom of the chord.
> >2. BUT... if there's a dot that according to the rules turns up to be two
> >spaces away, don't place ANY notes outside the range of spaces occupied
> >by the chord *.
> >* spaces occupied by the chord includes the half space occupied by part
> >of a notehead on a line.
>
> But this "inconsistency" that you find, is exactly illustrated in her
> examples.  She shows *precisely* the behavior you find inconsistent as the
> recommended behavior. See Gould2.png.  Gould is silent on whether the
> spaces occupied by the chord includes the half-space or not, and none of
> her examples include a note that would use the half-space.  So I don't
> disagree with you.
>
> >I think what she actually meant, and basing this also on guides like the
> >ABRSM theory books, is
> >
> >- every note needs a dot, where possible
> >- notes on a line need their dot moving up or down to the nearest space
> >- sometimes the dot needs to shift away from its parent, and that's ok
> >within the compass of the chord
>
> In your example 14, with a dots limit of 3, the dot from the E moves to
> the F space, and the dot from the F moves to the A space (within the
> compass of the chord), and you consider the dot on the A space to be
> unnecessary.  So my interpretation of your personal preference is that
> you'd prefer to never have a dot moved more than one staff position away
> from its "home".
>
> Gould would put the dot in the A space, according to the written rules.
> You accept it, but believe it's unnecessary.  If it's unnecessary, I think
> we should leave it out, because it's just clutter.  I'm reading that if
> you had your preferred style, it would be left out.  And I think LilyPond
> should have some way to support your preferred style.
>
> >- dots two or more staff _positions_ (not staff _spaces_ as written) away
> >from the top or bottom of the chord look strange, so exclude those.
>
> Gould specifically shows dot patterns with dots two staff positions away
> from a note in a space.  I included them previously, and include them
> again here as gould1.png.
>
> Note that in gould2.png, the dots that would be only two staff positions
> (one space) away from the top and bottom of the chord *are* excluded, not
> just the one that is four positions (two spaces) away.
>
> I'm going to send you (by separate email) a scan of Gould's section on
> dotted notes.  I'd be happy to have you show me how I've misunderstood her
> rules (if in fact I have).  But I'm quite sure that I have them right
> (with the possible exception of the spaces occupied by the chord including
> the half-spaces of notes on the line).
>
> >
> >Pragmatically though, I strongly believe it's a mistake for Lilypond's
> >defaults to go against the grain of what most readers of music expect and
> >have learnt to expect, even if the holy grail appears to say it's "right".
>
> Counterexamples from high-quality hand-engraved music are certainly
> welcome.   Contrary rules from other notation experts (e.g. Ross, Read,
> Stone) are also welcome.  I agree that we should do what's right.
> Sometimes the challenge is deciding what's right.
>
> I will check Read and Ross tonight.  I don't remember if I still have
> Stone or not.  If I do, I'll check it as well.
>
> Thanks,
>
> Carl
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 4:15 PM, "Chris Yate"  wrote:

>
>Please note I'm working without her examples,  but I disagree about
>[Lilypond's interpretation of] Gould's rules, because they appear to be
>in contradiction with **every piece of published music I've ever seen**.
>Given just her text, I think she has possibly not worded things as
>clearly as possible. And if it is correct to have five dots on a chord
>spanning a ninth == five spaces, then why is it incorrect to have three
>dots for a chord spanning three spaces?
>The place that her rules stop making sense is this inconsistency:
>1. It's ok to have a dot a full two staff positions away from the top or
>bottom of the chord.
>2. BUT... if there's a dot that according to the rules turns up to be two
>spaces away, don't place ANY notes outside the range of spaces occupied
>by the chord *.
>* spaces occupied by the chord includes the half space occupied by part
>of a notehead on a line.

But this "inconsistency" that you find, is exactly illustrated in her
examples.  She shows *precisely* the behavior you find inconsistent as the
recommended behavior. See Gould2.png.  Gould is silent on whether the
spaces occupied by the chord includes the half-space or not, and none of
her examples include a note that would use the half-space.  So I don't
disagree with you.

>I think what she actually meant, and basing this also on guides like the
>ABRSM theory books, is
>
>- every note needs a dot, where possible
>- notes on a line need their dot moving up or down to the nearest space
>- sometimes the dot needs to shift away from its parent, and that's ok
>within the compass of the chord

In your example 14, with a dots limit of 3, the dot from the E moves to
the F space, and the dot from the F moves to the A space (within the
compass of the chord), and you consider the dot on the A space to be
unnecessary.  So my interpretation of your personal preference is that
you'd prefer to never have a dot moved more than one staff position away
from its "home".

Gould would put the dot in the A space, according to the written rules.
You accept it, but believe it's unnecessary.  If it's unnecessary, I think
we should leave it out, because it's just clutter.  I'm reading that if
you had your preferred style, it would be left out.  And I think LilyPond
should have some way to support your preferred style.

>- dots two or more staff _positions_ (not staff _spaces_ as written) away
>from the top or bottom of the chord look strange, so exclude those.

Gould specifically shows dot patterns with dots two staff positions away
from a note in a space.  I included them previously, and include them
again here as gould1.png.

Note that in gould2.png, the dots that would be only two staff positions
(one space) away from the top and bottom of the chord *are* excluded, not
just the one that is four positions (two spaces) away.

I'm going to send you (by separate email) a scan of Gould's section on
dotted notes.  I'd be happy to have you show me how I've misunderstood her
rules (if in fact I have).  But I'm quite sure that I have them right
(with the possible exception of the spaces occupied by the chord including
the half-spaces of notes on the line).

>
>Pragmatically though, I strongly believe it's a mistake for Lilypond's
>defaults to go against the grain of what most readers of music expect and
>have learnt to expect, even if the holy grail appears to say it's "right".

Counterexamples from high-quality hand-engraved music are certainly
welcome.   Contrary rules from other notation experts (e.g. Ross, Read,
Stone) are also welcome.  I agree that we should do what's right.
Sometimes the challenge is deciding what's right.

I will check Read and Ross tonight.  I don't remember if I still have
Stone or not.  If I do, I'll check it as well.

Thanks,

Carl

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

Re: Augmentation dot positioning

[Paul]

On 09/15/2016 12:41 PM, Chris Yate wrote:

I think the trouble with Gould's rules is that they're inconsistent, 
or could at least be interpreted in such a way.  She says to use dots 
only on the spaces occupied by the chord, and yet says you MAY need to 
put a dot a space or more away from the chord.


On 09/15/2016 09:36 AM, Chris Yate wrote:

the key is the last bit of Gould's text as quoted by Brian above:

"When a dot is forced to be two or more stave-spaces from the chord, 
its function becomes less relevant. In such cases,//use only as many 
dots as cover the number of stave-spaces taken up by the chord."




Hi Chris,  As I read this quote, Gould's recommendation to "use only as 
many dots as cover the number of stave-spaces taken up by the chord" 
only applies "when a dot is forced to be two or more stave-spaces from 
the chord" because she limits her recommendation to "in such cases".


Maybe such a strict reading resolves what you are seeing as an 
inconsistency, at least as far as the logic of this quote goes.


(All of that said, I don't know why her recommendation for such cases is 
not just to "omit any dots that would be two or more stave-spaces from 
the chord" instead... but I claim no expertise here.)


Anyway, I agree that providing a way to adjust the output as desired 
would be great, and it seems like Carl is on top of it.


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

Re: Augmentation dot positioning

[Chris Yate]

On 15 Sep 2016 22:45, "Carl Sorensen"  wrote:
>
>
> On 9/15/16 10:41 AM, "Chris Yate"  wrote:>
> >
> >I think the trouble with Gould's rules is that they're inconsistent, or
> >could at least be interpreted in such a way.  She says to use dots only
> >on the spaces occupied by the chord, and yet says you MAY need to put a
> >dot a space or more away from the chord.
>
> No, let me summarize Gould's rules.
>
> Rule 1: Every notehead in a chord must take a duration dot.
>
> Rule 2: Move dots away from a note head on a line by moving it either up
> or down (she has some guidelines for how to do this, but I'm skipping them
> right now)
>
> Rule 3: Every dot needs to have a staff space to itself.  This implies
> (although it's not explicitly stated, but it is shown) that you may need
> to move dots farther than one staff space away from the note head.
>
> Rule 4: Center the dots on the chord.  This fixes problems that may show
> up by applying rule 3.
>
> Rule 5: If one of the remaining dots is two or more staff spaces from the
> chord, the dot pattern is bad, so instead of having one dot per note head,
> just have one dot per staff space included in the chord.
>
> Every example she shows is consistent with these rules.  The examples you
> show from Sibelius are not consistent with these rules.  That doesn't make
> them wrong, just inconsistent with Gould.
>
>
> >
> >
> >
> >At the very least, we should be able to decide in our own scores what
> >logic is used for dot placement :-)
>
> Yes.  Perhaps we could make a scheme callback for cleaning up dots.  And
> that could become a property of a DotColumn, and the user would be free to
> implement their own Scheme function for cleaning up the dots.
>
> >
> >
> >Are you editing the code in dot-column.cc. or is there some Scheme code
> >for this too?
>
> Just editing code in dot-column.cc.  No Scheme code anywhere that I can
> see.
>
> So what rules do you use to decide when a dot is necessary below the
> bottom note of a chord, above the top of a chord, or in the middle of a
> chord with an interval larger than a third?
>
> Looking at your statements in Dots.ly, I would infer the following rules:
>
>
> 1. Put dots next to note heads on staff spaces.
> 2. Put dots in the space above note heads on staff lines.  If the space is
> already taken, and the space below the note head is available, place the
> dot in the space below the note head.  If the space is already taken, and
> the space below the note head is taken as well, omit the dot.
>
>
> I think those two rules provide the dots that you have considered to be
> necessary in Dots.ly, without any of the dots you consider unnecessary.

Please note I'm working without her examples,  but I disagree about
[Lilypond's interpretation of] Gould's rules, because they appear to be in
contradiction with **every piece of published music I've ever seen**.

Given just her text, I think she has possibly not worded things as clearly
as possible. And if it is correct to have five dots on a chord spanning a
ninth == five spaces, then why is it incorrect to have three dots for a
chord spanning three spaces?

The place that her rules stop making sense is this inconsistency:

1. It's ok to have a dot a full two staff positions away from the top or
bottom of the chord.

2. BUT... if there's a dot that according to the rules turns up to be two
spaces away, don't place ANY notes outside the range of spaces occupied by
the chord *.

* spaces occupied by the chord includes the half space occupied by part of
a notehead on a line.

I think what she actually meant, and basing this also on guides like the
ABRSM theory books, is

- every note needs a dot, where possible
- notes on a line need their dot moving up or down to the nearest space
- sometimes the dot needs to shift away from its parent, and that's ok
within the compass of the chord
- dots two or more staff _positions_ (not staff _spaces_ as written) away
from the top or bottom of the chord look strange, so exclude those.

Pragmatically though, I strongly believe it's a mistake for Lilypond's
defaults to go against the grain of what most readers of music expect and
have learnt to expect, even if the holy grail appears to say it's "right".

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 10:41 AM, "Chris Yate"  wrote:

>On Thu, 15 Sep 2016 at 17:33 Carl Sorensen  wrote:
>
>
>
>I note that sib1.png is exactly the same chord as in the Gould scan.  And
>it has two less dots than Gould shows.  So it's not consistent with Gould.
>
>
>
>
>I'm not quite sure what she's showing in that example you scanned, but I
>thought it was about centering the dots.

It is about centering the dots.  But it is also exactly the same chord you
use in sib1.png.  And it has 5 dots, not three dots.

>
> 
>I think the trouble with Gould's rules is that they're inconsistent, or
>could at least be interpreted in such a way.  She says to use dots only
>on the spaces occupied by the chord, and yet says you MAY need to put a
>dot a space or more away from the chord.

No, let me summarize Gould's rules.

Rule 1: Every notehead in a chord must take a duration dot.

Rule 2: Move dots away from a note head on a line by moving it either up
or down (she has some guidelines for how to do this, but I'm skipping them
right now)

Rule 3: Every dot needs to have a staff space to itself.  This implies
(although it's not explicitly stated, but it is shown) that you may need
to move dots farther than one staff space away from the note head.

Rule 4: Center the dots on the chord.  This fixes problems that may show
up by applying rule 3.

Rule 5: If one of the remaining dots is two or more staff spaces from the
chord, the dot pattern is bad, so instead of having one dot per note head,
just have one dot per staff space included in the chord.

Every example she shows is consistent with these rules.  The examples you
show from Sibelius are not consistent with these rules.  That doesn't make
them wrong, just inconsistent with Gould.


> 
> 
>
>At the very least, we should be able to decide in our own scores what
>logic is used for dot placement :-)

Yes.  Perhaps we could make a scheme callback for cleaning up dots.  And
that could become a property of a DotColumn, and the user would be free to
implement their own Scheme function for cleaning up the dots.

>
>
>Are you editing the code in dot-column.cc. or is there some Scheme code
>for this too?

Just editing code in dot-column.cc.  No Scheme code anywhere that I can
see.

So what rules do you use to decide when a dot is necessary below the
bottom note of a chord, above the top of a chord, or in the middle of a
chord with an interval larger than a third?

Looking at your statements in Dots.ly, I would infer the following rules:


1. Put dots next to note heads on staff spaces.
2. Put dots in the space above note heads on staff lines.  If the space is
already taken, and the space below the note head is available, place the
dot in the space below the note head.  If the space is already taken, and
the space below the note head is taken as well, omit the dot.


I think those two rules provide the dots that you have considered to be
necessary in Dots.ly, without any of the dots you consider unnecessary.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 8:01 AM, "Chris Yate"  wrote:

>On Thu, 15 Sep 2016 at 14:36 Chris Yate  wrote:
>
>
>> According to Gould, I believe that dots limit 3 is the correct setting.
>
>
>
>
>
>OK. On reflection, perhaps I can see your reasoning, although I disagree
>that the current situation reliably produces the notation one would
>expect. And it's insufficiently controllable.

I believe I agree that it's insufficiently controllable.

>
>
>In any case, I might argue "chord-dots-limit" isn't unambiguously
>explained
>
>
>". Limits the column of dots on each chord to the height of the chord
>plus chord-dots-limit staff-positions."

I would change the wording to say something like "The maximum distance
between the extreme dot on a dot column and the closest note on a chord
must be less than or equal to chord-dots-limit staff positions."

>
>
>In situation 1 in my test cases, the height of the chord is 4
>staff-positions... or is it 2 and a half staff-spaces?

In situation 1, the dot in the A space is one staff-space (two staff
positions) above the top of the chord; the dot in the B space is one-half
staff space (one staff position) below the bottom of the chord.

> 
>
>
>Should I want in example 2, to have dots on the D, F, A spaces and not on
>B, then chord-dots-limit=1 might be interpreted to suppress the dot
>that's 2 staff positions away from the chord (on B space) and place one 1
>staff position _above_ the chord, on
> A.  The dotsUp and dotsDown settings don't appear to have any effect
>here.

I see your point here.  It seems that we ought to be able to set
chords-dots-limit to 2, and then get the dots on the D, F and A instead of
B, D, and F.  And perhaps we have no property that will allow this to
happen.

Thanks,

Carl



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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 17:33 Carl Sorensen  wrote:

>
> I note that sib1.png is exactly the same chord as in the Gould scan.  And
> it has two less dots than Gould shows.  So it's not consistent with Gould.
>

I'm not quite sure what she's showing in that example you scanned, but I
thought it was about centering the dots.

If the trim rule for Gould were "trim to the chord spaces if the dot
> spaces are two or more staff spaces larger than the chord spaces", then
> we'd get the Sibelius output.
>

If you could check what she shows for the 9th-spanned cluster chord (which
Brian mentioned above) -- Brian said she shows only five dots there. So
perhaps she's not self-consistent.


> The current logic doesn't reflect Gould's rules at all, as it only refers
> to the number of staff positions taken by the chord, not the number of
> staff spaces taken by the chord.  And Gould clearly considers staff spaces
> to be the important metric in her rules.
>

I think the trouble with Gould's rules is that they're inconsistent, or
could at least be interpreted in such a way.  She says to use dots only on
the spaces occupied by the chord, and yet says you MAY need to put a dot a
space or more away from the chord.


> So the challenge is to figure out a way to implement Gould's rules with
> some adjustable parameter that allow us to get Sibelius's rules.


At the very least, we should be able to decide in our own scores what logic
is used for dot placement :-)

Are you editing the code in dot-column.cc. or is there some Scheme code for
this too?

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 10:11 AM, "Chris Yate"  wrote:

>For the sake of argument, here's what Sibelius does in similar
>circumstances, and which I think is right, and actually within the spirit
>of Gould's coments.

I note that sib1.png is exactly the same chord as in the Gould scan.  And
it has two less dots than Gould shows.  So it's not consistent with Gould.

If the trim rule for Gould were "trim to the chord spaces if the dot
spaces are two or more staff spaces larger than the chord spaces", then
we'd get the Sibelius output.

The current logic doesn't reflect Gould's rules at all, as it only refers
to the number of staff positions taken by the chord, not the number of
staff spaces taken by the chord.  And Gould clearly considers staff spaces
to be the important metric in her rules.

So the challenge is to figure out a way to implement Gould's rules with
some adjustable parameter that allow us to get Sibelius's rules.

I'll have to think about it a bit.  My current change improved some
things, but made others worse.

But I'm sure it's doable.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Chris Yate]

For the sake of argument, here's what Sibelius does in similar
circumstances, and which I think is right, and actually within the spirit
of Gould's coments.

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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 16:37 Carl Sorensen  wrote:That
certainly is strange.  I wonder why it drops to four dots instead of

> 5, given that there are 5 notes in the cluster.  And the G space dot would
> only be two staff positions away from the E.
>
> I'm looking into the code now.  I'll see if I can figure out what's going
> on.
>
> Thanks,
>
> Carl
>

There appears to be a bias towards placing dots beneath the chord in
certain conditions.

Apparently there's an example in Gould of chords spanning a ninth, such as:

A)
\new Staff {
 \relative c' { 2. }
}
and
B)
\new Staff {
  \relative c' { 2. }
}

for A, dots limit 0 or 1 gives a sensible result with five dots, as does 4
or 5 with seven -- depending on your preference.

for B,  we need dots limit 3 to get six evenly spaced dots. Any higher than
4 and theres unnecessary dots.

Hopefully you'll find something :)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 8:35 AM, "Chris Yate"  wrote:
>
>Thanks -- but that example is about balancing the dots around a chord,
>which I believe we're not disagreed about.  (This scanned example is
>related her statement about not placing the dots in one direction).

I believe the first chord \relative c'{ 4.} is exactly analogous
to your case 2 -- four note cluster, space at the bottom.  And the bottom
dot is one staff space below the bottom note of the chord.

>
>
>And yet: 
>
>\relative c' { 2. }
>does not produce the output she suggests for this chord. I need
>chord-dots-limit = 4 for that.

That certainly is strange.  I wonder why it drops to four dots instead of
5, given that there are 5 notes in the cluster.  And the G space dot would
only be two staff positions away from the E.

I'm looking into the code now.  I'll see if I can figure out what's going
on.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 15:22 Carl Sorensen  wrote:

>
>
> On 9/15/16 7:36 AM, "Chris Yate"  wrote:
>
> >Carl, the key is the last bit of Gould's text as quoted by Brian above:
> >"When a dot is forced to be two or more stave-spaces from the chord, its
> >function becomes less relevant. In such cases, use only as many dots as
> >cover the number of stave-spaces taken up by the chord."
> >In my 30-odd years experience of reading music I don't think I've ever
> >seen augmentation dots extending even a full space away from a chord
> >(apart from moving a half-step above or below a line-note).
>
> Please see attached scan from Gould.
>
> Thanks,
>
> Carl


Thanks -- but that example is about balancing the dots around a chord,
which I believe we're not disagreed about.  (This scanned example is
related her statement about not placing the dots in one direction).

And yet:
\relative c' { 2. }
does not produce the output she suggests for this chord. I need
chord-dots-limit = 4 for that.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/15/16 7:36 AM, "Chris Yate"  wrote:

>Carl, the key is the last bit of Gould's text as quoted by Brian above:
>"When a dot is forced to be two or more stave-spaces from the chord, its
>function becomes less relevant. In such cases, use only as many dots as
>cover the number of stave-spaces taken up by the chord."
>In my 30-odd years experience of reading music I don't think I've ever
>seen augmentation dots extending even a full space away from a chord
>(apart from moving a half-step above or below a line-note).

Please see attached scan from Gould.

Thanks,

Carl

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

Re: Augmentation dot positioning

[Chris Yate]

On Thu, 15 Sep 2016 at 14:36 Chris Yate  wrote:

> > According to Gould, I believe that dots limit 3 is the correct setting.
>

OK. On reflection, perhaps I can see your reasoning, although I disagree
that the current situation reliably produces the notation one would expect.
And it's insufficiently controllable.

In any case, I might argue "chord-dots-limit" isn't unambiguously explained

". Limits the column of dots on each chord to the height of the chord plus
chord-dots-limit staff-positions."

In situation 1 in my test cases, the height of the chord is 4
staff-positions... or is it 2 and a half staff-spaces?

Should I want in example 2, to have dots on the D, F, A spaces and not on
B, then chord-dots-limit=1 might be interpreted to suppress the dot that's
2 staff positions away from the chord (on B space) and place one 1 staff
position _above_ the chord, on A.  The dotsUp and dotsDown settings don't
appear to have any effect here.

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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/13/16 11:53 AM, "Chris Yate"  wrote:

>
>Thanks Werner. That's potentially a useful workaround. But the default
>behaviour is obviously broken. There's no way I should see a dot placed
>on the space above or below a note on a space -- obviously notes on a
>line are a different matter.  As far as I can tell the default should be
>never to place the dot more than one staff position away from the top or
>bottom note of a chord.

Gould's rule disagree with your assertion.  Gould specifically shows good
examples with dots both above and below a note on a space. She also shows
an error where a dot one staff space above the chord is removed (I'll try
to get scans today).

The only trimming Gould does (which LilyPond may not do, I guess) is that
if the full set of dots would result in a dot that is two or more staff
spaces away from the upper or lower note of the chord, the dots are
trimmed to cover the staff spaces taken up by the chord.

Thanks,

Carl


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

Re: Augmentation dot positioning

[Carl Sorensen]

On 9/14/16 9:05 AM, "Chris Yate"  wrote:
>
>
>
>Attached with some extra cases I'd forgotten about (the inverted versions
>of the final 6.

According to Gould, I believe that dots limit 3 is the correct setting.

Case 1: Gould says that the dot in the A space is correct.  The only dots
she removes are dots that are 2 staff spaces or more away from the chord
(p. 56); the A space is only one staff space away.

Case 2: Similarly, the B space dot is correct according to Gould.

Case 9: Just as in case 2, the B space dot is correct.

Case 10: The C space dot is correct according to Gould -- one staff space
above chord.

Case 12: See cases 2 and 9; B space dot is one staff space below chord

Case 13: I am unsure about the G dot -- it's one and a half staff spaces
below the chord, so by Gould's strict rule, it should be there, I guess.
But I prefer it gone.

Case 14: I'm not sure why you consider the A space dot unnecessary.
According to Gould's rules, it should be there.

Case 15: Same as case 14.

Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.

Case 17: Same as 16

Case 18: Same as 16

Case 19: Same as 16

Case 20: Gould's rules say A space dot is correct.

Case 21: Same as 20

Case 23: Same as 16

Case 24: Gould's rules say G space dot is correct.

Case 25: Gould's rules say B space dot is correct.

In short, dots limit 3 never fails according to Chris's rules, and appears
to me to be exactly correct with respect to Gould's rules.  So I have a
hard time seeing what the issue is.

Thanks,

Carl





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

Re: Augmentation dot positioning

[Chris Yate]

On 15 Sep 2016 14:27, "Carl Sorensen"  wrote:
>
>
>
> On 9/14/16 9:05 AM, "Chris Yate"  wrote:
> >
> >
> >
> >Attached with some extra cases I'd forgotten about (the inverted versions
> >of the final 6.
>
> According to Gould, I believe that dots limit 3 is the correct setting.
>
> Case 1: Gould says that the dot in the A space is correct.  The only dots
> she removes are dots that are 2 staff spaces or more away from the chord
> (p. 56); the A space is only one staff space away.
>
> Case 2: Similarly, the B space dot is correct according to Gould.
>
> Case 9: Just as in case 2, the B space dot is correct.
>
> Case 10: The C space dot is correct according to Gould -- one staff space
> above chord.
>
> Case 12: See cases 2 and 9; B space dot is one staff space below chord
>
> Case 13: I am unsure about the G dot -- it's one and a half staff spaces
> below the chord, so by Gould's strict rule, it should be there, I guess.
> But I prefer it gone.
>
> Case 14: I'm not sure why you consider the A space dot unnecessary.
> According to Gould's rules, it should be there.
>
> Case 15: Same as case 14.
>
> Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.
>
> Case 17: Same as 16
>
> Case 18: Same as 16
>
> Case 19: Same as 16
>
> Case 20: Gould's rules say A space dot is correct.
>
> Case 21: Same as 20
>
> Case 23: Same as 16
>
> Case 24: Gould's rules say G space dot is correct.
>
> Case 25: Gould's rules say B space dot is correct.
>
> In short, dots limit 3 never fails according to Chris's rules, and appears
> to me to be exactly correct with respect to Gould's rules.  So I have a
> hard time seeing what the issue is.
>
> Thanks,
>
> Carl

Carl, the key is the last bit of Gould's text as quoted by Brian above:

"When a dot is forced to be two or more stave-spaces from the chord, its
function becomes less relevant. In such cases,* use only as many dots as
cover the number of stave-spaces taken up by the chord*."

In my 30-odd years experience of reading music I don't think I've ever seen
augmentation dots extending even a full space away from a chord (apart from
moving a half-step above or below a line-note).

On 15 Sep 2016 14:27, "Carl Sorensen"  wrote:



On 9/14/16 9:05 AM, "Chris Yate"  wrote:
>
>
>
>Attached with some extra cases I'd forgotten about (the inverted versions
>of the final 6.

According to Gould, I believe that dots limit 3 is the correct setting.

Case 1: Gould says that the dot in the A space is correct.  The only dots
she removes are dots that are 2 staff spaces or more away from the chord
(p. 56); the A space is only one staff space away.

Case 2: Similarly, the B space dot is correct according to Gould.

Case 9: Just as in case 2, the B space dot is correct.

Case 10: The C space dot is correct according to Gould -- one staff space
above chord.

Case 12: See cases 2 and 9; B space dot is one staff space below chord

Case 13: I am unsure about the G dot -- it's one and a half staff spaces
below the chord, so by Gould's strict rule, it should be there, I guess.
But I prefer it gone.

Case 14: I'm not sure why you consider the A space dot unnecessary.
According to Gould's rules, it should be there.

Case 15: Same as case 14.

Case 16: As in cases 2 and 9, Gould suggests the B space dot belongs.

Case 17: Same as 16

Case 18: Same as 16

Case 19: Same as 16

Case 20: Gould's rules say A space dot is correct.

Case 21: Same as 20

Case 23: Same as 16

Case 24: Gould's rules say G space dot is correct.

Case 25: Gould's rules say B space dot is correct.

In short, dots limit 3 never fails according to Chris's rules, and appears
to me to be exactly correct with respect to Gould's rules.  So I have a
hard time seeing what the issue is.

Thanks,

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

Re: Augmentation dot positioning

[Werner LEMBERG]

> Attached with some extra cases I'd forgotten about (the inverted
> versions of the final 6.

Looks good, thanks.  Please post this to the bug list so that a
bugmeister can create an issue – since the old issue was tagged as
fixed, a new one will be created.


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

Re: Augmentation dot positioning

[Werner LEMBERG]

>>> Did you intentionally mark those examples with unnecessary dots as
>>> "OK", rather than "FAIL"?

Yes.

>>> In my opinion, they should probably be failure cases.

I don't think so.  IMHO, the default should be value 0; if you
increase the value, more dots do appear, so it's not a failure if they
get displayed.

> The "Extension above 4-note line top cluster with a 3rd" examples
> for dot-limits 1,2 should also have "unnecessary dot on B space".

Please correct :-)


Werner

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

Re: Augmentation dot positioning

[Chris Yate]

On Wed, 14 Sep 2016 at 15:20 Chris Yate  wrote:

> On Wed, 14 Sep 2016 at 15:18 Chris Yate  wrote:
>
>> On Wed, 14 Sep 2016 at 14:55 Werner LEMBERG  wrote:
>>
>>>
>>> > Here's some test cases. I doubt this is the best place to post them
>>> > (bugs list?) but they're relevant to the conversation.
>>>
>>> Thanks!  However, your PDF file was not in sync with the input file;
>>> I've taken the opportunity to clean up the file and to add some `OK'
>>> and `FAIL' strings.  Please check.
>>
>> Werner
>>>
>>
>> Thanks - this is clearer. (and yes, there was a mistake in the final set
>> (cut and paste issue) with the unnecessary dot on B not A).
>>
>> Did you intentionally mark those examples with unnecessary dots as "OK",
>> rather than "FAIL"? In my opinion, they should probably be failure cases.
>>
>> Chris
>>
>
> Errata: The
>

Apologies, sent in error:

The "Extension above 4-note line top cluster with a 3rd" examples for
dot-limits 1,2 should also have "unnecessary dot on B space".

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

Re: Augmentation dot positioning

[Chris Yate]

On Wed, 14 Sep 2016 at 15:18 Chris Yate  wrote:

> On Wed, 14 Sep 2016 at 14:55 Werner LEMBERG  wrote:
>
>>
>> > Here's some test cases. I doubt this is the best place to post them
>> > (bugs list?) but they're relevant to the conversation.
>>
>> Thanks!  However, your PDF file was not in sync with the input file;
>> I've taken the opportunity to clean up the file and to add some `OK'
>> and `FAIL' strings.  Please check.
>
> Werner
>>
>
> Thanks - this is clearer. (and yes, there was a mistake in the final set
> (cut and paste issue) with the unnecessary dot on B not A).
>
> Did you intentionally mark those examples with unnecessary dots as "OK",
> rather than "FAIL"? In my opinion, they should probably be failure cases.
>
> Chris
>

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

Re: Augmentation dot positioning

[Chris Yate]

On Wed, 14 Sep 2016 at 14:55 Werner LEMBERG  wrote:

>
> > Here's some test cases. I doubt this is the best place to post them
> > (bugs list?) but they're relevant to the conversation.
>
> Thanks!  However, your PDF file was not in sync with the input file;
> I've taken the opportunity to clean up the file and to add some `OK'
> and `FAIL' strings.  Please check.

Werner
>

Thanks - this is clearer. (and yes, there was a mistake in the final set
(cut and paste issue) with the unnecessary dot on B not A).

Did you intentionally mark those examples with unnecessary dots as "OK",
rather than "FAIL"? In my opinion, they should probably be failure cases.

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

Re: Augmentation dot positioning

[Davide Liessi]

2016-09-14 14:24 GMT+02:00 Chris Yate :
> Here's some test cases. I doubt this is the best place to post them (bugs
> list?) but they're relevant to the conversation.

I may be wrong, but I would say that examples "Extension above 4-note
line-top cluster with a 3rd" (page 6, top group) with dot limit 1 and
2 are *not* OK.
In my opinion all examples on page 6 except the very first line have
an unwanted dot on the "B space" below the staff.

Best wishes.
Davide

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

Re: Augmentation dot positioning

[Chris Yate]

On Wed, 14 Sep 2016 at 11:58 Werner LEMBERG  wrote:

>
> >> However, you have found a bug I think, since it doesn't seem to
> >> work correctly for your case, eliminating dots on the wrong side of
> >> the chord.
> >
> > Also, it’s clearly wrong to have dots in two ‘columns’. They look
> > like double-dotted notes.
>
> Please have a closer look!  The lower chords in the first bar have a
> `4..' rhythm, the upper ones have `4.'.
> Werner
>

I've just rendered that example (below), and the first chord has the
double-dot the _space_below_ the "f4.." note. Which is almost certainly
wrong behaviour :(

Chris

ex.from the chord-dot regression:

\version "2.17.16"

\header {
  texidoc =
"The column of dots on a chord is limited to the height
of the chord plus @code{chord-dots-limit} staff-positions."
}

\layout{ ragged-right = ##t }

\new Staff \transpose c c' {
  \override Staff.DotColumn.chord-dots-limit = #1
  <<
{ 4. r8 4. r8 } \\
{ f4.. r16 4.. r16}
  >>
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Werner LEMBERG]

>> However, you have found a bug I think, since it doesn't seem to
>> work correctly for your case, eliminating dots on the wrong side of
>> the chord.
> 
> Also, it’s clearly wrong to have dots in two ‘columns’. They look
> like double-dotted notes.

Please have a closer look!  The lower chords in the first bar have a
`4..' rhythm, the upper ones have `4.'.


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

Re: Augmentation dot positioning

[Simon Albrecht]

On 13.09.2016 07:24, Werner LEMBERG wrote:



The issue occurs when writing closely spaced chords with an
augmentation dot in the rhythm. Dots are placed only on spaces
(which we should expect), but in certain very easy to reproduce
conditions, the dot appears in an unexpected place.

Cf. `regression/chord-dots.ly'; this is controlled by the
`chord-dots-limit' property.

However, you have found a bug I think, since it doesn't seem to work
correctly for your case, eliminating dots on the wrong side of the
chord.


Also, it’s clearly wrong to have dots in two ‘columns’. They look like 
double-dotted notes.


Best, Simon

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

Re: Augmentation dot positioning

[Chris Yate]

On 14 Sep 2016 04:26, "Brian Barker"  wrote:
>
> At 23:50 13/09/2016 +, Chris Yate wrote:
>>
>> Could someone that owns a copy of Gould chip in with a "best practice"
recommendation?
>
>
> I've not been following this thread in detail, so I'm not sure if this is
what you need. This from pages 55 and 56. (I'm aware the last sentence
contradicts the first.)
>
> Every notehead in a chord must take a duration dot. Vertically align the
dots after the chord.
> *Adjacent-note chords*
> When the upper note is on a line, the dot moves up to the next
stave-space, as usual. When the lower note is on a line, the dot drops to
the lower space.
> Each dot should have a stave-space to itself. This same spacing applies
to chords on ledger lines as well, where dots should not be bunched up just
because there are no stave lines to separate them into individual spaces.
> A dot may need to move a stave-space away from its notehead.
> Centre the dots on the chord, rather than placing them in one direction,
away from the chord.
> When a dot is forced to be two or more stave-spaces from the chord, its
function becomes less relevant. In such cases, use only as many dots as
cover the number of stave-spaces taken up by the chord.
>
> Her example of the last dictum has a chord of eight notes (spanning a
ninth) having a column of only five dots.
>
> Brian Barker

Perfect. Thanks. Although she said a dot may need to be moved a stave-space
away from its note, it typically looks wrong to me, and using only the
spaces occupied by the chord is right. However, that's why we have
\override directives...

One situation that apparently causes a "floating" dot is { d f fis },
assuming f and fis share a space. Since they are in the same staff position
it seems appropriate for them to share a dot.

The case of dotted chords coinciding in multiple voices probably has to be
treated separately. I think in that case the chords should move
horizontally to allow their dots to live next to the appropriate note heads
- but it is a different bug/feature.

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

Re: Augmentation dot positioning

[Chris Yate]

On Tue, 13 Sep 2016 at 19:55 Werner LEMBERG  wrote:

> It's issue 3179
>
>   https://sourceforge.net/p/testlilyissues/issues/3179/
>
> and commit dfff5d3d1a1001f65d1f7183837f56ccd64fb15a
>
>
> http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=dfff5d3d1a1001f65d1f7183837f56ccd64fb15a
>
> > There's no way I should see a dot placed on the space above or below
> > a note on a space -- obviously notes on a line are a different
> > matter.  As far as I can tell the default should be never to place
> > the dot more than one staff position away from the top or bottom
> > note of a chord.
>
> Hmm.  For some reasons the default value of `chord-dots-limit' is set
> to 3.  I can't remember why Keith has decided to use this number, but
> I would rather change the default to value 0.
>
> Werner
>

Zero dosn't an ideal choice in the situations I've been testing; I think 1
is safer.

e.g. here misses a dot on the space above g'
```
\version "2.19.45"
\new Staff {
   \override Staff.DotColumn.chord-dots-limit = 0
   < b d' e' f' g' >2.
}
```
This chord needs a setting of 1.

This example even worse (actually taken from the piano part of my
composition, which inspired the problem:
```
\version "2.19.45"
\new Staff {
   \override Staff.DotColumn.chord-dots-limit = 0
   \relative c'{   2. }
}
```
With dots limit 0 the a (treble clef 2nd space) gets no dot. With the
default chord-dots-limit = 3 there's a dot on the B- and G-spaces below
treble clef.

It's easy to produce a really horrible chord that confuses things
completely, and having two voices is by far the best way -- this I implied
by reference to the other issue on sourceforge about dot positioning around
shared vertical beams. Sensible writing would separate the two voices
horizontally for clarity, and that's how they should be dotted. (If one
ever came across such a pathological case in the wild).

But with a single voice it should be possible to come up with conclusive
test cases for every possibility (ignoring chromatic clusters like `< c cis
d dis e f  >`, which in any case aren't typeset very well by standard
methods).  I'd be happy to try to come up with the test cases, but
understanding and bug-fixing Scheme code gives me a headache ;-)

Could someone that owns a copy of Gould chip in with a "best practice"
recommendation? Once the maths bit is specified it should be relatively
easy to code.

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

Re: Augmentation dot positioning

[Werner LEMBERG]

>> > The issue occurs when writing closely spaced chords with an
>> > augmentation dot in the rhythm. Dots are placed only on spaces
>> > (which we should expect), but in certain very easy to reproduce
>> > conditions, the dot appears in an unexpected place.
>>
>> Cf. `regression/chord-dots.ly'; this is controlled by the
>> `chord-dots-limit' property.
>>
>> However, you have found a bug I think, since it doesn't seem to work
>> correctly for your case, eliminating dots on the wrong side of the
>> chord.
>>
>>
>> Werner
>>
> 
> Thanks Werner.  That's potentially a useful workaround. But the default
> behaviour is obviously broken.

It's issue 3179

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

and commit dfff5d3d1a1001f65d1f7183837f56ccd64fb15a

  
http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=dfff5d3d1a1001f65d1f7183837f56ccd64fb15a

> There's no way I should see a dot placed on the space above or below
> a note on a space -- obviously notes on a line are a different
> matter.  As far as I can tell the default should be never to place
> the dot more than one staff position away from the top or bottom
> note of a chord.

Hmm.  For some reasons the default value of `chord-dots-limit' is set
to 3.  I can't remember why Keith has decided to use this number, but
I would rather change the default to value 0.


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

Re: Augmentation dot positioning

[Chris Yate]

On Tue, 13 Sep 2016 at 18:53 Chris Yate  wrote:

>
>> However, you have found a bug I think, since it doesn't seem to work
>> correctly for your case, eliminating dots on the wrong side of the
>> chord
>>
>
This may be related (or fixed by?)

https://sourceforge.net/p/testlilyissues/issues/2201/
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Augmentation dot positioning

[Chris Yate]

On Tue, 13 Sep 2016 at 06:24 Werner LEMBERG  wrote:

>
> > The issue occurs when writing closely spaced chords with an
> > augmentation dot in the rhythm. Dots are placed only on spaces
> > (which we should expect), but in certain very easy to reproduce
> > conditions, the dot appears in an unexpected place.
>
> Cf. `regression/chord-dots.ly'; this is controlled by the
> `chord-dots-limit' property.
>
> However, you have found a bug I think, since it doesn't seem to work
> correctly for your case, eliminating dots on the wrong side of the
> chord.
>
>
> Werner
>

Thanks Werner. That's potentially a useful workaround. But the default
behaviour is obviously broken. There's no way I should see a dot placed on
the space above or below a note on a space -- obviously notes on a line are
a different matter.  As far as I can tell the default should be never to
place the dot more than one staff position away from the top or bottom note
of a chord.

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

Re: Augmentation dot positioning

[Werner LEMBERG]

> The issue occurs when writing closely spaced chords with an
> augmentation dot in the rhythm. Dots are placed only on spaces
> (which we should expect), but in certain very easy to reproduce
> conditions, the dot appears in an unexpected place.

Cf. `regression/chord-dots.ly'; this is controlled by the
`chord-dots-limit' property.

However, you have found a bug I think, since it doesn't seem to work
correctly for your case, eliminating dots on the wrong side of the
chord.


Werner
\version "2.17.16"

\header {
  texidoc =
"The column of dots on a chord is limited to the height
of the chord plus @code{chord-dots-limit} staff-positions."
}

\layout{ ragged-right = ##t }

\paper { indent = 0 }

\new Staff \with {
  \omit TimeSignature }
\transpose c c' {
  <>^"chord-dots-limit not set"
  <<
{ 4. r8 4. r8 } \\
{ f4.. r16 4.. r16 }
  >>

  <<
{ < g c d e f>2. r4 } \\
{ < bes dis e fis >4. r8 r2 }
  >>

  \break

  \override Staff.DotColumn.chord-dots-limit = #1
  <>^"chord-dots-limit = 1"
  <<
{ 4. r8 4. r8 } \\
{ f4.. r16 4.. r16 }
  >>

  <<
{ < g c d e f>2. r4 } \\
{ < bes dis e fis >4. r8 r2 }
  >>

  \break

  \override Staff.DotColumn.chord-dots-limit = #0
  <>^"chord-dots-limit = 0"
  <<
{ 4. r8 4. r8 } \\
{ f4.. r16 4.. r16 }
  >>

  <<
{ < g c d e f>2. r4 } \\
{ < bes dis e fis >4. r8 r2 }
  >>

  \break

  \override Staff.DotColumn.chord-dots-limit = #-1
  <>^"chord-dots-limit = -1"
  <<
{ 4. r8 4. r8 } \\
{ f4.. r16 4.. r16 }
  >>

  <<
{ < g c d e f>2. r4 } \\
{ < bes dis e fis >4. r8 r2 }
  >>
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Augmentation dot positioning

[Chris Yate]

Hi all,

I have only rarely typeset piano music in the past, which is probably why I
haven't come across this issue before.

The issue occurs when writing closely spaced chords with an augmentation
dot in the rhythm. Dots are placed only on spaces (which we should expect),
but in certain very easy to reproduce conditions, the dot appears in an
unexpected place.

\version "2.19.45"
\relative c' {
  < g c d e f>2. }

The attached image shows dots unexpectedly positioned on the A space and B
space below the staff. I'm not sure what the "correct" notation should be
in this situation, but writing by hand I would place dots on the spaces for
G, D and F.

Interestingly, I found a 4 year old Musescore bug report for this issue
which mentions Lilypond 2.15 having problems.

https://musescore.org/en/node/15434

We can readily reproduce a pathological case (image also attached).

\version "2.19.45"
\relative c' {
<<  < g c d e f>2. \\ < bes dis e fis >4. >>
}

The question for the list being, what workarounds are there for strangely
placed augmentation dots?  Perhaps suppressing the dots for certain notes?

Thanks in advance,

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