Re: untangling the remaining regressions
David Kastrup dak at gnu.org writes: (1) The positioning of fingerings using the outline of the note-column (the last patch under issue 2527) is a user-visible improvement, so it would be nice to keep it. I have posted patches to solve two issued (3465 and 3363) were caused by the fingering patch, so maybe we can go forward. I've tried a revert recently, and the number and nature of revert conflicts, probably partly because of related followup fixes, was rather ugly. This is entangled rather badly in our code history. Presumably you first reverted the follow-up patches, for issues 3327 3242 and 3109. If it is that complicated to retreat, it seems wiser to fix the remaining bugs and go forward. The fingering patch might also have made issue 601 worse, It did so. I have separated the new part of the bug into issue 3497. and possibly re-broken issue 40. No, that was the patch to tighten accidental placement, issue 2811. Studying the original fix for issue 40 and the patch for 2811, might make the proper solution clear. (2) The expanded use of unpure-pure containers (issue 3199) is a reorganization of the code. Overall, I think the patch makes things simpler, conceptually. The problem is that the patch in question does dozens of different things in a single commit, a number of which are not even related to the issue. Oh. Well if the regressions were caused by any of the unrelated things we can just reverse that part of the patch. We do have a patch posted under issue 3385 that reverts 3199 entirely, with a clean `make check`. I think the remaining problems that it caused (issue 3385, issue 3359 and blocking the patch for issue 3363) come from its removal of the test 'pure-relevant?', which ignored some objects for purposes of estimating the heights of staves for the planning of line/page-breaking (i.e., the pure-heights of VerticalAxisGroups). But they should have been replaced by pure-unpure-containers. Well, the function-pairs that calculate/estimate the heights or positions of these object have been linked together into pure-unpure-containers. Formerly, only objects with an explicit 'pure' (estimating) function were considered 'pure-relevant' but in the new design everything is pure-relevant. Mike posted three patches to issue 3385 that attempted to go halfway backwards, partially restoring the pure-relevant? test, but these ran into regressions. Going forward would be to make the pure versions of these functions, actually work properly before line-breaking, without triggering other calculations prematurely (i.e., make them acually 'pure'). That approach looks like it might do some untangling, by solving issued 3385 and 3363 together. The remaining regression would be the erroneous cross-staff tie, issue 3395, which has always been an error but now crashes LilyPond. For that, we should ensure in the code that the pure-Y-common (a.k.a. common_refpoint_of array) of a set of objects used to find the height of a staff, is the staff in question, because other code assert()s that condition. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: untangling the remaining regressions
On 14 août 2013, at 09:58, Keith OHara k-ohara5...@oco.net wrote: Mike posted three patches to issue 3385 that attempted to go halfway backwards, partially restoring the pure-relevant? test, but these ran into regressions. Going forward would be to make the pure versions of these functions, actually work properly before line-breaking, without triggering other calculations prematurely (i.e., make them acually 'pure'). I think my most recent patch set for 3385 does this. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for August 17th - 06:00 GMT
Hello *Countdown – August 17th – 06:00 GMT* * * * * * * * * 3487http://code.google.com/p/lilypond/issues/detail?id=3487q=label%3APatch-countdownsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Summary%20Modified Enhancement David Kastrup push Patch: Make several special characters with or without backslash non-special 3468http://code.google.com/p/lilypond/issues/detail?id=3468q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Other David Kastrup Countdown lilypond-book and spaces in application name 3493http://code.google.com/p/lilypond/issues/detail?id=3493q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup Countdown Patch: Let Skyline's copy constructor use whole-sale copy construction of members 3408http://code.google.com/p/lilypond/issues/detail?id=3408q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Phil Holmes Countdown Doc suggestion: include final double bar in some Learning Manual examples 3494http://code.google.com/p/lilypond/issues/detail?id=3494q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Julien Rioux Countdown Patch: make website fails on platforms where python3 is the default. 3214http://code.google.com/p/lilypond/issues/detail?id=3214q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Phil Holmes Countdown Insufficient spacing between footnote block and tagline 3465http://code.google.com/p/lilypond/issues/detail?id=3465q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Critical Keith Ohara Countdown Pitched trill layout Regression *Moved to 'Needs Work' this countdown* 3491http://code.google.com/p/lilypond/issues/detail?id=3491q=label%3APatch-reviewsort=modified%20patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Mark Polesky Needs Work Add \displayMarkup command. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for August 17th - 06:00 GMT
James wrote: Moved to 'Needs Work' this countdown 3491 Enhancement Mark Polesky Needs Work Add \displayMarkup command. ... Thomasmorely651 has some comments James, can you move my patch into the countdown for the 17th? I incorporated Harm's suggestions a day ago. Thanks, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for August 17th - 06:00 GMT
Mark, On 14 August 2013 08:43, Mark Polesky markpole...@yahoo.com wrote: James wrote: Moved to 'Needs Work' this countdown 3491 Enhancement Mark Polesky Needs Work Add \displayMarkup command. ... Thomasmorely651 has some comments James, can you move my patch into the countdown for the 17th? I incorporated Harm's suggestions a day ago. Thanks, Mark I can, but just so you know, I'm not the final say on this :) so you can just do this yourself as well. That is if a 'real developer' sees that I have made a mistake or misinterpreted something in the tracker or Rietveld (especially when conversation between devs gets a bit convoluted) then by all means correct my mistake - David et al, do this all the time. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for August 17th - 06:00 GMT
James pkx1...@gmail.com writes: That is if a 'real developer' sees that I have made a mistake or misinterpreted something in the tracker or Rietveld (especially when conversation between devs gets a bit convoluted) then by all means correct my mistake - David et al, do this all the time. Well, it seems like I am a stickler for authority: when I bypass procedures then rarely by overriding a decision of yours but rather by not giving you a chance to make one... Partly that's just because potential reviewers also rely on your decisions, so if you put back a patch from countdown or don't even place it on one, people might just have postponed taking a look. So I tend to be rather careful about overriding review-focused decisions without a good reason. While I am rather reckless once I decide that a given patch is not material asking for a second opinion _and_ has some urgency. So with non-urgent review-worthy patches that have been taken off from countdown or review by clerical mistake, I often grit my teeth and reenter the cycle, usually with a verbose explanation in order to avoid cycling another time for the same reason. It's not like it's causing major damage or something. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
Hi, i'm late with my comments but i'll publish them anyway. A general question: what about using -' or -, for staccatissimo? For me they seem to be somewhat more intuitive. Janek https://codereview.appspot.com/12432043/diff/23001/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/12432043/diff/23001/lily/parser.yy#newcode2719 lily/parser.yy:2719: $$ = scm_from_locale_string (Bang); Why is this Bang and not Exclaim? https://codereview.appspot.com/12432043/diff/23001/ly/script-init.ly File ly/script-init.ly (right): https://codereview.appspot.com/12432043/diff/23001/ly/script-init.ly#newcode9 ly/script-init.ly:9: dashBang = staccatissimo ditto https://codereview.appspot.com/12432043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
On 2013/08/14 11:41:43, janek wrote: A general question: what about using -' or -, for staccatissimo? For me they seem to be somewhat more intuitive. Additional advantage would be that they don't require Shift to produce on standard keyboard. Janek https://codereview.appspot.com/12432043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
The content LGTM. https://codereview.appspot.com/12724043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
make website fails on platforms where python3 is the default. (issue 12769043)
LGTM https://codereview.appspot.com/12769043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Increase tagline spacing (Issue 3214) (issue 12562050)
LGTM https://codereview.appspot.com/12562050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
trill-pitch-engraver: acknowledge stems and flags; issue 3465 (issue 12844043)
LGTM. https://codereview.appspot.com/12844043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
On 2013/08/14 11:43:08, janek wrote: On 2013/08/14 11:41:43, janek wrote: A general question: what about using -' or -, for staccatissimo? For me they seem to be somewhat more intuitive. Additional advantage would be that they don't require Shift to produce on standard keyboard. Janek I don't really agree. staccato is -. so it seems natural for me to have staccatissimo as -! (I mean, it was -| before). In addition, ' and , are slanted in most fonts and that does not really match the visuals of staccatissimo. I crosschecked with the parser and it would not object to either. The only argument _for_ such a change would be more visual similarity rather than mnemonic value and that rules out -, pretty definitely. One could talk about -' at most. It would be sort of a nuisance to change that including all documentation again but there would be no technical problem doing that. https://codereview.appspot.com/12432043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: trill-pitch-engraver: acknowledge stems and flags; issue 3465 (issue 12844043)
I'm in a rush right now so can't test. But would that even help with whole notes and breves? https://codereview.appspot.com/12844043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How are stems created?
Hi Phil, 2013/7/30 Phil Holmes em...@philholmes.net: I've been experimenting with alternative algorithms to create the flags used in mensural notation (see http://code.google.com/p/lilypond/issues/detail?id=3105), and part of the problem appears to be that the stems aren't attached symmetrically to the notehead. I'm not sure whether this is deliberate or not, but I would like to look at it. Could someone who understands this part of LilyPond explain how and where stems are added to noteheads (and, for completeness, flags are attached to stems)? Are you still working on this? I was looking at this area of the code with my alignment work (http://code.google.com/p/lilypond/issues/detail?id=3239 and others, which are the foundation for actually merging some of my gsoc work). I would be interested in collaborating on this. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
2013/8/14 d...@gnu.org: I don't really agree. staccato is -. so it seems natural for me to have staccatissimo as -! (I mean, it was -| before). In addition, ' and , are slanted in most fonts and that does not really match the visuals of staccatissimo. I crosschecked with the parser and it would not object to either. The only argument _for_ such a change would be more visual similarity rather than mnemonic value and that rules out -, pretty definitely. One could talk about -' at most. It would be sort of a nuisance to change that including all documentation again but there would be no technical problem doing that. Hmm. would there be a technical problem to have /both/ -! and -' as shorthands for staccato? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: trill-pitch-engraver: acknowledge stems and flags; issue 3465 (issue 12844043)
2013/8/14 d...@gnu.org: I'm in a rush right now so can't test. But would that even help with whole notes and breves? Good point. But i think that this can be added anyway, as it makes sense in itself. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
maintaining advanced power-user Scheme functions
Hi, Harm and David N. (and some other people) write lots of very advanced (and very helpful!) Scheme functions. These funcitons are improved over time, and there is a problem related to that: it's easy to get lost in all the email threads about them, and it's not always obvious where the most recent version is. I think that such functions should be tracked by version control, and i see two approaches: - include them in official LilyPond source as soon as they are created. Upside: there's bigger chance that they will be updated when there are some changes. Downside: one has to write documentation and go through official patch submitting channels. - use another repository. What about OpenLilyLib? http://www.openlilylib.org/ At any rate, we better do something about it - at current state, all these funcitons can easily become lost or forgotten, and that would be a grave loss. Thoughts? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
colorful make output! yum!
Hi, my cousin Franek changed the output of make from a heap of unreadable gobbledygook to some delicious eye-candy! Checkout branch dev/frax/colorful-make and build lilypond. How do you like it? As for me, i can spend whole day just looking at lilypond being built. I think we should add this to master asap :D (of course, after polishing some rough edges) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
On 2013/08/14 12:18:12, janek wrote: 2013/8/14 d...@gnu.org: I crosschecked with the parser and it would not object to either. The only argument _for_ such a change would be more visual similarity rather than mnemonic value and that rules out -, pretty definitely. One could talk about -' at most. It would be sort of a nuisance to change that including all documentation again but there would be no technical problem doing that. Hmm. would there be a technical problem to have /both/ -! and -' as shorthands for staccato? Technical? Not really except that we'd have to make a choice of convert-ly rule. But I don't think we help anybody by providing two shorthands for one particular articulation. Anybody else with an opinion regarding -! or -' (and of course the corresponding _! ^! _' ^' too) as the shorthand for staccatissimo, replacing the previous -| (which would not work due to technical reasons). https://codereview.appspot.com/12432043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
Janek Warchoł janek.lilyp...@gmail.com writes: Hi, my cousin Franek changed the output of make from a heap of unreadable gobbledygook to some delicious eye-candy! Checkout branch dev/frax/colorful-make and build lilypond. How do you like it? As for me, i can spend whole day just looking at lilypond being built. I think we should add this to master asap :D (of course, after polishing some rough edges) We have enough trouble maintaining our toolchain as it is. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How are stems created?
- Original Message - From: Janek Warchol janek.lilyp...@gmail.com To: Phil Holmes em...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Wednesday, August 14, 2013 1:09 PM Subject: Re: How are stems created? Hi Phil, 2013/7/30 Phil Holmes em...@philholmes.net: I've been experimenting with alternative algorithms to create the flags used in mensural notation (see http://code.google.com/p/lilypond/issues/detail?id=3105), and part of the problem appears to be that the stems aren't attached symmetrically to the notehead. I'm not sure whether this is deliberate or not, but I would like to look at it. Could someone who understands this part of LilyPond explain how and where stems are added to noteheads (and, for completeness, flags are attached to stems)? Are you still working on this? I was looking at this area of the code with my alignment work (http://code.google.com/p/lilypond/issues/detail?id=3239 and others, which are the foundation for actually merging some of my gsoc work). I would be interested in collaborating on this. Janek Actively working right now? No. Forgotten it? No. I can get perfectly aligned mensural flags on stems - there was really a bug in the way the old ones were reversed. I need to work on the flags' shape - I have a few scans of music from 1500-1600 and the flags and will work on these. Let me know what you're interested in. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How are stems created?
Hi Phil, 2013/8/14 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol Are you still working on this? I was looking at this area of the code with my alignment work (http://code.google.com/p/lilypond/issues/detail?id=3239 and others, which are the foundation for actually merging some of my gsoc work). I would be interested in collaborating on this. Actively working right now? No. Forgotten it? No. I can get perfectly aligned mensural flags on stems - there was really a bug in the way the old ones were reversed. I need to work on the flags' shape - I have a few scans of music from 1500-1600 and the flags and will work on these. Let me know what you're interested in. I'd like to change stem and flag code so that stems, flags and noteheads are attached to each other using generic functions from Self_alignment_interface instead of their own funcitons (if that's possible). Fiddling with metafont code can be interesting as well. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How are stems created?
- Original Message - From: Janek Warchoł janek.lilyp...@gmail.com To: Phil Holmes m...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Wednesday, August 14, 2013 6:20 PM Subject: Re: How are stems created? Hi Phil, 2013/8/14 Phil Holmes m...@philholmes.net: - Original Message - From: Janek Warchol Are you still working on this? I was looking at this area of the code with my alignment work (http://code.google.com/p/lilypond/issues/detail?id=3239 and others, which are the foundation for actually merging some of my gsoc work). I would be interested in collaborating on this. Actively working right now? No. Forgotten it? No. I can get perfectly aligned mensural flags on stems - there was really a bug in the way the old ones were reversed. I need to work on the flags' shape - I have a few scans of music from 1500-1600 and the flags and will work on these. Let me know what you're interested in. I'd like to change stem and flag code so that stems, flags and noteheads are attached to each other using generic functions from Self_alignment_interface instead of their own funcitons (if that's possible). Fiddling with metafont code can be interesting as well. cheers, Janek I'd concluded that they are attached because they have a common origin, so if this is wrong I probably won't be able to help. Always willing to try, though. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
Janek Warchoł writes: my cousin Franek changed the output of make from a heap of unreadable gobbledygook to some delicious eye-candy! Checkout branch dev/frax/colorful-make and build lilypond. How do you like it? The result looks nice but if you want any chance of putting this in, it should be rewritten as a make post-processor (IMHO of course), think make | build/aux/colorful.py Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for August 17th - 06:00 GMT
David Kastrup wrote: Partly that's just because potential reviewers also rely on your decisions, so if you put back a patch from countdown or don't even place it on one, people might just have postponed taking a look. With that in mind, developers should be sure to review my patch, which is now back in the countdown: http://codereview.appspot.com/12732043/ Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
LGTM https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
LGTM, apart from a query
https://codereview.appspot.com/12945044/diff/1/lily/ledger-line-spanner.cc
File lily/ledger-line-spanner.cc (right):
https://codereview.appspot.com/12945044/diff/1/lily/ledger-line-spanner.cc#newcode331
lily/ledger-line-spanner.cc:331: property of the
@rinternals{StaffSymbol} grob.,
Should this not be @ref{...}?
https://codereview.appspot.com/12945044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: maintaining advanced power-user Scheme functions
2013/8/14 Janek Warchoł janek.lilyp...@gmail.com: Hi, Harm and David N. (and some other people) write lots of very advanced (and very helpful!) Scheme functions. These funcitons are improved over time, and there is a problem related to that: it's easy to get lost in all the email threads about them, and it's not always obvious where the most recent version is. I think that such functions should be tracked by version control, and i see two approaches: - include them in official LilyPond source as soon as they are created. Upside: there's bigger chance that they will be updated when there are some changes. Downside: one has to write documentation and go through official patch submitting channels. - use another repository. What about OpenLilyLib? http://www.openlilylib.org/ At any rate, we better do something about it - at current state, all these funcitons can easily become lost or forgotten, and that would be a grave loss. Thoughts? Janek Hi Janek, well, if I think one of my functions, definitions etc is worth a patch, I do so, but ofcourse there's the risk I'm distracted by other tasks and forget about it or I've no time or ... The idea of version-control for such functions might be nice. But because I'm still not very familiar with git I'm feeling kind of ambivalent. Otoh, it might be an idea to do so for the LSR. Though, a lot of my functions, definitions etc are too special-cased, written to fit some users needs or they are workarounds not worth a patch. The right place for them would be the LSR, _if_ the LSR would be able to compile them and not use a LilyPond-version far too old for many of my ideas. There were some insinuations on the list the last months (or was it a year already?) to upgrade the LSR and yes, one should do so. But I hesitate to volunteer again for this task. I initiated the last ugrade and did perhaps the major work, supported by several developers and the great David Nalesnik. Though there was only one, I repeat _one_, other user who tried to help: Philippe Hezaine @Philippe Thanks a lot for trying to help. And let me say: You didn't waste my time! So I was annoyed by the lack of help/interest of others and I'm still pissed off. After my experience from doing it once, let me say: _Every_ user can start the LSR-upgrade. The relevant CG-chapter is in far better state than it was the last time. Ok, there will be snippets which need some (perhaps advanced) scheme-knowledge and there may be some which need advice from an experinced developer. Some tasks will need to be done by people, who have the permission (from the LSR-maintainer) to do so. But let me repeat: _Every_ user can start the LSR-upgrade. Volunteers? Be sure that I'd grant support. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: maintaining advanced power-user Scheme functions
Hi Janek, Hi Harm, 2013/8/14 Thomas Morley thomasmorle...@gmail.com So I was annoyed by the lack of help/interest of others and I'm still pissed off. Sorry for that, I think I totaly missed this discussion. Volunteers? Be sure that I'd grant support. Sure ! Maybe give me some links where I can find how to do it. Cheers, Pierre ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
On 15 août 2013, at 08:35, k-ohara5...@oco.net wrote: Of course this is two commits. probably three (axis-group-interface.cc and two independent changes in side-position-interface.cc). I do not know of any reason to distinguish the concept of 'cross-staff' from your new height_depends_on_grobs_from_another_vertical_ axis_group() In most cases, 'cross-staff' means exactly that the height (Y-extent) depends on staff-spacing. cross-staff is a non-exhaustive subset of this. your original fix to 3363 was the right way to go, but it would retrigger 3385, even with my fix. i prefer to keep it and fix the bug that it reveals, which is what this patch does. to fix 3385, we need for beam quanting not to be triggered by vertical axis group skyline calculations, which requires weeding out both cross-staff-grobs and all grobs whose heights depend on cross-staff grobs. this includes the ottava bracket, which we agreed not to mark as cross-staff. Could you mark the relevant object as 'cross-staff' when the cross-staff item is added to it 'support', rather than search through its support later? see above: this would mean that ottava brackets are marked as cross-staff, which we don't want. I am completely stumped how skipping some objects in computing skylines for staff-spacing has anything to do with quantizing. skipping means that quanting is not triggered. https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc File lily/side-position-interface.cc (right): https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc#newcode274 lily/side-position-interface.cc:274: // In the case of a stem, we will find a note head as well The comments are out of date ok https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc#newcode284 lily/side-position-interface.cc:284: !is_direction (e-get_property_data (direction) Now you skip *all* stems whose direction is still uncertain, while before you skipped only cross-staff stems of uncertain direction. That seems fine, but makes a lot more sense if the decisions about stems are all together in the next if()continue down below. I prefer to keep this as is, as they are two conceptually different things. The first if()continue tests to make sure that certain things don't happen in pure lookups. The second excludes stems that aren't conceptually supports because they don't point in the same direction as the supported grob. I've changed the comments a bit to better reflect this. https://codereview.appspot.com/12951044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
