Re: Let rhythmic-engraver make its articulation-or-event decision based on current listeners (issue 6098050)
Reviewers: Graham Percival, J_lowe,
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
On 2012/04/23 03:43:13, Graham Percival wrote:
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).
Can do. Problem is that this change, programmatically a side effect, is
rather important to the user on its own. If you want to have the items
more self-contained, they can be either written completely
independently, or the EventChord thing can end with The next two items
are also consequences of this change.
It's sort of a you will likely consider this a nuisance when writing
your own code, but there were good reasons for it reasoning. Maybe the
changes file is not the place for defending the decisions we (TM) made.
Anyway, I think this is important enough for the user-visible
consequences to warrant individual items. Should I mention the relation
in the lead-up, or just drop it?
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
On 2012/04/23 03:43:13, Graham Percival wrote:
awesome change.
Actually, an unexpected side effect of turning the event class hierarchy
away from being a compile-time constant.
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.
Well, this is not a music override but a context modification. I'll
check a bit around for style.
http://codereview.appspot.com/6098050/diff/2001/Documentation/notation/fretted-strings.itely#newcode527
Documentation/notation/fretted-strings.itely:527: \new TabStaff \with {
stringTunings = #bass-tuning } {
This would have to be formatted differently as well if I decided to
change the above.
Description:
Let rhythmic-engraver make its articulation-or-event decision based on
current listeners
This removes the dependency of the rhythmic engraver on a static list
of unlistened event classes and thus is part of work on issue 2449.
As one effect, string numbers on isolated notes in Voice contexts are
now typeset by default since the string numbers have no listener in
Voice contexts even though they would have one in TabVoice.
Please review this at http://codereview.appspot.com/6098050/
Affected files:
M Documentation/changes.tely
M Documentation/notation/fretted-strings.itely
M lily/dispatcher.cc
M lily/include/dispatcher.hh
M lily/rhythmic-music-iterator.cc
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
e57bbe7562eba77fe817a45b9d492552fcc550a8..c1bda08952f5d4b495c1138712360c74a50c7b9e
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -167,6 +167,11 @@ some events of the original chord, he can run the
repeat chord
replacement function @code{\chordRepeats} manually.
@item
+Another consequence is that string numbers and right hand fingerings on
+single notes appear in normal notation without having to be placed
+inside of chord brackets.
+
+@item
Scheme expressions inside of embedded Lilypond (@code{#@{@dots{}#@}})
are now executed in lexical closure of the surrounding Scheme code.
@code{$} is no longer special in embedded Lilypond. It can be used
Index: Documentation/notation/fretted-strings.itely
diff --git a/Documentation/notation/fretted-strings.itely
b/Documentation/notation/fretted-strings.itely
index
e8deaafb8c9402363d8e4f9195a39416d2d4c82d..ef004f3e2cf032f75d849a5f240c4279d254f1e2
100644
--- a/Documentation/notation/fretted-strings.itely
+++ b/Documentation/notation/fretted-strings.itely
@@ -97,15 +97,11 @@ Notation Reference:
@cindex fingering vs. string numbers
The string on which a note should be played may be indicated by
-appending @code{\@var{number}} to a note inside a chord construct
-@code{}.
-
-@warning{String numbers @strong{must} be
Re: Change \bendAfter and \rightHandFinger into event functions (issue 6102045)
Reviewers: Graham Percival,
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
On 2012/04/23 03:45:38, Graham Percival wrote:
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?
Done.
Description:
Change \bendAfter and \rightHandFinger into event functions
Please review this at http://codereview.appspot.com/6102045/
Affected files:
M Documentation/notation/expressive.itely
M Documentation/notation/fretted-strings.itely
M ly/music-functions-init.ly
Index: Documentation/notation/expressive.itely
diff --git a/Documentation/notation/expressive.itely
b/Documentation/notation/expressive.itely
index
0d86f3e639dd7b1344726ce61b11e680dd37e088..d38175ce4858544b5b34f441de1c4ab1a93ef64e
100644
--- a/Documentation/notation/expressive.itely
+++ b/Documentation/notation/expressive.itely
@@ -989,18 +989,14 @@ indicates the pitch interval that the fall or doit
will extend
@emph{beyond} the main note.
@lilypond[verbatim,quote,relative=2]
-c2-\bendAfter #+4
-c2-\bendAfter #-4
-c2-\bendAfter #+6.5
-c2-\bendAfter #-6.5
-c2-\bendAfter #+8
-c2-\bendAfter #-8
+c2\bendAfter #+4
+c2\bendAfter #-4
+c2\bendAfter #+6.5
+c2\bendAfter #-6.5
+c2\bendAfter #+8
+c2\bendAfter #-8
@end lilypond
-The dash @code{-} immediately preceding the @code{\bendAfter}
-command is @emph{required} when writing falls and doits.
-
-
@snippets
@lilypondfile[verbatim,quote,texidoc,doctitle]
Index: Documentation/notation/fretted-strings.itely
diff --git a/Documentation/notation/fretted-strings.itely
b/Documentation/notation/fretted-strings.itely
index
e8deaafb8c9402363d8e4f9195a39416d2d4c82d..b9267e33d050aa0f8416c2d4051da80a8b7e7103
100644
--- a/Documentation/notation/fretted-strings.itely
+++ b/Documentation/notation/fretted-strings.itely
@@ -1580,24 +1580,24 @@ Right-hand fingerings @var{p-i-m-a} must be entered
within a
chord construct @code{} for them to be printed in the score,
even when applied to a single note.
-@warning{There @strong{must} be a hyphen before
-@code{@bs{}rightHandFinger} and a space before the closing @code{}.}
+@warning{If the number is entered in Scheme notation, remember to append
+a space before following it with a closing @code{} or similar.}
@lilypond[quote,verbatim,relative=0]
\clef treble_8
-c-\rightHandFinger #1 4
-e-\rightHandFinger #2
-g-\rightHandFinger #3
-c-\rightHandFinger #4
-c,-\rightHandFinger #1 e-\rightHandFinger #2
- g-\rightHandFinger #3 c-\rightHandFinger #4 1
+c\rightHandFinger #1 4
+e\rightHandFinger #2
+g\rightHandFinger #3
+c\rightHandFinger #4
+c,\rightHandFinger #1 e\rightHandFinger #2
+ g\rightHandFinger #3 c\rightHandFinger #4 1
@end lilypond
For convenience, you can abbreviate @code{\rightHandFinger} to something
short, for example @code{RH},
@example
-#(define RH rightHandFinger)
+RH=#rightHandFinger
@end example
Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index
80c3020ac04b7a2574ad72b85e59cad45edffaac..59a11264f7c741d84d3c854494adfd3f8cdfad2c
100644
--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -178,7 +178,7 @@ barNumberCheck =
cbn n))
bendAfter =
-#(define-music-function (parser location delta) (real?)
+#(define-event-function (parser location delta) (real?)
(_i Create a fall or doit of pitch interval @var{delta}.)
(make-music 'BendAfterEvent
'delta-step delta))
@@ -952,7 +952,7 @@ for time signatures of @var{time-signature}.)
(revert-time-signature-setting time-signature))
rightHandFinger =
-#(define-music-function (parser location finger) (number-or-string?)
+#(define-event-function (parser location finger) (number-or-string?)
(_i Apply @var{finger} as a fingering indication.)
(make-music
___
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)
On 2012/04/23 04:50:21, Keith wrote: 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.) It would make more sense to use \voiceOne for the upper voice. http://codereview.appspot.com/6105049/ ___ 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)
On 2012/04/23 12:03:41, Neil Puttock wrote: On 2012/04/23 04:50:21, Keith wrote: 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.) It would make more sense to use \voiceOne for the upper voice. \voiceOne is already used for the upper voice. The problem is that the voice settings are totally messed up by the standard grace synchronization problem. Remove the graces, and the score typesets fine. http://codereview.appspot.com/6105049/ ___ 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)
On 2012/04/23 12:09:15, dak wrote: \voiceOne is already used for the upper voice. The problem is that the voice settings are totally messed up by the standard grace synchronization problem. Remove the graces, and the score typesets fine. Ah, I didn't scroll down that far. :) Nevertheless, the voicing should be fixed even if it means adding explicit \voiceOne commands at appropriate places. It looks bad with both voices stem-down. The glissando overrides are messed up too. Probably since Mike added code which avoids accidentals automatically (though this should be generalized for other side-supports such as fingerings). http://codereview.appspot.com/6105049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: for_UP_and_DOWN
On 22 April 2012 13:16, Han-Wen Nienhuys hanw...@gmail.com wrote:
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.
Great! http://codereview.appspot.com/6109046/ :)
Łukasz
___
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)
On 2012/04/23 12:09:15, dak wrote: Remove the graces, and the score typesets fine. Removing the initial acciaccatura seems appropriate here. It is used as an example of what LilyPond can do; but starting with a grace note is not yet something LilyPond can do. Changing the music is no problem because this example does not make musical sense --it is only a typesetting example. 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#oldcode49 Documentation/ly-examples/tab-example.ly:49: \partial 4. s4. The manual would recommend a synchronizing grace skip here, \partial 4. \grace s16 s4. and that, instead of the override I suggested earlier, clears the warnings. But, now the \voiceOne and \voiceTwo settings are reversed. http://codereview.appspot.com/6105049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GSoC
Dear Jan, Congratulations on having your Lyrics project accepted for Google Summer of Code! Mike Solomon has been assigned as your mentor, if you're not yet aware of that. I believe that I will be serving as your backup mentor. It's now time to ramp up to speed on your project. It's great to have you working on GSoC for LilyPond! Good job with your perseverance in getting your project accepted! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC
Carl Sorensen wrote Monday, April 23, 2012 9:40 PM Congratulations on having your Lyrics project accepted for Google Summer of Code! Wow, congratulations from me too! You really did put the hours in to generate a great submission - in the middle of your exams too - so you definitely deserve the award! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 21/04/2012 13:09, Graham Percival ha scritto: From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Because then it would be overwritten whenever we do a LSR import. In fact, why do we even need a texidoc string*inside* the snippet? I don't use one for @lilypond examples. Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. So it seems that there are only two possible solutions (I'm just daydreaming): 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone system that would let normal unprivileged users contribute to the docs with almost no oversight by anybody with git access. With all the developer effort that's gone into build and maintaing it, we could have made it easier to do stuff in git and/or trained more doc editors. Since the gamble hasn't paid off (i.e. it didn't encourage *potential contributors*), why keeping this structure that is really annoying current translators (i.e. *real contributors*)? Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC
On Mon, Apr 23, 2012 at 08:40:30PM +, Carl Sorensen wrote: It's great to have you working on GSoC for LilyPond! Good job with your perseverance in getting your project accepted! This, especially. It's great to see that sometimes lots of effort is rewarded! Congratulations, Janek! - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Tue, Apr 24, 2012 at 12:04:57AM +0200, Federico Bruni wrote: Il 21/04/2012 13:09, Graham Percival ha scritto: Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. So it seems that there are only two possible solutions (I'm just daydreaming): 1) manage all the docs snippets in Git and say hello to LSR (see bottom of my email) Do you mean goodbye instead of hello ? 2) ask the LSR author to add the possibility to insert translated titles and descriptions (the website itself could benefit from this, since it may enable language negotiation). But managing the updates may be a problem.. You'd be asking him to do about 30 hours of unpaid work. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone Since the gamble hasn't paid off (i.e. it didn't encourage *potential contributors*), why keeping this structure that is really annoying current translators (i.e. *real contributors*)? Because any change involves work. Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. Any non-trivial change to the current system will take a minimum of 10 hours of work, and I would not be the slightest bit surprised if it ends up taking 50 hours. Are *you* offering to do all that work? To spend 50 hours, and at the end of all that work, have the documentation look exactly the same as it does right now? I don't see this as a wise investment right now. We have much more urgent problems to tackle. And even if we didn't, I think we could get better bang for our buck by putting that amount of energy a different direction. Organizing ly/, organizing the regtests, make Patchy handle automatic countdowns, maybe start GLISS...? there's a *ton* of great projects which would be less work and would produce better rewards. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On 4/23/12 6:25 PM, Graham Percival gra...@percival-music.ca wrote: On Tue, Apr 24, 2012 at 12:04:57AM +0200, Federico Bruni wrote: Personally, I'm a bit worried about going on with translating NR when I know that keeping it up-to-date will be an hassle. Let's manage all the doc snippets in Git and say hello to LSR import! Which are the arguments against this change? It involves work. In particular, horrible build system work, which always takes an order of magnitude longer than you might expect. If the proposal is to eliminate makelsr.py, and just manage our own snippets in Documentation/snippets, it seems to me that the primary task is to eliminate the Do not edit fields from the contents of Documentation/snippets. Is there more that I'm not aware of? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)
Looks good to me, but I suggest you also solve the bug you found (issue 2493) in this patch but preferably as a separate commit. Then you can convert all the loops. http://codereview.appspot.com/6109046/diff/1/flower/include/direction.hh File flower/include/direction.hh (right): http://codereview.appspot.com/6109046/diff/1/flower/include/direction.hh#newcode63 flower/include/direction.hh:63: // huh? If you replace *all* the while(flip()) loops, you can remove the flip function, which is merely object-oriented obfuscation for the unary minus operator. http://codereview.appspot.com/6109046/diff/1/lily/ledger-line-spanner.cc File lily/ledger-line-spanner.cc (right): http://codereview.appspot.com/6109046/diff/1/lily/ledger-line-spanner.cc#newcode52 lily/ledger-line-spanner.cc:52: + current_extents[d].length (); This was mentioned as suspicious in the email, but it looks okay to me. http://codereview.appspot.com/6109046/diff/1/lily/ledger-line-spanner.cc#newcode68 lily/ledger-line-spanner.cc:68: while (flip (d) != DOWN); Possibly you have found the cause for http://code.google.com/p/lilypond/issues/detail?id=2493 One nice thing about your macro (or a loop with both conditions in one place) is that it helps to avoid this type of mistake. http://codereview.appspot.com/6109046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Macro for(UP_and_DOWN) and 3 similar. (issue 2491) (issue 6109046)
LGTM http://codereview.appspot.com/6109046/diff/1/flower/include/direction.hh File flower/include/direction.hh (right): http://codereview.appspot.com/6109046/diff/1/flower/include/direction.hh#newcode78 flower/include/direction.hh:78: #define DOWN_and_UP(d) \ I see that our code uses both versions, and I fully support this patch making a simple substitution for these macros. After it's accepted, it might be nice to investigate this further: do we ever depend on the order of DOWN_and_UP, and if not, could we standardize on UP_and_DOWN (or vice versa). It might also be nice to standardize on either (d) or (dir); I support the latter. However, this is again something which should happen after this patch is pushed. http://codereview.appspot.com/6109046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: measure counter engraver
David Nalesnik david.nales...@gmail.com writes: The examples are written to work with the latest versions. (I'm using the current release candidate.) Then one could use make-engraver. I'd love for people to try this out, to see if it works in situations where you might want such a thing. (If you have a suggestion, see a problem, manage to break it, please do let me know!) Using define-event-class makes the file unfit for inclusion in multi-file runs of LilyPond since define-event-class permanently changes LilyPond. I am working on a replacement URL:http://code.google.com/p/lilypond/issues/detail?id=2449, but the pending patch is just one of several changes needed for changing the event class hierarchy into a per-parser item instead of a global entity. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
