What's with the test-patches volunteers?
It is close to two months that I have been the only person running test-patches, even though several volunteers claimed they would do so. It has been the main reason I shelled out €20 for a week of internet access during my spring vacation. My limited computing resources mean that I have to take every shortcut I can to get this reasonably done. It is a bottleneck of development. My shortcuts tend to lead to erroneous data for making decisions, cf URL:http://code.google.com/p/lilypond/issues/detail?id=2468#c25, and thus can alienate developers and cause unnecessary delays and hickups. It also means that I can spare no flexibility for dealing with things like submissions not following the rules URL:http://code.google.com/p/lilypond/issues/detail?id=2480, again possibly alienating developers instead of getting them more smoothly into our procedures. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
hideNotes should hide also TabNoteHead (issue 2480). (issue 6105049)
LGTM http://codereview.appspot.com/6105049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
2012/4/22 James pkx1...@gmail.com: Hello, On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote: 2012/4/20 Graham Percival gra...@percival-music.ca: We do not have a long history of flawless git actions from translations, so my preference would be not to touch anything. Good idea! The definitive recipe for eternal flawless development is not to touch anything, ever. Better safe than sorry. Gosh! Talk about taking something out of context. No one said 'ever' - you said that, True, apologies. Failed joke/irony. consider this a moment of 'reflection', if you want an analogy. James Oh, I watch and see myself reflected, thanks. I tried to react more to the not a long history than to the not touching. I want my and others' work to be there but I am afraid of doing anything that breaks it all. On the other hand, I can not omit doing things forever just for safety. Therefore, I have to assume a certain degree of risk. I already apologized when it went bad. After that, everything has gone smoothly. Git history will judge us all. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Francisco Vila paconet@gmail.com writes: On the other hand, I can not omit doing things forever just for safety. Therefore, I have to assume a certain degree of risk. I already apologized when it went bad. After that, everything has gone smoothly. Git history will judge us all. The thing to remember is that git history can be both _viewed_ and _changed_ before pushing it upstream. So there is not much of a risk one has to assume. Graham asked for extra carefulness when pushing directly to release/unstable. That is different from asking for extra fatalism because one can always check what one is doing. The current spacing folderol in connection with issue 2468 makes this a moot point right now: we can't really release 2.15.37 as 2.16, so translators have a bit more time for business as usual. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's with the test-patches volunteers?
- Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Sunday, April 22, 2012 7:31 AM Subject: What's with the test-patches volunteers? It is close to two months that I have been the only person running test-patches, even though several volunteers claimed they would do so. It has been the main reason I shelled out €20 for a week of internet access during my spring vacation. My limited computing resources mean that I have to take every shortcut I can to get this reasonably done. It is a bottleneck of development. My shortcuts tend to lead to erroneous data for making decisions, cf URL:http://code.google.com/p/lilypond/issues/detail?id=2468#c25, and thus can alienate developers and cause unnecessary delays and hickups. It also means that I can spare no flexibility for dealing with things like submissions not following the rules URL:http://code.google.com/p/lilypond/issues/detail?id=2480, again possibly alienating developers instead of getting them more smoothly into our procedures. -- David Kastrup = I think Marek was looking at doing this? Paging Marek? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnote documentation error
Hi bug-squad, On 22/04/12 06:39, James wrote: Hello, On 22 April 2012 04:12, Mark Mathias d8val...@gmail.com wrote: So... as far as the Bug Squad is concerned, are we still waiting for something or does this need to get added to the tracker? Thanks, Mark As far as the bug squad are concerned - being one myself - we'd like a confirmation that this is a documentation error or an unexpected/inconsistent behaviour in the code. I haven't seen a case for either yet. Or do you have enough information for determining it as a case of TTWIW (that's the way it works) and answering this as Invalid? Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Strange loop executed only once!
Hi,
I have spotted a strange loop in lily/ledger-line-spanner.cc (lines 46-69):
Direction d = UP;
do
{
.
}
while (flip (d) != DOWN);
*It will be executed only once - with d set to UP.* To be executed for d =
UP and then d = DOWN, it should be:
while (flip (d) != *UP*);
Could someone take a look at this?
Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Git history will judge us all. Interesting. Up to now I've assumed God does this. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Werner LEMBERG w...@gnu.org writes: Git history will judge us all. Interesting. Up to now I've assumed God does this. If HE weren't a fan of distributed version control systems, why create the world in the first place? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Interesting. Up to now I've assumed God does this. If HE weren't a fan of distributed version control systems, why create the world in the first place? Good point :-) This reminds me of a joke: Two planets meet. `How are you?' `Well, not very well.' `How comes?' `I suffer from homo sapiens.' `Oh, don't worry, you'll get over it.' Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Hello, On 22 April 2012 11:59, David Kastrup d...@gnu.org wrote: Werner LEMBERG w...@gnu.org writes: Git history will judge us all. Interesting. Up to now I've assumed God does this. If HE weren't a fan of distributed version control systems, why create the world in the first place? God Loves Git Now there's a rallying cry/T-shirt slogan if ever I've heard one! James PS For all those who are not British, I don't think I can convey the absolute simple pleasure that I (at least, perhaps others) get from having a DVCS called 'Git' :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: for_UP_and_DOWN
sorry for the delay; I was on holidays
On Fri, Apr 20, 2012 at 10:45 AM, Łukasz Czerwiński
milimet...@gmail.com wrote:
Could you please say, if there was a reason for using
do {
} while(flip(d));
instead of my macro: if (UP_and_DOWN)
Macros make code harder to read for people not into the project, so it
is good to be conservative with applying them. That said, I think a
macro for this pattern is justified given its frequency of appearance.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Strange loop executed only once!
On Sun, Apr 22, 2012 at 7:20 AM, Łukasz Czerwiński milimet...@gmail.com wrote:
Hi,
I have spotted a strange loop in lily/ledger-line-spanner.cc (lines 46-69):
Direction d = UP;
do
{
.
}
while (flip (d) != DOWN);
It will be executed only once - with d set to UP. To be executed for d = UP
and then d = DOWN, it should be:
while (flip (d) != UP);
Could someone take a look at this?
Looks like a bug. Maybe you could work on a test/repro case? I think
it will trigger if you have noteheads with ledgers very closely spaced
under the staff (the code is to enforce a minimum distance so the
ledger lines remain visible).
this also looks a little suspect:
Real total_head_length = previous_extents[d].length ()
+ current_extents[d].length ();
I would expect that it should add
current[d][RIGHT] - previous[d][LEFT]
perhaps this will set rods too large if you have lots of ledgered
chords with seconds in them, in a tight spacing configuration.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part_combine_iterator::derived_mark: don't abort marking prematurely. (issue 6057044)
On Wed, Apr 18, 2012 at 4:56 AM, d...@gnu.org wrote:
Short of any protests, I think I'll be going with
void
Part_combine_iterator::derived_mark () const
{
if (first_iter_)
scm_gc_mark (first_iter_-self_scm ());
if (second_iter_)
scm_gc_mark (second_iter_-self_scm ());
if (unisono_event_)
scm_gc_mark (unisono_event_-self_scm ());
if (mmrest_event_)
scm_gc_mark (mmrest_event_-self_scm ());
if (solo_one_event_)
scm_gc_mark (solo_one_event_-self_scm ());
if (solo_two_event_)
scm_gc_mark (solo_two_event_-self_scm ());
}
All the rest is too smart for its own good.
FYI, my experience is that writing this type of code involves cut
paste, and it is easy to make errors like
if (some_new_event_)
mark(the_event_i_copied_it_from_)
I agree that 4 is borderline small enough not to use a loop.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's with the test-patches volunteers?
On 12-04-22 03:57 AM, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Sunday, April 22, 2012 7:31 AM Subject: What's with the test-patches volunteers? It is close to two months that I have been the only person running test-patches, even though several volunteers claimed they would do so. It has been the main reason I shelled out €20 for a week of internet access during my spring vacation. My home machine stays powered and idle, except for BOINC, while I'm at the office. With a bit of a leg up, I can help out by way of a cron job. Cheers, Colin Senex -- 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: What's with the test-patches volunteers?
Hello, On 22 April 2012 16:00, Colin Campbell c...@shaw.ca wrote: On 12-04-22 03:57 AM, Phil Holmes wrote: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Sunday, April 22, 2012 7:31 AM Subject: What's with the test-patches volunteers? It is close to two months that I have been the only person running test-patches, even though several volunteers claimed they would do so. It has been the main reason I shelled out €20 for a week of internet access during my spring vacation. My home machine stays powered and idle, except for BOINC, while I'm at the office. With a bit of a leg up, I can help out by way of a cron job. This isn't 'that' patchy - you cannot really cron it Needs a bit of human input. http://lilypond.org/doc/v2.15/Documentation/contributor/patchy Specifically - test-patches.py: I already run lilypond-patchy-staging.py on my machine, you don't need to worry about that so much. Graham calls it all 'patchy' - I like to think of them as Brother and Sister. ;) Patchy and Patchita chuckle James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: LM - Use Homophonic instead of Monophonic (issue 6107045)
http://codereview.appspot.com/6107045/diff/1/Documentation/learning/fundamental.itely File Documentation/learning/fundamental.itely (right): http://codereview.appspot.com/6107045/diff/1/Documentation/learning/fundamental.itely#newcode1045 Documentation/learning/fundamental.itely:1045: % The following notes are homophonic I don't have a better suggestion right now, but _notes_ are always mono/homophonic. Voices, or voicings, or passages or pieces or composition styles are mostly homo/polyphonic. For example, a Bach choral will usually be set in a homophonic style, whereas something he marks chorus will tend to be largely polyphonic. http://codereview.appspot.com/6107045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnote documentation error
So... as far as the Bug Squad is concerned, are we still waiting for something or does this need to get added to the tracker? Thanks, Mark On Fri, Apr 20, 2012 at 1:52 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 20, 2012, at 7:40 AM, James wrote: Hello, On 20 April 2012 00:40, Nick Payne nick.pa...@internode.on.net wrote: The documentation at http://lilypond.org/doc/v2.15/Documentation/notation/creating-footnotesfor both automatic and manual footnotes says that the \footnote command must come *before* the grob to which the footnote is being attached. This doesn't seem to be the case. Here the \footnote commands are after the notes to which they are attached, and they work fine: I think this was to do with David's additional work on Mike's a few months ago when what he did changed the requirement from the original footnote document in earlier versions of 2.15. We did re-write much of the examples and obviously missed this. I actually think this has something to do with David's work on the parser (could be wrong...). This is the postfix variety of footnote, or the one that does not need to specify a grob and assigns the footnote to whatever grob is created by the first event that comes down the pipe. I'm actually amazed that it works, as the NoteHead is facultative - if you replaced it w/ Stem it'd do the same thing (meaning footnote the NoteHead). Cheers, MS ___ lilypond-user mailing list lilypond-u...@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Rename translation branch
Hello, David and all, I'd like the lilypond/translation branch to be renamed to just 'translation' if there are no objections. David, I recall you did something similar for 'staging'. A good moment would be just after one or two 2.16 releases, I think. Comments? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename translation branch
Francisco Vila paconet@gmail.com writes: Hello, David and all, I'd like the lilypond/translation branch to be renamed to just 'translation' if there are no objections. David, I recall you did something similar for 'staging'. A good moment would be just after one or two 2.16 releases, I think. Comments? We can do this as soon as you want to. I don't see that this would be related to releases, as the branch naming is not relevant to users. In fact, since we distribute the Contributor's Guide also as part of the stable documentation (and it will stick around for a long time on people's disks), it would make more sense to preferably change it _before_ rather than after major releases, and make the CG match. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rename translation branch
Le 22/04/2012 19:59, David Kastrup disait : Francisco Vilapaconet@gmail.com writes: Hello, David and all, I'd like the lilypond/translation branch to be renamed to just 'translation' if there are no objections. David, I recall you did something similar for 'staging'. A good moment would be just after one or two 2.16 releases, I think. Comments? We can do this as soon as you want to. I don't see that this would be related to releases, as the branch naming is not relevant to users. In fact, since we distribute the Contributor's Guide also as part of the stable documentation (and it will stick around for a long time on people's disks), it would make more sense to preferably change it _before_ rather than after major releases, and make the CG match. I totally agree to do it before the release. Paco, you know what just happened with lilypond.pot. I consider its generation should be part of releasing. I'm still on it. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Document fingerings being frets rather than fingers for fretted instruments. (issue 6099046)
One nitpick; otherwise LGTM http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely File Documentation/notation/fretted-strings.itely (right): http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely#newcode68 Documentation/notation/fretted-strings.itely:68: when assigning strings, this distinction is not academical. In English we'd say academic; is American different? http://codereview.appspot.com/6099046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Document fingerings being frets rather than fingers for fretted instruments. (issue 6099046)
I believe that this is wrong -- fingerings are fingers for fretted instruments, not frets. http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely File Documentation/notation/fretted-strings.itely (right): http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely#newcode68 Documentation/notation/fretted-strings.itely:68: when assigning strings, this distinction is not academical. I don't think this is true. Fingerings specify string and finger; the fret is automatically calculated. Tablature notations heed string assignments, which determine frets. Then non-assigned strings try to find frets within a specified reach. I think this paragraph is wrong. If it is right, please create a snippet that shows the difference. http://codereview.appspot.com/6099046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Document fingerings being frets rather than fingers for fretted instruments. (issue 6099046)
Reviewers: Trevor Daniels, carl.d.sorensen_gmail.com,
http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/6099046/diff/1/Documentation/notation/fretted-strings.itely#newcode68
Documentation/notation/fretted-strings.itely:68: when assigning strings,
this distinction is not academical.
On 2012/04/22 21:03:12, Carl wrote:
I don't think this is true.
Fingerings specify string and finger; the fret is automatically
calculated.
Tablature notations heed string assignments, which determine frets.
Then
non-assigned strings try to find frets within a specified reach.
I think this paragraph is wrong. If it is right, please create a
snippet that
shows the difference.
The documentation itself contains examples with finger 6 6 7 or so: I
think it was me who added them some time ago. Checking the code, it
might indeed be that the only question asked of the fingering might be
0 or not. I will cross-check with actual tablatures tomorrow.
If you are right, the existing examples in the docs need some changes.
Description:
Document fingerings being frets rather than fingers for fretted
instruments.
Please review this at http://codereview.appspot.com/6099046/
Affected files:
M Documentation/notation/fretted-strings.itely
Index: Documentation/notation/fretted-strings.itely
diff --git a/Documentation/notation/fretted-strings.itely
b/Documentation/notation/fretted-strings.itely
index
e8deaafb8c9402363d8e4f9195a39416d2d4c82d..77ac4ea5b402ab543bc9a58844b031ad0a249d2e
100644
--- a/Documentation/notation/fretted-strings.itely
+++ b/Documentation/notation/fretted-strings.itely
@@ -62,7 +62,10 @@ are covered elsewhere:
@itemize
@item Fingerings are indicated as shown in
-@ref{Fingering instructions}.
+@ref{Fingering instructions}. As opposed to unfretted string
+instruments, however, the @q{fingerings} don't indicate the finger but
+rather the fret to use. Since the tablature notations heed fingerings
+when assigning strings, this distinction is not academical.
@item Instructions for @notation{Laissez vibrer} ties
as well as ties on arpeggios and tremolos can be found in
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120424
For 20:00 MDT Tuesday April 24 Critical: Issue 2468 http://code.google.com/p/lilypond/issues/detail?id=2468: augmentation dot of a moved rest is placed on a line - R6035053 http://codereview.appspot.com/6035053/ Defect: Issue 2449 http://code.google.com/p/lilypond/issues/detail?id=2449: Redesign stream event class representation - R6098050 http://codereview.appspot.com/6098050/ Documentation: Issue 2488 http://code.google.com/p/lilypond/issues/detail?id=2488: Doc: LM - Change 'Monophonic' to 'Homophonic' - R6107045 http://codereview.appspot.com/6107045/ Issue 2490 http://code.google.com/p/lilypond/issues/detail?id=2490: Patch: Document fingerings being frets rather than fingers for fretted instruments. - R6099046 http://codereview.appspot.com/6099046/ Enhancement: Issue 2489 http://code.google.com/p/lilypond/issues/detail?id=2489: Patch: Change \bendAfter and \rightHandFinger into event functions - R6102045 http://codereview.appspot.com/6102045/ Patch: Issue 2480 http://code.google.com/p/lilypond/issues/detail?id=2480: hideNotes and unHideNotes should include also TabNoteHead - R6105049 http://codereview.appspot.com/6105049/ Cheers, Colin -- 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: Doc: LM - Use Homophonic instead of Monophonic (issue 6107045)
LGTM, please push directly. Small suggestion below but I'm not particularly enamoured with it. You can push it whether or not you like it. http://codereview.appspot.com/6107045/diff/1/Documentation/learning/fundamental.itely File Documentation/learning/fundamental.itely (right): http://codereview.appspot.com/6107045/diff/1/Documentation/learning/fundamental.itely#newcode1045 Documentation/learning/fundamental.itely:1045: % The following notes are homophonic On 2012/04/22 16:16:00, dak wrote: I don't have a better suggestion right now, but _notes_ are always mono/homophonic. This section is homophonic ? http://codereview.appspot.com/6107045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: LM - Use Homophonic instead of Monophonic (issue 6107045)
LGTM, please push directly. Small suggestion below but I'm not particularly enamoured with it. You can push it whether or not you like it. http://codereview.appspot.com/6107045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Let rhythmic-engraver make its articulation-or-event decision based on current listeners (issue 6098050)
LGTM
http://codereview.appspot.com/6098050/diff/2001/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/6098050/diff/2001/Documentation/changes.tely#newcode170
Documentation/changes.tely:170: Another consequence is that string
numbers and right hand fingerings on
IMO each @item should be self-contained, and multi-paragraph items are
the way to go if there's multiple implications of a single change.
Could this (and the previous @item) just be additional paragraphs (i.e.
remove the @item).
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (left):
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely#oldcode103
Documentation/notation/fretted-strings.itely:103: @warning{String
numbers @strong{must} be defined inside a chord
awesome change.
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely#newcode521
Documentation/notation/fretted-strings.itely:521: \new Voice \with {
\override StringNumber #'stencil = ##f } {
our vague almost-certainly-unwritten guidelines on lilypond formatting
would suggest that the \override should be on a newline, but I can't be
bothered to complain about this.
http://codereview.appspot.com/6098050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Change \bendAfter and \rightHandFinger into event functions (issue 6102045)
LGTM http://codereview.appspot.com/6102045/diff/1/Documentation/notation/fretted-strings.itely File Documentation/notation/fretted-strings.itely (right): http://codereview.appspot.com/6102045/diff/1/Documentation/notation/fretted-strings.itely#newcode1589 Documentation/notation/fretted-strings.itely:1589: e\rightHandFinger 2 oh god. At one point, we tried to eliminate all #-less numbers to avoid confusion like this. I know that you're proud of parser work which lets us write a bare 2 here, but I fear this would lead to user confusion and not be a net positive. Could we leave the #2 there? http://codereview.appspot.com/6102045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20120424
On Apr 22, 2012, at 9:01 PM, Colin Campbell c...@shaw.camailto:c...@shaw.ca wrote: For 20:00 MDT Tuesday April 24 Documentation: Issue 2488http://code.google.com/p/lilypond/issues/detail?id=2488: Doc: LM - Change 'Monophonic' to 'Homophonic' - R 6107045http://codereview.appspot.com/6107045/ Issue 2490http://code.google.com/p/lilypond/issues/detail?id=2490: Patch: Document fingerings being frets rather than fingers for fretted instruments. - R 6099046http://codereview.appspot.com/6099046/ 2490 should be removed from countdown. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20120424
Carl Sorensen c_soren...@byu.edu writes: On Apr 22, 2012, at 9:01 PM, Colin Campbell c...@shaw.ca wrote: For 20:00 MDT Tuesday April 24 Documentation: Issue 2488: Doc: LM - Change 'Monophonic' to 'Homophonic' - R 6107045 Issue 2490: Patch: Document fingerings being frets rather than fingers for fretted instruments. - R 6099046 2490 should be removed from countdown. Don't worry. It won't reach the finishing line, anyway. I am just annoyed that a number of cousins already made it and need to get ripped out again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hideNotes should hide also TabNoteHead (issue 2480). (issue 6105049)
works good for me. I can see the sense in either splitting into two commits as you mentioned in email (the \hideNotes commit first) or combining into one (which makes more sense to me since they are so closely related). http://codereview.appspot.com/6105049/diff/1/Documentation/ly-examples/tab-example.ly File Documentation/ly-examples/tab-example.ly (left): http://codereview.appspot.com/6105049/diff/1/Documentation/ly-examples/tab-example.ly#oldcode41 Documentation/ly-examples/tab-example.ly:41: e-3 \2 ( d-1 b ) \grace ais-2 16 ( \glissando a8 g ) s4. I need an \override NoteColumn #'ignore-collision = ##t here or else I get a warning (either before or after this patch). I mention this only because I broke the doc build not too long ago by causing a warning from Lilypond input in the docs. (patchy didn't catch this, at the time.) http://codereview.appspot.com/6105049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let rhythmic-engraver make its articulation-or-event decision based on current listeners (issue 6098050)
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely#newcode521
Documentation/notation/fretted-strings.itely:521: \new Voice \with {
\override StringNumber #'stencil = ##f } {
On 2012/04/23 03:43:13, Graham Percival wrote:
our vague almost-certainly-unwritten guidelines on lilypond formatting
would
suggest that the \override should be on a newline, but I can't be
bothered to
complain about this.
Unless it produces a black bar line at the end of the PDF output. Then
Phil will be pissed ;)
http://codereview.appspot.com/6098050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
