print transposed guitar chords on piano sheets

print transposed guitar chords on pia

[Janek Warchol, 2011-07-05 22:04:49]

Modify chord-name-engraver to print transposed guitar chords on piano sheets
Add associated properties capoPitch and capoVertical to 
define-context-properties

[wolwise1, 2011-07-05 22:47:28]

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#newc...
lily/chord-name-engraver.cc:106: bool capo = false;
Delete this declaration - it's a bug that masks scope

[pkx166h, 2011-07-06 06:43:59]

Passes Make and reg tests

James

[Janek Warchol, 2011-07-06 09:07:14]

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

[Janek Warchol, 2011-07-06 19:31:49]

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.

[antlists_youngman.org.uk, 2011-07-06 22:23:26]

On 06/07/11 20:31, lemniskata.bernoullego@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

[Carl, 2011-07-07 02:21:51]

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#n...
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#n...
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))

[Janek Warchol, 2011-07-07 08:00:03]

2011/7/7 Wols Lists <antlists@youngman.org.uk>:
> On 06/07/11 20:31, lemniskata.bernoullego@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

[antlists_youngman.org.uk, 2011-07-07 09:01:20]

On 07/07/11 08:59, Janek Warchoł wrote:
> 2011/7/7 Wols Lists <antlists@youngman.org.uk>:
>> On 06/07/11 20:31, lemniskata.bernoullego@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

[antlists_youngman.org.uk, 2011-07-07 13:05:04]

On 07/07/11 03:21, Carl.D.Sorensen@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#n...
> 
> 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

[mike_apollinemike.com, 2011-07-07 13:30:52]

> 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

[c_sorensen, 2011-07-07 13:49:29]

On 7/7/11 7:30 AM, "mike@apollinemike.com" <mike@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

[Neil Puttock, 2011-07-07 17:08:01]

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

[antlists_youngman.org.uk, 2011-07-07 18:09:58]

On 07/07/11 18:08, n.puttock@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

[Neil Puttock, 2011-07-07 18:26:47]

On 7 July 2011 19:09, Wols Lists <antlists@youngman.org.uk> 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

[c_sorensen, 2011-07-07 23:23:16]

On 7/7/11 12:26 PM, "Neil Puttock" <n.puttock@gmail.com> wrote:

> On 7 July 2011 19:09, Wols Lists <antlists@youngman.org.uk> 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

[antlists_youngman.org.uk, 2011-07-08 00:58:27]

On 08/07/11 00:23, Carl Sorensen wrote:
> On 7/7/11 12:26 PM, "Neil Puttock" <n.puttock@gmail.com> wrote:
> 
>> On 7 July 2011 19:09, Wols Lists <antlists@youngman.org.uk> 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

[c_sorensen, 2011-07-08 03:37:49]

On 7/7/11 6:58 PM, "Wols Lists" <antlists@youngman.org.uk> wrote:

> On 08/07/11 00:23, Carl Sorensen wrote:
>> On 7/7/11 12:26 PM, "Neil Puttock" <n.puttock@gmail.com> wrote:
>> 
>>> On 7 July 2011 19:09, Wols Lists <antlists@youngman.org.uk> 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

[Janek Warchol, 2011-07-08 23:26:21]

Sorry for being silent for some time, i got distracted by other things...

2011/7/7 Wols Lists <antlists@youngman.org.uk>:
> On 07/07/11 08:59, Janek Warchoł wrote:
>> 2011/7/7 Wols Lists <antlists@youngman.org.uk>:
>>> On 06/07/11 20:31, lemniskata.bernoullego@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

[Janek Warchol, 2011-07-08 23:35:20]

2011/7/8 Wols Lists <antlists@youngman.org.uk>:
> 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

[Neil Puttock, 2011-07-10 22:14:37]

On 8 July 2011 04:37, Carl Sorensen <c_sorensen@byu.edu> 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

[Janek Warchol, 2011-07-17 10:35:20]

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

[Carl, 2011-07-17 12:45:01]

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

[Graham Percival (old account), 2011-08-03 19:50:06]

patch fails due to fixcc.

[Janek Warchol, 2011-08-03 22:13:42]

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.