Re: Add changes entry for Mike's work on skylines. (issue 8613043)

[dak]

On 2013/04/16 08:34:43, MikeSol wrote:
> On 2013/04/16 07:51:46, dak wrote:
> >
> > I hate it when I get last-minute realizations.  Here is another
> > thing we need to do for the stable release: go through all
> > problems of the "too snug" kind and work out defaults that avoid
> > them.  It's ok to tell people in our documentation how to get
> > stuff move closer in case of necessity, but if we aren't talking
> > about running text and similar things, looser spacing than
> > necessary is _not_ a bug.
> >
> > Closer spacing than appropriate _is_ a bug.  One can publish a
> > score with loose spacing, but one can't publish a score where
> > things are sitting on each other.
> >
> > So for a stable release, we need conservative settings.  Settings
> > that won't _force_ people to pepper their sources with overrides
> > and tweaks just to throw them all out again when the next version
> > arrives.

> This is a great time to ping the user list.  People who have been
> using the development version for a while now have had a chance to
> get used to scores with this spacing, and if they have anything that
> they consider "too tight", then we can use simple skylines for those
> things.

Actually, I'd very much prefer if we can make do with larger and/or
different defaults for padding.  Throwing away skylines is a drastic
measure.  Admittedly, one providing continuity with previous stable
releases, but I think we still should try first working with
parameterizing the new code differently before switching it off,
providing a less uniform (though in some aspects more
"backward-compatible") experience.

> We've already had some back-and-forth about text grobs but not much
> else.

Text grobs might be somewhat special, admittedly.

The main problem we have right now is that most of our spacing is an
all-or-nothing game: it does not figure in _benefits_ of tighter
spacing like closing large white gaps separating _related_ items, or
fitting additional systems in, or maintaining consistent distance
between systems.  Basically one wants to typeset the score with
_really_ tight skyline-based spacing first, and then let it "relax"
into a state where skylines are increasingly padded as long as this
does not cause major gaps or other problems, so that the tight spacing
is retained only for those situations where it actually makes _sense_.

> I think it is a percentage game, more than anything else.  Meaning
> "what percent of users need to consider spacing too close before it
> is inappropriate as a default."  If 90% like the new spacing and 10%
> think it is too close,

You can't make bugs go away by a vote of confidence.  And that is a
red herring anyway since nobody suggested switching off the skyline
code.  It would not make sense to keep the associated code complexity
while switching the code off.

So what we need is not a vote.  What we need is as much feedback as we
can get about cases considered problematic, and we need to see whether
we can change defaults in a way where they cease being a problem, at
least to the degree where people will not bother fiddling with
overrides in order to get rid of them.

So we need feedback from the heavy hitters, and we have annoyingly few
of them I know about.  Kieren is one.  I don't know how many tweaks
there are in Valentin's opera, but that might be another opportunity.
You would be one, except that your kind of scores require oodles of
overrides and tweaks anyway so they escape your notice.  People
maintaining a large corpus of music would be relevant, but Mutopia is
close to dead regarding its feedback with us, and more active
score-maintaining sites like Scorio or Philomelos have not really
moved onto even the 2.16 train (at least regarding last year's news).
Other projects using LilyPond as backend might also be relevant:
Denemo comes to mind.

So we will likely want to make some huge announcements and use
artificial version numbers like 2.17.95 to get people's attention.

> Anyway, we'll know none of these things without consulting people
> making real scores.  I prefer all the spacing improvements in my
> scores so no complaints here.  But I'm willing to admit of course
> that I wouldn't have done any of this work unless there were some
> internal motivation stemming from my own aesthetic preferences.

And your scores are highly maintenance-intensive in a certain manner.
They are not likely to transfer well to newer versions of LilyPond,
anyway.  For our progression of stable releases, we want a score
without significant numbers of tweaks and overrides (sort of a
"stable" score) to render uniformly better than before.


https://codereview.appspot.com/8613043/