Re: Add changes entry for Mike's work on skylines. (issue 8613043)
2013/4/17 Keith OHara k-ohara5...@oco.net:
On Tue, 16 Apr 2013 04:10:32 -0700, Janek Warchoł janek.lilyp...@gmail.com
wrote:
2013/4/16 d...@gnu.org:
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.
Then let's un-tweak the defaults for Lyrics. Sure, some padding helped in
your Tota pulchra but it might result in wrong placement in other cases,
so we should remove it:
\new ChoirStaff
\new Lyrics = s
\new Staff = staff
\new Voice = s \transpose c c'' { \voiceOne d4 d }
\new Voice = a \transpose c c' { \voiceTwo d4 d }
\new Lyrics = s \with { alignAboveContext = staff }
\context Lyrics = s \lyricsto s { Ni }
\context Lyrics = a \lyricsto a { j lli }
\layout { \context {\Lyrics
\override VerticalAxisGroup #'nonstaff-relatedstaff-spacing = #'()
\override LyricText #'skyline-horizontal-padding = #0 }}
Well, that's indeed amazingly ugly example.
I apologize if my email sounded unfriedndly and/or disparaging. I
agree that we need sane defaults for skylines, and i admit that
there's room for improvement from the current state. I'll report any
problematic skyline case if i encounter one.
all the best,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#newcode153 Documentation/changes.tely:153: @item I would add a note that, if there is too-snug spacing for an object, setting its vertical skylines to #'() will generally restore old behavior. https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 06:05:42, MikeSol wrote: https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#newcode153 Documentation/changes.tely:153: @item I would add a note that, if there is too-snug spacing for an object, setting its vertical skylines to #'() will generally restore old behavior. I am not really enthused about telling people that, since too snug is a bug and needs to get fixed rather than worked around. We'll get a proliferation of LilyPond sources irretrievably tied into the bugs of particular versions if we tell people to work around bugs rather than report them. https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 07:20:59, dak wrote: On 2013/04/16 06:05:42, MikeSol wrote: I would add a note that, if there is too-snug spacing for an object, setting its vertical skylines to #'() will generally restore old behavior. I am not really enthused about telling people that, since too snug is a bug and needs to get fixed rather than worked around. We'll get a proliferation of LilyPond sources irretrievably tied into the bugs of particular versions if we tell people to work around bugs rather than report them. Indeed. That is why we do not document bugs or add workarounds to the documentation (with a few exceptions, usually when it is agreed a fix is most unlikely to materialise, e.g. the grace timing problem.) Bugs (and their workarounds) should be recorded in the Bug DB. Trevor https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 07:40:19, Trevor Daniels wrote: On 2013/04/16 07:20:59, dak wrote: On 2013/04/16 06:05:42, MikeSol wrote: I would add a note that, if there is too-snug spacing for an object, setting its vertical skylines to #'() will generally restore old behavior. I am not really enthused about telling people that, since too snug is a bug and needs to get fixed rather than worked around. We'll get a proliferation of LilyPond sources irretrievably tied into the bugs of particular versions if we tell people to work around bugs rather than report them. Indeed. That is why we do not document bugs or add workarounds to the documentation (with a few exceptions, usually when it is agreed a fix is most unlikely to materialise, e.g. the grace timing problem.) Bugs (and their workarounds) should be recorded in the Bug DB. 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. https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 07:51:46, dak wrote: 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. So for this particular case we'd need to add predefs like \vSkylinesOn and \vSkylinesOff, as the override to turn them on is not quite as straightforward as turning them off, IIRC. These would be easy to implement and document. https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 07:51:46, dak wrote: On 2013/04/16 07:40:19, Trevor Daniels wrote: On 2013/04/16 07:20:59, dak wrote: On 2013/04/16 06:05:42, MikeSol wrote: I would add a note that, if there is too-snug spacing for an object, setting its vertical skylines to #'() will generally restore old behavior. I am not really enthused about telling people that, since too snug is a bug and needs to get fixed rather than worked around. We'll get a proliferation of LilyPond sources irretrievably tied into the bugs of particular versions if we tell people to work around bugs rather than report them. Indeed. That is why we do not document bugs or add workarounds to the documentation (with a few exceptions, usually when it is agreed a fix is most unlikely to materialise, e.g. the grace timing problem.) Bugs (and their workarounds) should be recorded in the Bug DB. 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. 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. 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. https://codereview.appspot.com/8613043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
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/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 16 avr. 2013, at 12:59, d...@gnu.org wrote: 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. Didn't think of that...this is a better idea. We've already had some back-and-forth about text grobs but not much else. Text grobs might be somewhat special, admittedly. Agreed. The main problem we have right now is that most of our spacing is an all-or-nothing game: Agreed. 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_. Agreed, but now you're talking about padding being a spring instead of a number, which is a cool idea but LilyPond is wayy far away from that being possible. Vertical spacing is controlled by springs at a marco level in page-layout-problem but implementing this at a micro level would take probably someone working full time for a year. 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. We should hit up Jay: https://github.com/horndude77/open-scores. He'd have a good sense of this. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
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. For my pieces, I always try to avoid overrides and tweaks as much as possible. In case something doesn't look OK, I usually submit a bug report. IMHO, the very test for lilypond w.r.t. to spacing is piano music from the romantic era. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
2013/4/16 d...@gnu.org:
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 mts...@gmail.com:
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 d...@gnu.org:
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
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/8613043/diff/19001/Documentation/changes.tely#newcode160
Documentation/changes.tely:160: #(ly:set-option 'debug-skylines #t)
\override Score.MetronomeMark #'skyline-horizontal-padding = #0.2
\override Score.TextScript #'skyline-horizontal-padding = #0.2
\override Score.Script #'skyline-horizontal-padding = #0.2
%{ LyricText already had this padding. Other items need it, or old
people like me will need to turn-off skylines so we can read the scores.
Some other items have a version of this padding that has effect only
between the item and the staff contents, so I'll turn it off here to
just show the effect of one padding. %}
\override Score.TextScript #'outside-staff-horizontal-padding = #0
\override Score.MetronomeMark #'outside-staff-horizontal-padding = #0
https://codereview.appspot.com/8613043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 2013/04/16 11:11:03, janek wrote:
2013/4/16 d...@gnu.org:
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.
Wrong placement? Seriously? Can you give any articulation where
you'd get bad behavior for considering just its bounding box?
Most are rather compact anyway, and I don't see how we get an
advantage from being able to sink the dot of a tenuto into a bow
marking.
For inter-script spacing, skylines seem like the entirely wrong thing
to use. It is conceivable that you can avoid shifting some unrelated
accidental more than a minimum, but that's a harmless problem compared
to scripts creeping into one another.
In general, skylines are mostly nice for grouping _unrelated_
material. For several things of the _same_ kind, you usually don't
want to shift them into one another.
https://codereview.appspot.com/8613043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On 16 avr. 2013, at 22:12, d...@gnu.org wrote:
On 2013/04/16 11:11:03, janek wrote:
2013/4/16 d...@gnu.org:
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.
Wrong placement? Seriously? Can you give any articulation where
you'd get bad behavior for considering just its bounding box?
f4--.
In the bad old days, the staccato was spaced too far from the accent.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On Tue, 16 Apr 2013 12:15:23 -0700, m...@mikesolomon.org m...@mikesolomon.org
wrote:
On 16 avr. 2013, at 22:12, d...@gnu.org wrote:
Wrong placement? Seriously? Can you give any articulation where
you'd get bad behavior for considering just its bounding box?
f4--.
In the bad old days, the staccato was spaced too far from the accent.
{f'4--.
\once\override Script #'skyline-horizontal-padding = #0.2 %{ for a fiddler
withold eyes %}
f'4--.
\once\override Script #'vertical-skylines = #'() %{ just use boxes %}
f'4--. }
That is subtle. We do have individual properties for each type of script, in
scm/scripts.scm.
The downbow and similar could get skyline-horizontal-padding, leaving it zero for
the accent.
On the other hand, the special thing about accents is not that we want other scripts to
sidle up alongside, but rather that objects can come close to its straight lines and still
remain visually clear. More appropriate to reduce the individually-defined padding in for
accent in scripts.scm.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On Tue, 16 Apr 2013 04:10:32 -0700, Janek Warchoł janek.lilyp...@gmail.com
wrote:
2013/4/16 d...@gnu.org:
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.
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.
Then let's un-tweak the defaults for Lyrics. Sure, some padding helped in your
Tota pulchra but it might result in wrong placement in other cases, so we
should remove it:
\new ChoirStaff
\new Lyrics = s
\new Staff = staff
\new Voice = s \transpose c c'' { \voiceOne d4 d }
\new Voice = a \transpose c c' { \voiceTwo d4 d }
\new Lyrics = s \with { alignAboveContext = staff }
\context Lyrics = s \lyricsto s { Ni }
\context Lyrics = a \lyricsto a { j lli }
\layout { \context {\Lyrics
\override VerticalAxisGroup #'nonstaff-relatedstaff-spacing = #'()
\override LyricText #'skyline-horizontal-padding = #0 }}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
2013/4/13 Keith OHara k-ohara5...@oco.net: On Fri, 12 Apr 2013 03:24:46 -0700, janek.lilyp...@gmail.com wrote: actually, placement of d4-.\downbow looks like a bug to me. Its too similar to square fermata. All the more reason to include it in the changes announcement. We would not want this to surprise anyone. ok Another case where magnetic skylines would help. We have something very close with 'skyline-horizontal-padding'. Do you think that more people will use it if you change its name to 'skyline-magnetism' ? But horizontal padding is something quite different from magnetic skylines. (hmm, maybe i didn't explain it well enough?) Anyway, i think it would be great to do some work on implementing magnetic skylines (and other skyline improvements). I'd gladly help with that, but i'm pretty sure that i wouldn't be able to do this by myself - would you be interested in forming a small team to work on this, perhaps together with Mike? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
lgtm
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode156
Documentation/changes.tely:156: using an integral-like approach. This
generally results in more
What is an integral?
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode162
Documentation/changes.tely:162: c'4\f a4\f d\f( f)
d'4-.\downbow a4^r'venu... c \tempo T1 e
shows more of the affected grob types
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode178
Documentation/changes.tely:178: Affected grobs include
@code{Accidentals}, @code{Beams}, @code{Clefs},
What is a grob?
https://codereview.appspot.com/8613043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode156
Documentation/changes.tely:156: using an integral-like approach. This
generally results in more
On 2013/04/12 06:53:34, Keith wrote:
What is an integral?
Indeed, many users won't be familiar with this mathematical concept.
I wanted to give a hint about how things work without being too wordy
(i.e. that the objects' outlines are being approximated using simple
functions (https://en.wikipedia.org/wiki/Simple_function - i don't know
how to name it better... stair function??)).
Suggestions for better term?
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode162
Documentation/changes.tely:162: c'4\f a4\f d\f( f)
On 2013/04/12 06:53:34, Keith wrote:
d'4-.\downbow a4^r'venu... c \tempo T1 e
shows more of the affected grob types
good idea.
actually, placement of d4-.\downbow looks like a bug to me. Its too
similar to square fermata. Another case where magnetic skylines would
help.
https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode178
Documentation/changes.tely:178: Affected grobs include
@code{Accidentals}, @code{Beams}, @code{Clefs},
On 2013/04/12 06:53:34, Keith wrote:
What is a grob?
Done.
https://codereview.appspot.com/8613043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add changes entry for Mike's work on skylines. (issue 8613043)
On Fri, 12 Apr 2013 03:24:46 -0700, janek.lilyp...@gmail.com wrote: https://codereview.appspot.com/8613043/diff/5001/Documentation/changes.tely#newcode162 Documentation/changes.tely:162: c'4\f a4\f d\f( f) On 2013/04/12 06:53:34, Keith wrote: d'4-.\downbow a4^r'venu... c \tempo T1 e shows more of the affected grob types actually, placement of d4-.\downbow looks like a bug to me. Its too similar to square fermata. All the more reason to include it in the changes announcement. We would not want this to surprise anyone. Another case where magnetic skylines would help. We have something very close with 'skyline-horizontal-padding'. Do you think that more people will use it if you change its name to 'skyline-magnetism' ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
