Re: Better pure heights for slurs (issue 5431065)
Keith, retested. http://code.google.com/p/lilypond/issues/detail?id=2051#c9 passes make and a new set of reg test diffs are up. James http://codereview.appspot.com/5431065/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
commit a228baa1e5bb0f0d6
Uh, this reads
commit a228baa1e5bb0f0d65c371e7da5076a7d8f58a5e
Author: David Kastrup
Date: Fri Nov 25 18:39:58 2011 +0100
Tiny convertrule fix for occurences of 2468 inside of embedded Scheme with
#{ ... #}
and now it has already made its way into master so I can't change that
cryptic description. Just for personal amusement of the posters, this
commit has likely been created using
git commit -m "Tiny convertrule fix for occurences of $$ inside of ...
I need to pick my quote characters more carefully... Now you all know
the process id of the shell with which I made the commit.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR updates and Issue 1971
- Original Message - From: "Graham Percival" To: "Phil Holmes" Cc: "Devel" Sent: Friday, November 25, 2011 7:10 PM Subject: Re: LSR updates and Issue 1971 On Fri, Nov 25, 2011 at 05:59:04PM -, Phil Holmes wrote: I've got a large patch that updates the snippets from the LSR and fixes Issue 1971. It's a few hundred files. make and make doc are fine after adding it. Should I push to staging or do something like a review - it seems unlikely anyone will have the enthusiasm to review all 300-odd changed files. Excellent! I'd personally prefer to split it into 2 separate commits: 1. run makelsr.py locally (i.e. don't point it at your tarball). this will update the GIT_COMMITISH for every single file. Quite annoying, pollutes the history, but apparently translators need that. if you skim over the patch in gitk, you shouldn't see anything weird. commit that and push directly to staging. Depends what counts as weird. I see lots of commitish changes, and one or two others - e.g. translation changes. I'm guessing that this is because master and staging aren't quite lined up at present? Should I wait until those changes in staging are committed, or push anyway? 2. run makelsr.py and point at the downloaded LSR directory. look at that patch more carefully, then please upload it for review -- there should be 1-20 changed files. Maybe 30. we won't bother with a full countdown, but I'd like to skim it before you push it. Willdo. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)
Passes Make - reg tests here: http://lilypond-stuff.1065243.n5.nabble.com/Tracker-2053-26-November-td5023673.html Jam http://codereview.appspot.com/5432070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
chords grid
hi
i am Sacha, new user of Lilypond
i wanted to suggest you the implementation of something very simple in Lilypnd
to get Chord grids
for example a \Chordgrid (width= height = number of raws = number of columns =)
{a/c b:7} etc
that would be very useful
Xavier worked for me and managed to get a grid to whom it misses one line...
and his code was (i find) very complicated
regards
Sacha
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: OT: Vocal music (was Re: Better pure heights for slurs (issue 5431065))
I saw Steven Schick and Shahrokh Yadegari perform this live, and it literally changed me as a musician — one of the top ten artistic experiences of my entire life. Here's a sample: Of course, video doesn't match the insane spectacularity of the live performance (both by Schick and the live processing by Yadegari). Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)
On 2011/11/26 07:32:48, dak wrote: The functionality seems to be there just fine. What makes you suspect that this copying-of-properties-at-definition-and-documentation-time is responsible for a crash? I'm just flying blind. Mike pointed out that using properties that weren't in an interface could lead to segfaults. My thought was that since the whole function was copied into the properties argument, things that weren't properties would be set, which could trigger the segfaults that Mike had identified. And eliminating this code eliminated the segfault. I know you've pushed a different patch, which fixes Issue 1900, but doesn't fix 1997. Have you tried this patch to see if it fixes 1997? Thanks, Carl http://codereview.appspot.com/5432081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)
I know you've pushed a different patch, which fixes Issue 1900, but doesn't fix 1997. Have you tried this patch to see if it fixes 1997? I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you have a reference for Mike's analysis? It seems we should rather fix the segfault at its source than hide one way of getting it. http://codereview.appspot.com/5432081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)
On 2011/11/26 15:07:17, dak wrote: I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you have a reference for Mike's analysis? http://lists.gnu.org/archive/html/lilypond-devel/2011-11/msg00556.html It seems we should rather fix the segfault at its source than hide one way of getting it. I agree with you. Thanks, Carl http://codereview.appspot.com/5432081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)
On 2011/11/26 15:15:25, Carl wrote: On 2011/11/26 15:07:17, dak wrote: > > I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you > have a reference for Mike's analysis? http://lists.gnu.org/archive/html/lilypond-devel/2011-11/msg00556.html > > It seems we should rather fix the segfault at its source than hide one way of > getting it. I agree with you. Any way, your patch does not fix the segfault on Ubuntu 11.10 without specific compilation options, so we can as well forget it, I guess. Mike, any more details regarding your analysis? If we don't have the documentation considered as an essential part of our garbage protection scheme, it might make sense to disable _all_ documentation for testing purposes, and then see whether we get more useful segfaults than previously. http://codereview.appspot.com/5432081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)
On 2011/11/26 15:43:34, dak wrote: On 2011/11/26 15:15:25, Carl wrote: Any way, your patch does not fix the segfault on Ubuntu 11.10 without specific compilation options, so we can as well forget it, I guess. OK, I'll close this issue. We have a record of the conversation on -devel. Thanks, David. Carl http://codereview.appspot.com/5432081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Better pure heights for slurs (issue 5431065)
On Nov 26, 2011, at 4:11 AM, k-ohara5...@oco.net wrote:
> On 2011/11/26 02:09:57, Keith wrote:
>> Maybe the *0.5 was converting half-staff-spaces to staff-spaces
> No; the units are fine.
>
> The problem seems to be not so much the overestimate of the slur extent,
> but that said overestimate of space is allowed before each each script
> with avoid-slur 'outside :
>
> \paper{ annotate-spacing = ##t }
> \layout { \context { \Score
> \override PaperColumn #'stencil = #ly:separation-item::print
> }} #(ly:set-option 'debug-skylines)
> { b2( d')_>_\downbow_3 }
Pacifier prints to the command line from side-position-interface.cc are
verifying to me that that's indeed the real problem. Do you feel like tackling
it? If not, I'll have some time in a couple weeks.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)
On Nov 26, 2011, at 9:56 PM, Keith OHara wrote: > Mike, Maybe change-clefs should not get the full extra-spacing-height by > default. I could do this if I could call Item::break_visible before line breaking (which would let me know which clefs are change clefs as opposed to beginning-of-line-clefs). However, I remember Neil saying that this was a bad idea, although I don't remember why. Any ideas why this call isn't Kosher? > Engravers tend to tuck change-clefs in with the least possible disruption of > the note spacing. > > Also, the test 'dots.ly' shows a ledger line sliding under a bar line. > I think the (-1 . +1) extra-spacing height for the BarLine is not quite > enough. LilyPond gives ledger line columns only the minimum necessary > extra-spacing height, which I think is correct because traditionally and > practically people slide neighboring accidentals under ledger lines. > Perhaps a stupid question, but why does LilyPond even take ledger lines into account if they have no vertical or horizontal extent? How do they factor into the spacing calculations? > Also, there are still two definitions for extra-spacing height in > TimeSignature. Will fix. I see that you too have found in Debussy a gold mine of NonMusicalPaperColumn quandaries. I am convinced that he anticipated the existence of LilyPond and purposefully composed music to complicate our lives. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR updates and Issue 1971
On Sat, Nov 26, 2011 at 12:53:55PM -, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > >if you skim over the patch in gitk, you shouldn't see anything > >weird. commit that and push directly to staging. > > Depends what counts as weird. I see lots of commitish changes, and > one or two others - e.g. translation changes. I'm guessing that > this is because master and staging aren't quite lined up at present? No; translators work on snippets, but their work doesn't become visible until you run makelsr.py locally. > Should I wait until those changes in staging are committed, or push > anyway? eh... could do either. If you can see more translation stuff in staging, then I suppose it won't hurt to wait a few hours until James does the merge. (come to think of it, by the time you receive this email, he'll probably have already done it) Certainly nothing in your description sounds like "weird" to me, so if you make another patch and it looks similar, go ahead and push. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses the pure-from-neighbor-interface for NonMusicalPaperColumn horizontal spacing. (issue 5432070)
On Sat, 26 Nov 2011 14:48:29 -0800, m...@apollinemike.com
wrote:
On Nov 26, 2011, at 9:56 PM, Keith OHara wrote:
Mike, Maybe change-clefs should not get the full extra-spacing-height by
default.
I could do this if I could call Item::break_visible before line breaking (which
would let me know which clefs are change clefs as opposed to
beginning-of-line-clefs). However, I remember Neil saying that this was a bad
idea, although I don't remember why. Any ideas why this call isn't Kosher?
Oops. I was thinking the smaller change clef was a different "grob", but it is
not.
'break_visible' calls break_status_dir() to look up whether an item is visible
based on the results of line-breaking, so you don't want that. Now I see that
the clef:calc_glyph_name() does the same.
I think all the Clefs that exist before line-breaking should be change clefs,
with the begin-of-line clefs added afterwards. Probably best if no Clefs use
the pure-from-neighbor height, certainly not CueClefs.
The distinction between beginning-of-line and middle-of-line spacing is made
with 'space-alist'. Most of the spacing based on the meaning, rather than
extent, of symbols is done with that system.
Actually, your "don't-hang-over-me" rule would fit there nicely as a new type in a 'space-alist' to go
alongside "minimum-space", "semi-fixed-space" etc. It could be "no-overlap-space" and
use the extent of the Item and the next-note column rather than their skylines.
Perhaps a stupid question, but why does LilyPond even take ledger lines into
account if they have no vertical or horizontal extent? How do they factor into
the spacing calculations?
Neighboring note-columns are allowed to tuck under ledger lines, but not within
the ledger lines. {e'''8 cis'' e''' fis'' }
The NoteHead has extra-spacing-height to enforce this rule.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues 1503 and 1572 - improved jazz chord support. (issue 5343050)
As far as I can see, this patch is approved for pushing, but hasn't been pushed yet. Are you going to push it, Adam, or should I push the one that I have? Thanks, Carl http://codereview.appspot.com/5343050/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
