Re: print transposed guitar chords on piano sheets (issue4626094)

[Wols Lists]

On 08/07/11 00:23, Carl Sorensen wrote:
> On 7/7/11 12:26 PM, "Neil Puttock" <address@hidden> wrote:
> 
>> On 7 July 2011 19:09, Wols Lists <address@hidden> 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