Removes outside-staff-priority from dynamic-related objects in Dynamic context

Removes outside-staff-priority from dynamic-related objects in Dynamic context

[MikeSol, 2013-03-26 15:03:11]

Fixes spelling mistake

[janek, 2013-03-27 21:50:02]

I see that these overrides solve the problem, but it would be nice to know why
this works.  Can you write an explanation?  What was wrong with the skylines
that caused this bug?  Maybe this is just one instance of a more general
problem.

https://codereview.appspot.com/7655045/diff/2001/input/regression/dynamics-ou...
File input/regression/dynamics-outside-staff-priority.ly (right):

https://codereview.appspot.com/7655045/diff/2001/input/regression/dynamics-ou...
input/regression/dynamics-outside-staff-priority.ly:18: >>
I suggest to minimize this example to 

<<
  \new Staff = "Test" {
    \tempo "Andante" c'1
  }
  \new Dynamics \with { alignAboveContext = "Test" } {
    s1\f
  }
>>

[MikeSol, 2013-03-29 04:50:30]

Changes regtest

[MikeSol, 2013-03-29 04:52:29]

On 2013/03/27 21:50:02, janek wrote:
> I see that these overrides solve the problem, but it would be nice to know why
> this works.  Can you write an explanation?  What was wrong with the skylines
> that caused this bug?  Maybe this is just one instance of a more general
> problem.

Objects that are placed inside the staff were being placed outside the staff. 
Conceptually, dynamics are "inside" a staff in Dynamics contexts, even if there
is no staff.

> 
>
https://codereview.appspot.com/7655045/diff/2001/input/regression/dynamics-ou...
> File input/regression/dynamics-outside-staff-priority.ly (right):
> 
>
https://codereview.appspot.com/7655045/diff/2001/input/regression/dynamics-ou...
> input/regression/dynamics-outside-staff-priority.ly:18: >>
> I suggest to minimize this example to 
> 
> <<
>   \new Staff = "Test" {
>     \tempo "Andante" c'1
>   }
>   \new Dynamics \with { alignAboveContext = "Test" } {
>     s1\f
>   }
> >>

Done

[janek, 2013-03-29 10:57:54]

On 2013/03/29 04:52:29, MikeSol wrote:
> On 2013/03/27 21:50:02, janek wrote:
> > I see that these overrides solve the problem, but it would be nice to know
why
> > this works.  Can you write an explanation?  What was wrong with the skylines
> > that caused this bug?  Maybe this is just one instance of a more general
> > problem.
> 
> Objects that are placed inside the staff were being placed outside the staff. 
> Conceptually, dynamics are "inside" a staff in Dynamics contexts, even if
there
> is no staff.

Interesting.  Why the skylines weren't completely empty,
but only cropped?
(please let me know if i'm bothering you too much - my
goal is to understand the issue and ensure good commit 
message, not to get you annoyed :) )

Janek

[mike7, 2013-03-29 14:10:41]

On 29 mars 2013, at 12:57, janek.lilypond@gmail.com wrote:

> On 2013/03/29 04:52:29, MikeSol wrote:
>> On 2013/03/27 21:50:02, janek wrote:
>>> I see that these overrides solve the problem, but it would be nice
> to know why
>>> this works.  Can you write an explanation?  What was wrong with the
> skylines
>>> that caused this bug?  Maybe this is just one instance of a more
> general
>>> problem.
> 
>> Objects that are placed inside the staff were being placed outside the
> staff.
>> Conceptually, dynamics are "inside" a staff in Dynamics contexts, even
> if there
>> is no staff.
> 
> Interesting.  Why the skylines weren't completely empty,
> but only cropped?
> (please let me know if i'm bothering you too much - my
> goal is to understand the issue and ensure good commit
> message, not to get you annoyed :) )
> 

Not sure - I haven't had a chance to investigate why it was wrong.  I just
spotted the problem and fixed it.

