Re: Modify chord-name-engraver to call capo-handler (issue4800051)

[Wols Lists]

On 02/08/11 21:24, address@hidden wrote:
> 
> http://codereview.appspot.com/4800051/diff/12002/Documentation/notation/chords.itely
> 
> File Documentation/notation/chords.itely (right):
> 
> http://codereview.appspot.com/4800051/diff/12002/Documentation/notation/chords.itely#newcode516
> 
> Documentation/notation/chords.itely:516: In make-pitch, leave the first
> argument at 0, the second argument is the
> A bit of syntactic sugar would OK here.  Since it's now possible to pass
> pitches as arguments to music functions, it would be nice to have a
> \capo function which doesn't require users to wrestle with
> ly:make-pitch.
> 
That's already been posted to lily-frogs for review, if you would care
to take a look. It contains a bit too much pseudo-code and "how do I do
this" comments for my liking, which is why I didn't want to post it
anywhere else ... :-)

Basically, the idea is you put "\capoKey A" after "\key C \major" or
whatever, and it does the rest, working out the transposition, the fret,
and printing the appropriate text, ie "Capo 3 (A)" at the start of the
score.

> http://codereview.appspot.com/4800051/diff/12002/lily/chord-name-engraver.cc
> 
> File lily/chord-name-engraver.cc (right):
> 
> http://codereview.appspot.com/4800051/diff/12002/lily/chord-name-engraver.cc#newcode127
> 
> lily/chord-name-engraver.cc:127: SCM capo_proc = ly_lily_module_constant
> ("capo-handler");
> While this gets round the duplication in formatter functions, it hides
> the actual context property which does the formatting (and you won't
> find another instance of ly_lily_module_constant () used in this way).
> I still think the minor duplication is preferable.

:-(

And if somebody creates a new chord-formatter and forgets it, some poor
user is going to get bitten by the mysterious failure of the capo
function :-(
> 
> http://codereview.appspot.com/4800051/
> 
Cheers,
Wol