On 02/08/11 21:24, n.putt...@gmail.com 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