It is true that knowing what's going on internally would help, but that's worth
filing another issue for to the tune perhaps of "outside-staff positining above
empty inside-staff skylines leads to inconsistent results."

That said, if we are positioning above an empty element, it is difficult to know
what expected behavior would/should be.

Cheers,
MS

[janek, 2013-03-29 19:00:42]

On Fri, Mar 29, 2013 at 1:58 PM,  <mike@mikesolomon.org> wrote:
> Not sure - I haven't had a chance to investigate why it was wrong.
> I just spotted the problem and fixed it.
>
> It is true that knowing what's going on internally would help,
> but that's worth filing another issue for to the tune perhaps
> of "outside-staff positining above empty inside-staff skylines
> leads to inconsistent results."

ok - let's just put your previous answer into commit message/comment.

>>> Objects that are placed inside the staff were being placed outside
>>> the staff. Conceptually, dynamics are "inside" a staff in Dynamics
>>> contexts, even if there is no staff.

LGTM,
Janek

[Keith, 2013-03-30 04:35:36]

On 2013/03/27 21:50:02, janek wrote:
> What was wrong with the skylines
> that caused this bug?  Maybe this is just one instance of a more
> general problem.
> 

The skylines themselves were fine, but objects above a Staff are not checked for
collisions with objects below a Staff.

In the example a Dynamics was serving as the staff,  Dynamics has no staff-lines
but does have a conceptual reference line.  The tempo mark is placed above the
Dynamics and the forte "f" below.

Usually, above-staff things go above the reference line and below-staff things
go below it, but DynamicLineSpanner had an override of its Y-offset, centering
it on the reference line.  So adding the overrides to make DynamicLineSpanner
*not* outside the staff seems sensible.

Other above- or below-staff objects still have the usual Y-offset = 
#side-position-interface::y-aligned-side  putting them clearly on one side or
the other of the reference line, so the problem would not appear for other
objects 

... until Mike changed side-position-interface::y-aligned-side() so that now
below-staff text scripts now sit on top of the Dynamics reference line ?!

[mike7, 2013-03-30 05:07:46]

> On 2013/03/27 21:50:02, janek wrote:
>> What was wrong with the skylines
>> that caused this bug?  Maybe this is just one instance of a more
>> general problem.
> 
> 
> The skylines themselves were fine, but objects above a Staff are not
> checked for collisions with objects below a Staff.
> 
> In the example a Dynamics was serving as the staff,  Dynamics has no
> staff-lines but does have a conceptual reference line.  The tempo mark
> is placed above the Dynamics and the forte "f" below.
> 
> Usually, above-staff things go above the reference line and below-staff
> things go below it, but DynamicLineSpanner had an override of its
> Y-offset, centering it on the reference line.  So adding the overrides
> to make DynamicLineSpanner *not* outside the staff seems sensible.
> 
> Other above- or below-staff objects still have the usual Y-offset =
> #side-position-interface::y-aligned-side  putting them clearly on one
> side or the other of the reference line, so the problem would not appear
> for other objects
> 
> ... until Mike changed side-position-interface::y-aligned-side() so that
> now below-staff text scripts now sit on top of the Dynamics reference
> line ?!
> 
> https://codereview.appspot.com/7655045/

Could you send an example of the text scripts doing this?

Cheers,
MS

[Keith, 2013-04-05 17:46:59]

On 2013/03/30 05:07:46, mike7 wrote:
> > On 2013/03/27 21:50:02, janek wrote:
> > 
> > ... until Mike changed side-position-interface::y-aligned-side() so that
> > now below-staff text scripts now sit on top of the Dynamics reference
> > line ?!
> > 
> Could you send an example of the text scripts doing this?
> 
Any text scripts on an empty portion of the staff,
 \new Dynamics {s_"bb"^"gg"}
and also that line of dynamics in the regtest 'les-néréides', 
but both is resolved now that the patch for 3256 is reverted.