Re: skyline vertical spacing

[Erik Sandberg]

On Monday 13 November 2006 21:11, Joe Neeman wrote:
> Here's a patch for introducing skyline vertical spacing. The bulk of the
> changes are to rewrite skyline so that
> 1) merging is linear (in the sum of the lengths of the skylines) time
> 2) building a skyline from boxes is O(n lg(n)) time
> 3) we support sloped-roof skylines. This isn't used yet, but I think it can
> be used for skylines where more accuracy is needed (for example in
> horizontal spacing). In any case, it only adds a constant factor to the
> complexity.

This sounds very cool.

Just a question: I have been thinking about skyline spacing in music for a 
while (trying to figure out cases where skyline spacing can give bad 
results), and I have one idea: In some cases, objects could come too close 
together with skyline spacing. E.g., if a stem sticks up from one staff, and 
a horizontally nearby stem sticks down from the staff above, the stems could 
end up too close to each other, like:

======
==o===
  |
 |||
 |||
 | |
=o=o==
=====

I have an idea on how to work around this problem: We could define a maximum 
slope for 'sloped-roof' skylines; i.e., for vertical spacing, we allow 
horizontal lines but not vertical lines, instead the slope of a skyline can 
maximally be (say) 60 degrees. So the skyline of the upper staff becomes 
something like (sorry for the lousy ascii art):

===============
__===o===____
  \  |  /
   \ | /
    \|/

With the right choice of maximum slope, this would hopefully increase the 
distance sufficiently to prevent too tight spacing.

I know nothing about the theories of skylines, and I haven't looked at your 
code yet, so maybe there is a better solution to the problem already; my 
apologies in that case. If not, does this sound sensible to you?

-- 
Erik