Re: [frogs] Re: tablature: ties and harmonics (issue1669041)
Carl Sorensen schrieb: On 6/30/10 1:48 AM, Marc Hohl m...@hohlart.de wrote: Carl Sorensen schrieb: [...] http://codereview.appspot.com/1669041/diff/26001/27004#newcode130 scm/define-grob-properties.scm:130: (bracket-width ,number? Width of the harmonic angle bracket.) Why do we need bracket-width? Why can't we just use the pre-existing width property? Hm, Neil proposed to use a more descriptive name for this property, IIUC. Done. Well, if we want to have this be part of the parenthesis-interface, then we may want to go ahead with bracket-width. Ok, done. [...] If instead of making the whiteout and the stencil different stencils, we combined them, then parenthesize-stencil would work great. But this might not be possible if we need to have the stencil and the whiteout on separate layers. As an alternative, parenthesize-stencil could be modified to take white-padding as an argument. There's nothing that says we can't modify scm/stencil.scm so that it works better for tablature. It's much better, IMO, to have one general-purpose piece of code than to have two separate special-purpose code chunks. So I tried to extend the parenthesize-stencil function in scm/stencil.scm. It compiles without error, but the regression file is cluttered up. Can you tell me what you mean by the regression file is cluttered up? Can you tell me which examples fail the regression test for graphical output? (The changes that indicate different amounts of memory don't bother me a bit). Oh, sorry, I meant the newly introduced input/regression/tablature-tie-harmonic.ly. With the patch set before, it worked as expected, now the angle brackets surround invisible fret numbers again, and after line breaks, the harmonic brackets overlap the parentheses construct (while erasing the fret number :-( ) I feel that this is not the right approach, either. I still don't understand why I have to shift the TabNoteHead #'layer at all. As far as I see it, HarmonicParenthesesItem #'stencils is a list of stencils, containing the left and the right angle bracket, which are placed either side of the TabNoteHead #'stencil. So the order in which the stancils are placed should not change anything at all, but if the TabNoteHead #'stencil is set *before* the HarmonicParenthesesItem #'stencils, it seems that some whitespace occurs between the angle brackets, overriding the already placed TabNoteHead. Have you looked at the list of stencils created by parenthesis-item::calc-parentehesis-stencils grob and map stencil-whiteout (parenthesis-item::calc-parentehesis-stencils grob) to see how they differ? Sometimes lists get reversed during LilyPond processing. Perhaps this is happening to this list. You might see what happens if you reverse the list of stencils I think I understand now - Neil has given me the clue to this. [...] Furthermore, I have a bad feeling to misuse your time reviewing my patch for error seeking issues, but I am stuck here. I don't view it as a misuse of time. But right now I'm very busy, so I may not get to it very quickly Thanks for your kind words - you do a great job in motivating frustrated people like me ;-) I like the general idea of not defining the same functionality over and over again, but on the other hand, the parenthesize-stencil function in scm/stencil.scm does not seem to be used anywhere else ... Parenthesize-stencil will be used for the new chord namer, so we need to keep it in stencil.scm and keep the current functionality. Ok. Thank you Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: tablature: ties and harmonics (issue1669041)
n.putt...@gmail.com schrieb: On 2010/06/30 07:48:12, marc wrote: So I tried to extend the parenthesize-stencil function in scm/stencil.scm. It compiles without error, but the regression file is cluttered up. I can't test this. Would you mind uploading another version here which includes all the changes since the first patch set? Of course! I hope I did it right - at least it looks like I have catched everything. I feel that this is not the right approach, either. I still don't understand why I have to shift the TabNoteHead #'layer at all. As far as I see it, HarmonicParenthesesItem #'stencils is a list of stencils, containing the left and the right angle bracket, which are placed either side of the TabNoteHead #'stencil. So the order in which the stancils are placed should not change anything at all, but if the TabNoteHead #'stencil is set *before* the HarmonicParenthesesItem #'stencils, it seems that some whitespace occurs between the angle brackets, overriding the already placed TabNoteHead. You added the default for 'whiteout to HarmonicParenthesesItem in your first patch. It applies the whiteout to the total extent: the two brackets plus the space between. Ah, that makes everything clearer, thanks for this explanation! I don't know why grobs with the same layer sometimes swap places, but there's nothing we can do about it apart from change 'layer to ensure visibility, unless you remove 'whiteout for the angle brackets. Now the whole #'layer stuff makes a lot more sense to me ... Thank you Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Align metronome mark at time signature or first musical element. Fixes #684. (issue1579041)
So, how are we doing here? Ready to commit close http://code.google.com/p/lilypond/issues/detail?id=684 http://codereview.appspot.com/1579041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website: added Academia items
Cool, thanks. Do any of these papers have an online presence (ie url?) summary, content or otherwise? This is already great, IWBN to have some links there. 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 http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: authors+contributors list
2010/6/29 Jan Nieuwenhuizen janneke-l...@xs4all.nl: Op dinsdag 29-06-2010 om 13:35 uur [tijdzone +0100], schreef Graham Percival: Any new / new-ish contributors, please check: http://lilypond.org/website/authors.html And translators, please go over all manuals links, esp. in Documentation/LANG/web/manual.itexi and remove the -LANG bit from each non-translated manual, Caught, thanks -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website: added Academia items
On Thu, Jul 01, 2010 at 10:13:58AM +0200, Jan Nieuwenhuizen wrote: Do any of these papers have an online presence (ie url?) summary, content or otherwise? It's only a work in progress; there's another 15-20 papers we can add to that list. Some of them will have publicly-accessible papers, but I'm certain that some of them *won't* be publicly-accessible. (granted, we could still link to the login page for those non-publicly-accessible papers) We're not fussing over the exact formatting yet; we're waiting for http://code.google.com/p/lilypond/issues/detail?id=1162 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Align metronome mark at time signature or first musical element. Fixes #684. (issue1579041)
Hi Jan, On 2010/07/01 08:08:36, jan.nieuwenhuizen wrote: So, how are we doing here? Ready to commit close I'm testing the latest set at the moment; will report back with more comments. Cheers, Neil http://codereview.appspot.com/1579041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for issue #1116 (one stencil in fill-line) (issue1689041)
Hi Alexander, LGTM. It just needs some regression tests; the examples from #1116 and #382 should suffice. Cheers, Neil http://codereview.appspot.com/1689041/diff/2001/3001 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/1689041/diff/2001/3001#newcode845 scm/define-markup-commands.scm:845: (set! line-stencils empty-stencil) Hmm, line-stencils isn't appropriate from this point, since it's no longer a list of stencils; perhaps it would be clearer to bind to another variable? http://codereview.appspot.com/1689041/diff/2001/3001#newcode847 scm/define-markup-commands.scm:847: (stack-stencils-padding-list indent http://codereview.appspot.com/1689041/diff/2001/3001#newcode848 scm/define-markup-commands.scm:848: X RIGHT fill-space line-stencils))) On 2010/06/30 18:34:35, joeneeman wrote: These two set!s could be written more concisely as (set! line-stencils (stack-stencils-padding-list X RIGHT fill-space empty-stenc No, they're part of the `if' form above. http://codereview.appspot.com/1689041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
