Issue 2535: Staccato on stem side alignment when other articulations are present

Issue 2535: Staccato on stem side alignment when other articulations are present

The default positioning of staccato dots in combination with other articulations
is poor, because the dot is positioned midway between the center of the note head
and the stem, while all other scripts are centered on the note head.

A mechanism is needed to allow a staccato dot to be positioned differently when alone
and when in combination with other articulations.  The property 'toward-stem-shift
controls the alignment of scripts appearing on the side of the stem.  This patch
changes the type of 'toward-stem-shift to number-pair rather than number.  The first
member of the pair indicates the shift when alone, the second the shift when the
script is contained by a ScriptColumn object.  The vast majority of articulations
default to '(0.0 . 0.0), indicating that they are always centered above the note head
when on the stem side.  Three articulations--staccato, staccatissimo, and stopped--are
set to '(1.0 . 0.0), either directly above the stem or centered on the note head,
ensuring that combinations like accent-staccato will be properly aligned by default.

The previous default of 0.5 for staccato has been modified, in accordance with Gould's
recommendation.

In order to allow a script to recognize the column organizing it, a pointer to
ScriptColumn, called 'script-column, has been added to script-interface.

[david.nalesnik, 2015-01-27 00:03:19]

Please review.

[lemzwerg, 2015-01-27 00:33:57]

LGTM, thanks!

[dak, 2015-01-27 07:26:53]

It seems to me like this number-pair consists of two settings that would almost
always be adjusted independently.  Wouldn't it make more sense to make a
separate property here?  That way, the user would not need to remember and
restate the setting he is not interested in.

[dak, 2015-01-27 07:32:24]

Aaaand another thought: wouldn't it make more sense instead of having
independent shifts for "with other articulations" and "without other
articulations" when the articulation closest to the notehead is responsible for
aligning the whole stack of articulations?

Which would be the extreme case of a weighted average where articulations
closest to the notehead count most towards alignment.  But I suspect that
looking at more than just the closest articulation would likely be overkill and
not an actual improvement.

[lemzwerg, 2015-01-27 07:52:05]

On 2015/01/27 07:26:53, dak wrote:
> It seems to me like this number-pair consists of two settings that would
almost
> always be adjusted independently.  Wouldn't it make more sense to make a
> separate property here?  That way, the user would not need to remember and
> restate the setting he is not interested in.

IMHO it's better to logically stick stuff together.  We already have far too
much properties, and in this particular case I doubt that the user will change
the values very often so I think the benefits of having a single property are
exceeding the potential disadvantages.

[dak, 2015-01-27 08:50:36]

On 2015/01/27 07:52:05, lemzwerg wrote:
> On 2015/01/27 07:26:53, dak wrote:
> > It seems to me like this number-pair consists of two settings that would
> almost
> > always be adjusted independently.  Wouldn't it make more sense to make a
> > separate property here?  That way, the user would not need to remember and
> > restate the setting he is not interested in.
> 
> IMHO it's better to logically stick stuff together.  We already have far too
> much properties, and in this particular case I doubt that the user will change
> the values very often so I think the benefits of having a single property are
> exceeding the potential disadvantages.

You can "logically stick stuff together" by naming it appropriately, making them
come next to each other in alphabet and thus in documentation.  You state "the
benefits of having a single property are exceeding the potential disadvantages"
but don't actually name a single such benefit.

The main problem with having "far too many properties" is that one has a lot of
individual controls.  But you don't actually propose having fewer controls but
rather making it impossible to use one control without specifying a value for
the other one.  That's not a simplification but a complication.  And we are not
talking about something where the two values are related like in an interval.

At any rate, this discussion may be idle: it is likely that we don't need two
separate settings anyway if it is feasible to align the whole accent stack based
on its notehead-closest member.  The only time when this might not work is when
stem and accents are on the same side of the notehead and wide accents like --
(or was that -_ ?) come into play.  I don't think this should happen often, but
at least with double-stemmed noteheads it would be hard to avoid.

[david.nalesnik, 2015-01-27 14:20:20]

On 2015/01/27 07:32:24, dak wrote:
> Aaaand another thought: wouldn't it make more sense instead of having
> independent shifts for "with other articulations" and "without other
> articulations" when the articulation closest to the notehead is responsible
for
> aligning the whole stack of articulations?

Not in the case of staccatos, however.  Staccatos are ideally (according to
Gould) centered on the stem when alone, and centered on the notehead when with
others.  I can't think of an example of a compound articulation where staccato
is at the bottom.

> Which would be the extreme case of a weighted average where articulations
> closest to the notehead count most towards alignment.  But I suspect that
> looking at more than just the closest articulation would likely be overkill
and
> not an actual improvement.

Yes, I think weighting different toward-stem-shift values is too much.  After
all, articulations ought to be vertically aligned, and if a user for some reason
wants to shift a single member of the stack, the numbers they use ought to
reflect exactly the position relative to notehead and stem.

[david.nalesnik, 2015-01-27 14:37:27]

