note-name-engraver: add user-defined note names support

note-name-engraver: add user-defined note names support

Property "noteNameList" added in order to display
note names in languages other than Deutsch.

Example:
\version "2.13.37"
\include "espanol.ly"
notes = \relative do' { do re mi do }

\new Staff <<
  \notes
  \context NoteNames { 
    \set noteNameList = #'("la" "si" "do" "re" "mi" "fa" "sol") 
    \notes }
>>

[fanziye1, 2013-04-20 00:03:17]

Hi Janek,
It seems I forgot to publish this issue in list. This is for the googlecode
issue 1367. Only a few c++ code was added, nothing done with regression test and
docs. Was it appropriate to post a patch like this? Or is there anything I
should do for an issue? I think I will add them later.

Thanks very much!

note-name-engraver: add user-defined note names support

Property "noteNameList" added in order to display
note names in languages other than Deutsch.

Example:
\version "2.13.37"
\include "espanol.ly"
notes = \relative do' { do re mi do }

\new Staff <<
  \notes
  \context NoteNames { 
    \set noteNameList = #'("la" "si" "do" "re" "mi" "fa" "sol") 
    \notes }
>>


Fan Ziye

[janek, 2013-04-21 21:09:30]

Hi,

On 2013/04/20 00:03:17, fanziye1 wrote:
> Hi Janek,
> It seems I forgot to publish this issue in list. This is for
> the googlecode issue 1367. Only a few c++ code was added,
> nothing done with regression test and docs. Was it appropriate
> to post a patch like this? Or is there anything I should
> do for an issue? I think I will add them later.

It's ok to post an incomplete patch asking for suggestions.  
Of course, any related documentation changes etc. should be 
added to the patch before its pushed.

> note-name-engraver: add user-defined note names support
> 
> Property "noteNameList" added in order to display
> note names in languages other than Deutsch.

Actually, current language is Dutch, not German.

> Example:
> \version "2.13.37"
> \include "espanol.ly"
> notes = \relative do' { do re mi do }
> 
> \new Staff <<
>   \notes
>   \context NoteNames { 
>     \set noteNameList = #'("la" "si" "do" "re" "mi" "fa" "sol") 
>     \notes }
> >>

As for the code, i think that it would be better to get
notenames from within lilypond instead of asking the
user to specify them.  A comment in the tracker issue 
says "do it just like \displayLilyMusic does", so i've 
tried some searching.  grep showed that \displayLilyMusic 
is defined in ly/music-functions-init.ly using Scheme 
function display-lily-music, which in turn is defined 
in scm/music-functions.scm. It seems that most of this 
stuff lives in scm/define-music-display-methods.scm.  
Also in the tracker is mentioned the property "pitchnames" 
which seems to be holding the names in appropriate language.  
I think that you should be able to access it in C++ using 
get_property ("pitchnames").

hth.
Janek

https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc
File lily/note-name-engraver.cc (right):

https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc#newc...
lily/note-name-engraver.cc:51: int note_name_list_length =
scm_to_int(scm_length(scm_note_name_list));
a general note: we have some rules for how C++ code should be formatted so that
our source files will have a uniform appearance.  The easiest way to ensure that
your code complies with them is to run scripts/auxiliar/fixcc.py on it - please
do this when you upload a patch.

https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc#newc...
lily/note-name-engraver.cc:54: note_name_list.push_back (ly_scm2string
(scm_list_ref (scm_note_name_list, scm_from_int(i))));
as a general rule, please try to keep lines under 80 characters long if
possible.

[fanziye1, 2013-04-24 17:16:14]

