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

[Janek Warchoł]

2013/4/16  <address@hidden>:
> 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.

This might be impossible.  For example to avoid this problem {
d''4-.\downbow } we'd have to turn off or significantly pad Scripts
skylines, and that will result in wrong placement in other cases.

> 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.

I don't agree.  Too loose spacing is 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.

I wouldn't publish a score which is too loose.  Please look at
https://github.com/janek-warchol/eja-mater-demonstration
and compare the output between 2.16 and 2.17.  2.16 output is not
publication quality, because systems aren't clearly separated; fixing
spacing by hand would be a nightmare.

> 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 _will_happen anyway.  With each and every big feature that
significantly improves something, loads of overrides from user scores
have to be deleted.  You cannot avoid that - we can only try to
minimize this, and with limited success.


2013/4/16  <address@hidden>:
> 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.  We've
> already had some back-and-forth about text grobs but not much else.
>
> 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, then it is important to do something like Trevor is
> talking about that gives them a way out.  However, if it is 50/50, then
> it's better to err on the side of conservative.

probably a good idea.

On behalf of me and Urs Liska i can say that we're using skylines for
our Fried project (100 pages of quite complicated piano music) and
we're very pleased with them.  In fact, we were using them before they
were even pushed to master (using a custom Lily build, which caused us
lots of trouble but i think it was worth it).


2013/4/16  <address@hidden>:
> 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.

maybe..

>> 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.

Indeed.  I've already suggested to use "area spacing" for that, and i
still think it would be a good way to go, but implementing it would
take considerable amount of time.

> 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_.

Area spacing.

>> 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.

Yes, but i'd rather say that things like improving spacing in {
d''4-.\downbow } is a feature request.  Or it means that skylines are
incomplete.  But it's not a bug - the code is doing what it's supposed
to do.  To fix that situation, one has to implement additional
features.

> 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.

I agree except for the fact that i already think its impossible to
tweak defaults to achieve this.

> 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.

ok, but i'm afraid that this way we won't release 2.18 in a few
months.  I may be wrong though.

>> 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://github.com/janek-warchol/eja-mater-demonstration
(you can checkout initial commits to get a completely override-free score).

best,
Janek