Re: print transposed guitar chords on piano sheets (issue4626094)
This patch is obsolete. Current patch is here http://codereview.appspot.com/4800051/ and it is compatible with fixcc. My bad... I should've closed this issue and sent a note. http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
patch fails due to fixcc. http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 2011/07/17 10:35:20, Janek Warchol wrote: Hi all, as acting Frog Meister i'm worried that nothing happens here :( Wol, how can i help you? Neil, Carl: do i understand correctly that Wol could've done this using a more elegant solution, but nevertheless his patch doesn't brake anything and works correctly (i don't remember any problems when i tried it)? Can i label it patch-review? I think it should be patch-needs-work. The proper way to do the capo-chord has been proposed (in Anthony's words -- a "shim"). A sample patch (by Neil) has been referenced. Anthony's patch should be revised to be consistent with Neil's proof-of-concept patch. Thanks, Carl http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Hi all, as acting Frog Meister i'm worried that nothing happens here :( Wol, how can i help you? Neil, Carl: do i understand correctly that Wol could've done this using a more elegant solution, but nevertheless his patch doesn't brake anything and works correctly (i don't remember any problems when i tried it)? Can i label it patch-review? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 8 July 2011 04:37, Carl Sorensen wrote: > 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. A ChordName grob doesn't have all the information required to generate a stencil based on its event-cause since it only carries the root note-event. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
2011/7/8 Wols Lists : > It's certainly muddied the waters! :-) I'll try baling the bilges and > see what comes of it :-) Wol, i'm sorry that i cannot help you here - i'm not familiar enough in internals and also don't handle scheme well. However, i can say that what Carl tells us sounds right to me :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Sorry for being silent for some time, i got distracted by other things... 2011/7/7 Wols Lists : > On 07/07/11 08:59, Janek Warchoł wrote: >> 2011/7/7 Wols Lists : >>> On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote: > >> >>> And it's the one supplied with lilypond - I assumed it formatted the >>> code as per lilypond guidelines ... >> >> It isn't, mostly because there were no precisely defined guidelines >> for a long time - sorry for that... >> We've just discussed it and we're implementing a solution, so soon >> this won't be a problem anymore. >> If you have a patch that wasn't processed by fixcc, send it to me, but >> if you don't, i'll take care of this. >> > Oops. I should have known better - I follow the kernel a little and they > moan there that format changes should always be in their own patch... > > No. I don't have a patch without the format changes, sorry :-( But it's > a mistake I doubt I'll make again! :) As for this patch, i'll handle adapting it to fit our style guidelines (if necessary). > Out of curiosity, what fix are you proposing? Something with git-hooks? I haven't followed the discussion about technical details, but IIRC you can find it by searching for mails with topic "GOP-PROP 3 - C++ formatting" and "Adapt fixcc.py to use Astyle". cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 7/7/11 6:58 PM, "Wols Lists" wrote: > On 08/07/11 00:23, Carl Sorensen wrote: >> On 7/7/11 12:26 PM, "Neil Puttock" wrote: >> >>> On 7 July 2011 19:09, Wols Lists 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 08/07/11 00:23, Carl Sorensen wrote: > On 7/7/11 12:26 PM, "Neil Puttock" wrote: > >> On 7 July 2011 19:09, Wols Lists 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
Re: print transposed guitar chords on piano sheets (issue4626094)
On 7/7/11 12:26 PM, "Neil Puttock" wrote: > On 7 July 2011 19:09, Wols Lists 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. > > 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 > >> 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. 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. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 07/07/11 18:08, n.putt...@gmail.com wrote: > Hi Anthony, > > When we discussed this last year, I argued that it shouldn't be part of > the Chord_name_engraver. I still think this approach is misguided since > we already have a convenient way of generating chord name markup via the > formatter function. Except I still think you haven't grasped the point of this ... And I think you were alone in thinking the formatter function was the right place. Bear in mind that it would require editing EVERY formatter, whereas here I am just making a (small) modification to the engraver. > > If you check the archives, you'll see a proof-of-concept patch I posted > which shows how easy it would be to implement this enhancement in scheme > via the existing chord name formatting code. 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. I really can't understand why having to modify EVERY formatter is better than having to modify ONE engraver. > > Cheers, > Neil > Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 7 July 2011 19:09, Wols Lists 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. Why don't you apply the patch first before jumping to conclusions? > 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). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Hi Anthony, When we discussed this last year, I argued that it shouldn't be part of the Chord_name_engraver. I still think this approach is misguided since we already have a convenient way of generating chord name markup via the formatter function. If you check the archives, you'll see a proof-of-concept patch I posted which shows how easy it would be to implement this enhancement in scheme via the existing chord name formatting code. Cheers, Neil http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 7/7/11 7:30 AM, "m...@apollinemike.com" wrote: >> Mmmm... >> >> Do we have generic procedures for "combine markup" and "stack markup"? >> If not, there'll be a flurry of frog emails as I try and write them :-) >> (note to self - ly:stencil-combine-at-edge) >> > > line and column > (see line 1074 and line 1426 of scm/define-markup-commands.scm) > >> Because the chord_name_capo_proc will basically be "if vertical then >> stack else combine". >> >> Should my scheme function go in the scm directory? > > Yes, likely in define-markup-commands.scm. I think not in define-markup-commands.scm, since this is not a general markup command. I'd recommend scm/chord-name.scm > >> And what would be a good name for it? > > Something descriptive :) capo-chord-name > >> Do those functions get loaded into lily automatically? > > Yes. > >>> >> Moving on slightly, if I'm messing about with scheme for markup, how do >> I mess around with scheme for engravers. It looks like they're defined >> inside lilypond code - do they go in the ly directory? >> > > Engravers are defined in the lily/ directory (C++), but you can also define > theme from scheme (see the scheme engraver regtest). If you're thinking that > this should become part of LilyPond, I'd write it in C++ for the time being. > The community's gonna have a discussion about Scheme vs C++ in the not too > distant future, but at the present moment, no Scheme engravers (that I know > of) are part of the source. The problem we have with Scheme engravers is that we have no automatic way of including them in the documentation. So at present, C++ is preferred over Scheme because they become part of the internals. Probably Scheme engravers should be .ily, and go (at least temporarily) in the ly/ directory. Nicolas Sceaux shared a marvelous example of a Scheme engraver on -user: http://lists.gnu.org/archive/html/lilypond-user/2011-06/msg00581.html As you create a capo_engraver, realize that you will need to adjust the parser and/or lexer so that a capo music event is generated for the capo engraver to listen to. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
> Mmmm... > > Do we have generic procedures for "combine markup" and "stack markup"? > If not, there'll be a flurry of frog emails as I try and write them :-) > (note to self - ly:stencil-combine-at-edge) > line and column (see line 1074 and line 1426 of scm/define-markup-commands.scm) > Because the chord_name_capo_proc will basically be "if vertical then > stack else combine". > > Should my scheme function go in the scm directory? Yes, likely in define-markup-commands.scm. > And what would be a good name for it? Something descriptive :) > Do those functions get loaded into lily automatically? Yes. >> > Moving on slightly, if I'm messing about with scheme for markup, how do > I mess around with scheme for engravers. It looks like they're defined > inside lilypond code - do they go in the ly directory? > Engravers are defined in the lily/ directory (C++), but you can also define theme from scheme (see the scheme engraver regtest). If you're thinking that this should become part of LilyPond, I'd write it in C++ for the time being. The community's gonna have a discussion about Scheme vs C++ in the not too distant future, but at the present moment, no Scheme engravers (that I know of) are part of the source. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 07/07/11 03:21, carl.d.soren...@gmail.com wrote:
> Looks nice!
>
> I have a few suggestions.
>
> As far as running things through the formatter goes, the current
> formatter in git master is *not* the one that we are trying to get
> approved. So it shouldn't be run on current files.
Ummm. In that case, shouldn't reference to it be deleted from the
current contributor's guide? That's why I ran it! :-(
>
> Thanks for your work!
Thanks.
>
> Carl
>
>
>
> lily/chord-name-engraver.cc:177: SCM capovertical = get_property
> ("capoVertical");
> capovertical should be capo_vertical
You'll note at the moment it gives a C++ error of "variable not used". :-)
>
> http://codereview.appspot.com/4626094/diff/8001/lily/chord-name-engraver.cc#newcode189
>
> lily/chord-name-engraver.cc:189: chord_name_->set_property ("text",
> final_markup);
> I recommend that all this be done in the form of a scheme procedure, and
> that the scheme procedure be called.
>
> That would make it much easier to alter in the future, or for a user to
> customize. They can just redefine the Scheme procedure, and they are
> good to go.
>
> So you'd have something like
>
> chord_name->set_property ("text", scm_call_3 (chord_name_capo_proc,
> markup, capo_markup, capo_vertical))
Mmmm...
Do we have generic procedures for "combine markup" and "stack markup"?
If not, there'll be a flurry of frog emails as I try and write them :-)
(note to self - ly:stencil-combine-at-edge)
Because the chord_name_capo_proc will basically be "if vertical then
stack else combine".
Should my scheme function go in the scm directory? And what would be a
good name for it? Do those functions get loaded into lily automatically?
If not how do I load them?
And where would "combine markup" and "stack markup" go if I have to
write them? Markups are the bane of my typesetting life, so a bunch of
routines like this would be great, and they could well be useful to
other people as well...
>
> http://codereview.appspot.com/4626094/
>
Moving on slightly, if I'm messing about with scheme for markup, how do
I mess around with scheme for engravers. It looks like they're defined
inside lilypond code - do they go in the ly directory?
This is the capo-engraver, which should work like the key engraver -
where the user sets up stuff like time sig, key etc, they can AFTER the
key is set they can set the capo. Something like "\key C \major \capo
A". That'll then calculate the semitone difference between the key sig
and the transposed key, and print the transposition as "Capo 3 (A)". And
it needs to be aware of major/minor to print eg Am.
(Once I've done that, I've got two more engravers in mind, but they can
wait until this is properly done. brass-finger-engraver, and
bar-count-engraver - and that latter is NOT anything to do with bar
numbers!)
Cheers,
Wol
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 07/07/11 08:59, Janek Warchoł wrote: > 2011/7/7 Wols Lists : >> On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote: > >> And it's the one supplied with lilypond - I assumed it formatted the >> code as per lilypond guidelines ... > > It isn't, mostly because there were no precisely defined guidelines > for a long time - sorry for that... > We've just discussed it and we're implementing a solution, so soon > this won't be a problem anymore. > If you have a patch that wasn't processed by fixcc, send it to me, but > if you don't, i'll take care of this. > Oops. I should have known better - I follow the kernel a little and they moan there that format changes should always be in their own patch... No. I don't have a patch without the format changes, sorry :-( But it's a mistake I doubt I'll make again! Out of curiosity, what fix are you proposing? Something with git-hooks? Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
2011/7/7 Wols Lists : > On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote: >> New patch set uploaded. >> Hmm, Wol, did you use some code formatting tool on a whole file? I see a >> lot of style changes, and not all of them are for the good. >> >> http://codereview.appspot.com/4626094/ >> > Did I use a formatting tool? Yes I did - it's mentioned in the patch :-) Ah, sorry, i forgot to read the description. > And it's the one supplied with lilypond - I assumed it formatted the > code as per lilypond guidelines ... It isn't, mostly because there were no precisely defined guidelines for a long time - sorry for that... We've just discussed it and we're implementing a solution, so soon this won't be a problem anymore. If you have a patch that wasn't processed by fixcc, send it to me, but if you don't, i'll take care of this. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Looks nice!
I have a few suggestions.
As far as running things through the formatter goes, the current
formatter in git master is *not* the one that we are trying to get
approved. So it shouldn't be run on current files.
Thanks for your work!
Carl
http://codereview.appspot.com/4626094/diff/8001/lily/chord-name-engraver.cc
File lily/chord-name-engraver.cc (right):
http://codereview.appspot.com/4626094/diff/8001/lily/chord-name-engraver.cc#newcode177
lily/chord-name-engraver.cc:177: SCM capovertical = get_property
("capoVertical");
capovertical should be capo_vertical
http://codereview.appspot.com/4626094/diff/8001/lily/chord-name-engraver.cc#newcode189
lily/chord-name-engraver.cc:189: chord_name_->set_property ("text",
final_markup);
I recommend that all this be done in the form of a scheme procedure, and
that the scheme procedure be called.
That would make it much easier to alter in the future, or for a user to
customize. They can just redefine the Scheme procedure, and they are
good to go.
So you'd have something like
chord_name->set_property ("text", scm_call_3 (chord_name_capo_proc,
markup, capo_markup, capo_vertical))
http://codereview.appspot.com/4626094/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
On 06/07/11 20:31, lemniskata.bernoull...@gmail.com wrote: > New patch set uploaded. > Hmm, Wol, did you use some code formatting tool on a whole file? I see a > lot of style changes, and not all of them are for the good. > > http://codereview.appspot.com/4626094/ > Did I use a formatting tool? Yes I did - it's mentioned in the patch :-) And it's the one supplied with lilypond - I assumed it formatted the code as per lilypond guidelines ... Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
New patch set uploaded. Hmm, Wol, did you use some code formatting tool on a whole file? I see a lot of style changes, and not all of them are for the good. http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Some style nitpicks. I also think i found why it didn't work.
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc
File lily/chord-name-engraver.cc (right):
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode126
lily/chord-name-engraver.cc:126: {
AFAIK when there is only one statement in if, we don't use braces. So it
should be
if (capo)
capo_inversion = capo_transpose (p, capo_pitch);
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode135
lily/chord-name-engraver.cc:135: capo_bass = capo_transpose (p,
capo_pitch);
same as above
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode143
lily/chord-name-engraver.cc:143: capo_pitches = scm_cons (capo_transpose
(p, capo_pitch), capo_pitches);
same as above
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode166
lily/chord-name-engraver.cc:166: capo_pitches = scm_sort_list
(capo_pitches, Pitch::less_p_proc);
same as above
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode174
lily/chord-name-engraver.cc:174: capo_markup = scm_call_4 ( name_proc,
capo_pitches, capo_bass, capo_inversion,
same as above
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode187
lily/chord-name-engraver.cc:187: } else {
i think this should be
if (!capo)
chord_name_->set_property ("text", markup);
else
{
http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode191
lily/chord-name-engraver.cc:191: SCM hspace_proc =
ly_lily_module_constant ("hspace_markup");
change line_markup to line-markup and hspace_markup to hspace-markup. I
think it will work then.
http://codereview.appspot.com/4626094/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Passes Make and reg tests James http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
print transposed guitar chords on piano sheets (issue4626094)
Reviewers: antlists_youngman.org.uk, carl.d.sorensen_gmail.com,
Message:
Modify chord-name-engraver to print transposed guitar chords on piano
sheets
Add associated properties capoPitch and capoVertical to
define-context-properties
Description:
print transposed guitar chords on pia
Please review this at http://codereview.appspot.com/4626094/
Affected files:
M lily/chord-name-engraver.cc
M scm/define-context-properties.scm
Index: lily/chord-name-engraver.cc
diff --git a/lily/chord-name-engraver.cc b/lily/chord-name-engraver.cc
index
d0ced5a395f836e99fe57970185e26793b52612f..5037825ca0149eb08d9e0150f0b45bc43334bf2e
100644
--- a/lily/chord-name-engraver.cc
+++ b/lily/chord-name-engraver.cc
@@ -2,6 +2,7 @@
This file is part of LilyPond, the GNU music typesetter.
Copyright (C) 1998--2011 Jan Nieuwenhuizen
+ Copyright (C) 2011 Anthony Youngman
LilyPond is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -43,11 +44,14 @@ protected:
DECLARE_TRANSLATOR_LISTENER (note);
DECLARE_TRANSLATOR_LISTENER (rest);
private:
+ SCM capo_transpose( SCM, SCM) const;
+
Item *chord_name_;
vector notes_;
SCM last_chord_;
Stream_event *rest_event_;
+
};
void
@@ -76,6 +80,13 @@ Chord_name_engraver::process_music ()
SCM inversion = SCM_EOL;
SCM pitches = SCM_EOL;
+ SCM capo_markup;
+ SCM capo_bass = SCM_EOL;
+ SCM capo_inversion = SCM_EOL;
+ SCM capo_pitches = SCM_EOL;
+
+ bool capo = false;
+
if (rest_event_)
{
SCM no_chord_markup = get_property ("noChordSymbol");
@@ -88,6 +99,17 @@ Chord_name_engraver::process_music ()
if (!notes_.size ())
return;
+ // This is set by "\set ChordNames.CapoPitch = #(ly:make-pitch 0 1
1)" in the lily source file
+ // declare properties in define-context-properties.scm
+
+ SCM capo_pitch = get_property ( "capoPitch" );
+ bool capo = false;
+ if ( !(capo_pitch == SCM_EOL) )
+ {
+Pitch *cp = unsmob_pitch (capo_pitch);
+capo = (Pitch::compare ( *cp, Pitch() ) != 0);
+ }
+
Stream_event *inversion_event = 0;
for (vsize i = 0; i < notes_.size (); i++)
{
@@ -100,11 +122,27 @@ Chord_name_engraver::process_music ()
{
inversion_event = n;
inversion = p;
+ if (capo)
+ {
+capo_inversion = capo_transpose (p, capo_pitch);
+ }
}
else if (n->get_property ("bass") == SCM_BOOL_T)
+{
bass = p;
+ if (capo)
+ {
+capo_bass = capo_transpose (p, capo_pitch);
+ }
+}
else
+{
pitches = scm_cons (p, pitches);
+ if (capo)
+ {
+capo_pitches = scm_cons (capo_transpose (p, capo_pitch),
capo_pitches);
+ }
+}
}
if (inversion_event)
@@ -123,10 +161,19 @@ Chord_name_engraver::process_music ()
}
pitches = scm_sort_list (pitches, Pitch::less_p_proc);
-
+ if (capo)
+ {
+capo_pitches = scm_sort_list (capo_pitches, Pitch::less_p_proc);
+ }
+
SCM name_proc = get_property ("chordNameFunction");
markup = scm_call_4 (name_proc, pitches, bass, inversion,
context ()->self_scm ());
+ if (capo)
+ {
+capo_markup = scm_call_4 ( name_proc, capo_pitches, capo_bass,
capo_inversion,
+ context ()->self_scm ());
+ }
}
/*
Ugh.
@@ -135,8 +182,25 @@ Chord_name_engraver::process_music ()
chord_name_ = make_item ("ChordName",
rest_event_ ? rest_event_->self_scm () : notes_[0]->self_scm ());
- chord_name_->set_property ("text", markup);
-
+ if (!capo) {
+chord_name_->set_property ("text", markup);
+ } else {
+SCM capovertical = get_property ("capoVertical");
+SCM paren_proc = ly_lily_module_constant ("parenthesize-markup");
+SCM line_proc = ly_lily_module_constant ("line_markup");
+SCM hspace_proc = ly_lily_module_constant ("hspace_markup");
+
+SCM final_markup = scm_list_n (line_proc,
+ scm_list_3 (markup,
+ scm_list_2 (hspace_proc,
+
scm_from_int(1)),
+ scm_list_2 (paren_proc,
capo_markup)),
+ SCM_UNDEFINED);
+
+chord_name_->set_property ("text", final_markup);
+ }
+
+
SCM chord_changes = get_property("chordChanges");
if (to_boolean (chord_changes) && scm_is_pair (last_chord_)
&& ly_is_equal (chord_as_scm, last_chord_))
@@ -145,6 +209,15 @@ Chord_name_engraver::process_music ()
last_chord_ = chord_as_scm;
}
+SCM
+Chord_name_engraver::capo_transpose (SCM scm_pitch, SCM capo_pitch) const
+{
+ Pitch *s_p = unsmob_pitch (scm_pitch);
+ Pitch *c_p = unsmob_pitch (cap