I found the variable 'pitchnames'(Thanks for your teaching:).
There is a note-name->lily-string procedure can be used to get a pitch's name.
Now I want to use it in C++ code. According to the Guile Reference, 'gh_call'
seems a right choice. But I found no appearance of 'gh_call' in lily/*.cc . So
how do you call a scheme procedure from C++ in lilypond?


On 2013/04/21 21:09:30, janek wrote:
> Hi,
> 
> It's ok to post an incomplete patch asking for suggestions.  
> Of course, any related documentation changes etc. should be 
> added to the patch before its pushed.
> 
> Actually, current language is Dutch, not German.
>
I'm sorry. I'll correct it.

> As for the code, i think that it would be better to get
> notenames from within lilypond instead of asking the
> user to specify them.  A comment in the tracker issue 
> says "do it just like \displayLilyMusic does", so i've 
> tried some searching.  grep showed that \displayLilyMusic 
> is defined in ly/music-functions-init.ly using Scheme 
> function display-lily-music, which in turn is defined 
> in scm/music-functions.scm. It seems that most of this 
> stuff lives in scm/define-music-display-methods.scm.  
> Also in the tracker is mentioned the property "pitchnames" 
> which seems to be holding the names in appropriate language.  
> I think that you should be able to access it in C++ using 
> get_property ("pitchnames").
> 
> hth.
> Janek
> 
> https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc
> File lily/note-name-engraver.cc (right):
> 
>
https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc#newc...
> lily/note-name-engraver.cc:51: int note_name_list_length =
> scm_to_int(scm_length(scm_note_name_list));
> a general note: we have some rules for how C++ code should be formatted so
that
> our source files will have a uniform appearance.  The easiest way to ensure
that
> your code complies with them is to run scripts/auxiliar/fixcc.py on it -
please
> do this when you upload a patch.
> 
>
https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc#newc...
> lily/note-name-engraver.cc:54: note_name_list.push_back (ly_scm2string
> (scm_list_ref (scm_note_name_list, scm_from_int(i))));
> as a general rule, please try to keep lines under 80 characters long if
> possible.

Thank you very much. I'll try to rewrite the patch and add related documentation
changes. but now that I've uploaded a patch here, how could I modify it (or add
new changes)? should I upload new patch to the same googlecode issue?

[pkx166h, 2013-04-25 18:15:07]

On 2013/04/24 17:16:14, fanziye1 wrote:
but now that I've uploaded a patch here, how could I modify it (or add
> new changes)? should I upload new patch to the same googlecode issue?

If you use git-cl it does it all for you. It will set the googlecode issue to
'Patch-new' automatically (which means the automated scripts that others run
will test this for you) and it also alerts everyone there is a new patch. Once
it has been tested (and all has passed) then the automatic scripts will set the
patch label to 'patch-review' and again it gets more review.

There is also an email that goes out every few days to developer list with the
subject 'PATCHES; Countdown for xxxx' which lists all patches currently to be
reviewed or pushed. This is used by most of the developers, which is why it is
always good to update the google tracker as well, and git-cl (see the
Contributors Guide) does a lot of this automatically for you.

[janek, 2013-04-26 22:38:57]

On 2013/04/24 17:16:14, fanziye1 wrote:
> I found the variable 'pitchnames'(Thanks for your teaching:).
> There is a note-name->lily-string procedure can be used to get a pitch's name.
> Now I want to use it in C++ code. According to the Guile Reference, 'gh_call'
> seems a right choice. But I found no appearance of 'gh_call' in lily/*.cc . So
> how do you call a scheme procedure from C++ in lilypond?

Maybe gh_call is from guile 2.0?  We're still at 1.8 or something like that.

> On 2013/04/21 21:09:30, janek wrote:
> >
https://codereview.appspot.com/8593046/diff/1/lily/note-name-engraver.cc#newc...
> > lily/note-name-engraver.cc:54: note_name_list.push_back (ly_scm2string
> > (scm_list_ref (scm_note_name_list, scm_from_int(i))));
> > as a general rule, please try to keep lines under 80 characters long if
> > possible.
> 
> Thank you very much. I'll try to rewrite the patch and add related
documentation
> changes. but now that I've uploaded a patch here, how could I modify it (or
add
> new changes)? should I upload new patch to the same googlecode issue?

New patchset should be "announced" in the tracker issue, yes.

As for uploading new patchset, i'm not sure about one thing: how did you upload
the first patchset to Rietveld?
If you didn't use git-cl, you should try it now, as described here:
http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patch...
(be sure to set the Rietveld issue number using 'git cl issue <issue-number>' so
that the patchset will be added to this issue instead of creating a new one).

If you did use git-cl, it seems that you might need to update git-cl to latest
version to get optimal results (i.e. have tracker issue status set for you by
git-cl).  If you have trouble checking if your installed git-cl is up-to-date,
let us know.

I get a feeling that my explanations are becoming somewhat convoluted, so if
anything's unclear, just ask.

best,
Janek

[Valentin Villenave, 2015-04-12 20:19:24]

On 2013/04/26 22:38:57, janek wrote:
> New patchset should be "announced" in the tracker issue, yes.

Hi everybody,
I realize this patch has been (sort of) forgotten, so I thought I’d update it
and re-upload it:
https://codereview.appspot.com/221710044/

Cheers,
Valentin.