Re: a Lyric Report (- my GSoC project)
Dear Janek, what a great list of improvements to look forward to. I solve these issues most times with lengthy overrides boxed in music-functions ... if there is a way of helping (testing?), let me know! Cheers, Jan-Peter Am 30.03.2012 um 20:17 schrieb Janek Warchoł: Dear Team, i've just created a multi-issue bug report about Lyrics: see issues 2450 - 2462 (http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject). I dedicate them to Valentin, as he was skeptical whether Lyrics in LilyPond need much improvement ;) I've set the owner of these issues to myself, because one of my two applications for Google Summer of Code will be about improving Lyrics in Lily - it would be troublesome if suddenly someone did the work for me! Feel free to comment on these issues (suggestions greatly appreciated!), but please don't do any coding unless my application is rejected (final decision will be known on April 20th). thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc/LSR-problem?
Am 30. März 2012 21:32 schrieb Thomas Morley thomasmorle...@googlemail.com:
Hi,
I just downloaded today's tarball: lsr-snippets-all-2012-03-30.tar.gz
in order to make some checks.
Something went wrong:
In the updated files the old version and the old header is not
replaced by the new ones.
Instead the new versions/headers were simply added.
[...]
I just informed Sebastiano.
Sebastiano answered:
Am 31. März 2012 02:45 schrieb Sebastiano Vigna vi...@dsi.unimi.it:
On Mar 30, 2012, at 12:24 PM, Thomas Morley wrote:
\version 2.12.2
This was easy: there is a field Constants.VERSION that had to be updated.
doctitle = Adding fingerings to chords
}
\version 2.14.0
\header {
texidoc =
Fingerings for chords can be obtained by adding them to individual
pitches.
That's instead entirely different. The snippets for updating are assumed to
contain exactly the snippets--nothing else. The header is added automatically.
Now the header is build into the snippets, which will cause the header to be
added twice.
I suggest that you contact the manual maintainer and let them know that they
MUST clarify the updating procedure in the manual: only the actual Lilypond
code should be contained in the snippet--and nothing else.
Ciao,
seba
Well, I could suggest some changes to the CG.
If there's need to delete all the versions and headers from all files
of the updated lsr-tarball before sending it back to Sebastiano, then
a shell-script to do so should be created. But that's beyond my
knowledge.
-Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a Lyric Report (- my GSoC project)
- Original Message - From: Trevor Daniels t.dani...@treda.co.uk To: Janek Warchoł janek.lilyp...@gmail.com; LilyPond Developmet Team lilypond-devel@gnu.org; Valentin Villenave valen...@villenave.net Cc: perpeduumimmob...@gmail.com Sent: Friday, March 30, 2012 9:11 PM Subject: Re: a Lyric Report (- my GSoC project) Hi Janek An impressive collection of suggested enhancements! I hope your exams don't suffer! Most look excellent to me, but I have comments on a couple of them which I'll add to the issues themselves. Trevor +1. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR is now on 2.14
- Original Message - From: James pkx1...@gmail.com To: Graham Percival gra...@percival-music.ca Cc: lilypond-devel lilypond-devel@gnu.org Sent: Friday, March 30, 2012 6:57 AM Subject: Re: LSR is now on 2.14 Hello, On 30 March 2012 02:24, Graham Percival gra...@percival-music.ca wrote: ... Well, currently I can't self-compile LilyPond or prepare a formal patch or sth else in this direction. Seems I have to learn a lot. ;) Yep. To warn you: at the moment the quick start section of the CG is broken; following its instructions will give you neither a quick nor painless start. Your options are: 1) go through the painful process of figuring out which parts are still valid and which are not. Without a mentor, this will be especially painful. 2) wait for lilydev to be updated (ETA: 6 weeks) and somebody to fix up at least the short quick start section (ETA: 1 month after lilydev is updated). 3) ask/wait for somebody else to handle the LSR import. Unfortunately there is no magic wand that will let us offer you an option other than those three. (unless I've forgotten about something, which is possible given my mental state these days. James: I have not forgotten about your recent work on lilydev, but I stand behind my pessimistic estimate) I've updated LilyDev and been working with it this week testing the basics - it makes the code and the doc. I've given Mike a copy of the iso (as he was the only one I knew who used LilyDev in anger) and I FTP'd the iso to Phil's website last night. As far as I know, this is good to go. James I use LilyDev quite a bit - a slightly out of date version. The only machine for which this is not true is the Ubuntu 64-bit real machine I use for build. My PC VM is lilydev, as is my GUB VM on the big build box. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc/LSR-problem?
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com To: lilypond-devel lilypond-devel@gnu.org Sent: Saturday, March 31, 2012 11:20 AM Subject: Re: Doc/LSR-problem? Well, I could suggest some changes to the CG. If there's need to delete all the versions and headers from all files of the updated lsr-tarball before sending it back to Sebastiano, then a shell-script to do so should be created. But that's beyond my knowledge. -Harm If you send my (or James) updated text for the CG, one or other of us will add it. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR is now on 2.14
Phil, I use LilyDev quite a bit - a slightly out of date version. The only machine for which this is not true is the Ubuntu 64-bit real machine I use for build. My PC VM is lilydev, as is my GUB VM on the big build box. Oh good. I thought you only used a phys machine. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR is now on 2.14
- Original Message - From: Thomas Morley thomasmorle...@googlemail.com Subject: Re: LSR is now on 2.14 Ok, I checked it. Only the following 37 files have to be added manually (the others are updates of existing LSR-files) alternative-breve-note.ly changing-the-ambitus-gap.ly changing-the-number-of-augmentation-dots-per-note.ly changing-the-size-of-woodwind-diagrams.ly chordchanges-for-fretboards.ly chord-glissando-in-tablature.ly controlling-spanner-visibility-after-a-line-break.ly defining-an-engraver-in-scheme-ambitus-engraver.ly dynamics-custom-text-spanner-postfix.ly dynamics-text-spanner-postfix.ly expressive-headword.ly figured-bass-headword.ly fretboards-alternate-tables.ly fretted-string-harmonics-in-tablature.ly graphical-and-text-woodwind-diagrams.ly hiding-accidentals-on-tied-notes-at-the-start-of-a-new-system.ly keyboard-headword.ly lyrics-old-spacing-settings.ly making-slurs-with-complex-dash-structure.ly non-default-tuplet-numbers.ly numbers-as-easy-note-heads.ly open-string-harmonics-in-tablature.ly pitches-headword.ly repeats-headword.ly rhythms-headword.ly screech-boink.ly setting-the-double-repeat-default-for-volte.ly simultaneous-headword.ly slides-in-tablature.ly snap-pizzicato-bartok-pizzicato.ly staff-headword.ly text-headword.ly unfretted-headword.ly using-the-whiteout-property.ly vocal-headword.ly wind-headword.ly woodwind-diagrams-listing.ly -Harm Simplest way might be for Harm, David and myself to put these in the LSR. Don't think it'll take that long. I'd then check and approve them - so if I took 10 and you 2 share the others out, that should be fair? What do you think? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a Lyric Report (- my GSoC project)
On Fri, Mar 30, 2012 at 10:11 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Hi Janek An impressive collection of suggested enhancements! I hope your exams don't suffer! We'll see, we'll see :) Most look excellent to me, but I have comments on a couple of them which I'll add to the issues themselves. Many thanks! On Fri, Mar 30, 2012 at 10:55 PM, m...@apollinemike.com m...@apollinemike.com wrote: Agreed - this is fantastic work. I'm happy to hear that! I wish there were more reports of this quality. It'd make it easier to fix stuff. I have more! Reports about augmentation dots, dynamics and articulation placement, stem lengths, horizontal spacing, tie shapes, beam positions - You name it! All i need is time to write them in a tidy manner - it's extremely time-consuming. I estimate that this Lyrics Report took about 30 hours to write, and i was collecting engraved examples since summer. I'll do my best adding more reports - however some other things, like improving contributor workflow and organizing a Kickstarter project, keep my mind busy... not mentioning GSoC. I have a pretty good sense of how difficult each issue will be to fix - lemme know if you need an order of attack once you get cracking on these problems. Sure! I'm writing my GSoC application now (it will include my plan for doing these issues), and i'll post it on the list when it's finished (hopefully today) - please comment on it! On Sat, Mar 31, 2012 at 10:16 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote: what a great list of improvements to look forward to. I solve these issues most times with lengthy overrides boxed in music-functions ... if there is a way of helping (testing?), let me know! Sure, any help with testing and designing good solutions is welcome! I'll keep you informed. thanks! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected style of comments (issue 5862052)
I'm sorry for that, but the next bunch of corrections are in a separate
issue: http://codereview.appspot.com/5975054
It seems that following the procedure from
http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review
does not make git-cl ask for the issue number. Instead it creates a new
one. How to change that? Always call 'git cl issue' before 'git cl
upload'?
http://codereview.appspot.com/5862052/diff/1/flower/include/direction.hh
File flower/include/direction.hh (right):
http://codereview.appspot.com/5862052/diff/1/flower/include/direction.hh#newcode77
flower/include/direction.hh:77: * Thanks to a #define below, instead of
writing:
On 2012/03/23 07:23:36, Keith wrote:
Only you and Han Wenn have answered. Maybe other agree on
changing do to for_UP_and_DOWN? How do I know?
You cannot know every individual opinion, so you must decide what is
wise. You
know that I fear that I will forget if there is any difference between
do{}while(flip()) and for_UP_and_DOWN. You know that HanWenn suggests
changing
all do{}while(flip) at once.
If you change just a few do{}while(flip) to your new idiom, then I
will be
tempted to create a third idiom:
for (Direction d = UP; d = DOWN; d = (Direction)(d + DOWN - UP)
Yes, you are right - I should have changed all occurences at once. There
are 136 such. Do you have an idea, if it could be done automatically?
http://codereview.appspot.com/5862052/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):
http://codereview.appspot.com/5862052/diff/1/lily/accidental-placement.cc#newcode116
lily/accidental-placement.cc:116: //TODO: add comment to this class
On 2012/03/22 14:55:38, Graham Percival wrote:
I'm not certain this line adds anything. Also, isn't it a struct, not
a class?
Well, I think it adds something - a request to comment a struct that is
not obvious one.
Yes, it's a struct, not a class. AFAIR it's not a big difference in C++,
but ok, I'll correct the comment.
http://codereview.appspot.com/5862052/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):
http://codereview.appspot.com/5862052/diff/1/lily/note-collision.cc#newcode76
lily/note-collision.cc:76: /* Filter out the 'o's in this configuration,
since they're no
Keith, I'm trying to understand the whole function and divide it into
parts.
Does this comment refer only to the two lines below?
http://codereview.appspot.com/5862052/diff/1/lily/note-collision.cc#newcode183
lily/note-collision.cc:183: */
On 2012/03/23 07:23:36, Keith wrote:
Move the block comment above down below your new comments, to keep it
adjacent
to the if...elseif... block that it describes.
Done.
http://codereview.appspot.com/5862052/diff/1/lily/note-collision.cc#newcode286
lily/note-collision.cc:286: // The offset should depend on line
thickness, not staff space, at least in some cases (like stem-to-stem,
where it should be bigger for smaller font size)
On 2012/03/23 07:23:36, Keith wrote:
What does the offset refer to? shift_amount?
Yes. Corrected.
http://codereview.appspot.com/5862052/diff/1/lily/note-collision.cc#newcode383
lily/note-collision.cc:383: void update_offsets (Drul_arrayvectorReal
*offsets,
Well, ok, the function is indeed too short. But the whole function
check_meshing_chords should be split, don't you think? Currently it has
over 300 lines!
http://codereview.appspot.com/5862052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues 2266 and 1721
Hi all,
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present a
translated link towards snippets, like @rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is snippets/hauteurs.fr.html which
doesn't exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is snippets/pitches.fr.html where I want
to go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present a
translated link towards glossary both in LM and NR, and I never get
any kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
music-glossary/pitch-names.fr.html where I want to arrive and it's a
perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and why,
though they look identical do they work differently according to the
target manual?
Cheers,
Jean-Charles
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected style of comments (issue 5862052)
On Sat, Mar 31, 2012 at 6:13 PM, milimet...@gmail.com wrote: I'm sorry for that, but the next bunch of corrections are in a separate issue: http://codereview.appspot.com/5975054 It seems that following the procedure from http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review does not make git-cl ask for the issue number. Instead it creates a new one. How to change that? Always call 'git cl issue' before 'git cl upload'? The information about Rietveld issue is stored in your git config, in the properties of the branch you used when you uploaded first. If you upload new patch revision from a new branch, the script doesn't know what rietveld number is because it doesn't see it in branch properties. It's a good practice to use one branch for your fix. HTH, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected style of comments (issue 5862052)
Hello, 2012/3/31 Janek Warchoł janek.lilyp...@gmail.com: On Sat, Mar 31, 2012 at 6:13 PM, milimet...@gmail.com wrote: I'm sorry for that, but the next bunch of corrections are in a separate issue: http://codereview.appspot.com/5975054 It seems that following the procedure from http://lilypond.org/doc/v2.15/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review does not make git-cl ask for the issue number. Instead it creates a new one. How to change that? Always call 'git cl issue' before 'git cl upload'? The information about Rietveld issue is stored in your git config, in the properties of the branch you used when you uploaded first. If you upload new patch revision from a new branch, the script doesn't know what rietveld number is because it doesn't see it in branch properties. It's a good practice to use one branch for your fix. I find that using 'git-cl issue 0' helps to 'reset' any doubts abuot what git-cl thinks it has currently. I use a VM with Lilydev and have a number of patches on the go, so forget which is which, so just reset git-cl and then either let git-cl create my new issue number or I find my rietveld issue and then run git-cl issue where is the rietveld number. Then I know I am good to go. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)
LGTM, except that it confuses the two programs we have used recently for automatic code indentation. http://codereview.appspot.com/5975054/diff/1/flower/include/direction.hh File flower/include/direction.hh (right): http://codereview.appspot.com/5975054/diff/1/flower/include/direction.hh#newcode90 flower/include/direction.hh:90: for (Direction d = UP; d != CENTER; flip(d), d == UP ? d = CENTER : d) It is still difficult to understand. Consider for (Direction d = UP; d != CENTER; d = (UP == d)? DOWN, CENTER) http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc File lily/note-collision.cc (right): http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc#newcode45 lily/note-collision.cc:45: /* Filter out the 'o's in this configuration, since they're no Keith, I'm trying to understand the whole function and divide it into parts. Does this comment refer only to the two lines below? It explains the two assignment lines below. We use the results of those assignments, the filtered arrays of note-heads, for the rest of the function. Therefore you don't need to pass 'ups' and 'dps' as arguments in to this function. See http://code.google.com/p/lilypond/issues/detail?id=984 http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc#newcode404 lily/note-collision.cc:404: for_UP_and_DOWN (d) The code-indenting program we use http://astyle.sourceforge.net/ is not smart enough to determine that this macro starts a control block, so it indents the code as if for_UP_and_DOWN was a function call or function definition. The indenter in emacs does the same. If you write the 'for' loop directly in the code, then neither humans nor auto-indent programs need to learn a macro: for (Direction d = UP; d; d = (UP == d)? DOWN : CENTER) http://codereview.appspot.com/5975054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issues 2266 and 1721
On Sat, Mar 31, 2012 at 07:47:18PM +0200, Jean-Charles Malahieude wrote:
Hi all,
I just noticed something:
1- I overuse of @rlsrnamed{original,translated} in order to present
a translated link towards snippets, like
@rlsrnamed{Pitches,Hauteurs}.
1-1 When in NR, this produces tons of lines in the logs like
WARNING: Unable to find node 'translated' in book snippets.
@rlsrnamed{Pitches,Hauteurs} is snippets/hauteurs.fr.html which
doesn't exist, so I get nowhere.
1-2 When in LM, there in nothing in the logs
@rlsrnamed{Pitches,Hauteurs} is snippets/pitches.fr.html where I
want to go, but non success.
2- I overuse of @rglosnamed{original,translated} in order to present
a translated link towards glossary both in LM and NR, and I never
get any kind of warning or error, and the link is effective.
@rglosnamed{{Pitch names,Noms des notes} is
music-glossary/pitch-names.fr.html where I want to arrive and it's
a perfect landing.
My questioning is:
Why a same macro could behave differently when in LM or in NR, and
why, though they look identical do they work differently according
to the target manual?
Hi Jean-Charles, and thanks for reporting your problem.
Are you reporting a problem against a released version of Lilypond? Is so,
please let me know which version and then I can raise an issue tracker for the
unexpected behaviour.
If you are working with unreleased code then I think I should allow the
developers to respond to your queries.
Cheers,
Colin.
--
Colin Hall
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120403
For 20:00 MDT Tuesday, April 3 Issue 2441 http://code.google.com/p/lilypond/issues/detail?id=2441: Stems no longer adjust for merged note heads - R5934050 http://codereview.appspot.com/5934050/ Cheers, Loof Lirpa Ton -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected comments and a function check_meshing_chords divided in two. (issue 5975054)
could you split this into 2 (or more) separate patches? - some of your comments are good, and could have been pushed a month ago. - the macro changes are highly problematic and probably won't be accepted for at least a few months. I never like seeing good changes postponed due to them being squashed together with questionable ones. http://codereview.appspot.com/5975054/diff/1/lily/accidental-placement.cc File lily/accidental-placement.cc (right): http://codereview.appspot.com/5975054/diff/1/lily/accidental-placement.cc#newcode116 lily/accidental-placement.cc:116: //TODO: add comment to this struct this still doesn't add any useful information. I mean, of course it would be nice to explain stuff in the code. But there's no point going around adding // TODO: comment this to every single struct/class/method/function. http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc File lily/note-collision.cc (right): http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc#newcode404 lily/note-collision.cc:404: for_UP_and_DOWN (d) On 2012/03/31 21:04:35, Keith wrote: If you write the 'for' loop directly in the code, then neither humans nor auto-indent programs need to learn a macro: for (Direction d = UP; d; d = (UP == d)? DOWN : CENTER) Ouch. I don't find that for loop to be particularly easy to understand; it would be much nicer if there was a macro for this. I wonder if we could ask astyle to add a --custom-loop-commands=for_UP_and_DOWN option? it would take a while for that to reach an official release, but at least there would be some hope of simplifying this. I agree that we shouldn't switch to a macro if that ruins the indentation. http://codereview.appspot.com/5975054/diff/1/lily/note-collision.cc#newcode577 lily/note-collision.cc:577: for_UP_and_DOWN (d) // please, make a comment to this loop (better than the above one...) adding a comment to say please comment this does not help http://codereview.appspot.com/5975054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
