Re: Limit looping in Grob::common_refpoint (issue 4079) (issue 134600043 by e...@ticalc.org)
On 7 sept. 2014, at 09:20, d...@gnu.org wrote: > > I don't like it. The maximum range of a variable is an arbitrary value > and this "loop avoidance" will not do us much good on a 64-bit > architecture. > > If this is a real concern, we should be either using a tortoise/hare > algorithm here in order to bomb out on circular references. > > Or, much preferable, we should catch any such cases where the circular > reference is established. This can usually be triggered by including certain engravers twice (dynamic align, for example). I tried once to write an algorithm that detected circular dependencies before allowing parent relationships to be created but it slowed LilyPond down by around 3%. I'm not sure of a good general solution without taking a performance hit. Cheers, MS > This can only happen when an existing grob > already established as a parent of some other grob gets its parent > pointed to another existing grob. > > Since it is much too late by the time Grob::common_refpoint is called to > figure out the culprit in the circular refpoint chain, that's close to > useless for debugging. > > https://codereview.appspot.com/134600043/ > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in Lookup::bezier_sandwich
Sent from my iPhone
> On 30 août 2014, at 18:54, "Jürgen Reuter" wrote:
>
> Hi all,
> there is a bug in Lookup::bezier_sandwich that severely affects ancient
> notation. This method was originally added to lookup.cc for
> flexa/porrectus support.
>
> In version 2.14, the bezier_sandwich curve still looks correctly, see
> here:
> http://lilypond.org/doc/v2.14/Documentation/a9/lily-551aed0c.png
> or (with more context) here:
> http://lilypond.org/doc/v2.14/Documentation/notation/ancient-notation
>
> In version 2.15 and later, the bezier_sandwich curve has zero height at
> its right end, which is bad; see here:
> http://lilypond.org/doc/v2.15/Documentation/bf/lily-ac979051.png
> or (with more context) here:
> http://lilypond.org/doc/v2.15/Documentation/notation/ancient-notation
>
> I tried to track down the problem and found the following suspicious
> commit:
>
> commit 35725a573e47be7c02c51964641ea534fb88be6b
> Author: Mike Solomon
> Date: Mon Feb 6 15:03:20 2012 +0100
> Gets rid of bezier-sandwich stencil
> diff --git a/lily/lookup.cc b/lily/lookup.cc
> index 3f393e0..7b63b83 100644
> --- a/lily/lookup.cc
> +++ b/lily/lookup.cc
> @@ -449,22 +449,32 @@ Lookup::slur (Bezier curve, Real curvethick, Real
> linethick,
>Stencil
>Lookup::bezier_sandwich (Bezier top_curve, Bezier bottom_curve, Real
> thickness)
>{
> - /*
> -Need the weird order b.o. the way PS want its arguments
> - */
> - SCM list = SCM_EOL;
> - list = scm_cons (ly_offset2scm (bottom_curve.control_[3]), list);
> - list = scm_cons (ly_offset2scm (bottom_curve.control_[0]), list);
> - list = scm_cons (ly_offset2scm (bottom_curve.control_[1]), list);
> - list = scm_cons (ly_offset2scm (bottom_curve.control_[2]), list);
> - list = scm_cons (ly_offset2scm (top_curve.control_[0]), list);
> - list = scm_cons (ly_offset2scm (top_curve.control_[3]), list);
> - list = scm_cons (ly_offset2scm (top_curve.control_[2]), list);
> - list = scm_cons (ly_offset2scm (top_curve.control_[1]), list);
> -
> - SCM horizontal_bend = scm_list_n (ly_symbol2scm ("bezier-sandwich"),
> -ly_quote_scm (list),
> + SCM commands = scm_list_n (ly_symbol2scm ("moveto"),
> + scm_from_double
> (top_curve.control_[0][X_AXIS]),
> + scm_from_double
> (top_curve.control_[0][Y_AXIS]),
> + ly_symbol2scm ("curveto"),
> + scm_from_double
> (top_curve.control_[1][X_AXIS]),
> + scm_from_double
> (top_curve.control_[1][Y_AXIS]),
> + scm_from_double
> (top_curve.control_[2][X_AXIS]),
> + scm_from_double
> (top_curve.control_[2][Y_AXIS]),
> + scm_from_double
> (top_curve.control_[3][X_AXIS]),
> + scm_from_double
> (top_curve.control_[3][Y_AXIS]),
> + ly_symbol2scm ("curveto"),
> + scm_from_double
> (bottom_curve.control_[2][X_AXIS]),
> + scm_from_double
> (bottom_curve.control_[2][Y_AXIS]),
> + scm_from_double
> (bottom_curve.control_[1][X_AXIS]),
> + scm_from_double
> (bottom_curve.control_[1][Y_AXIS]),
> + scm_from_double
> (bottom_curve.control_[0][X_AXIS]),
> + scm_from_double
> (bottom_curve.control_[0][Y_AXIS]),
> + ly_symbol2scm ("closepath"),
> + SCM_UNDEFINED);
> +
> + SCM horizontal_bend = scm_list_n (ly_symbol2scm ("path"),
> scm_from_double (thickness),
> +ly_quote_scm (commands),
> +ly_quote_scm (ly_symbol2scm
> ("round")),
> +ly_quote_scm (ly_symbol2scm
> ("round")),
> +SCM_BOOL_T, SCM_UNDEFINED);
>
> Interval x_extent = top_curve.extent (X_AXIS);
>
> I do not fully understand the rationale / implications of this change,
> so I do really know what to do here without affecting other places in
> the code. By the way, ancient notation does not make use of the
> "thickness" argument; probably it has been introduced for some other
> use elsewhere.
>
> Could someone of the active developers look into this? That would be
> great!
>
> Thanks a lot,
> Juergen
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
I can have a look at it this week - thanks for pointing it out!
~Mike
___
lilypond-devel mailing list
li
Re: Adds dimension stencil command to correct with-dimension (issue 12957047)
Sent from my iPhone On 24 août 2013, at 12:47, pkx1...@gmail.com wrote: > On 2013/08/24 08:25:14, dak wrote: >> On 2013/08/24 08:05:13, mike7 wrote: >> > On 24 août 2013, at 10:18, mailto:lemzw...@googlemail.com wrote: >> > >> > > LGTM, except of using `surrogate' in the name. Given that the > stencil >> > > dimensions are actively overridden on request, I would like rather > like >> > > having `override'. For me, the word `surrogate' suggests > something >> > > passive. >> > > >> > > https://codereview.appspot.com/12957047/ >> > >> > The definition reads: > >> It doesn't matter what the definition reads. English has a live > vocabulary of >> over 15 words and there is no need to use all of them in > identifiers. We >> want our identifier names to be boring and following our own > terminology >> elsewhere as well as that of other programs. > >> If you pick a non-standard word with slightly different connotations, > people >> will think that the slightly different connotations are important, > rather than >> that this is just playing randomization games with a thesaurus. > > Having to send highly technical responses to non-native English speakers > daily as part of my job, I do get Werner's point. Surrogate isn;t > immediately obvious unless you have a wide vocabulary. I don't know what > this fix does, but could we use a word like 'alternate' or 'replace' or > 'proxy' (assuming it is a function/command that has to take a value, and > 'replace' it temporarily before it puts it back - see? I told you I > didn't know what this does), or perhaps 'stand-in' or 'backup'. > > We had a classically educated programmer once that used to produce > beautifully composed 'event' messages and errors, however it just caused > a lot of confusion to our non-English customers (even some American ones > ;) ) that we went 'boring' as David so succinctly put it. > > https://codereview.appspot.com/12957047/ The stencil command takes the skyline of stencil X and uses it as a replacement for skyline Y. We could use replacement-skyline-stencil as the command. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Cross-staff and skyline work
Hey all, Just a quick note to say that I'm eye-deep in work but I'm reading the LilyPond list every other day. I don't want anything related to my work to get bogged down by my absence. If you have specific questions about how something works (or doesn't), don't hesitate to send me an e-mail and I'll do my best to respond. I'll be back around the 28th. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids direction checking for cross-staff side-support-elements (issue 8557044)
On 24 avr. 2013, at 01:06, k-ohara5...@oco.net wrote: > lgtm > > Somewhere I'll have to write down the definition > "cross-staff": true for a grob whose placement or size could depend on > the spacing of staves on the page. It's not quite that. In the definition above, a treble clef on the 5th staff of a system is cross-staff because its placement depends on what is contained in the systems above. What will not change is its placement with respect to its staff. I like "Any grob that is not the element of a vertical axis group or whose relative extent with respect to the vertical axis group of which it is an element changes as a result of how far apart two or more vertical axis groups are." This opens up the definition to all vertical axis groups (i.e. Dynamics, ChordNames). But it is obviously too technical for a docstring. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds padding around extender of line-spanners. (issue 8819043)
On 20 avr. 2013, at 08:06, k-ohara5...@oco.net wrote: > > https://codereview.appspot.com/8819043/diff/5001/lily/line-spanner.cc > File lily/line-spanner.cc (right): > > https://codereview.appspot.com/8819043/diff/5001/lily/line-spanner.cc#newcode371 > lily/line-spanner.cc:371: // actual stencil bounds may be different > The actual stencil bounds are (inf , -inf) if someone sets style=none > When I try this on input/regression/dynamics-alignment-no-line.ly the > while loop in add_grobs_of_one_priority() takes forever. > > https://codereview.appspot.com/8819043/diff/5001/lily/line-spanner.cc#newcode377 > lily/line-spanner.cc:377: Real new_left_y = minmax (-d, extremity, > line_left[Y_AXIS] + d * skyline_spanner_padding); > The smaller of the extent of the cresc.--- and the line padded by > skyline_spanner_padding. Is that what you want? > Yeah, because we never want the padding going outside of the grob. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3325 in lilypond: Stems should not pass between the letters of a word
Current master off of lilydev Sent from my iPhone On 19 avr. 2013, at 19:55, lilyp...@googlecode.com wrote: > > Comment #3 on issue 3325 by k-ohara5...@oco.net: Stems should not pass > between the letters of a word > http://code.google.com/p/lilypond/issues/detail?id=3325 > > I need to match your fonts. What operating system and version do you want? > > -- > You received this message because this project is configured to send all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gives DynamicTextSpanner a default skyline-horizontal-padding (issue 8799045)
On 18 avr. 2013, at 10:51, k-ohara5...@oco.net wrote:
> I suggest that you set the defaults consistently for all text grobs, so
> that I don't have to file bug reports one-at-a-time for every possible
> case:
>
> \paper { indent = 0\mm
> line-width = 42.2\mm
> ragged-right = ##f }
> \score { << \new Staff { b1_\markup\huge"innocent" }
>\new Staff << { e''4 e''' r2 } \\ e'1 >> >> }
>
They're different beasts - we need to figure out what is the best value for
each one given its habitual size and content. Bigger grobs should get bigger
default values. I'd like to raise separate issues for different families. For
example, text spanner and dynamic next spanner make sense together in the same
patch with the same default vale, but not text script and metronome mark.
Cheers,
MS
> https://codereview.appspot.com/8799045/
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add callback factory grob::inherit-parent-property (issue 8726045)
On 17 avr. 2013, at 21:45, d...@gnu.org wrote: > Reviewers: MikeSol, > > Message: > On 2013/04/17 18:27:05, MikeSol wrote: >> Hey, I hadn't seen this. I just finished writing an equivalent patch. > Yours is >> better, so keep it. You can use this for the > inherit-X-parent-visibility and >> eliminate the inherit-Y-parent-visibility callback, which is cruft and > can be >> replaced with the X one. > > I did not actually replace anything because I was not sure of the intent > of the code matching the actual code. > > inherit-x-parent-visibility is used only once, so is > inherent-y-parent-visibility. > > Apart from the axis discrepancy, the only visible difference is that > inherit-x-parent-visibility has a default of all-invisible, while > inherit-y-parent-visibility has a default of '() and thus can > distinguish the default use, possibly substituting something else. I think the y callback should have never been added - you should use the x one instead. I tested out replacing the y with x and didn't see any visual changes, so it should be ok. I think the X parent of a FootnoteItem is the Y parent anyway. 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 16 avr. 2013, at 22:12, d...@gnu.org wrote:
> On 2013/04/16 11:11:03, janek wrote:
>> 2013/4/16 :
>> > 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 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: Woodwind diagrams (issue 1425041)
On 15 avr. 2013, at 15:38, d...@gnu.org wrote: > > https://codereview.appspot.com/1425041/diff/12001/ps/music-drawing-routines.ps > File ps/music-drawing-routines.ps (right): > > https://codereview.appspot.com/1425041/diff/12001/ps/music-drawing-routines.ps#newcode196 > ps/music-drawing-routines.ps:196: +% Note that filled is not boolean to > permit for different graylevels (ie for trill keys) > What's the reason for this falsehood? "filled" is quite obviously > boolean and used as such. You're right, this comment is wrong. Seems like filled is only being used for boolean. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)
On 12 avr. 2013, at 22:29, k-ohara5...@oco.net wrote: > > https://codereview.appspot.com/7310075/diff/67001/lily/skyline.cc > File lily/skyline.cc (right): > > https://codereview.appspot.com/7310075/diff/67001/lily/skyline.cc#newcode370 > lily/skyline.cc:370: if (x1 >= last_end) > Oops. This controls whether to put an empty, -inf height, building in > the gap. (When do we ever want Building data structures marking gaps? > The skyline concept seems to allow for gaps.) > > These zero-width anti-buildings would not have any effect, except that > they are drawn (issue 3311) but they are not the boxes that surprised us > when they disappeared (issue 3161). > > Probably safest to put back the x1 > last_end + EPS > > https://codereview.appspot.com/7310075/ Fair 'nuf. Can you write a patch? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Wanting to be involved in lilypond project again
On 10 avr. 2013, at 16:13, "Fan Ziye" wrote: > Dear list, > > Hi, I introduced myself to you several weeks ago – a fourth-year > undergraduate student of EECS wanting to be involved in lilypond’s > developing. And then Mike told me to read the CG. (Thank you very much!). > But sorry for my absence in recent time, I was busy with my graduate project. > Luckily my project is about to be finished now, so I want to come back and > find something I can do. > > I have just read through the CG and set up my developing environment ( > archlinux in a virtualbox, lily-git ). Is there any bug that would be > instructive to start with? Thanks! J > > Regards, > Fan Ziye > > April 10, 2013 > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel Hey Fan! Welcome to the club. We are gearing up for a stable release and there are lots of little things that can help with that. I don't have a good sense of what those things are but I know they exist. Perhaps someone else can chime in? Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 9 avr. 2013, at 20:31, k-ohara5...@oco.net wrote: > On 2013/03/26 04:10:38, mike7 wrote: >> >> On 25 mars 2013, at 07:10, mailto:k-ohara5...@oco.net wrote: >> >> >> >>> Please do just one manual review of the regression suite between >> >>> versions before adding another test of this length. >> >> >> I wanted to exhaust as many possibilities as I could think of (broken > slurs over >> one note, several notes, beginning broken, and broken, etc.) for both > slur and >> phrasing. Would it be better to split each system up into a separate > test? Get >> rid of some tests? > > We need exhaustive test files while debugging, but probably we should > reduce them to the essentials for the regtest that gets pushed. > > Issue 3307 was plain to see in the regtest > ‘rest-on-nonstandard-staff.ly’, but nobody succeeded in seeing the > problem. > Ok - feel free to chop this down however you see fit - I trust you. Cheers, MS > https://codereview.appspot.com/7424049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stable release state
On 6 avr. 2013, at 12:07, David Kastrup wrote: > > With the recent batch of material with missing documentation, extensive > code changes and new functionality without previous exposure and moving > interfaces (like > commit 88d306d9c5666b5ade4a136df29cca19c5ff5ed7 > Author: Mike Solomon > Date: Sat Apr 6 09:54:58 2013 +0200 > >Break slurs between alternative endings in repeats; issue 1698. > >Create new event-types BreakPhrasingSlurEvent BreakSlurEvent, >and a music-function \free so that users can create them. >Create these event-types in the volta-repeat-iterator to break >slurs between alternatives in a \repeat volta structure. > > ) it is clear that master has stopped being suitable for turning into a > stable branch. There are several ways forward, none of them > particularly endearing. Quick note to say that I'm fine reverting this if it gets in the way of stable release plans and waiting till a stable release comes out before this goes in. In this case, what would help on the countdown is to know what is patch push straightaway and what is patch push after the next stable release. Cheers, MS > > _ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)
On 3 avr. 2013, at 01:57, d...@gnu.org wrote: > On 2013/04/02 22:34:53, janek wrote: >> I'll risk joining the discussion. > >> I see valid points from both of you. I agree that it's better to fix > a broken >> design than to patch it with red tape. > > It isn't patched. minimum-length is used in multiple > contexts/interfaces, and Mike's patch muddies the situation further. > >> However, if we only accepted code changes that were implementing the >> Ultimate Solution, i'm afraid that the development process would >> grind to a halt - Ultimate Solutions are obvioulsly best, but they >> take much much more time to implement, and usually only experts can >> write them. > > That's the ultimate excuse to never bother about doing things right. > >> This should not be an excuse for broken code, but i think that we >> can accept patches that are iterations towards Ultimate Solution. > > This one is an iteration away from a proper solution since it > increases the inconsistency of minimum-length. > >> As i see it, Mike's patch doesn't make matters worse - it's just a >> piece of duct tape to make a temporary solution (i.e. current messy >> code) less broken. > > No, it makes it _more_ broken in order to paper over an annoying > consequence of the brokenness. > >> I think that we could add a FIXME to it and accept it, because it's >> not making future rewrite harder (at least it seems so to me). > > How does an increase in the inconsistency of minimum-length _not_ make > a future rewrite harder? > >> Also, we're trying to make a stable release soon, so this is not a >> good time to start rewriting big pieces of code. > > It is not a good time shoving in behavior that is not going to survive > into the next stable release (assuming that this _is_ going to be > fixed in a sensible manner) either. The behavior of our stable > releases should not be erratic but rather increasingly reliable. > > > https://codereview.appspot.com/7453046/ The callback for minimum length is broken. This patch fixes a broken callback that used to work in a previous version of LilyPond. You are objecting to the patch because you don't like the naming of the property that he callback is attached to. I think the benefits of fixing this issue (which is a regression and IMHO should be marked as critical) far outweighs the disadvantages of continuing to use the bad naming scheme, especially as said scheme is used here as it is everywhere else in the documentation. We can talk about how to better name things later, but that should not stop this regression from being fixed. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rewrite Self_alignment_interface (issue 7768043)
On 2 avr. 2013, at 00:51, janek.lilyp...@gmail.com wrote: > On Mon, Apr 1, 2013 at 1:20 PM, m...@mikesolomon.org > wrote: >> X-extent is used in many things other than self alignment positioning, >> so u don't want to change extents. Every positioning in LilyPond has >> some notion of padding save this interface. It would be a good > addition, >> but could easily be in a follow-up patch. > > Ok, i agree that some padding would be desirable. What worries me is > the multitude of paddings we have - they give me a headache; i quite > frankly am lost in their different meanings. As of now i'm unsure how > to implement such padding without making things more complicated, so i > suggest to wait until other design questions are answered. > >>> As for chain_offset_callback, i've tried it (see attached patch), >>> but i get a strange error: > >>> Processing `input/regression/add-stem-support.ly' >>> Parsing... >>> Interpreting music... >>> Preprocessing graphical objects...ERROR: >>> In procedure ly:self-alignment-interface::x-align-grob: >>> ERROR: Wrong number of arguments to >>> # > >>> quite frankly, i don't know what's wrong. >>> I've looked at other uses of chain_offset_callback >>> and it seems that i've written my code correctly. > >> I'll look into it when I get home. > > did you have any sucess with this stuff? > Try making the function accept a second optional argument with a previous offset (check out the offset functions in side position interface) Cheers, MS > thanks, > janek > > https://codereview.appspot.com/7768043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rewrite Self_alignment_interface (issue 7768043)
On 1 avr. 2013, at 14:13, Janek Warchoł wrote: > Hi all, > > On Mon, Apr 1, 2013 at 7:52 AM, wrote: >> I'd recommend adding a sort of padding property to the >> self-alignment-interface to get it completely there. >> That is, imagine that we right align to a grob and we want >> to be padded by 0.1 We should be able to do that. >> That'd allow self-alignment-interface to be used >> for grobs like InstrumentName. > > I think that this should be done by manipulating extents: > if i want an InstrumentName to be "horizontally-aligned- > with-padding", i add desired padding value to its X-extent, > and voilà! LilyPond thinks that InstrumentName is slightly bigger, > aligns it as if it was slightly bigger, and thus it ends up padded. > What do you think? X-extent is used in many things other than self alignment positioning, so u don't want to change extents. Every positioning in LilyPond has some notion of padding save this interface. It would be a good addition, but could easily be in a follow-up patch. > > As for chain_offset_callback, i've tried it (see attached patch), but > i get a strange error: > > Processing `input/regression/add-stem-support.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects...ERROR: > In procedure ly:self-alignment-interface::x-align-grob: > ERROR: Wrong number of arguments to > # > > quite frankly, i don't know what's wrong. > I've looked at other uses of chain_offset_callback > and it seems that i've written my code correctly. > I'll look into it when I get home. > PS i'll look into Ambitus extent later - right now i'm getting some > unexpected regressions after doing some additional modifications. > <0001-use-chain-offsets-instead-of-setting-properties.patch> ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
instrument name patch reverted
Hey all, I reverted the instrument name patch in staging. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows outside staff positioning for vertical axis groups with no staff (issue 8188044)
On 30 mars 2013, at 10:29, k-ohara5...@oco.net wrote: > Simpler to just reverse the "special X-alignment" commit. > > The old code, that followed the comment about a 'kldge' whatever that > means, was rather elegant. If we are placing something alongside an > empty set, place it against the reference point for that set. Having a > special case for StanzaNumbers and another special case for empty > VerticalAxisGroups gets messy. > > https://codereview.appspot.com/8188044/ Fair enough, revert and I'll add a comment. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows outside staff positioning for vertical axis groups with no staff (issue 8188044)
On 30 mars 2013, at 08:33, k-ohara5...@oco.net wrote:
> Why not use the flat-line for empty VerticalAxisGroups specifically in
> side-position-interface.cc when placing something against the staff (in
> the clause if (include_staff) {} ) ?
include_staff is false for VerticalAxisGroups without staves because there is
no staff grob.
>
> If you make each empty VerticalAxisGroup into a line, wouldn't that
> prevent interleaving beteen left- and right-hand piano staves, if there
> is a Dynamics in between that happens to be empty ?
This wouldn't happen (at least I don't think it would after a quick test) -
vertical axis group spacing is controlled in page-layout-problem.cc and doesn't
use the same mechanisms.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 3256 in lilypond: Patch: Eliminates side poisition calculations for system-start-text grobs.
On 30 mars 2013, at 08:27, lilyp...@googlecode.com wrote: > Updates: > Labels: -Patch-push > > Comment #8 on issue 3256 by d...@gnu.org: Patch: Eliminates side poisition > calculations for system-start-text grobs. > http://code.google.com/p/lilypond/issues/detail?id=3256 > > This patch has broken incipits, like in input/regression/incipit.ly. Its > commit message is _totally_ different from the issue description or the > Rietveld issue description. It does not contain the issue number either. > You have not marked the issue as fixed, and the commit id is not to be found > anywhere. > > In consequence, it is not possible to track the commit to this particular > issue and review. It is not the first time, either. Please keep the commit > messages and the issue and review descriptions the same and mark the issues > as fixed _including_ the commit id _right_ _after_ _pushing_. > > The commit in question is > commit 6e4e69f2735a764eab2e6f70f83546461da0203b > Author: Mike Solomon > Date: Fri Mar 29 05:55:13 2013 +0100 > >Uses special X alignment for instrument names. > >Previously, instrument names used the side-position-interface for >calculations in its alignment function. This made no sense, as it never >had any side-support elements, requiring a kludge to get them to >align properly. > >Here, we remove that kludge and align them by aligning them to their >right end and adding padding. We also change the name of the grob array >in which vertical axis groups are stored to >system-start-text-align-elements so that the grob is not accidentally >treated as an axis-group implementing an elements array. > > I propose reverting it since using the instrumentName for prefatory material > is documented and previously working behavior and it is not clear what this > will break in addition to incipits. So it is not really fit to be included > in a stable release at this point of time. > It is not clear what this patch does and doesn't break until people use it. Unfortunately, the regtest checker does not pick up on certain differences, so it is important for users testing the software to signal these. I fix them right away. You are absolutely right that it is not clear what this will break in addition to incipits, but I'd rather deal with that as it crops up as it is impossible to know given our current regtest checking suite. With Phil's pixel comparator this sort of problem will go away, but that'd need to get integrated into the build system. Fixes are quick, so I just need to know the problem. I can then fix it ASAP. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More regtest differences
On 30 mars 2013, at 07:08, m...@mikesolomon.org wrote:
> On 30 mars 2013, at 06:42, Keith OHara wrote:
>
>> Phil Holmes philholmes.net> writes:
>>
>>> The second is the substantial change in the Les Nereides system
>>> spacing. Deliberate?
>>
>> The second change is from the commit immediately before yours,
>> "Uses special X alignment for instrument names."
>>
>> Text in a Dynamics line now has its baseline on the reference line of the
>> Dynamics. This means it will collide with tempo marks (as in issue 3241)
>> or with text if someone puts text both above and below a Dynamics
>> \new Dynamics {s_"bb"^"gg"}
>>
>> Janek was just asking if issue 3241 would appear elsewhere.
>>
>> "Les Néréides" looks better with the change (and there has a commented
>> override that would have done much the same!) but I will recommend that
>> Mike change this detail back, so that below-Dynamics things remain below
>> the Dynamics reference line.
>>
>
> Ah, OK, you answered my question. On it.
>
> Cheers,
> MS
Patch posted as issue 3278 on the tracker.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More regtest differences
On 30 mars 2013, at 06:42, Keith OHara wrote:
> Phil Holmes philholmes.net> writes:
>
>> The second is the substantial change in the Les Nereides system
>> spacing. Deliberate?
>
> The second change is from the commit immediately before yours,
> "Uses special X alignment for instrument names."
>
> Text in a Dynamics line now has its baseline on the reference line of the
> Dynamics. This means it will collide with tempo marks (as in issue 3241)
> or with text if someone puts text both above and below a Dynamics
> \new Dynamics {s_"bb"^"gg"}
>
> Janek was just asking if issue 3241 would appear elsewhere.
>
> "Les Néréides" looks better with the change (and there has a commented
> override that would have done much the same!) but I will recommend that
> Mike change this detail back, so that below-Dynamics things remain below
> the Dynamics reference line.
>
Ah, OK, you answered my question. On it.
Cheers,
MS
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Removes outside-staff-priority from dynamic-related objects in Dynamic context (issue 7655045)
> 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More regtest differences
On 29 mars 2013, at 20:36, Janek Warchoł wrote: > On Fri, Mar 29, 2013 at 7:04 PM, Phil Holmes wrote: >> - Original Message - From: "Janek Warchoł" >> >> >>> On Fri, Mar 29, 2013 at 5:48 PM, Phil Holmes wrote: it seems that all system start braces have been pushed a little bit further from the initial system clef. >>> >>> Isn't this a rounding error introduced when converting postsript to >>> raster image? I tried compiling this regtest with these two commits >>> and the resulting pdfs were the same. >> >> Don't reckon so. I've now taken PDFs from Lilypond built from master and >> from my earlier commit, and they're different - master has moved the system >> start bar, such that the barlines protrude over it. See attached images, >> created by rasterizing the PDFs at 1200 dpi and then downsizing them. > > Indeed, you're right. My master wasn't up to date - my bad. > The faulty commit is either 6e4e69f2735a764eab2e6f70f83546461da0203b > or 8a35d5d2e856fa07c42c626ae7966c69dde61fdb (both from Mike). > > best, > Janek Created tracker issue 3277 to fix that. The problem is that there are some grobs that position themselves on an empty set of grobs. 8a35d5d2e856fa07c42c626ae7966c69dde61fdb ends this practice, but there are some residual grobs whose functioning were built on this behavior like StanzaNumbers. I created a function to deal with this case. Apparently SystemStartBars are the same, but as they don't show up in regtests this can't be seen. So, I just used the StanzaNumber function for SystemStartBars (renaming the function to make it more general) and it works like a charm. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More regtest differences
On 29 mars 2013, at 18:48, Phil Holmes wrote: > I've been comparing the result of my push of my pixel-based regtest > comparator (b4fe233aec83383bd2e6b6170fca67a31a8c492d) with current master > (6e4e69f2735a764eab2e6f70f83546461da0203b). There are 2 changes that concern > me. The first is that it seems that all system start braces have been pushed > a little bit further from the initial system clef. You can see that if you > blink between the 2 attached accidental-piano images. Is this deliberate? No, but I am positive that this is my work. I'll have a look at it. > The second is the substantial change in the Les Nereides system spacing. > Deliberate? > Also my work, but deliberate this time - my continual work on skylines makes everything more snug. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown - for March 26th 19:00GMT
On 23 mars 2013, at 13:59, James wrote: > Hello, > > Countdown – March 26th 2013 – 19:00 GMT > > > > > > > > > 3134 Enhancement Mike SolomonPushPatch: Removes the > translate_axis call from axis-group-interface outside-staff positioning. > > > > > > > James > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel Hey all, I'm holding off on this until 2.18 comes out, unless it becomes evident that 2.18 is far away. But it seems like it is imminent, as the general consensus is that the remaining critical issues are no longer critical (as they are no longer release blocking). Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: critical issues
On 27 mars 2013, at 07:54, Werner LEMBERG wrote: > >> https://code.google.com/p/lilypond/issues/detail?id=2656 >> >> This is really bad. I agree that it is critical. I unfortunately >> have no way to test this, but do people have an ETA for fixing this? >> If not, it will hold 2.18 up for a long time, in which it may be >> worth pushing the translate_axis patch that I've been holding in the >> works. > > As can be seen in comment #26, Behdad is willing to help, but a > LilyPond developer (or power user) using a Windows box must step > forward, using a current version of Pango (and probably Harfbuzz) to > test the issue. The results should then be added to GUB. > Someone who "knows what they're doing" (tm) needs to head up the effort and send an e-mail to the LilyPond user list recruiting 2-3 power users. A 1-2 hour Skype session should be all that is needed for the data gathering. I'm in wedding mode for the next 3-4 weeks, so that's a no go for me :-( Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
critical issues
There are two critical issues that we're going to have to start seriously thinking about now if 2.18 is going to happen anytime soon: https://code.google.com/p/lilypond/issues/detail?id=2733 I'm not comfortable marking this critical: not because it is not critical for Laura, nor because it may not be our fault, but because there is not enough information to know where the problem comes from. I have no problem on my homebrewed installation of LilyPond running LilyPond book. I think that it is important to work with a user who is having a problem like this, especially if the user is active in soliciting developer help, but let's only mark it critical if it is somehow a generalized problem (i.e. for all users running a given OS). What do you think? https://code.google.com/p/lilypond/issues/detail?id=2656 This is really bad. I agree that it is critical. I unfortunately have no way to test this, but do people have an ETA for fixing this? If not, it will hold 2.18 up for a long time, in which it may be worth pushing the translate_axis patch that I've been holding in the works. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Suggestions for participating institutions?
On 26 mars 2013, at 10:52, David Kastrup wrote: > > Hi, > > I met a former colleague in the bus to Chemnitz, and he is at least > knowledgeable about EU research programmes. Do people here have ideas > about possible institutions who could be made to participate? I think > the conditions are institutions from at least three EU countries, and > monetary participation of at least 25%. So we need some institution > with a reasonable interest of its own to get to some LilyPond-related > goals. > > Objective ICT-2013.8.2 Technology-enhanced learning > > Target Outcomes > Research under this objective targets tailored, scaled and tested R&D > for stimulating the take-up of learning technologies in different > learning contexts, reinforces the evidence-base of effectiveness of > learning technologies and encourages their innovative use. > > a) ICT-enabled learning environments: joint pre-commercial procurement > (PCP) of innovative solutions for teaching national curricular topic(s) > in primary and/or secondary education, based on latest advances in > pedagogical, cognitive and other relevant scientific disciplines. > > These solutions should: > • combine, and operate across different digital media and devices and > stretch the boundaries of place, time, type and styles of active > learning in the digital age; > • include rich and intuitive interfaces for teachers and students and > simulations and representations for teaching, learning and communicating > about the topic; > • adapt to different teaching practices and learning methods (e.g. > collaborative, inquiry-based and personalised learning and 1:1 tutoring) > and provide efficient support for the teacher in planning, monitoring, > assessment and in the management of classroom activities. > > The participatory design of the systems should involve all key > stakeholders in the value chain, e.g. public authorities, researchers, > developers and end-users, through iterative processes and take into > account contextual variables that affect learning in particular contexts > (e.g. local, regional and/or national situations, learner and teacher > profiles, types and styles of learning). The proposed solutions should > aim for wide adoption at local, regional or national level and their > relevance and effectiveness for learning should be demonstrated by > appropriate evaluation methods and benchmarking. > > PCPs shall be implemented according to the conditions outlined in > objective 11.1 and Appendix 6 and cover the full PCP life-cycle > encompassing solution design, prototyping, and original development of a > limited volume of products/services in the form of a validated test > series. They should seek to contribute to standards in digital > educational solutions. > > ... > > Expected Impact > • Broaden use of ICT in education in at least one curricular topic > leading to wider take up by end-users; > • Effective public-private partnerships for providing digital learning > solutions in Europe; > • Stronger growth of the European ICT-enabled learning markets; > • More efficient use of ICT for learning through the exploitation of > learning analytics tools; > • More timely and effective acquisition of skills/competences through > learning technologies, in public administrations, indicated a.o. through > % of decrease in time to proven competency and in time to carry out the > tasks, and % of savings in study time; > • Increased awareness on the benefit of the adoption of learning > technologies. > > Funding Schemes > a) CP-CSA, b) STREP, CSA, c) IP/STREP d) CSA (CA only). > Indicative budget distribution > > CP-CSA, IP/STREP: EUR 22 million, of which a minimum of 25% allocated to > CP-CSA (max 25% for the CSA part), a minimum of 40% to IPs and 30% to > STREPs; > > For outcome b) : 1-2 STREPS to be funded > CSA: EUR 3 million > > Call: > FP7-ICT-2013-11 > This is the exact sorta thing I've been looking for. I work with a group in France that'd be perfect for this (the Grame) - I'll ask them. I also have some contacts to the Sibelius Academy in Finland... Will keep you posted. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 26 mars 2013, at 05:58, "Keith OHara" wrote: > On Mon, 25 Mar 2013 00:29:35 -0700, m...@mikesolomon.org > wrote: > >> On 25 mars 2013, at 07:10, k-ohara5...@oco.net wrote: >> >>> It looks like you try to use a common UP/DOWN direction for the portions >>> of a broken slur, and the image you posted to the bug-tracker showed a >>> common direction for each half of a broken slur, but the current patch >>> gives me inconsistent directions (in every case but especially line 3). >> >> I only use a common UP/DOWN if it is set by the user beforehand. Otherwise, >> it is calculated with the usual callbacks. > > I see. I thought you were using the same machinery that breaks slurs at > line-breaks, which uses a common direction between halves. I see now that > you are breaking earlier, at 'engraving', before all the notes under a slur > are engraved, thus befor the slur directions are determined. Shucks. I can look into this. > >>> Please do just one manual review of the regression suite between >>> versions before adding another test of this length. >> >> What do you mean here? > > You'll see a large number of very small regression tests, and a few huge very > repetitive tests. You might think the huge repetitive tests get in the way > of review. > I wanted to exhaust as many possibilities as I could think of (broken slurs over one note, several notes, beginning broken, and broken, etc.) for both slur and phrasing. Would it be better to split each system up into a separate test? Get rid of some tests? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 25 mars 2013, at 07:10, k-ohara5...@oco.net wrote: > Thanks for taking the time to do this. No-one else knows enough of the > various stages of processing to bring all the pieces together. > > It looks like you try to use a common UP/DOWN direction for the portions > of a broken slur, and the image you posted to the bug-tracker showed a > common direction for each half of a broken slur, but the current patch > gives me inconsistent directions (in every case but especially line 3). > I only use a common UP/DOWN if it is set by the user beforehand. Otherwise, it is calculated with the usual callbacks. > >> After some consideration, I consider the name \broken >> suboptimal since it implies two pieces. > > Conceptually, of course, there *are* two pieces. The other piece is > probably at the other end of the repeat. The automatic behavior is quite > good, so fortunately we will rarely need to look up whatever name the > committee approves for the command to make a broken slur. > It'd be a shame for this to get stuck in the pipes because we can't figure out a good name. I am indifferent and I don't mind \broken or whatever really. > > https://codereview.appspot.com/7424049/diff/65002/input/regression/repeat-slur.ly > File input/regression/repeat-slur.ly (right): > > https://codereview.appspot.com/7424049/diff/65002/input/regression/repeat-slur.ly#newcode2 > input/regression/repeat-slur.ly:2: > Please do just one manual review of the regression suite between > versions before adding another test of this length. > What do you mean here? Thanks for the review! Cheers, MS > https://codereview.appspot.com/7424049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snaps horizontally-offset fingerings to vertical column. (issue 7988043)
On 25 mars 2013, at 06:42, k-ohara5...@oco.net wrote: > Code looks good, but we could get the same result with > \override Accidental #'horizontal-skylines = #'() > > Conceptually, I'm a fan of the snapping idea, but you're right that it takes more time. Would this \override fix all problems of a lack of "snapping"? Would it force accidentals to be that should be staggered? If your idea gives a satisfactory result, we can go with that and keep my patch around in case one day we need something more fine-tuned. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminates side poisition calculations for system-start-text grobs. (issue 7574048)
On 24 mars 2013, at 14:59, d...@gnu.org wrote:
>
> https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly
> File input/regression/instrument-name-x-align.ly (right):
>
> https://codereview.appspot.com/7574048/diff/5001/input/regression/instrument-name-x-align.ly#newcode33
> input/regression/instrument-name-x-align.ly:33: \set Staff .
> instrumentName = \markup \right-column {
> Make no mistake: the previous code looked suspiciously asymmetric. Is
> your change a cosmetic one, or is it related to other strange behaviors
> like the \left-column/\column mismatch we had noticed elsewhere?
>
> https://codereview.appspot.com/7574048/
The latter - I noticed it clashed and have run into problems with right column
in the past and decided to get rid of it.
I can put it in a different commit before pushing this one.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fingering not aligned in 2.17, ok in 2.16
On 22 mars 2013, at 18:32, SoundsFromSound wrote:
> Hmm..I kind of like the new behavior too, it's easier on my eyes. I like how
> it staggers to flow with the score, but I can see why some would want strict
> lined-up fingerings as well.
>
> Just my 2 cents.
>
> Ben
>
>
> Werner LEMBERG wrote
>>> See below. In 2.16.2, the fingering indications are vertically
>>> aligned. In 2.17.14, they aren't.
>>>
>>> \relative f'' {
>>> \set fingeringOrientations = #'(left)
>>>
>>
>> 4
>>> }
>>
>> Do you consider this a bug? Actually, I like the new behaviour
>> better. What does the literature say?
>>
>>
>>Werner
>>
>> ___
>> lilypond-user mailing list
>
>> lilypond-user@
>
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
Ugh, my LilyPond development is going to screech to a halt now (too much work)
but I have the solution sketched out in my head. If someone wants to tackle it
in C++ lemme know and I can give them the blueprint I have.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
git-cl TransientError
Hey all, I'm getting: Unhandled exception. [TransientError] from git-cl. Any ideas as to what that's all about? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
(almost-)freezing current master
Hey all, To prepare for 2.18, I think we can get it out fastish, but we need to more or less freeze current master aside from bug fixes and documentation. I have a lot of stuff on the countdown or on patch push that I'm not gonna push for a few months until we get 2.18 out (Ferneyhough hairpins, repeat slurs, etc.). Is everyone comfortable adopting a similar policy? David has suggested 2-months as a possible time frame, which I think is possible (there are no egregious, unfixable bugs). I can hold off this long on pushing big patches. Any longer and it starts to become tedious w/ rebasing and further work and whatnot, so I am way-for an almost-freeze of current master. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 09:26, Trevor Daniels wrote: > > m...@mikesolomon.org > >> I completely agree. It's just that "fake" in English means false or >> counterfeit. It needs another word, just don't know what yet. unchained? >> free? > > At the risk of prolonging the bike-shedding, here's my take. For me, the key > consideration is to provide an easily remembered name that can be internally > vocalised as the slur is typed in. And we need a user-centric (not > developer-centric) word - what is the user's conception of such a slur? Also > we need an attribute of the end point of the slur, not the slur as a whole, > since it is to be applied to an end point. The word should fit comfortably > as an adjective in the phrase "xxx slur start/end" as "free slur end" to aid > vocalisation. > > I'm not keen on \broken or \fake; they have other incorrect and unhelpful > connotations. \detached or \free are better. Others might be \floating, > \hanging, \loose, \dangling, although these are a bit long. Of all the > suggestions so far I prefer \free. > > Trevor If we're not going to refer to unfinished bridges in Scotland (tear), I like \free and \loose. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 18:25, "m...@mikesolomon.org" wrote:
> Sent from my iPhone
>
> On 20 mars 2013, at 16:38, David Kastrup wrote:
>
>> Werner LEMBERG writes:
>>
>>>> I think any further proposals should _definitely_ explain how to write
>>>> the given example
>>>>
>>>> g f e d(
>>>> \repeat { c d) e f ( }
>>>> \alternatives {
>>>> { g) a b( a \fake) }
>>>> { \fake( e) d c( d \fake) }
>>>> { \fake( d) c d( e }
>>>> }
>>>> d c) d c
>>>
>>> Hmm. It's not clear to me why lilypond can't handle this
>>> automatically:
>>>
>>> g f e d(
>>> \repeat { c d) e f( }
>>> \alternatives {
>>> { g) a b( a }
>>> { e) d c( d }
>>> { d) c d( e }
>>> }
>>> d c) d c
>>
>> The example actually is a bit too orthogonal to illustrate all pertinent
>> points. Here are some variations:
>>
>> g f e d( \fake)
>> \repeat { \fake( c d) e f ( }
>> [...]
>>
>> Now the first slur will _not_ lead into the repeat unbroken, a valid
>> variation.
>>
>> g f e d( \fake)
>> \repeat { \fake\single\slurDotted( c d) e f
>> [...]
>>
>> This is typical for lyrics where there is a melisma leading into the
>> first repeat but not into all subsequent ones. If there is no melisma
>> into the first repeat but in some alternative, you'd write instead
>>
>> g f e d
>> \repeat { \fake\single\slurDotted( c d) e f }
>> [...]
>>
>> Now since \unfoldRepeats would remove all \fake slurs, the result would
>> be fine here. The opposite case, where a repeat leads into only some
>> alternatives, would be
>>
>> \repeat { c d e f\single\slurDotted( \fake) }
>>
>> which works less well. One possible way around that would be to combine
>> tweaks from start and end slur events, leading to
>>
>> \repeat { c d e f( \fake\single\slurDotted) }
>>
>> which is still not good enough for unfolding unless one starts slur-less
>> alternatives with something like \fake( d\single\omit). Which would not
>> work for audio so for that case we probably really need an explicit slur
>> killing command.
>>
>>
>> Here is another example:
>>
>> g f e d(
>> \repeat { c d) e f }
>> \alternatives {
>> { g a b( a \fake) }
>> { e d c( d \fake) }
>> { d c d e }
>> }
>> d c d c
>>
>> The suggested automatism would turn this into
>>
>> g f e d(
>> \repeat { c d) e f }
>> \alternatives {
>> { g a b( a }
>> { e d c( d }
>> { d c d e }
>> }
>> d c d c
>>
>> which makes for a lot of visually unpaired opening parens in the source
>> code. Mind you: this is pretty much what I have asked for myself. I
>> just have my doubts that an automatism for some cases will not make it
>> harder for other cases and will leave the music source in a less
>> convincing state.
>>
>> I have to admit that leaving _all_ automatism aside does not seem
>> warranted: I can think of no case where inconsistent slur orientation
>> across visual jumps would be desirable.
>>
>>> It seems that I've *completely* misunderstood the syntax we were
>>> talking about, so thanks for this detailed example. However, I still
>>> don't like \fake. Looking at your syntax about, the corresponding TeX
>>> name would be \phantom which I do now suggest.
>>
>> Well, TeX uses \phantom for something which has dimensions but no visual
>> appearance, whereas we would use it for something which has visual
>> appearance (before unfolding) but no sound.
>>
>> But TeX is separate enough from LilyPond that I actually like \phantom
>> rather well for this purpose.
>
> Anything like phantom, fake and co doesn't sit right in English. Granted, the
> majority of LilyPond users are non-native speakers, so this probably doesn't
> make have the same impact. But, given that English is the language of
> lilypond, I think it's important to pay heed to the underlying sense of
> words. 'faux' in French, which means fake, would feel more suitable here, as
> it also means false and can apply to real things. But LilyPond is not in
> French.
>
> Some other English ideas:
>
> unhinged
> unbridled
> unanchored
> loose
> split
> chopped
> frayed
>
> Cheers,
> MS
Even better, how about:
\anderston
The Anderston pedestrian bridge is a real life example of what we're talking
about.
http://en.m.wikipedia.org/wiki/M8_Bridge_to_Nowhere#section_3
I'm totally for this - it would be fantastic if people called these things
"Anderston slurs" or "Anderston beams."
Why not be poetic? There are plenty of musical terms that use
metaphors/allusions.
So that's my new vote...
Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
Sent from my iPhone
On 20 mars 2013, at 16:38, David Kastrup wrote:
> Werner LEMBERG writes:
>
>>> I think any further proposals should _definitely_ explain how to write
>>> the given example
>>>
>>> g f e d(
>>> \repeat { c d) e f ( }
>>> \alternatives {
>>> { g) a b( a \fake) }
>>> { \fake( e) d c( d \fake) }
>>> { \fake( d) c d( e }
>>> }
>>> d c) d c
>>
>> Hmm. It's not clear to me why lilypond can't handle this
>> automatically:
>>
>> g f e d(
>> \repeat { c d) e f( }
>> \alternatives {
>>{ g) a b( a }
>>{ e) d c( d }
>>{ d) c d( e }
>> }
>> d c) d c
>
> The example actually is a bit too orthogonal to illustrate all pertinent
> points. Here are some variations:
>
> g f e d( \fake)
> \repeat { \fake( c d) e f ( }
> [...]
>
> Now the first slur will _not_ lead into the repeat unbroken, a valid
> variation.
>
> g f e d( \fake)
> \repeat { \fake\single\slurDotted( c d) e f
> [...]
>
> This is typical for lyrics where there is a melisma leading into the
> first repeat but not into all subsequent ones. If there is no melisma
> into the first repeat but in some alternative, you'd write instead
>
> g f e d
> \repeat { \fake\single\slurDotted( c d) e f }
> [...]
>
> Now since \unfoldRepeats would remove all \fake slurs, the result would
> be fine here. The opposite case, where a repeat leads into only some
> alternatives, would be
>
> \repeat { c d e f\single\slurDotted( \fake) }
>
> which works less well. One possible way around that would be to combine
> tweaks from start and end slur events, leading to
>
> \repeat { c d e f( \fake\single\slurDotted) }
>
> which is still not good enough for unfolding unless one starts slur-less
> alternatives with something like \fake( d\single\omit). Which would not
> work for audio so for that case we probably really need an explicit slur
> killing command.
>
>
> Here is another example:
>
> g f e d(
> \repeat { c d) e f }
> \alternatives {
> { g a b( a \fake) }
> { e d c( d \fake) }
> { d c d e }
> }
> d c d c
>
> The suggested automatism would turn this into
>
> g f e d(
> \repeat { c d) e f }
> \alternatives {
> { g a b( a }
> { e d c( d }
> { d c d e }
> }
> d c d c
>
> which makes for a lot of visually unpaired opening parens in the source
> code. Mind you: this is pretty much what I have asked for myself. I
> just have my doubts that an automatism for some cases will not make it
> harder for other cases and will leave the music source in a less
> convincing state.
>
> I have to admit that leaving _all_ automatism aside does not seem
> warranted: I can think of no case where inconsistent slur orientation
> across visual jumps would be desirable.
>
>> It seems that I've *completely* misunderstood the syntax we were
>> talking about, so thanks for this detailed example. However, I still
>> don't like \fake. Looking at your syntax about, the corresponding TeX
>> name would be \phantom which I do now suggest.
>
> Well, TeX uses \phantom for something which has dimensions but no visual
> appearance, whereas we would use it for something which has visual
> appearance (before unfolding) but no sound.
>
> But TeX is separate enough from LilyPond that I actually like \phantom
> rather well for this purpose.
>
Anything like phantom, fake and co doesn't sit right in English. Granted, the
majority of LilyPond users are non-native speakers, so this probably doesn't
make have the same impact. But, given that English is the language of lilypond,
I think it's important to pay heed to the underlying sense of words. 'faux' in
French, which means fake, would feel more suitable here, as it also means false
and can apply to real things. But LilyPond is not in French.
Some other English ideas:
unhinged
unbridled
unanchored
loose
split
chopped
frayed
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 14:26, d...@gnu.org wrote: > Yet another possibility would be \inner but that implies a hierarchy. > More accurate would be \continued. > > https://codereview.appspot.com/7424049/ I like \interrupted Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 14:52, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> On 20 mars 2013, at 14:26, d...@gnu.org wrote: >> >>> Yet another possibility would be \inner but that implies a hierarchy. >>> More accurate would be \continued. >>> >>> https://codereview.appspot.com/7424049/ >> >> I like \interrupted > > I considered that but self-censored because it leads to the visual > pairings ( ... \interrupted) and \interrupted( ... ). > > That is, \interrupted) talks about ) being interrupted when ) has not > yet been seen. For \interrupted( the naming choice works better. I'd > prefer it if we found a word that makes good sense in both > places/directions, saving the user from dealing with a naming > redundancy. > I don't completely follow what you're saying above - could you say it another way? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 07:50, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> On 20 mars 2013, at 06:07, David Kastrup wrote:
>>
>>> "m...@mikesolomon.org" writes:
>>>
>>>> Trying to put myself in the shoes of the average user, \fake would
>>>> not mean a function that uses a fake post event, but rather a
>>>> function that produces a \fake something. I would think "this makes
>>>> a fake slur", which is not the case.
>>>
>>> It makes a fake slur start or end.
>>
>> The word "fake" still doesn't sit right with me... There is nothing
>> fake about the slur:
>>
>> { a \fake ( b c d ) }
>
> Mike, that code does not even make any sense.
If one is quoting another instrument starting in mid-measure, why wouldn't that
make sense?
> You would not place a
> fake slur start or fake slur end anywhere except right after or right
> before a visual discontinuity from a repeat construct. You probably did
> not understand what I wrote, probably because "it makes a fake slur
> start or end" is not grammatically clear. I mean "It makes a fake
> slur-start or a fake slur-end" by that.
Ok, I'm getting what you're saying. I still don't like "fake" just because the
begin and start are still real. They are just offset.
>
>> It is real.
>
> The slur is real. The end point isn't.
What is not real about the endpoint? If I jump on a train in between two
stations, it is still a real getting-on-board.
>
>> The function, to me, should describe an attribute of the slur.
>
> But it doesn't. It describes an attribute of its visual start or end
> point.
This is a good idea.
>
>> The slur looks detached and broken, but not fake.
>
> But the attachment is fake, and the slur will get properly attached to
> the proper end points when repeats are unfolded.
Perhaps non-musical?
>
>> There are commands like slurDashed, slurDotted, etc. that describe
>> what the output will be like.
>
> And the output will be like that even when repeats are unfolded.
>
>> I think it's important to stay in that logic. If we're going to use
>> this for many spanners, my vote would be \broken.
>
> But it is not the slur that is "broken" but rather its visual connection
> to _one_ or even _two_ of its end points. You can perfectly well and
> meaningfully have an alternative written as
>
> { \fake\( c d e f \fake\) }
>
> and when unfolding, the phrasing slur will start at some point preceding
> this passage and end at some point succeeding it.
>
>> The slurs look broken,
>
> If you want to, but the whole of
> ( \broken) \broken( \broken) \broken( )
> is just _one_ slur broken into three pieces, not one whole slur and two
> broken slurs. That logic is more apparent with writing
> ( \fake) \fake( \fake) \fake( )
>
> The breaking occurs at artificial points not related to the music
> function of the slur, and it will get dissolved when unfolding repeats.
>
> The break of the slur does not occur where \broken is written, but
> rather it is at a visual discontinuity logically connected with matching
> pairs of \broken) ... \broken(. Your above example suggests that this
> relation does not seem clear to you.
>
>> and things like beams and hairpins will definitely look broken as well
>> if we split them using the same sort of algorithm.
>
> Sure, and again the split will be between matching pairs of artificial
> end and start points that are not logical end and start points and will
> disappear when repeats are unfolded and the broken construct gets joined
> visually as well as logically.
>
>> To me, something can look "broken" and this designation does not have
>> any bearing on if all the pieces are there or not. It is a quality of
>> the object.
>
> No, it is a quality of the respective visual (but not logical) start and
> end points. And I would prefer a naming choice that makes it easier for
> people to understand what they are doing. You are making a strong case
> for this being hard enough to make it prudent to avoid fallacious
> naming.
I completely agree. It's just that "fake" in English means false or
counterfeit. It needs another word, just don't know what yet. unchained? free?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 07:25, Werner LEMBERG wrote:
>
>> I can even imagine to use to commands, \start and \end to get, say,
>> `\start(' or `\end\>'. Who knows, maybe this destinction is
>> advantageous sometime in the future.
>
> Maybe even better \startOf and \endOf.
>
>
>Werner
The problem with \cut is that it is both a verb and adjective - the thing looks
"cut", but people might think that cutting is done.
As for start/end, all spanners are started and ended by definition, so this may
be confusing.
My vote:
1) \broken
2) \detached
3) \cut
4) \alignSpannerToNonMusicalPaperColumn
5) \fake
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 06:07, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> Trying to put myself in the shoes of the average user, \fake would not
>> mean a function that uses a fake post event, but rather a function
>> that produces a \fake something. I would think "this makes a fake
>> slur", which is not the case.
>
> It makes a fake slur start or end.
The word "fake" still doesn't sit right with me... There is nothing fake about
the slur:
{ a \fake ( b c d ) }
It is real. The function, to me, should describe an attribute of the slur.
The slur looks detached and broken, but not fake.
There are commands like slurDashed, slurDotted, etc. that describe what the
output will be like. I think it's important to stay in that logic. If we're
going to use this for many spanners, my vote would be \broken. The slurs look
broken, and things like beams and hairpins will definitely look broken as well
if we split them using the same sort of algorithm. To me, something can look
"broken" and this designation does not have any bearing on if all the pieces
are there or not. It is a quality of the object.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reorganize self_alignment_interface (issue 7768043)
On 20 mars 2013, at 00:27, Janek Warchoł wrote: > Hi, > > On Tue, Mar 19, 2013 at 11:40 PM, m...@mikesolomon.org > wrote: >> The main reason that I suggest this is that exceptions in the code base lead >> to harder maintenance. >> I am guilty of adding some from time to time (i.e. in stencil integral) but >> I try to get rid of them as fast as possible. >> One example in the code base that I don't like: check out line 136. > > In which file? line 136 of self-alignment-interface.cc from master is empty. separation-item.cc - sorry for the omission. > >> Granted, whoever created it doesn't like it either from the looks of the >> comment. >> It makes the code harder to read, maintain and understand. >> The worst offender by far is the metronome mark - there are so many >> exceptions >> concerning who its parent is that it leads to actual problems with layout in >> certain cases. > > Sure, that's no good at all. > >> I definitely like your idea of coming up with a single function, though. >> Perhaps try the following: >> >> -) always decompose axis-groups into elements (recursively if need be) > > What do you mean by axis-groups? 'hims' (a vector of grobs that me > shoulld be aligned to)? > >> -) create a non_musical flag that, if set, weeds out all grobs where >> non-musical is set to #t > > I'm not quite surehow non-musical grobs are related to alignment code. > Do you mean that this flag would be responsible for "getting rid of > PaperColumn parent"? > I'll try to propose a patch later today - it's easier to do that than explaining with words. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 20 mars 2013, at 03:24, d...@gnu.org wrote: > On 2013/03/19 22:37:14, wl_gnu.org wrote: >> >> After some consideration, I consider the name \broken suboptimal > since >> >> it implies two pieces. Two other possibilities would be \detached > and >> >> \fake. >> > >> > I vote for detached. > >> I vote for \broken. For me, it doesn't imply two pieces. This was >> David's first, quick suggestion, and I think it's good for exactly >> this reason. > > The first suggestion just picked this off the proposed music event name. > Here is why I consider \fake or \detached better: > > when I see \broken\< or \broken\!, this does not really help me figure > out where to use them. \broken\! actually looks, uh, broken. How do > you break an end spanner? > > However, \fake\< or \fake\! immediately make clear that we are talking > about something still being used in the function of a starting and > ending spanner, respectively. Trying to put myself in the shoes of the average user, \fake would not mean a function that uses a fake post event, but rather a function that produces a \fake something. I would think "this makes a fake slur", which is not the case. I like \detached because it describes accurately what is going on - if I were reading the manual and saw that \detached ( created a slur detached from noteheads, I'd remember the command. \broken slightly less because we are not always breaking something (we are only doing that with \breakSlur). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 19 mars 2013, at 23:37, Werner LEMBERG wrote: >>> After some consideration, I consider the name \broken suboptimal since >>> it implies two pieces. Two other possibilities would be \detached and >>> \fake. >> >> I vote for detached. > > I vote for \broken. For me, it doesn't imply two pieces. This was > David's first, quick suggestion, and I think it's good for exactly > this reason. > > >Werner I amend my statement - I should have said that I don't have a preference. Anything that people like is fine. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reorganize self_alignment_interface (issue 7768043)
On 19 mars 2013, at 22:04, janek.lilyp...@gmail.com wrote: > Hi Mike & all, > > On 2013/03/19 15:21:37, MikeSol wrote: >> I like where you're going with this. > > cool! :) > >> I would recommend creating a function algined_on_grobs that accepts a > grob, an >> vector of grobs to align to, and an axis. Then algined_on_parent > becomes a >> subset of this where the vector is of length one and is the parent. >> Then, you can create a function >> Self_alignment_interface::lyrics_algined_on_note_columns that invokes >> aligned_on_grobs with a vector of note columns returned using the > search method >> in this function. > > On 2013/03/19 15:28:45, MikeSol wrote: >> With respect to my last review, this function should accept a pointer > to a >> vector of grob pointers: > >> vector &hims > >> so that you can do the note column stuff for lyrics. > > I don't think this (defining special lyrics_algined_on_note_columns > callback) is optimal approach. > > With your suggestion, here's how i expect alignment stuff would look > like: > - there'd be a method Self_alignment_interface::aligned_on_grobs that > can align a grob on another grob(s) > - we'd have two callbacks: > Self_alignment_interface::lyrics_aligned_on_note_columns > and > Self_alignment_interface::lyrics_aligned_on_parent_notehead > - we'd have to decide when which callback should be used. How should > LyricText definition in define-grobs.scm look like? We should use > lyrics_aligned_on_note_columns when lyrics are unassociated, and > lyrics_aligned_on_parent_notehead when there is an associatedVoice - how > to write that in define-grobs? > > And the same thing will be repeated for many other grobs, for example > DynamicTexts: we'll have to specify different callback for DynamicTexts > attached to NoteHeads, and different one for standalone Dynamics (e.g. > in Dynamic Context). > > How alignment stuff would look like with my approach: > - aligned_on_grobs would be more complicated, because it'd have to grab > NoteColumn extent if 'him' turns out to be a PaperColumn > - we'd have one callback for everything > - we won't have to think about anything when defining grobs. We'd just > write X-offset = ly:self-alignment-interface::align-grob, and it would > be aligned_on_grobs' job to align on appropriate grob if the default one > (parent) is inappropriate. > > The difference is conceptual: aligning on NoteColumn is an exception, an > emergency exit needed only when grob doesn't have an ordinary parent. > As far as i know, if grob's parent is a NoteHead or some other "normal" > grob, we always want to align on that; and when grob's parent is a > PaperColumn, we always want to align grob on an appropriate NoteColumn. > > As for using a vector 'hims' instead of single 'him', maybe it's a good > idea, but i don't see any uses for it (besides your above suggestion, > which seems to be unnecessary). The main reason that I suggest this is that exceptions in the code base lead to harder maintenance. I am guilty of adding some from time to time (i.e. in stencil integral) but I try to get rid of them as fast as possible. One example in the code base that I don't like: check out line 136. Granted, whoever created it doesn't like it either from the looks of the comment. It makes the code harder to read, maintain and understand. The worst offender by far is the metronome mark - there are so many exceptions concerning who its parent is that it leads to actual problems with layout in certain cases. I definitely like your idea of coming up with a single function, though. Perhaps try the following: -) always decompose axis-groups into elements (recursively if need be) -) create a non_musical flag that, if set, weeds out all grobs where non-musical is set to #t This may achieve the same effect but it is a lot more general, as the distinction is between musical and non-musical rather than between note column and everything else. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 19 mars 2013, at 22:26, d...@gnu.org wrote: > On 2013/03/19 15:22:41, MikeSol wrote: >> Two backslashes > > After some consideration, I consider the name \broken suboptimal since > it implies two pieces. Two other possibilities would be \detached and > \fake. > > https://codereview.appspot.com/7424049/ I vote for detached. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates more possibilities for vertical and horizontal skyline functions. (issue 7516048)
On 19 mars 2013, at 12:49, janek.lilyp...@gmail.com wrote: > Mike, > > i've read the patch 3 times and i don't understand how it solves the > problem. > > I see that you remove some weird c++ code, but why can you do this? > Also, why marking some grobs as cross-staff helps with solving issue > 3242, which is about manual beams over rests? > What figured bass has to do with this at all? > >> Creates more possibilities for vertical and horizontal skyline > functions. > > I think this sentence applied to first version of the patch; it seems > unrelated to current patchset. > > I'm sorry to say this, but i think this issue is unreviewable :/ Thanks for the feedback! I've changed the message on Rietveld to be more in line with the current patch - you're right that it's bounced around quite a bit. I've also added a couple comments. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 17 mars 2013, at 17:46, joseph.wakel...@gmail.com wrote: > On a related issue: one thing that's probably clear looking at > Ferneyhough scores is the way in which the vertical placement of hairpin > endpoints is strongly coupled with the vertical placement of dynamic > marks. > > I don't think it's really appropriate to bundle all of this together > into one feature request, but it would probably be useful as a > complementary feature request to do some re-evaluation of Lilypond's > vertical placement of hairpin end-points, and whether it's possible to > automate the placement of angled hairpins so as to optimize the relative > positions of hairpin start- and endpoints and nearby dynamic marks. > > N.B. this is useful for all music, not just Ferneyhough. It's a fairly > consistent bugbear of mine that hairpin start- and endpoints are not > better placed relative to dynamic marks. > > I think this has already been touched on to an extent in the discussion > above ... ? > > https://codereview.appspot.com/7615043/ It's more swingable now that skylines are based on stencils for many grobs instead of extents. This is the sorta thing I know how to do but that'd take a while. If you can open a tracker issue w/ the full request, I'll try to get to it (I have some time next week and then again in late April). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 17 mars 2013, at 17:25, joseph.wakel...@gmail.com wrote: > > > Final remark: while it's nice to see Ferneyhough getting namechecked > might it be worth naming this alteration as flared-hairpin rather than > ferneyhough-hairpin? My suggestion was flairpin, which is infinitely cheesier and thus way cooler. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documents make-partial-ellipse-stencil (issue 7497046)
On 17 mars 2013, at 17:22, m...@hohlart.de wrote: > Just one nitpick. > > > https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm > File scm/stencil.scm (right): > > https://codereview.appspot.com/7497046/diff/1/scm/stencil.scm#newcode251 > scm/stencil.scm:251: "Makes a list of angle/radius paris at intervals of > PI/2 for > s/paris/pairs/ > Too much time in France... Pretty soon I'll be writing sentences like "angle/radius godewaersvelde" ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 17 mars 2013, at 13:36, thomasmorle...@googlemail.com wrote: > On 2013/03/17 07:27:37, MikeSol wrote: >> On 2013/03/13 21:38:59, thomasmorley65 wrote: > >> > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm >> > File scm/output-lib.scm (right): >> > >> > > > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061 >> > scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness > grob))) >> > At first sight I was surprised about `layout-line-thickness´. Than I >> remembered, >> > it is defined in bar-line.scm >> > How about making it public, moving it to lily-library.scm? >> > It could be used then in local custom-definitions. >> > Same with `layout-blot-diameter´. >> > I know, it's another topic, though, what do you think about it? > >> Great idea! > > I'd have expected _this_ change in another patch. > At least it should be mentioned in the commit-message. Will do. > >> > > > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078 >> > scm/output-lib.scm:1078: >> > What do you think about predefining sth like >> > ferneyhoughHairpinOn/Off >> > constanteHairpinOn/Off >> > in /lyproperty-init.ly? >> > i.e. >> > ferneyhoughHairpinOn = >> > \override Hairpin #'stencil = #ferneyhough-hairpin > >> I'm not against this idea at all - I'd like to see it proposed in a > different >> patch set, if possible. I am teerible at judging UI issues > because I hack >> so much. It is true that shortcuts help, but there are many, many > overrides >> that are shortcut-worthy. I'm not sure what standard determines which > overrides >> should get shortcuts and which shouldn't, so I leave that to a future > (and >> important!) conversation. > > ok > >> > > > https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082 >> > scm/output-lib.scm:1082: (define-public constante-hairpin >> > I'm not happy with constante-hairpin. > [...] > >> The constante indication means that the dynamic should not change at > all, so the >> decision to use a hairpin that grows in a given direction is > admittedly a hack. >> The idea of dimMolto (or crescMolto) with constante is a contradiction > (get very >> quiet while not changing dynamic). > > Yep. > And this contradiction _is_ disturbing. Agreed. > >> Insofar as a hairpin represents a change in >> dynamics, constante should, in theory, be a different grob. My > solution is not >> ideal, but I think it is an OK middle-ground short of the creation of > a separate >> grob. If people think it is too hackish, I will propose a new patch > with a >> Constante grob (or make the hairpin grow-direction = #CENTER default > to >> constante, which'd be difficult but doable). > > For now I'd tend to let it as it stands. > Nevertheless, it _is_ hackish and I think it should be replaced by one > of your proposals later. Agreed. > > > Though, how about: > >> Is it possible to make the hook-direction depending on the position of > the >> Hairpin i.e below or above the staff? > ? > > You'd have to have a wrapper function with a call to ly:scale-stencil with a -1 to the Y axis based on the direction of the grob. This is doable, but I'd wait to see from someone who knows how these things work if this is actually how they are printed. I want to say that they are always printed with the line going up irrespective of the side of the staff, but I could be wrong. Thanks for the review! Cheers, ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
On 17 mars 2013, at 12:29, Neil Puttock wrote:
>
> On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org" wrote:
>
> > In the stop_translation_timestep method of the lyric engraver, lyrics are
> > given note heads as parents. Could you send a minimal where the lyrics are
> > unassociated from note-heads?
>
> \lyrics { do re mi }
>
> If there's no associated voice the lyrics have no parent until the
> Paper_column_engraver steps in.
>
> Cheers,
> Neil
>
Cool cool - thanks!
Then, going back to Janek's question, Janek - what would an appropriate
note-column be? If there are several, how do we know from user input which one
the lyric should align to?
Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
On 17 mars 2013, at 11:05, Janek Warchoł wrote: > Hi, > > On Sat, Mar 16, 2013 at 12:20 PM, David Kastrup wrote: >> Do we >> really need a particular associated voice instead of being able to do >> this with general music column alignment? > > I'll write a full answer later today, but for now i can say that i > don't know a way to do this. > Let's say i have an unassociated LyricText grob. It's parent is a > PaperColumn. Do you know how to grab an appropriate NoteColumn (if it > exists)? > (see self-alignment-interface.cc, line 134. How to get a NoteColumn > when all we have is 'him'?) > Hey Janek, Sorry for the lack of review - today is my first day off in a long time! I saw in one of your patch sets that you use the word "parent" to name a function that takes grobs me and him. If there is no longer a parental relationship built into the function, it's worth changing the name of the function. In the stop_translation_timestep method of the lyric engraver, lyrics are given note heads as parents. Could you send a minimal where the lyrics are unassociated from note-heads? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)
On 17 mars 2013, at 10:19, d...@gnu.org wrote: > You don't fix your own work after it has been committed, This is patently false. Please do not write e-mails like this to a public list that can be read by future employers of mine that want to evaluate my integrity. > so why would > you fix inconsistencies afterwards that you felt ok to ignore in the > first place? Who is going to fix them? "the community". Please try > acting as a part of "the community" instead of piling work on for "the > community" that "somebody else (TM)" will at some time solve. > "Please try acting as a part of the community" is insulting. I fix bugs that I've cause and I have fixed numerous bugs that other people (including you) have introduced. The more caustic your e-mails are, the more difficult it is to extract the useful parts from them. Please tone down your language or, if that is too difficult, please send me e-mails privately. Public e-mails of this nature will result eventually in my leaving the project. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: big-picture question regarding Lilypond's capabilities (current and potential)
On 16 mars 2013, at 17:17, Kieren MacMillan wrote: > Hello all, > > My two-act musical, "Robin Hood: The Legendary Musical Comedy", had a > three-week run at Toronto's Hart House Theatre in January. It was quite > successful, to the point that several parties have voiced an interest in > further developing and producing it. > > In my dream world, people who are interested in producing any of my musicals > should be able to say (e.g.) the following: > >1. “I would like PDFs for the full score, vocal score, vocal book, and > band parts for piano+bass+percussion." >2. "I would like ‘Generosity’ transposed down a tone.” >3. “In the opening number, I would like to cut mm. 101-117, and have mm. > 212-213 made into a vamp (i.e., with repeat signs and the word ‘vamp, cont. > on vox’ written above).” > > This email is to determine to what degree these are possible now, or might be > possible in the future. > > In particular, I'm interested in #3, since it could more seriously impact the > way I organize the input code. (For #1 and #2, it's mostly just figuring out > and perfecting the infrastructure for on-demand printing — nontrivial, to be > sure, but mostly post-input-code.) I use tags with absolute note entry for this sorta thing all the time. One thing that is relatively easy to do is to create code formatting tools that will parse .ly code and spit out, for example, one measure per line (for simple music) that are all tagged via some sorta system. Then, a music function can generate keepWithTag and removeWithTag stuff based on the bars you want. In general, in the realm of code beautifying and formatting, there are lots of 3rd party tools that can be developed around LilyPond. The less out-there the music, the easier it is to apply these and augment the music's plasticity. Cheers, MS > > Given the current (v2.17) capabilities of Lilypond, what are the various ways > I could accomplish #3? > What's likely the "best" way? > Are functions like \partCombine, \extractMusic, etc. up to the task(s)? > > Thanks, > Kieren. > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates more possibilities for vertical and horizontal skyline functions. (issue 7516048)
On 16 mars 2013, at 04:26, k-ohara5...@oco.net wrote: > good enough > > > https://codereview.appspot.com/7516048/diff/1/scm/define-grobs.scm > File scm/define-grobs.scm (right): > > https://codereview.appspot.com/7516048/diff/1/scm/define-grobs.scm#newcode312 > scm/define-grobs.scm:312: (vertical-skylines . > ,grob::simple-vertical-skylines-from-y-extent) > I'm confused, because the fall-back for vertical-skylines seems to do > exactly the same thing for Spanners, and it looks like this is a > Spanner. > That's only in the pure equivalent. The unpure function doesn't have this. > https://codereview.appspot.com/7516048/diff/1/scm/define-grobs.scm#newcode2237 > scm/define-grobs.scm:2237: (horizontal-skylines . > ,grob::simple-horizontal-skylines-from-x-extent) > The fall-back would be the same if this Grob were marked cross-staff = > #t Would it be more smarter to mark this and similar grobs cross-staff > ? Running regtests. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gives invisible stems point extents. (issue 7762049)
On 14 mars 2013, at 08:05, k-ohara5...@oco.net wrote: > So then the convention for an extent is > '(+inf.0 . -inf.0) is empty, but for skylines in the cross direction it > is an infinite wall; > '(0 . 0) is a point, but ignored for skylines; > '(-inf.0 . +inf.0) is an infinite wall all the time. > > Could you filter out this effect on RhythmicStaves ? > > My heavy-metal band uses a flame-shaped glyph for some Stems, and it > needed zero X-extent for some spacing reason. While fixing another MIDI > bug I had the Midi_performer listen for Stems and send a message, if on > channel 10, when it sees a zero-width Stem, by convention. That message > fires the flamethrowers, so if you push this change I have to remind the > boys to avoid that part of the stage in case the drummer has any beamed > rests. > > https://codereview.appspot.com/7762049/ New patch up that doesn't get in the way of your band! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses single algorithm for side-position spacing. (issue 6827072)
On 14 mars 2013, at 06:44, m...@mikesolomon.org wrote:
>
> On 14 mars 2013, at 06:42, k-ohara5...@oco.net wrote:
>
>> issue 3242
>>
>>
>> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc
>> File lily/axis-group-interface.cc (right):
>>
>> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode902
>> lily/axis-group-interface.cc:902: Skyline_pair skylines
>> (inside_staff_skylines);
>> \relative c'' {
>> r2^\f r4 f8^[ r]
>> }
>>
>> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc
>> File lily/stencil-integral.cc (right):
>>
>> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc#newcode992
>> lily/stencil-integral.cc:992: xex.set_full ();
>> Oops.
>>
>> https://codereview.appspot.com/6827072/
>
> Yup, just caught this myself, we're on the same page.
> This set_full needs to happen for other grobs, but by giving invisible stems
> a point stencil instead of an empty stencil, things are fixed. Running the
> regtests.
>
> Cheers,
> MS
Another solution is to introduce the idea of "blocking grob." The comment I
put about SystemStartBracket and BassFigureAlignmentPositioning is because both
of them conceptually need to extend forever in both directions to never be
moved over/under/left/right of another grob. This could perhaps be done via
two properties:
horizontal-skyline-minimum-height
and
vertical-skyline-minimum-height
Thoughts?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses single algorithm for side-position spacing. (issue 6827072)
On 14 mars 2013, at 06:42, k-ohara5...@oco.net wrote:
> issue 3242
>
>
> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc
> File lily/axis-group-interface.cc (right):
>
> https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode902
> lily/axis-group-interface.cc:902: Skyline_pair skylines
> (inside_staff_skylines);
> \relative c'' {
> r2^\f r4 f8^[ r]
> }
>
> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc
> File lily/stencil-integral.cc (right):
>
> https://codereview.appspot.com/6827072/diff/38003/lily/stencil-integral.cc#newcode992
> lily/stencil-integral.cc:992: xex.set_full ();
> Oops.
>
> https://codereview.appspot.com/6827072/
Yup, just caught this myself, we're on the same page.
This set_full needs to happen for other grobs, but by giving invisible stems a
point stencil instead of an empty stencil, things are fixed. Running the
regtests.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly rule
On 13 mars 2013, at 11:56, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> On 13 mars 2013, at 11:00, David Kastrup wrote: >> >>> It might also be possible to let a callback check for the existing >>> grob interfaces in possible cases of contention and only use the >>> respective value if the grob had the proper interface. >>> >>> So you'd have a callback that only looked at staff-padding in the >>> tuplet-bracking-interface manner if the grob had that interface, and >>> would look at it in the side-position-interface manner only if the >>> grob had _that_ interface. >>> >>> That would require giving grobs a set of interfaces that interpret >>> any given property only in one manner. >> >> Then that would mean that the tuplet bracket could never use side >> position interface and vice versa. > > Yes. The set of interfaces is not user-changeable as far as I know. So > this would hamper the system programmers regarding the possible > interface choices rather than the users. > > Not fabulous, but I have a hard time at the current point of time coming > up with something that does not either have significant naming > redundancy and awkwardness, or is lacking flexibility. At least when it > is supposed to fit more or less with the current scheme of things. Makes sense. In my work with eliminating the translate_axis call, then, I'd need to create an: outside-staff-interface For all grobs that can be positioned outside the staff. That way TupletBracket could be part of this without having bleedover from the side-position-interface's use of staff-padding. It'd require adding a new interface to a lot of grobs, but it actually adds a lot of clarity, as in the documentation we can indicate that the internals reference shows all grobs that can be outside-staff positioned via this interface. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly rule
On 13 mars 2013, at 11:00, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> I'm not too good at writing convert-ly rules. Is there a model I can >> use for replacing a property with another? Specifically, I'd like to >> write a patch changing: >> >> TupletBracket.staff-padding >> >> to: >> >> TupletBracket.bracket-staff-padding >> >> as one cannot currently use the side position interface callbacks on >> TupletBrackets because staff-padding in the tuplet-bracket-interface >> works differently than staff-padding in the side-position-interface. >> >> Lemme know if anyone has a good solution. Otherwise I'll hack away... > > I am not happy about name proliferation. Me neither. > On the other hand, I don't > know how something like > > TupletBracket.tuplet-bracket-interface.staff-padding > > could sensibly be implemented Instead of using dots, you use another symbol like @. Then, the symbol is parsed into the before and after @. If there is no before, the property applies to all interfaces implementing after. > and it would be pretty much impossible to > know reliably when and when not a further qualification would be > required to keep all callbacks properly informed. It's true that this is a mess for override and revert... > > It might also be possible to let a callback check for the existing grob > interfaces in possible cases of contention and only use the respective > value if the grob had the proper interface. > > So you'd have a callback that only looked at staff-padding in the > tuplet-bracking-interface manner if the grob had that interface, and > would look at it in the side-position-interface manner only if the grob > had _that_ interface. > > That would require giving grobs a set of interfaces that interpret any > given property only in one manner. Then that would mean that the tuplet bracket could never use side position interface and vice versa. > > That would work without convert-ly rules and a larger namespace set. It > would also mean that you would look at the interfaces of a grob in the > documentation to decide which values were supported. That there are > some callbacks able to interpret the _same_ property differently > depending on the interfaces of a given grob, in contrast, is an > implementation detail buried deep enough to probably not appear > disturbing to a user. > This is the current state of things minus the verification step. We are admittedly only talking about the world of overrides for now, but it seems that certain kludges exist in the code base to work around this problem (like for minimum-length). There are also documentation bugs, as these properties do multiple things but only have doc strings for a single case. In terms of extensibility, we should have a way to deal with the creation of new properties and the managing of old ones to avoid this sorta problem. > -- > David Kastrup > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly rule
On 13 mars 2013, at 10:51, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> I'm not too good at writing convert-ly rules. Is there a model I can >> use for replacing a property with another? Specifically, I'd like to >> write a patch changing: >> >> TupletBracket.staff-padding >> >> to: >> >> TupletBracket.bracket-staff-padding >> >> as one cannot currently use the side position interface callbacks on >> TupletBrackets because staff-padding in the tuplet-bracket-interface >> works differently than staff-padding in the side-position-interface. > > Is bracket-staff-padding a smart name? We also have OttavaBracket, > VoltaBracket, PianoPedalBracket, ArpeggioBracket, BassFigureBracket, > LigatureBracket, HorizontalBracket, SystemStartBracket... This sounds > like a recipe for the next naming collision. > > Maybe tuplet-staff-padding instead? What is it being used for? > It's being used for ligature bracket and tuplet bracket. I don't mind tuplet-bracket-staff-padding, but that is counterintuitive for ligature brackets... Cheers, MS > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly rule
Hey all, I'm not too good at writing convert-ly rules. Is there a model I can use for replacing a property with another? Specifically, I'd like to write a patch changing: TupletBracket.staff-padding to: TupletBracket.bracket-staff-padding as one cannot currently use the side position interface callbacks on TupletBrackets because staff-padding in the tuplet-bracket-interface works differently than staff-padding in the side-position-interface. Lemme know if anyone has a good solution. Otherwise I'll hack away... Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)
On 12 mars 2013, at 23:44, janek.lilyp...@gmail.com wrote: > Hi Mike, > > i've read changes in code and i don't quite get what this change is for. > What makes it possible that we can now accept boxes that are narrower > than epsilon? What can we achieve with that and why? > > I'm sorry for asking such boring questions, but this is one of your > smallest patches and therefore i'd like to actually understand what you > are doing here - with your regular changes it's way too difficult for me > ;) > > cheers, > Janek > > https://codereview.appspot.com/7310075/ Good question! Imagine that there is a notehead with a width smaller than epsilon. We'd like to use it to position elements, but if skylines throw away anything with a width less than epsilon, the note head will not be part of the skyline and things will be positioned on top of it. The concern before was a comment about numerical inaccuracy, but after having tested the patch, this seems not to be an issue. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 13 mars 2013, at 00:02, janek.lilyp...@gmail.com wrote: > Nice hairpins! > > Janek > > > https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhough-hairpins.ly > File input/regression/ferneyhough-hairpins.ly (right): > > https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhough-hairpins.ly#newcode4 > input/regression/ferneyhough-hairpins.ly:4: texidoc = "LilyPond creates > hairpins found in Ferneyhough scores. > Please be more specific - a user might not know what Ferneyhough scores > look like. > For example, add "There are two variants of Ferneyhough hairpins: one is > horizontal for its whole length with short vertical line at the end that > is louder, and another one is similar to ordinary hairpin except that > its width doesn't change evenly - it's narrower with a wide opening at > the end" > (ccing Trevor) Obviously I want the name that is the most appropriate for the object. Trevor, having suggested it, may know what it is called in Anglo-American contemporary music circles (I like "flairpin" :) Once we decide on a name, I'll add this to the texidoc. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 12 mars 2013, at 00:38, thomasmorle...@googlemail.com wrote: > Hi Mike, > > sorry to have some more nit-picks. > > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm > File scm/output-lib.scm (right): > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1051 > scm/output-lib.scm:1051: 0.1 > Hard-coded thickness. > Why not multiply 'thickness-property from Hairpin and 'line-thickness as > usual? Good call! > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1052 > scm/output-lib.scm:1052: 1.0 > I'd do the scaling here. > ly:stencil-scale would be superfluous than. I'll try it out. > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1077 > scm/output-lib.scm:1077: (cons xtrans ytrans))) > I'm not sure ytrans is needed. > Setting it 0 seems to make no difference. > Delete and use ly:stencil-translate-axis? I'm not sure if it makes a difference either. The idea is that, conceptually, we want the stencil to have the same translation as the original (which is always 0 for now). If that changes in the hairpin print function, we want that to change in this function as well. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Freezing for 2.18
On 11 mars 2013, at 16:32, "Trevor Daniels" wrote: > > David Kastrup wrote Sunday, March 10, 2013 5:32 PM > >> 2.16 is growing old. >> >> So I want to see 2.18 soon. That means we need to stabilize work that >> has already been done and cut down on experiments in the master branch. > > Agreed. > >> Stabilizing means more or less accepting the current feature set, and >> making sure it works as intended, is a useful combination of things, >> does not offer interfaces which are sure not to survive into the next >> stable version, and most of all, is properly documented to the user. > > Once the decision to stabilise is taken, further work on new features > should take place in branches. It doesn't have to stop. That's how the > skyline code was developed before it was merged into 2.17 and that > procedure worked well. > >> At any rate, I'd like to aim for 2.18 at about the end of May, and >> getting into serious freeze at the end of April. A focus on bug fixes, >> in particular bugs introduced in the 2.17 development cycle, should take >> priority. Fixing long-standing bugs hard to address should likely be >> left for early 2.19 and/or be done in a branch. > > Why not freeze sooner? The current state is sufficiently different from > 2.16 to justify a new stable. > > I'd also like to propose we adopt the same controls as we did for 2.16, > if David is willing, since that also worked well. That way we'll get a > clear plan - what must be fixed, what must be documented, what is > permitted to go into master, etc. Otherwise we'll simply disagree for > ever. > I like the idea of freezing right away and releasing after two weeks of critical-bug-free lily. What is difficult for me is setting the freeze down the line without being able to wrap up work first. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Freezing for 2.18
On 10 mars 2013, at 22:30, David Kastrup wrote: > Werner LEMBERG writes: > >>> So, to resume, I agree that a freeze is important. When the freeze >>> kicks in, I'd rather that we say something like "no new big projects >>> starting on date X will be part of 2.18" so that developers can plan >>> out their next few months accordingly. >> >> +1 > > Actually, "no projects without a serious chance to get finished and > debugged until date X" is a more important metric. Take a look at the > "full" \relative proposal: it is a biggy touching several thousands of > lines. But consequences are clear to estimate and shake out, so the > decision to do this kind of big thing can be done quite late in the > game. Because the fallout is quite clear and limited. > > The starting date is much less important than a realistic view of the > wrapup date. > I think it is important for everyone in the community of developers to tie off things that they feel to be important before putting out a stable release. We should feel out where everyone is with their work, life plans and when/where a gel in adding things could fit into these things. If LilyPond were a piece of commercial software I could understand one person imposing a limit, but as it is a team of peers working together, I think that everyone should set a limit that makes sense for them, announce it, and stick to it. This may push a stable release date back some, but I'd rather there be a later stable release that every volunteer developer feels good about than an earlier one. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Freezing for 2.18
On 10 mars 2013, at 18:32, David Kastrup wrote: > > Ok folks, it is this time of the year again: I am trying to make myself > unpopular. There's a time of the year for that? > It also means that commits of the "this really does nothing, but it > prepares the ground for $xxx, and I don't know just where this is going, > so quite a bit of it might be changed into something different yet" > should happen in a branch. Actually, I am of the opinion that most of > these changes should happen in a branch anyway. A "commit" implies > commitment, and if one has taken a bad path, redoing it is much harder > if the dead end has already ended in the main code base. As the world champion of this style of coding, I can conclusively say that I have no problem freezing all my experiments except the large translate_axis call patch, as I am sure that I know where its going and I almost have it wrapped up after many rounds of revision and review. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 10 mars 2013, at 01:47, thomasmorle...@googlemail.com wrote: > Hi Mike, > > decrescendo doesn't work!! Yikes! Will fix. Thanks for spotting this. > > My idea about "drag-hairpin" seems not too hard to implement, ofcourse > there would be need to do a clean definition of the property, currently > LilyPond returns a unsurprisingly warning: I see what you're saying, but this is a more general issue about Hairpin rotation and non-linear DynamicLineSpanners that should be addressed conceptually as a separate issue. However, it is an excellent idea and I'd be happy to work on it at some point later down the line. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)
On 9 mars 2013, at 09:51, d...@gnu.org wrote: > On 2013/03/09 07:18:50, mike7 wrote: >> On 8 mars 2013, at 14:10, mailto:d...@gnu.org wrote: > >> > >> > > > https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly >> > File input/regression/minimum-length-end-line.ly (right): >> > >> > > > https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly#newcode10 >> > input/regression/minimum-length-end-line.ly:10: \override >> > TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods >> > Why is this override needed for the regtest? The other overrides > are >> > obvious user-accessible overrides for triggering the tested >> > functionality. >> > >> > But should _this_ override not be the default? >> > >> > https://codereview.appspot.com/7453046/ > >> Perhaps open a tracker issue for this? >> The question is not only valid for text spanners but also hairpins, > glissandos, >> etc. > > Last time I looked, this issue purportedly "Allows minimum-length to > work for end-of-line spanners." And according to the regtest, it does > not do the job. Without additional messing with springs-and-rods it > does not allow minimum-length to work for end-of-line-spanners. > The definition of "allow" in the New Oxford American Dictionary is "give the necessary time or opportunity for." This patch gives spanners the opportunity to have minimum length work at the end of the line. Additional messing with springs and rods is because minimum-length is currently implemented by four different interfaces (lyric-hyphen, multi-measure-rest, ottava-bracket and spanner) and is also looked up in lyric-extender in a way that does not correspond to its docstring. So, certain uses of minimum length require the additional override whereas others don't. I do not think this is ideal, which is why I proposed a few weeks ago standardizing property names across interfaces. It seems like the issues you are raising above and below have less to do with this patch and more to do with the multiple implementation of minimum-length and the use of the springs-and-rods property. > The only thing more frustrating than missing functionality is > purportedly available functionality that needs non-user-comprehensible > trickery to actually work. I do not have a problem with the current need to set the springs-and-rods separately. If you do, please file an issue then to fix this as well as the following snippets in the Documentation: -) http://lilypond.org/doc/v2.17/Documentation/notation/expressive-marks-as-lines#index-glissando-1 -) http://lilypond.org/doc/v2.17/Documentation/notation/spanners.html, specifically "For some layout objects, the minimum-length property becomes effective only if the set-spacing-rodsprocedure is called explicitly. To do this, the springs-and-rods property should be set to ly:spanner::set-spacing-rods. For example, the minimum length of a glissando has no effect unless the springs-and-rodsproperty is set." > So it is not clear that using this functionality would not > break other things elsewhere. > I'm positive it would because of the way that minimum-length is multiply defined. That is why this patch is intended for the "some layout objects" discussed above like the TextSpanner. I agree that the multiple use of the minimum-length property should be changed, but this seems like the business of another patch. If the regtest is bothering you that much, I can just eliminate it from this patch. It won't change the better functionality of this patch and will just stop shedding light on the issue I'm discussing above. But that does not seem like a good solution, nor does setting springs-and-rods with a default property. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)
On 8 mars 2013, at 14:10, d...@gnu.org wrote: > > https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly > File input/regression/minimum-length-end-line.ly (right): > > https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly#newcode10 > input/regression/minimum-length-end-line.ly:10: \override > TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods > Why is this override needed for the regtest? The other overrides are > obvious user-accessible overrides for triggering the tested > functionality. > > But should _this_ override not be the default? > > https://codereview.appspot.com/7453046/ Perhaps open a tracker issue for this? The question is not only valid for text spanners but also hairpins, glissandos, etc. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)
On 9 mars 2013, at 00:15, thomasmorle...@googlemail.com wrote: > Hi Mike, > > one thought. > > The image Trevor Bača posted > http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png > shows that the left ends of a decrecsendo-hairpin are vertical aligned > even if the hairpin isn't extended horizontal but ascending. > Currently the vertical alignment is gone if the hairpin is rotated, and, > afaik, this is the only way an ascending hairpin is available (apart > from constructing a new one from scratch). > > (Similiar for cresc-hairpins.) > > Is it possible to extend your code to achieve this? > Might be an interesting feature for common hairpins as well. > > Since I don't know of I explained myself well enough, here some > markup-code which mimics it: > > #(define drag-hairpin 5) % try different values > > \markup > \postscript > #(string-append > " >0 1.5 moveto >0.5 -0.75 rlineto >15 >" >(number->string (+ -0.75 drag-hairpin)) >" >rlineto > >0 -1.5 moveto >0.5 0.75 rlineto >15 >" >(number->string (+ 0.75 drag-hairpin)) >" >rlineto >stroke > >% a red line to show vertical alignment: > >gsave >0 3 moveto >1 0 0 setrgbcolor >0 -6 rlineto >stroke >grestore > ") > > > > > > > https://codereview.appspot.com/7615043/ Hey Harm, I think it's worth adding an issue to the tracker for this. You can make a minimal example with the hairpins in current master. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Change name of Patch Handler to Patch Meister in CG (issue 7498045)
On 6 mars 2013, at 10:13, d...@gnu.org wrote: > It's a mystery to me how anybody could interpret this text in any other > manner, but there is no point in being less clear than possible, so > LGTM. > > https://codereview.appspot.com/7498045/ A "handler" handles things, i.e. is the person who physically handles something. In UPS, if I talk about my "package handler", it is the person who is taking my package from point A to Z. They put their "hand" on something, thus handle. The patch mesiter does everything but handling when doing work like setting tags from new to review to countdown. It is a misleading name that should be changed. I thought I was the patch handler when reading that document because I am the one handling my patch. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cannot Merge Staging this mornining
On 2 mars 2013, at 10:28, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> On 2 mars 2013, at 10:16, David Kastrup wrote: >> >>> James writes: >>> >>>> From: James >>>> Subject: Cannot Merge Staging this mornining >>>> Newsgroups: gmane.comp.gnu.lilypond.devel >>>> To: Devel >>>> Date: Sat, 2 Mar 2013 09:02:37 + (4 minutes, 27 seconds ago) >>>> >>>> Fails on Make. >>>> >>>> Only one commit in staging >>>> >>>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=2ae751cb5169165c23e3b1a9a2da2182ef8c78ba >>>> >>>> --- >>>> >>>> Avoids measuring distances between empty and non-empty skylines >>>> staging >>> >>> Removed from staging. See >>> http://code.google.com/p/lilypond/issues/detail?id=3169#c12> >>> >> >> Found the problem - I forgot to add skyline.scm in the commit. > > How can you even do that when using git and git cl for reviews and > Rietveld had it on display? I make a diff off of my branch and then I do git apply mydiff.diff instead of merging. This way I don't include the entire commit history of my local branch into LilyPond. But it means that I need to manually add all new files. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cannot Merge Staging this mornining
On 2 mars 2013, at 10:16, David Kastrup wrote: > James writes: > >> From: James >> Subject: Cannot Merge Staging this mornining >> Newsgroups: gmane.comp.gnu.lilypond.devel >> To: Devel >> Date: Sat, 2 Mar 2013 09:02:37 + (4 minutes, 27 seconds ago) >> >> Fails on Make. >> >> Only one commit in staging >> >> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=2ae751cb5169165c23e3b1a9a2da2182ef8c78ba >> >> --- >> >> Avoids measuring distances between empty and non-empty skylines >> staging > > Removed from staging. See > http://code.google.com/p/lilypond/issues/detail?id=3169#c12> > Found the problem - I forgot to add skyline.scm in the commit. Thanks for removing. I'll add with the file added. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative pixel-based regtest checker
On 1 mars 2013, at 22:33, David Kastrup wrote: > "Phil Holmes" writes: > >> There's lots of improvements that could be made: parallelism, using >> something other than diff, but it basically works. >> >> Thoughts? > > CMP(1) User Commands CMP(1) > > NAME > cmp - compare two files byte by byte > > SYNOPSIS > cmp [OPTION]... FILE1 [FILE2 [SKIP1 [SKIP2]]] > > DESCRIPTION > Compare two files byte by byte. > > -- > David Kastrup As LilyPond is non deterministic, it does not draw stencils to the page in the same order every time, which means (I think) that the same input can generate two different PNG files. So, a bytewise comparison may trigger false positives. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative pixel-based regtest checker
On 1 mars 2013, at 20:15, Phil Holmes wrote: > 4 files attached. To try this out: create a new directory and place > NoTagline.ly in it. Create a subdirectory called input and put some regtest > files in there. Run MakeOldPix.sh. Make a change to lilypond. Run > MakeNewPix.sh. Run ComparePix.sh. Om my tests there were some false alarms, > but it seems a fairly simple way to make an alternative regtest checker. > > There's lots of improvements that could be made: parallelism, using something > other than diff, but it basically works. > > Thoughts? > Cool! For me, one of the most important things in the regtests are the signature files. We'd have to maintain the red flags popping up from those (which may not show up in the images). But it is true that this sort of approach would catch issues like the bar line one. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows inheritence for slur engravers (issue 7437048)
On 1 mars 2013, at 17:30, d...@gnu.org wrote: > On 2013/03/01 14:45:27, mike7 wrote: > >> > "doubleSlurs" is not generic but rather specific. I'd use something >> > like >> > if (double_property_name_ && to_boolean (get_property >> > (double_property_name_))) >> > instead, then we can, if desired, have a separate doublePhrasingSlur >> > property at some point of time. > >> Done. Had to make the check slightly different: > >> if ((double_property_name_ != "") >> && to_boolean (get_property (double_property_name_.c_str ( > > Oh, I'd have made double_property_name_ a const char * const instead > of a string. That can be 0, and you don't need to c_str on it. > >> as GCC complains that there is no operator && for the check you're > suggesting. I've always avoided using const char * because I never understood how it works with memory management. Given that we are creating a pointer (an array of chars), wouldn't we have to delete it in the destructor? Furthermore, how does GCC know to allocate the correct amount of memory for the string? Wouldn't that change depending on the length of the string? That's probably the sort of thing you learn in a Freshman CS class...sorry for the basic question... Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows inheritence for slur engravers (issue 7437048)
Thanks for the review!
Cheers,
MS
> Thanks for the rebase!
>
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-engraver.cc
> File lily/slur-engraver.cc (right):
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-engraver.cc#newcode51
> lily/slur-engraver.cc:51: event_name_ = "slur-event";
> As a matter of style, I'd declare all of those const and initialize them
> in the initializer list, so
> Slur_engraver::Slur_engraver () : grob_name_ ("Slur"), event_name_ ...
Done.
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-engraver.cc#newcode64
> lily/slur-engraver.cc:64: context ()->set_property ("slurMelismaBusy", m
> ? SCM_BOOL_T : SCM_BOOL_F);
> Well, we have ly_bool2scm. Not a fabulous code saver, but as long as we
> have it...
Done.
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-engraver.cc#newcode70
> lily/slur-engraver.cc:70: internal_process_music ();
> I'd rather make this function the default behavior of
> Slur_proto_engraver::process_music
> and make set_melisma a virtual function of Slur_proto_engraver that does
> nothing by default and is overriden by Slur_engraver::set_melisma.
Done.
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-proto-engraver.cc
> File lily/slur-proto-engraver.cc (right):
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-proto-engraver.cc#newcode119
> lily/slur-proto-engraver.cc:119: slurs_[i]->warning (_ (("unterminated
> "+warning_name_).c_str ()));
> I'd not use warning_name_ but rather something like object_name_. After
> all, there is no logical connection to warnings.
Done.
> https://codereview.appspot.com/7437048/diff/1/lily/slur-proto-engraver.cc#newcode138
> lily/slur-proto-engraver.cc:138: && make_double_slur_)
> "doubleSlurs" is not generic but rather specific. I'd use something
> like
> if (double_property_name_ && to_boolean (get_property
> (double_property_name_)))
> instead, then we can, if desired, have a separate doublePhrasingSlur
> property at some point of time.
Done. Had to make the check slightly different:
if ((double_property_name_ != "")
&& to_boolean (get_property (double_property_name_.c_str (
as GCC complains that there is no operator && for the check you're suggesting.
>
> https://codereview.appspot.com/7437048/diff/1/lily/slur-proto-engraver.cc#newcode183
> lily/slur-proto-engraver.cc:183: slur->programming_error ("slur without
> a cause");
> warning_name_ (or, after my proposal, _object_name_) here.
>
Done.
https://codereview.appspot.com/7437048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 28 févr. 2013, at 22:29, Neil Puttock wrote: > > On Feb 28, 2013 8:37 PM, "m...@mikesolomon.org" wrote: > > > You're right, but I've opted for the breaking behavior in the most recent > > patch-set (\breakSlurHere). Otherwise, slurs wouldn't be able to span only > > one musical moment. > > Ok, so how about using an event of class break-span-event (like > \breakDynamicSpan)? > > Brilliant! Done. > > We miss you! Come back! > > Thanks. :-) > > I can feel the itch returning, but really need to get a laptop first unless I > can commandeer our new iMac when it arrives next month and work out how to do > things iOS fashion. > > Good deal. I'm a Mac user but I do all my development in a virtual box to keep from messing up my OS. Looking forward to more of your contributions and reviews! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On 28 févr. 2013, at 21:30, n.putt...@gmail.com wrote:
>
> https://codereview.appspot.com/7424049/diff/1/input/regression/repeat-slur.ly
> File input/regression/repeat-slur.ly (right):
>
> https://codereview.appspot.com/7424049/diff/1/input/regression/repeat-slur.ly#newcode14
> input/regression/repeat-slur.ly:14: \alternative { { a' ) b' \set
> breakSlurAtBarLine = ##t c' ( d' }
> Can't you use 'to-barline for this?
>
> https://codereview.appspot.com/7424049/
>
You're right, but I've opted for the breaking behavior in the most recent
patch-set (\breakSlurHere). Otherwise, slurs wouldn't be able to span only one
musical moment.
We miss you! Come back!
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Musings on interfaces and properties
On 28 févr. 2013, at 12:47, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> On 28 févr. 2013, at 12:40, Werner LEMBERG wrote: >> >>> >>>>> Renaming properties which do something differently is the way to go >>>>> IMHO. >>>> >>>> Then the first step is finding all properties that are defined in >>>> multiple interfaces and changing their names. >>> >>> Maybe a naïve question: Are there many? >>> >> >> >> I'd guess between 10 and 20. > > One can probably boil the set actually causing conflicts down. > Absolutely, but the goal should be to eliminate this sort of thing entirely. Conflicts can easily be caused if people use different overrides than the habitual ones. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Musings on interfaces and properties
On 28 févr. 2013, at 12:40, Werner LEMBERG wrote: > >>> Renaming properties which do something differently is the way to go >>> IMHO. >> >> Then the first step is finding all properties that are defined in >> multiple interfaces and changing their names. > > Maybe a naïve question: Are there many? > I'd guess between 10 and 20. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Musings on interfaces and properties
On 28 févr. 2013, at 12:16, Werner LEMBERG wrote: > >> I think that at the current point of time, we should try getting >> along with a flat namespace approach. That might imply renaming >> properties like "padding" to "side-padding" if we can't achieve >> reasonable results otherwise. Not sure about that. > > I support that. Renaming properties which do something differently is > the way to go IMHO. > > Then the first step is finding all properties that are defined in multiple interfaces and changing their names. This'll be one heck of a convert-ly rule... Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)
On 28 févr. 2013, at 06:48, d...@gnu.org wrote:
> On 2013/02/27 23:00:48, mike7 wrote:
>> On 27 févr. 2013, at 19:06, mailto:d...@gnu.org wrote:
>
>> >
>> >
>
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly
>> > File input/regression/scheme-text-spanner.ly (right):
>> >
>> >
>
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly#newcode129
>> > input/regression/scheme-text-spanner.ly:129:
>> > side-position-interface::y-aligned-side)
>> > I really don't understand why you ask on the developer list about
>> > gratuitous prefix changes because of a different implementation
> language
>> > when you propose such changes right afterwards.
>> >
>
>> In my e-mail, I stated:
>> "I'd prefer if all native Scheme functions did not have the ly: prefix
> - it
>> helps to know what things are where."
>
> So why do you ask when you ignore the answer?
>
>> side-position-interface::y-aligned-side above is a native Scheme
> function that
>> does not have the ly: prefix.
>
> You remove the prefix in this patch set.
Sorry, but I still don't understand what you mean.
ly:side-position-interface::y-aligned-side is defined in
side-position-interface.cc
side-position-interface::y-aligned-side is defined in output-lib.scm
The function defined in C++ has the ly: prefix, whereas the function defined in
Scheme doesn't.
>
>> > https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc
>> > File lily/grob.cc (right):
>> >
>> >
> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc#newcode866
>> > lily/grob.cc:866: if (to_boolean (scm_object_property
>> > (me->get_property_data ("stencil"), ly_symbol2scm ("ly:stencil?"
>> > Where is this object property being set?
>
>> In define-grobs.scm.
>
> I've looked very thoroughly without success. I can't find a setting
> of the ly:stencil? object property in your patch set, and I can't find
> it in the current code base, either.
>
> Care for a line number?
Ah, OK, I misunderstood your question.
In your reasking it, I now see (a) exactly what you mean; and (b) that I
screwed up this test. I fixed the test and posted a new patch set.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)
On 27 févr. 2013, at 19:06, d...@gnu.org wrote:
>
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly
> File input/regression/scheme-text-spanner.ly (right):
>
> https://codereview.appspot.com/7377046/diff/17001/input/regression/scheme-text-spanner.ly#newcode129
> input/regression/scheme-text-spanner.ly:129:
> side-position-interface::y-aligned-side)
> I really don't understand why you ask on the developer list about
> gratuitous prefix changes because of a different implementation language
> when you propose such changes right afterwards.
>
In my e-mail, I stated:
"I'd prefer if all native Scheme functions did not have the ly: prefix - it
helps to know what things are where."
side-position-interface::y-aligned-side above is a native Scheme function that
does not have the ly: prefix.
> https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc
> File lily/axis-group-interface.cc (right):
>
> https://codereview.appspot.com/7377046/diff/17001/lily/axis-group-interface.cc#newcode261
> lily/axis-group-interface.cc:261: if (!g->is_live ())
> Shouldn't you check for liveness before anything else?
The call to check the cross-staff property above could trigger the suicide.
In general, it is better to access properties first, suicide later.
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc
> File lily/grob-property.cc (right):
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-property.cc#newcode345
> lily/grob-property.cc:345: if (is_simple_closure (unpure))
> This is not related to this patch and review, but can anybody explain
> why this simple_closure $#!+ can't be replaced by a callable closure
> created using a smob type made callable via scm_set_smob_apply? Is it
> because of the delayed arg? Can't we deal with that by using a fluid
> (in Scheme, a parameter) in evaluate_with_simple_closure? These pseudo
> "simple" closures really make my head ache, and being able to throw all
> of them out would be quite a boon.
Agreed.
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc
> File lily/grob-scheme.cc (right):
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob-scheme.cc#newcode454
> lily/grob-scheme.cc:454: SCM_ASSERT_TYPE (ly_is_procedure (proc) ||
> is_unpure_pure_container (proc), proc, SCM_ARG2, __FUNCTION__,
> "procedure or unpure pure container");
> Possibly worth a named type predicate of its own?
Possibly. Could be in a separate patch.
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc
> File lily/grob.cc (right):
>
> https://codereview.appspot.com/7377046/diff/17001/lily/grob.cc#newcode866
> lily/grob.cc:866: if (to_boolean (scm_object_property
> (me->get_property_data ("stencil"), ly_symbol2scm ("ly:stencil?"
> Where is this object property being set?
In define-grobs.scm.
>
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm
> File scm/output-lib.scm (right):
>
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode61
> scm/output-lib.scm:61: (define-public
> (grob::wrap-in-unpure-pure-container fn)
> After issue 3200 passed, this is just ly:make-unpure-pure-container.
> Remove, change all its callers.
Ok. I'll try to remember for this patch set.
>
> https://codereview.appspot.com/7377046/diff/17001/scm/output-lib.scm#newcode89
> scm/output-lib.scm:89: (define-public
> grob::always-vertical-skylines-from-stencil
> I don't think that these are worth a definition of their own. Better
> expand them inline. An unpure-pure container is cheap enough that
> having separate containers for each use is not really a problem.
>
They reappear several times. It is a useful heuristic so that if I need to
change how this works, I only need to change it in one place instead of several.
Thanks for the review!
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Includes empty skylines in minimum translation calculations (issue 7304068)
On 27 févr. 2013, at 07:06, k-ohara5...@oco.net wrote: > Also needs some decruftification. > > > https://codereview.appspot.com/7304068/diff/22001/lily/align-interface.cc > File lily/align-interface.cc (right): > > https://codereview.appspot.com/7304068/diff/22001/lily/align-interface.cc#newcode299 > lily/align-interface.cc:299: vector non_empty_elems; > The disassembly and reassembly of the array is ridiculous, but with the > comment at least people will not be confused, merely laugh. > > https://codereview.appspot.com/7304068/diff/22001/scm/define-grobs.scm > File scm/define-grobs.scm (right): > > https://codereview.appspot.com/7304068/diff/22001/scm/define-grobs.scm#newcode2031 > scm/define-grobs.scm:2031: (horizon-padding . 100) > You don't need this anymore, and it will terribly confuse some poor > songwriter somewhere, if left in. Removed. Thanks for the review! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)
On 27 févr. 2013, at 07:03, k-ohara5...@oco.net wrote: > Just needs cleanup of some leftover unneeded complications. > > > https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc > File lily/skyline.cc (right): > > https://codereview.appspot.com/7310075/diff/38001/lily/skyline.cc#newcode488 > lily/skyline.cc:488: will be ignored. > What do you mean by "they will be ignored"? On line 501, empty segments > seem to be reversed, making non-empty segments. > Fixed. Bad copy and paste. > https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly > File ly/engraver-init.ly (right): > > https://codereview.appspot.com/7310075/diff/38001/ly/engraver-init.ly#newcode896 > ly/engraver-init.ly:896: \override Clef.Y-extent = > #grob::all-heights-from-stencil > Why the \overrride to the same value as its default ? Fixed. > > https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly > File ly/gregorian.ly (right): > > https://codereview.appspot.com/7310075/diff/38001/ly/gregorian.ly#newcode103 > ly/gregorian.ly:103: \once \override BreathingSign.Y-extent = > #grob::all-heights-from-stencil > This is now the default, so no need for overrides. Fixed. > > https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm > File scm/define-grobs.scm (right): > > https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1825 > scm/define-grobs.scm:1825: (Y-extent . > ,grob::unpure-empty-pure-point-height) > (Y-extent . ,grob::all-heights-from-stencil) > > We do not /want/ to allow outside-staff objects to slide down alongside > note-heads protruding from the staff, if by doing so they overlap any > repeat ties that might be there. I'll take this for a spin...not sure if it'll work but no harm regtesting it. My goal was to preserve the original behavior, but if this is better no harm in using it. > > https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1992 > scm/define-grobs.scm:1992: ; should preserve the span bar's presence for > horizontal spacing > "want this to be ignored" when ? > Presumably during staff-spacing, but what problem could it cause if not > ignored ? > It will be part of the skyline, potentially blocking things that shouldn't be blocked. > If staves would otherwise move away trying to make room for it, the > SpanBar avoids this using cross-staff = ##t The SpanBar has no height, so it is never taken into account in spacing. > > https://codereview.appspot.com/7310075/diff/38001/scm/define-grobs.scm#newcode1993 > scm/define-grobs.scm:1993: (Y-extent . > ,grob::unpure-empty-pure-point-height) > (Y-extent . (0 . 0)) > See above. > https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm > File scm/lily-library.scm (right): > > https://codereview.appspot.com/7310075/diff/38001/scm/lily-library.scm#newcode629 > scm/lily-library.scm:629: (define-public small-empty-interval '(0.01 . > -0.01)) > orphaned > Abandoned. > https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm > File scm/output-lib.scm (right): > > https://codereview.appspot.com/7310075/diff/38001/scm/output-lib.scm#newcode69 > scm/output-lib.scm:69: (ly:make-unpure-pure-container #f '(0 . 0))) > The changes to define-grobs.scm work for me, so this can be orphaned, > thankfully. I'm with you on RepeatTie, but not SpanBarStub. SpanBarStub needs to only have height in Separation_item::boxes which is accomplished via the addition of extra-spacing-height. Otherwise we don't want the spacing engine to know it's there. This can be accomplished (for now) by having a point pure height and adding the extra-spacing-height. The problem is that the notion "horizontal spacing equals pure height plus extra spacing height" is hardcoded into Separation_item::boxes. There should be horizontal-spacing-height and horizontal-spacing-width instead of extra-spacing-height and extra-spacing-width that has set as a default pure-height and width unless specified otherwise. But changing that would be a UI nightmare, so I'm reluctant to do it. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses only unpure-pure containers to articulate unpure-pure relationships. (issue 7377046)
On 27 févr. 2013, at 07:22, k-ohara5...@oco.net wrote: > The cardinal cantle seems meldable, but first the cruft needs to be > strained. > > > https://codereview.appspot.com/7377046/diff/11001/scm/define-grobs.scm > File scm/define-grobs.scm (right): > > https://codereview.appspot.com/7377046/diff/11001/scm/define-grobs.scm#newcode1827 > scm/define-grobs.scm:1827: (Y-extent . > ,grob::unpure-empty-pure-point-height) > (Y-extent . ,grob::always-Y-extent-from-stencil) Are you sure we want this? This isn't what was there previously. Previously, there was no height for these grobs save '(0 . 0) as a pure height. > > This leaked in from another patch set. > > https://codereview.appspot.com/7377046/diff/11001/scm/output-lib.scm > File scm/output-lib.scm (right): > > https://codereview.appspot.com/7377046/diff/11001/scm/output-lib.scm#newcode108 > scm/output-lib.scm:108: ;; decisions, so we make their unpure height #f. > This gives a way for an object to say: "Please leave space for me as if > I were just a dot, while I am still a virgin (before page-breaking) but > once I have carnal knowledge (during final page-layout) feel free to > print other things right on top of me." > Eeew. > As a developer whose work is pure as snow, I can't even fathom what you mean. My brain is going into catatonic mode to protect my innocence. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Musings on interfaces and properties
Hey all, Working on eliminating the translate_axis call from axis-group-interface, I've found a less-than-ideal situation in the naming/using of interfaces and properties that I'd like to clean up, but it'd be a major, major change and would take time to implement. So, before starting it as a project, I want to know if people think it is a good idea. Currently, interfaces can have whatever properties they want, leading things like `padding' or `staff-padding' to mean different things in different interfaces (tuplet-bracket-interface and side-position-interface, for example). This is bad when you try to mix functions from the two interfaces together that think these properties mean different things. To avoid this, there are a few steps we could take: 1) Require that, for a grob to use a callback from an interface, it must implement that interface. 2) Require that, for a callback to lookup a property, the property must be implemented by the interface that the callback is part of (i.e. ly:side-position-interface::y-aligned-side can only look up properties from side-position-interface). 3) Have interface multiple inheritance so that, for example, all properties of grob-interface are accessible by side-position-interface. 4) In cases where a grob implements multiple interfaces that have the same property, the property must be specified as property@interface (padding@side-position-interface). Otherwise, LilyPond issues a warning and sets all paddings to the value for all pertinent interfaces. 5) In define-grob-properties.scm, specify all interfaces for properties. What do people think? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)
On 25 févr. 2013, at 23:34, m...@mikesolomon.org wrote: > > On 25 févr. 2013, at 16:29, d...@gnu.org wrote: > >> On 2013/02/24 16:20:53, mike7 wrote: >>> On 24 févr. 2013, at 17:18, David Kastrup <mailto:d...@gnu.org> wrote: >> >>>> "m...@mikesolomon.org" <mailto:m...@mikesolomon.org> writes: >>>> >>>>> On 24 févr. 2013, at 16:37, mailto:d...@gnu.org wrote: >>>>> >>>>>> On 2013/02/24 13:27:39, mike7 wrote: >>>>>>> On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote: >>>>>> >>>>>>>> Stupid question: could you not just check whether >>>>>>>> outside-staff-priority has been set, and if it has, pass the >> buck >>>>>>>> to the right kind of callback automatically? That way, the user >>>>>>>> does not need to meddle with callbacks himself. >>>>>> >>>>>>> Yup, but it'd require creating an Outside_staff_callback engraver >>>>>>> with a call to acknowledge_grob. Calls to acknowledge_grob are >>>>>>> expensive and should be used only if there's no other viable >>>>>>> solution. >>>>>> >>>>>> Why can't the current Y-offset callback check >> outside-staff-priority >>>>>> on the grob? Why would there be a need for an acknowledger? >>>>> >>>>> That's exactly how the new Y-offset callbacks are implemented in >> this >>>>> patch set. The problem is that not all grobs have a Y-offset >>>>> callback. >>>> >>>> Well, something heeded outside-staff-priority previously, apparently >>>> calculating an offset based on it. What happened to it? >> >>> Before, there was a call to translate_axis. It wasn't done as a >>> callback for a Y-offset property but rather a vertical-skylines >>> property for VerticalAxisGroup that called translate_axis many times >>> (follow, in current master, >>> Axis_group_interface::calc_vertical_skylines to >>> avoid_outside_staff_collisions and you'll see how this is done). >>> This makes it impossible to wipe caches and recompute properties >>> with more information. The goal of this patch is to eliminate that >>> call to translate_axis so that the callback(s) for Y-offset >>> calculate the entire offset, which means we can cache and recache >>> pure equivalents. >> >> This is really like pulling teeth. Something _obviously_ consults >> Y-offset, or overriding it with a callback would not have an effect. >> Now said something can also check Y-offset for being unset (presumably >> the default) and outside-staff-priority for being set (the >> non-default) and call up the most likely of the totally dissimilarly >> named callbacks you mention in changes.tely without bothering to say >> which one to choose under what circumstances. >> >> Can you _merge_ those callbacks? Then there is no need to pick one. >> > > They are currently merged in that y-aligned-side automatically calls > calc-outside-staff-y-offset at the end. I forget why I didn't merge them > completely - there was a reason at one point, but they may be mergeable. > Will look into it. I see now why I didn't merge these two functions. The tuplet-bracket-interface currently implements a property called 'padding that would be read by helper functions called via ly:side-position-interface::y-aligned-side. We don't want this, so we write a second function that circumvents this and only does outside staff positioning. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)
On 25 févr. 2013, at 16:29, d...@gnu.org wrote: > On 2013/02/24 16:20:53, mike7 wrote: >> On 24 févr. 2013, at 17:18, David Kastrup <mailto:d...@gnu.org> wrote: > >> > "m...@mikesolomon.org" <mailto:m...@mikesolomon.org> writes: >> > >> >> On 24 févr. 2013, at 16:37, mailto:d...@gnu.org wrote: >> >> >> >>> On 2013/02/24 13:27:39, mike7 wrote: >> >>>> On 24 févr. 2013, at 12:40, mailto:d...@gnu.org wrote: >> >>> >> >>>>> Stupid question: could you not just check whether >> >>>>> outside-staff-priority has been set, and if it has, pass the > buck >> >>>>> to the right kind of callback automatically? That way, the user >> >>>>> does not need to meddle with callbacks himself. >> >>> >> >>>> Yup, but it'd require creating an Outside_staff_callback engraver >> >>>> with a call to acknowledge_grob. Calls to acknowledge_grob are >> >>>> expensive and should be used only if there's no other viable >> >>>> solution. >> >>> >> >>> Why can't the current Y-offset callback check > outside-staff-priority >> >>> on the grob? Why would there be a need for an acknowledger? >> >> >> >> That's exactly how the new Y-offset callbacks are implemented in > this >> >> patch set. The problem is that not all grobs have a Y-offset >> >> callback. >> > >> > Well, something heeded outside-staff-priority previously, apparently >> > calculating an offset based on it. What happened to it? > >> Before, there was a call to translate_axis. It wasn't done as a >> callback for a Y-offset property but rather a vertical-skylines >> property for VerticalAxisGroup that called translate_axis many times >> (follow, in current master, >> Axis_group_interface::calc_vertical_skylines to >> avoid_outside_staff_collisions and you'll see how this is done). >> This makes it impossible to wipe caches and recompute properties >> with more information. The goal of this patch is to eliminate that >> call to translate_axis so that the callback(s) for Y-offset >> calculate the entire offset, which means we can cache and recache >> pure equivalents. > > This is really like pulling teeth. Something _obviously_ consults > Y-offset, or overriding it with a callback would not have an effect. > Now said something can also check Y-offset for being unset (presumably > the default) and outside-staff-priority for being set (the > non-default) and call up the most likely of the totally dissimilarly > named callbacks you mention in changes.tely without bothering to say > which one to choose under what circumstances. > > Can you _merge_ those callbacks? Then there is no need to pick one. > They are currently merged in that y-aligned-side automatically calls calc-outside-staff-y-offset at the end. I forget why I didn't merge them completely - there was a reason at one point, but they may be mergeable. Will look into it. > Setting something like outside-staff-priority is still stuff that > users can comprehend (and that's actually documented in the manuals). > Having to pick one of several totally differently named callbacks > without useful documentation is _not_ a user interface. > > That's internals. The goal of the patchset is for all outside-staff grobs to still respond to outside-staff-priority. Are there any outside-staff grobs (Slur, Script, TupletBracket, whatever) that currently don't function like they used to in the given patch set? I didn't find a single one. > >> I think the current patch is fine. > > It does not have a usable user interface. It is not an option for a > user to choose between several undocumented callbacks. > I will document those two callbacks or the one callback if I merge them. What I'd appreciate is a list of outside-staff grobs as defined in the documentation that, with my patch set apply, no longer respond to outside-staff-priority. I believe that I've covered all the pertinent grobs. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtest 2.17.13
On 25 févr. 2013, at 15:10, David Kastrup wrote: > James writes: > >>> On 25 February 2013 12:00, David Kastrup wrote: >>> >>>"Phil Holmes" writes: >>> I've run my pixel comparator on 2.17.13 versus 2.17.12 (note - the output shows this as 2.17.11 since the windows exe contained the wrong version number). Output is at http://philholmes.net/lilypond/regtestresults/2.17.13/ As might be supposed, most of the differences are connecting bar lines. >>> >>> >>>Good grief. Yes. A real pity that our default regtest comparisons >>>blanked those out. >>> >>> >>> Well it could always be a case of me missing that assuming I did the >>> check. > > Unlikely. It is pretty likely that I also looked at regtest > differences, and the differences are far from subtle and rare. So I am > pretty sure that the tests were not given any visual presentation, > instead just being filtered prematurely based on the metrics. > > -- > David Kastrup > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel This is the case. Span Bar heights do not come from stencils (I believe they have an empty height by default), so changes in the stencils won't appear in the regtests comparisons, which focus exclusively on changes in height and width. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