On 2015/01/27 08:50:36, dak wrote:
> On 2015/01/27 07:52:05, lemzwerg wrote:
> > On 2015/01/27 07:26:53, dak wrote:
> > > It seems to me like this number-pair consists of two settings that would
> > almost
> > > always be adjusted independently.  Wouldn't it make more sense to make a
> > > separate property here?  That way, the user would not need to remember and
> > > restate the setting he is not interested in.
> > 
> > IMHO it's better to logically stick stuff together.  We already have far too
> > much properties, and in this particular case I doubt that the user will
change
> > the values very often so I think the benefits of having a single property
are
> > exceeding the potential disadvantages.
> 
> You can "logically stick stuff together" by naming it appropriately, making
them
> come next to each other in alphabet and thus in documentation.  You state "the
> benefits of having a single property are exceeding the potential
disadvantages"
> but don't actually name a single such benefit.
> 
> The main problem with having "far too many properties" is that one has a lot
of
> individual controls.  But you don't actually propose having fewer controls but
> rather making it impossible to use one control without specifying a value for
> the other one.  That's not a simplification but a complication.  And we are
not
> talking about something where the two values are related like in an interval.

This change is motivated by the very small numbers of articulations which behave
differently when alone or in a compound articulation, so it would make sense to
add another property instead of requiring a longer specification.  Only
accidentals which belong to a ScriptColumn and which have the new property set
would be affected.

What would this property be named? snap-to-column? shift-in-column?

While I see the arguments for adding another property, I worry that in so doing
there is a risk of making all of this even more obscure.
> 
> At any rate, this discussion may be idle: it is likely that we don't need two
> separate settings anyway if it is feasible to align the whole accent stack
based
> on its notehead-closest member.  The only time when this might not work is
when
> stem and accents are on the same side of the notehead and wide accents like --
> (or was that -_ ?) come into play.  I don't think this should happen often,
but
> at least with double-stemmed noteheads it would be hard to avoid.

[david.nalesnik, 2015-01-27 14:38:30]

Eek.  Sorry for overquoting.

[dak, 2015-01-27 15:07:24]

On 2015/01/27 14:37:27, david.nalesnik wrote:

> What would this property be named? snap-to-column? shift-in-column?

I suggest picking a name that starts in the same way as the existing property.

> While I see the arguments for adding another property, I worry that in so
doing
> there is a risk of making all of this even more obscure.

With similar names (and particularly similar name starts), at least the
properties are adjacent in the Internals manual.  I am not sure we want another
numeric property if its value is just some trial-and-error offset (possibly
unlikely to work with different notehead styles or values) to arrive at
"centered on notehead".

[david.nalesnik, 2015-01-27 16:14:55]

On 2015/01/27 15:07:24, dak wrote:
> On 2015/01/27 14:37:27, david.nalesnik wrote:
> 
> > What would this property be named? snap-to-column? shift-in-column?
> 
> I suggest picking a name that starts in the same way as the existing property.

toward-stem-shift-in-column would be unambiguous.  Long, perhaps, but its 27
characters are exceeded by several properties, like
"beamlet-max-length-proportion" and "outside-staff-placement-directive".

> 
I am not sure we want another
> numeric property if its value is just some trial-and-error offset (possibly
> unlikely to work with different notehead styles or values) to arrive at
> "centered on notehead".

I do think that another numeric property is necessary.  After all, this new
property boils down to an alternate value of 'toward-stem-shift (which is one of
the principal motivations for including it in a number pair).  As to potential
problems with other sorts of noteheads, I'd have to check, but that would mean
that 'toward-stem-shift itself is flawed.  From the X-offset callback for Script
in scm/output-lib, it appears that the interpretation of this property is sound.

[lemzwerg, 2015-01-27 20:43:56]

LGTM.

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
File input/regression/script-shift.ly (right):

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
input/regression/script-shift.ly:6: means centered on the stem.)
The old code is correct...

[david.nalesnik, 2015-01-27 20:48:14]

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
File input/regression/script-shift.ly (right):

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
input/regression/script-shift.ly:6: means centered on the stem.)
On 2015/01/27 20:43:56, lemzwerg wrote:
> The old code is correct...

I'm going by the American practice that the period goes inside the parentheses
if the parentheses enclose the sentence, outside if the sentence begins outside
the parentheses.  I'm happy to change it back though--it's kind of pedantic of
me!

[lemzwerg, 2015-01-27 22:00:49]

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
File input/regression/script-shift.ly (right):

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
input/regression/script-shift.ly:6: means centered on the stem.)
> I'm going by the American practice that the period goes
> inside the parentheses if the parentheses enclose the
> sentence, outside if the sentence begins outside
> the parentheses.  I'm happy to change it back though--it's
> kind of pedantic of me!

I fully agree with what you say, however, parentheses do *not* enclose a full
sentence here (contrary to another place of the patch).

[david.nalesnik, 2015-01-27 22:46:15]

On 2015/01/27 22:00:49, lemzwerg wrote:
>
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
> File input/regression/script-shift.ly (right):
> 
>
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
> input/regression/script-shift.ly:6: means centered on the stem.)
> > I'm going by the American practice that the period goes
> > inside the parentheses if the parentheses enclose the
> > sentence, outside if the sentence begins outside
> > the parentheses.  I'm happy to change it back though--it's
> > kind of pedantic of me!
> 
> I fully agree with what you say, however, parentheses do *not* enclose a full
> sentence here (contrary to another place of the patch).

You're certainly right. Seems like I imagined a period!  OK, will change.

[david.nalesnik, 2015-01-29 17:47:05]

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
File input/regression/script-shift.ly (right):

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-s...
input/regression/script-shift.ly:6: means centered on the stem.)
On 2015/01/27 22:00:49, lemzwerg wrote:
> > I'm going by the American practice that the period goes
> > inside the parentheses if the parentheses enclose the
> > sentence, outside if the sentence begins outside
> > the parentheses.  I'm happy to change it back though--it's
> > kind of pedantic of me!
> 
> I fully agree with what you say, however, parentheses do *not* enclose a full
> sentence here (contrary to another place of the patch).

Done.