lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carl Sorensen
Subject: Re: print transposed guitar chords on piano sheets (issue4626094)
Date: Thu, 7 Jul 2011 21:37:38 -0600



On 7/7/11 6:58 PM, "Wols Lists" <address@hidden> wrote:

> 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 ...

The grob has everything that is necessary to create the printed output.  You
can't apply a music function to a grob, but you can apply a scheme function
to the music contents of the grob.  So rather than translate the chord (a
music event), you'll translate the root (and perhaps the bass note), which
are available as part of the contents of the grob.

>> 
>> 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.

Actually, it can be made a 1->1->1. 1 music event (chord), which the
engraver uses to create a ChordName (grob), which the stencil function can
use to generate two different chord name markups, because the stencil
function is free to call the chord namer as many times as desired.

> 
> 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 ...
> 

No chord is represented by a rest.  I forget how it's handled internally.
I'll try to look into it more later.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]