On 08/07/11 00:23, Carl Sorensen wrote: > On 7/7/11 12:26 PM, "Neil Puttock" <n.putt...@gmail.com> wrote: > >> On 7 July 2011 19:09, Wols Lists <antli...@youngman.org.uk> wrote: >> >>> Which I probably didn't understand :-) BUT from what I remember did you >>> think that feeding a chord of, say, C into the formatter should chuck >>> out A as its result? Which is NOT what this does - it has to chuck out >>> both C *and* A. Bear in mind - that for EVERY chord the formatter has to >>> be run TWICE, so modifying all the formatters to loop will be a pain, >>> then anybody writing a new formatter has to remember to make it loop, >>> etc etc. > > There's another way -- have the grob stencil call the formatter twice. Then > the formatter doesn't have to be changed. It just gets called twice. I > think that's not particularly hard. > Hmmm... not that I understand quite properly what a grob is, (graphical object, yes, that's what the words say :-), but it seems to me that my modifications to the engraver now make the engraver create two grobs ... >> >> Why don't you apply the patch first before jumping to conclusions? > > here's a permalink to the patch: > > http://lilypond-frogs.2124236.n2.nabble.com/chord-name-engraver-plus-capo-sc > hemeing-away-tp5470055p5473400.html > Okay, I'll take a look and try and understand what that's doing. > >> >>> I really can't understand why having to modify EVERY formatter is better >>> than having to modify ONE engraver. >> >> We don't manupulate markup in engravers unless it's trivial (e.g., >> centring the octavation on a clef in the Clef_engraver). > > I think I finally understand the point Neil was trying to make before. Let > me try to explain it. > > The engraver creates a grob, ChordName. That grob can have any display > characteristics you want it to have. The display characteristics are > defined by the scheme procedure that is the grob's stencil. > > If the grob has a capoPitch property and a capoVertical property, then the > stencil procedure (responsible for creating the output stencil for the grob) > can easily call the chord formatter procedure twice and glue the two > stencils together appropriately. So there's no reason to modify the > engraver.
BUT. Is the grob supposed to know anything about the music object that it was created from? In other words, can you apply a music function (transpose) to a grob? That imho makes just as little sense ... > > I know that I'm really slow on this, but I think I finally got it. The > engraver is *not* responsible for generating the printed output. It *is* > responsible for creating a grob and setting any necessary/desired properties > for the grob, which will allow the stencil procedure to properly do the work > of generating the printed output. imho the problem is that the whole system is based on the presumption engraver->grob->print-object as a 1->1->1 relationship. Unfortunately, what I'm doing is a 1->2->1 relationship. I get what Neil's saying now, like you. I did it the way I did because it was the "obvious" way to do it. It doesn't make sense to do it in the chord name formatter, which is what I understood Neil to be saying. But if that's not what he's saying - if he's saying do it in a shim between the engraver and the formatter, then that's more sensible. > > HTH, > It's certainly muddied the waters! :-) I'll try baling the bilges and see what comes of it :-) btw, I had a thought today - how does the code handle "not a chord"? Not that this sort of music is likely to have that, but it shouldn't try and transpose that. Maybe this approach will make handling that easier ... > Carl > Cheers, Wol _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel