Make \footnote a post-event (issue 6203044)
I like the way you showed the results of the convert-ly regexp on the docs. Step 1 looks good, and I hope you can find time to do the re-ordering by hand for step 2. http://codereview.appspot.com/6203044/diff/1018/input/regression/collision-seconds.ly File input/regression/collision-seconds.ly (right): http://codereview.appspot.com/6203044/diff/1018/input/regression/collision-seconds.ly#newcode1 input/regression/collision-seconds.ly:1: \version 2.14.0 convert-ly changed this because I mis-typed an older version number when expanding this test. I'll change it later to 2.15.34 unless you do it with this commit. http://codereview.appspot.com/6203044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Display postevents on drum notes, rests and spacer rests (issue 6195059)
It works for me. Even if I can't read Scheme I can run it, and maybe pick different test-cases than you. http://codereview.appspot.com/6195059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: mention empty chords; avoid using zero-duration spacers in examples (issue 6197068)
LGTM
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely#newcode89
Documentation/notation/simultaneous.itely:89: r4 e8( g ) ^sul D \f
\ \repeat unfold 8 { c-. } r2\!
Interestingly, s1*0 does not work in this situation to attach the
annotations to the first note in the repeated section, but is fine.
Unfortunately, is of no help for attaching the \! to the final note
of the repeated section.
http://codereview.appspot.com/6197068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: mention empty chords; avoid using zero-duration spacers in examples (issue 6197068)
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely#newcode89
Documentation/notation/simultaneous.itely:89: r4 e8( g ) ^sul D \f
\ \repeat unfold 8 { c-. } r2\!
On 2012/05/10 08:50:38, Trevor Daniels wrote:
Interestingly, s1*0 does not work in this situation to attach the
annotations to
the first note in the repeated section, but is fine.
Unfortunately, is of
no help for attaching the \! to the final note of the repeated
section.
That example gives me a headache. s1*0 will work just fine: you just
have to put an explicit duration on { c8-. }. If the decrescendo should
be on the last note, you would either cut the repeat short by one, or
write
{ r4 e8( g { s8*7) ^sul D \f \ s8\! }
\repeat unfold 8 { c8-. } r2\! }
But I think the whole thing is too clever for the notation manual. The
rather contrived ways of avoiding to spell out first/last iterations
complicate things rather than simplify them.
http://codereview.appspot.com/6197068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \footnote a post-event (issue 6203044)
LGTM http://codereview.appspot.com/6203044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Stop SkipMusic from being marked as rhythmic-event. (issue 6189051)
LGTM http://codereview.appspot.com/6189051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Display postevents on drum notes, rests and spacer rests (issue 6195059)
LGTM http://codereview.appspot.com/6195059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PO: modifying po-replace before integrating it to the release process (issue 6188051)
I can't see anything wrong, but it would be nice if somebody other than lilyfan could test this. I'm on vacation so I can't really test it until May 30. http://codereview.appspot.com/6188051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: add updating of lilypond.pot in the release process (issue 6195060)
http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi File Documentation/contributor/release-work.itexi (right): http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi#newcode87 Documentation/contributor/release-work.itexi:87: make po-replace Thanks, this is exactly the kind of thing I wanted you to do! However, a few note: the po-replace must happen before the vi command, otherwise the make po-replace text will be sent to the vi command when I copypaste the entire block. Also, how about moving po-replace above the vi, then adding the git commit ... po/lilypond.pot above the vi command as well? That'll make the copypaste process easier. http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi#newcode373 Documentation/contributor/release-work.itexi:373: coordinator@@translationproject.org, mentioning lilypond-VERSION.pot I think you already know this, but just to confirm: you know that this isn't part of the regular release process? http://codereview.appspot.com/6195060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Plan for discussions
Spent yesterday wandering around Kloten, the old town part of Zurich, and looking at stain-glass windows. Spent this morning walking along Uetliberg, a series of hills right next to the city. Travel advice: skip the city and culture, just go straight to the Alps. Ok, maybe Uetliberg isn't high enough to qualify as alps, but the basic idea is the same -- cities aren't worth the trouble; the vertically-based wilderness is the place to be. Anyway. We need an avenue for structured discussions. Technical questions have a firm right or wrong -- a piece of code either leaks memory or it doesn't; a slur either collides with a finger or it doesn't. That type of discussion needs no special handling; in the very worst case, anybody involved can simply run the code and see the same results on their own computer. (or if the code runs differently, then the discussion can/will usefully shift to investigating the cross-platform problems) But policy and human-computer interaction questions lack objective answers. How often should we have stable releases? It depends on how we view the software, what kind of assurances we want to provide to users, what kind of reputation we want, etc. Depending on what we choose, we may have more (or fewer) questions on the mailing list, more (or fewer) new contributors, more (or less) morale of the existing developers, etc. There's no obviously correct answer, and even if we agreed on all the factors we should consider, every person involved would give different weights to each factor. Even worse, we don't have a firm plan on how to deal with these questions. My impression is that we don't mind postponing something if there's a clear reason to do so, as long as there's some assurance that it will be done -- and ideally, an exact date at which it will happen. So here's what I propose: in the summer we'll re-start the Grand Organization Project discussions, and also start GLISS. In June, we will begin GOP2 discussions with the same format as last year: I will post an initial discussion email which opens the topic, gives an overview of the options and their benefits and costs, and possibly includes a tentative suggestion. (this may be written by somebody other than me, but I will still schedule the discussions as well as check that a topic has enough info such that we can have a reasonable discussion about it) The discussion will last for one week to ideally reach consensus, then I'll summarize the discussion and the current proposal. There will then be a second week for second thoughts or additional debate. If everything has settled by the end of the second week, we accept that proposal; if not, we'll either extend the discussion or abandon/postpone the proposal. There's some doubts about some of the policy decisions we made last year, either because a topic didn't gather enough interest and slipped in, or because we have more information now than we did last year. For that reason, we'll revise everything. First two questions: 0. we are a GNU project. (not open to debate, just a re-affirmation of fact, plus a longer examination+discussion of exactly what that means) 1. release policy -- when should we have a stable release? In July, we will begin GLISS, almost certainly in the same format as GOP. Initial Discussion questions will try to be as general as possible -- for example, instead of arguing if we should have \hideNotes vs. \notesHide, we will discuss the general question of noun-verb vs. verb-noun command names (a third option would be to decide to have no general policy on this issue and treat everything on their own individual merits, but I hope we don't take this decision because that leads to a ton of discussions). Hopefully we can settle a good chunk of questions at once in that manner. My supervisor for my Masters degree often noted that HCI (human-factor interaction) conferences have the nastiest discussions in all of Computer Science -- if you're at a conference on data structures then people are really nice and positive and try to give useful advice to each other, whereas HCI discussions tend to rip each other apart. I've noted a similar thing in music academia -- the more subjective the subject, the more personal the participants take the debate. It's an understandable human response that is seen in any number of venues. For that reason, I'm going to try to keep the GLISS discussions as focused as possible. That's why I'm reserving an extra month before starting it. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: add updating of lilypond.pot in the release process (issue 6195060)
Uploading new version http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi File Documentation/contributor/release-work.itexi (right): http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi#newcode87 Documentation/contributor/release-work.itexi:87: make po-replace On 2012/05/10 13:26:29, Graham Percival wrote: Thanks, this is exactly the kind of thing I wanted you to do! However, a few note: the po-replace must happen before the vi command, otherwise the make po-replace text will be sent to the vi command when I copypaste the entire block. Also, how about moving po-replace above the vi, then adding the git commit ... po/lilypond.pot above the vi command as well? That'll make the copypaste process easier. Done. http://codereview.appspot.com/6195060/diff/1/Documentation/contributor/release-work.itexi#newcode373 Documentation/contributor/release-work.itexi:373: coordinator@@translationproject.org, mentioning lilypond-VERSION.pot On 2012/05/10 13:26:29, Graham Percival wrote: I think you already know this, but just to confirm: you know that this isn't part of the regular release process? Yes, but it is not bad to give the correct contact... http://codereview.appspot.com/6195060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dictionary for musical terms in Lilypond
On 9 May 2012 10:35, Trevor Daniels t.dani...@treda.co.uk wrote: Łukasz Czerwiński wrote Sunday, April 29, 2012 12:18 PM Thanks all three of you for your immediate reply! :) I didn't know about the glossary. One problem with it is that for musical terms, except for notes and rests, it works only it the opposite direction: English - other language, while the case is: other language - English. The solution could be for example creating for all terms such a table as for notes and rests: http://lilypond.org/doc/v2.15/**Documentation/music-glossary/** duration-names-notes-and-restshttp://lilypond.org/doc/v2.15/Documentation/music-glossary/duration-names-notes-and-rests **. What do you think? I think the easiest approach would be to create a multi-language index for each term. This was discussed briefly a couple of years ago, but nothing came of it. See http://lists.gnu.org/archive/**html/lilypond-user/2009-11/**msg2.htmlhttp://lists.gnu.org/archive/html/lilypond-user/2009-11/msg2.html Trevor Well, I could prepare translations for my language (Polish), but preparing the script to handle creating a nice table is above my capabilities. Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Your Gnu package lilypond
On Sun, May 6, 2012 at 5:24 PM, Graham Percival gra...@percival-music.ca wrote: On Sun, May 06, 2012 at 05:15:59AM -0400, John Darrington wrote: Thank you for your very comprehensive reply, which inspired me to look at the lilypond website. It is indeed very elaborate and certainly gives a very professional impression. (There are however a few terminology issues which I think need attention - See section 14 of the GNU Maintainers guide http://www.gnu.org/prep/maintain/maintain.html ) tldr. i assume it's about open source vs free software, i know this issue. Janek, how about you fix this. pushed as 38c1148ef2d73151379e9a694c3c061d8a31d548 cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Allows lyrics to slide under TimeSignature when OctaveEight present. (issue 6201068)
http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc File lily/pure-from-neighbor-engraver.cc (right): http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc#newcode56 lily/pure-from-neighbor-engraver.cc:56: in_same_column (Grob *g1, Grob *g2) That's problably the most stupid question ever, but why this doesn't it begin with Pure_from_neighbor_engraver:: ? I don't see it being special. http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc#newcode119 lily/pure-from-neighbor-engraver.cc:119: Pointer_group_interface::add_grob (need_pure_heights_from_neighbors[pos[j]][k], ly_symbol2scm (neighbors), pure_relevants_[i]); could you reduce line width, please? This one is way over regular 80 chars limit. http://codereview.appspot.com/6201068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
web: update GSoC subpage (issue 6190068)
A couple of small grammatical suggestions. I'm fine being listed on these projects as a potential mentor. Thanks, Carl http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi File Documentation/web/community.itexi (right): http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi#newcode878 Documentation/web/community.itexi:878: It is a global program ran by Google that offers students stipends s/ran/run/ http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi#newcode899 Documentation/web/community.itexi:899: very small ones. A full list of all know issues can be found s/know/known/ http://codereview.appspot.com/6190068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows lyrics to slide under TimeSignature when OctaveEight present. (issue 6201068)
LGTM, but I concur with the line-wrap comment of Janek. http://codereview.appspot.com/6201068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: web: update GSoC subpage (issue 6190068)
Reviewers: carl.d.sorensen_gmail.com,
Message:
fixed, thanks!
http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):
http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi#newcode878
Documentation/web/community.itexi:878: It is a global program ran by
Google that offers students stipends
On 2012/05/10 23:42:16, Carl wrote:
s/ran/run/
that's surprising.
http://codereview.appspot.com/6190068/diff/1/Documentation/web/community.itexi#newcode899
Documentation/web/community.itexi:899: very small ones. A full list of
all know issues can be found
On 2012/05/10 23:42:16, Carl wrote:
s/know/known/
Done.
Description:
web: update GSoC subpage
change to GSoC 2012 to make clear that it's over.
rewrite the text to be an inspiration for
anyone interested.
Please review this at http://codereview.appspot.com/6190068/
Affected files:
M Documentation/web/community.itexi
Index: Documentation/web/community.itexi
diff --git a/Documentation/web/community.itexi
b/Documentation/web/community.itexi
index
933e2e83961670fb2e10e52473cd388977f03bc3..642b4779fb66670f3d9ab3dde315b16bf2b35427
100644
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -48,7 +48,7 @@ discussing LilyPond.
@ref{Development}: for contributors and testers.
@item
-@ref{GSoC}: list of projects for Google Summer of Code.
+@ref{GSoC 2012}: our ideas for 2012 edition of Google Summer of Code.
@item
@ref{Authors}: the people who made LilyPond what it is today.
@@ -83,7 +83,7 @@ discussing LilyPond.
* Help us::
* Sponsoring::
* Development::
-* GSoC::
+* GSoC 2012::
* Authors::
* Publications::
* Old news::
@@ -869,41 +869,35 @@ manuals can be found at @url{http://lilypond.org}}
-@node GSoC
-@unnumberedsec GSoC
+@node GSoC 2012
+@unnumberedsec GSoC 2012
@divClass{column-center-top}
@subheading What is Google Summer of Code?
-Quoting
-@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
-GSoC website},
-@qq{Google Summer of Code is a global program that offers students
-stipends to write code for open source projects. Google has worked
-with the open source community to identify and fund exciting projects
-for the upcoming summer.}
+It is a global program run by Google that offers students stipends
+for working on open source software projects during summer vacations.
The LilyPond Team decided that this is an excellent opportunity to find
-new contributors, encourage students already participating in LilyPond
-development to become more involved, and - last but not least - write
-some great code for the benefit of all!
-
-We are participating in GSoC as a part of GNU Project. See
-@uref{http://www.gnu.org/software/soc-projects/guidelines.html,
-GNU GSoC webpage} for information on how to participate.
+new contributors and encourage students already participating in LilyPond
+development to become more involved. One of our contributors was accepted
+for 2012 edition of the program; we hope to participate in future editions
+as well.
@divEnd
@divClass{column-center-bottom}
-@subheading Our Ideas List
+@subheading Our 2012 Ideas List
-Below is a list of projects suggested for GSoC students. If you don't
-see a project that suits you, feel free to suggest your own!
-It's also possible to scale down a project if you feel it's too big.
+Below is a list of projects that we suggested for GSoC 2012 students.
+Although the application period is over, we decided to keep this webpage
+online as an inpiration for anyone who is interested in developing
LilyPond.
+Some members of the development team are willing to help people who would
like
+to tackle these projects.
-We require that every student has basic @code{git} knowledge, and
-recommend that everyone applying for projects other than the last one
-have basic music notation knowledge.
+Of course, there are many more things to improve in LilyPond, including
+very small ones. A full list of all known issues can be found
+@uref{http://code.google.com/p/lilypond/issues/list, here}.
@subheading Grace notes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plan for discussions
On Thu, May 10, 2012 at 4:04 PM, Graham Percival gra...@percival-music.ca wrote: Spent yesterday wandering around Kloten, the old town part of Zurich, and looking at stain-glass windows. Spent this morning walking along Uetliberg, a series of hills right next to the city. Travel advice: skip the city and culture, just go straight to the Alps. Ok, maybe Uetliberg isn't high enough to qualify as alps, but the basic idea is the same -- cities aren't worth the trouble; the vertically-based wilderness is the place to be. Sounds like a nice vacation :) We need an avenue for structured discussions. +1 If we don't discuss them in an organized way (and preferably once and for all), they'll keep appearing all the time. In June, we will begin GOP2 discussions with the same format as last year +1 i suggest to discuss some communication guidelines, for example don't say It's settled then until there's more than 1 day of discussion and not all concerns have been addressed, even if you think that the decision is obvious. Also, how do we treat partial/imperfect/temporary solutions? For example, in the documentation we are using s1*0 now, which has some side effects. doesn't have them, but looks somewhat cryptic. Ideally, a special command would be created, but this requires time, work and discussion, while is already working. Should we accept it or not? In July, we will begin GLISS, As i wrote in a private e-mail, whoah! almost certainly in the same format as GOP. Initial Discussion questions will try to be as general as possible -- for example, instead of arguing if we should have \hideNotes vs. \notesHide, we will discuss the general question of noun-verb vs. verb-noun command names Can we discuss bigger changes in syntax, too? I mean, not just the naming of commands (of course that's needed), but also the stuff that is related to how things work inside Lily. For example syntax for overriding broken spanners, context-id-specific overrides, etc. And independently from GLISS, i have an impression that discussing things over e-mail takes us so much time that there's little resources left for actual programming. At least i know that this affects me and i'm concerned about it; i'm afraid that discussing really big structural changes in LilyPond (which are necessary imho) over e-mail will take sooo much time that it'll be very ineffective. What about a real-life meeting? There will be a GNU conference in Dusseldorf (west Germany) in second half of July, maybe we could meet there for a couple of days and sort out some big picture stuff? I think that discussing LilyPond live for one day will give us better results than a month of mailing lists discussions. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: web: update GSoC subpage (issue 6190068)
Hey Janek, have you seen this thread in -bug list? http://lists.gnu.org/archive/html/bug-lilypond/2012-04/msg00042.html I think that gsoc page should be corrected now, i.e.: - hammer-on and pull-off are already implemented, the only feature to be implemented is bends (a link to issue 1196, where one could see the work done by Marc so far, would be a good idea IMO) issue 2475 (whose title should rather be hammer-on and pull-off should be documented) is not really related to gsoc page, is it? http://codereview.appspot.com/6190068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: note-collison.cc: Scale shifts by width of note at left; issue 1713 (issue 6189048)
http://codereview.appspot.com/6189048/diff/10001/lily/note-collision.cc
File lily/note-collision.cc (right):
http://codereview.appspot.com/6189048/diff/10001/lily/note-collision.cc#newcode301
lily/note-collision.cc:301: of the note heads on the sides that
interfere. */
So, should the offsets really be multiplied? I'd rather think not.
http://codereview.appspot.com/6189048/diff/10001/lily/note-collision.cc#newcode303
lily/note-collision.cc:303: shift_amount *= (extent_up[RIGHT] -
extent_down[LEFT]) / extent_down.length ();
The interesting thing is that the order of voices matters:
\override Staff.NoteHead #'style = #'altdefault
{ c''\breve*1/2 b'1 }
\\
{ b'1 c''\breve*1/2 }
the placement of the notes should be the same in both measures, but it
isn't. Moreover, it's the opposite of current master.
http://codereview.appspot.com/6189048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: note-collison.cc: Scale shifts by width of note at left; issue 1713 (issue 6189048)
On Thu, 10 May 2012 17:21:54 -0700, janek.lilyp...@gmail.com wrote:
The interesting thing is that the order of voices matters:
[]
the placement of the notes should be the same in both measures,but it isn't.
The order of voices produces different placement for half notes.
\override Staff.NoteHead #'style = #'altdefault
{ c''\breve*1/2 b'1 c''2 b' }
\\
{ b'1 c''\breve*1/2 b'2 c'' }
Do we need another special case for breves ?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: mention empty chords; avoid using zero-duration spacers in examples (issue 6197068)
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely#newcode89
Documentation/notation/simultaneous.itely:89: r4 e8( g ) ^sul D \f
\ \repeat unfold 8 { c-. } r2\!
On 2012/05/10 08:50:38, Trevor Daniels wrote:
Unfortunately, is of no help for attaching
the \! to the final note of the repeated section.
Somehow that never bothered me. Conceptually I think of decrescendos as
continuing through the last note. (If the rest were longer, though, I
personally would prefer \! R1*12 )
There is an example under Dynamics
/Documentation/notation/expressive-marks-attached-to-notes.html#dynamics
using a parallel sequence of spacer rests, that shows how to end the
crescendo wherever you want.
Of course a parallel sequence of spacer rests would work here, too, just
it substituted for the other cases of s1*0 in the docs, and like it
could for all the uses by those lazy users whose scores came up in a
search for s1*0 at mutopiaproject.
http://codereview.appspot.com/6197068/diff/1/Documentation/notation/simultaneous.itely#newcode89
Documentation/notation/simultaneous.itely:89: r4 e8( g ) ^sul D \f
\ \repeat unfold 8 { c-. } r2\!
We might not want an example for at all. This one was an amalgam of
the usage I found on mutopiaproject. Another way to demonstrate the
text could be
music = \relative c'' { e16 d c d }
{ f'4 \marcato \music r ^smorz. \mp \ \music \! }
http://codereview.appspot.com/6197068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows lyrics to slide under TimeSignature when OctaveEight present. (issue 6201068)
Reviewers: janek, carl.d.sorensen_gmail.com,
http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):
http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc#newcode56
lily/pure-from-neighbor-engraver.cc:56: in_same_column (Grob *g1, Grob
*g2)
On 2012/05/10 21:40:48, janek wrote:
That's problably the most stupid question ever, but why this doesn't
it begin
with Pure_from_neighbor_engraver:: ? I don't see it being special.
It doesn't need to be a class method - it'll never be called outside of
this file. It is just a small helper function.
http://codereview.appspot.com/6201068/diff/1/lily/pure-from-neighbor-engraver.cc#newcode119
lily/pure-from-neighbor-engraver.cc:119:
Pointer_group_interface::add_grob
(need_pure_heights_from_neighbors[pos[j]][k], ly_symbol2scm
(neighbors), pure_relevants_[i]);
On 2012/05/10 21:40:48, janek wrote:
could you reduce line width, please? This one is way over regular 80
chars
limit.
Done.
Description:
Allows lyrics to slide under TimeSignature when OctaveEight present.
Please review this at http://codereview.appspot.com/6201068/
Affected files:
A input/regression/lyric-octave-eight.ly
M lily/pure-from-neighbor-engraver.cc
Index: input/regression/lyric-octave-eight.ly
diff --git a/input/regression/lyric-octave-eight.ly
b/input/regression/lyric-octave-eight.ly
new file mode 100644
index
..d3ed333bf54f4a7d5a3aa512cc4d5d090d75bdff
--- /dev/null
+++ b/input/regression/lyric-octave-eight.ly
@@ -0,0 +1,16 @@
+\version 2.15.37
+
+\header {
+ texidoc = Lyrics should still slide under @code{TimeSignature} when an
+@code{OctaveEight} is present.
+
+}
+
+\new Staff {
+ \clef treble_8
+ b
+}
+\addlyrics {
+ \set stanza = 1.
+ aaa
+}
Index: lily/pure-from-neighbor-engraver.cc
diff --git a/lily/pure-from-neighbor-engraver.cc
b/lily/pure-from-neighbor-engraver.cc
index
a6e7b5f32fe4539867f3ddbabe136357b8ba9335..413bfe5215d2b5c29e8b08e7799981071aa32bab
100644
--- a/lily/pure-from-neighbor-engraver.cc
+++ b/lily/pure-from-neighbor-engraver.cc
@@ -52,6 +52,17 @@ Pure_from_neighbor_engraver::acknowledge_item (Grob_info
i)
pure_relevants_.push_back (i.item ());
}
+bool
+in_same_column (Grob *g1, Grob *g2)
+{
+ return (g1-spanned_rank_interval ()[LEFT]
+ == g2-spanned_rank_interval ()[LEFT])
+ (g1-spanned_rank_interval ()[RIGHT]
+ == g2-spanned_rank_interval ()[RIGHT])
+ (g1-spanned_rank_interval ()[LEFT]
+ == g1-spanned_rank_interval ()[RIGHT]);
+}
+
void
Pure_from_neighbor_engraver::acknowledge_pure_from_neighbor (Grob_info i)
{
@@ -80,8 +91,10 @@ Pure_from_neighbor_engraver::finalize ()
temp.push_back (need_pure_heights_from_neighbors_[l]);
for (;
(l need_pure_heights_from_neighbors_.size () - 1
-
(need_pure_heights_from_neighbors_[l]-spanned_rank_interval ()[LEFT]
-== need_pure_heights_from_neighbors_[l +
1]-spanned_rank_interval ()[LEFT]));
+ ((need_pure_heights_from_neighbors_[l]
+ -spanned_rank_interval ()[LEFT])
+== (need_pure_heights_from_neighbors_[l + 1]
+-spanned_rank_interval ()[LEFT])));
l++)
temp.push_back (need_pure_heights_from_neighbors_[l + 1]);
need_pure_heights_from_neighbors.push_back (temp);
@@ -99,15 +112,24 @@ Pure_from_neighbor_engraver::finalize ()
{
while (pos[1] (int) need_pure_heights_from_neighbors.size ()
(pure_relevants_[i]-spanned_rank_interval ()[LEFT]
-
need_pure_heights_from_neighbors[pos[1]][0]-spanned_rank_interval
()[LEFT]))
+ (need_pure_heights_from_neighbors[pos[1]][0]
+-spanned_rank_interval ()[LEFT])))
{
pos[0] = pos[1];
pos[1]++;
}
for (int j = 0; j 2; j++)
-if (pos[j] = 0 pos[j] (int)
need_pure_heights_from_neighbors.size ())
- for (vsize k = 0; k
need_pure_heights_from_neighbors[pos[j]].size (); k++)
-Pointer_group_interface::add_grob
(need_pure_heights_from_neighbors[pos[j]][k], ly_symbol2scm (neighbors),
pure_relevants_[i]);
+if (pos[j] = 0 pos[j]
+ (int) need_pure_heights_from_neighbors.size ())
+ for (vsize k = 0;
+ k need_pure_heights_from_neighbors[pos[j]].size ();
+ k++)
+if
(!in_same_column(need_pure_heights_from_neighbors[pos[j]][k],
+pure_relevants_[i]))
+ Pointer_group_interface::add_grob
+(need_pure_heights_from_neighbors[pos[j]][k],
+ ly_symbol2scm (neighbors),
+ pure_relevants_[i]);
}
need_pure_heights_from_neighbors_.clear ();
___
lilypond-devel mailing
PATCH: Countdown to 20120513
For 20:00 MDT Sunday May 13 Defect: Issue 2525 http://code.google.com/p/lilypond/issues/detail?id=2525: Patch: Fix a number of display-lily shortcomings - R 6203056 http://codereview.appspot.com/6203056/ Ugly: Issue 2469 http://code.google.com/p/lilypond/issues/detail?id=2469: stanza number fails to slide under time signature - R 6201068 http://codereview.appspot.com/6201068/ ( Mike updated this just as I was building the list, so if Patchy gives it LGTM, it could stay on countdown, as I believe the changes were cosmetic, not substantive) 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
