Re: Comparing program function usage over program runs
m...@mikesolomon.org m...@mikesolomon.org writes: Hey all, To further debug 2801, I am looking for a way to not have to run the regtests every time to make the bug appear. Do you mean have to run the regtests or do you mean have people run the regtests? The time for make test-clean make check is rather tolerable once you have a test baseline. Certainly much much shorter than building docs. And just touching some regtest and running make check without make test-clean is quite faster still. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: John Mandereau john.mander...@gmail.com; Devel lilypond-devel@gnu.org Sent: Monday, September 10, 2012 9:46 PM Subject: Re: Minor release checklist Yes. Did you get your repository with git clone ? if so, you should have an origin. It would seem so, because: My .git/config contains: [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://gperci...@git.sv.gnu.org/srv/git/lilypond.git [branch master] remote = origin merge = refs/heads/master rebase = true So do I. which AFAIK is set up automatically for me (other than the url line, which I had to change manually for push access) My guess is that you need the remote = origin line for the branch where you're trying to push to origin. If you're in detached HEAD, you don't have that. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: John Mandereau john.mander...@gmail.com; Devel lilypond-devel@gnu.org Sent: Tuesday, September 11, 2012 1:05 AM Subject: Re: Minor release checklist On Mon, Sep 10, 2012 at 11:54:05PM +0100, Phil Holmes wrote: I guess the best bet is to kick GUB off from a clean state: rm -rf uploads rm -rf target You don't need to kill all of target. It's enough to kill any file or subdirectory containing lilypond inside of target. This can be done with something like rm -rf target/*/*/*lilypond* but I'm not totally certain I have the right number of * in there. Be careful, since this could destroy a lot of your good data if you're not using a separate user account for GUB stuff. (i.e. if you accidently add a space somewhere, that command could start deleting everything on your hard drive) - Graham Hmm. Still getting the same problem. The following directories are missing: gub/uploads/localdoc/V2.17.2 gub/uploads/webdoc/V2.17.2 gub/uploads/webtest/V2.17.2 gub/uploads/webtest/V2.17.2/compare-etc This prevents the upload. It looks like they should be created by unlocked-doc-export: unlocked-test-export: but I can't figure out why these haven't run. Wonder whether running make unlocked-doc-export would fix it, but don't want to just go ahead without further consideration. FWIW I've not pulled the git repo for gub recently. I guess that even if this would help, it would be a long old compile again... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
Graham/Phil, On 11 September 2012 09:51, Phil Holmes m...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: John Mandereau john.mander...@gmail.com; Devel lilypond-devel@gnu.org Sent: Monday, September 10, 2012 9:46 PM Subject: Re: Minor release checklist Yes. Did you get your repository with git clone ? if so, you should have an origin. It would seem so, because: My .git/config contains: [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://gperci...@git.sv.gnu.org/srv/git/lilypond.git [branch master] remote = origin merge = refs/heads/master rebase = true So do I. This has nothing to do with GUB but the 'default' (if you use LilyGit.tcl) to download the git repo is --snip-- [remote origin] fetch = +refs/heads/master:refs/remotes/origin/master ... --snip-- The wildcard is always added manually (at least by me in my case) and took a (very) cursory scan through the CG and I don't see anywhere explicitly stated to make this edit - although I know that email threads with David K were where I know to do this. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .times.
Have to say that I think that there will be greater confusion down to
having 3 different ways to indicate a command, than there will be over
what entity the command applies to.
After all, the general form of
\command x
is easy to understand -- \command applies to the entity x, or
alternatively to any group of entities contained in brackets { }. I
don't think it's confusing in general that x could be a note or some
other entity. (Are there good examples where it _is_ confusing?)
The tricky thing is when you have something like,
c'4 \p c' c' c'
Ok, and now for something completely different. I think there has been
one proposal to bring \[ \] in line with the post-event nature of [ ]
and ( ), but the one thing I have been thinking about recently is
whether we should not actually be going the other way round.
Basically every construct that we would be tempted to use or s1*0 for
occasionally is one that is not really attached to a note, but rather to
a moment in time. You can put it in parallel music without changing
results. Most articulations with a shorthand can be attached to
individual notes in a chord: those are really intrinsically attached to
the note before, and it makes sense keeping that even if per-chord
articulations can be placed into parallel music. But things like ( ) \(
\) [ ] \p \ \! \ all happen at a moment in time in a voice. Why is a
tempo change a separate event, but a dynamic change isn't?
One argument might be that
c( c)
might look ugly, but less ugly than
(c )c
looks. Of course, neither is symmetric. But if our logic is strained
enough that people want to invent new constructs for preserving the
current _order_ of writing while differentiating the logic, maybe it
would make more sense to rethink the order.
Another argument against it would be that all of the above constructs
can benefit from a direction: ^[ is different from _[, and ^\p different
from _p. Should the direction modifier be tied to the occurence of
post-events? Valid question.
And one valid answer certainly would be this ship has sailed. But
that argument would hold equally for the invasive changes introducing
new syntactic differentiations.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Tuesday, September 11, 2012 1:04 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .times.
Have to say that I think that there will be greater confusion down to
having 3 different ways to indicate a command, than there will be over
what entity the command applies to.
After all, the general form of
\command x
is easy to understand -- \command applies to the entity x, or
alternatively to any group of entities contained in brackets { }. I
don't think it's confusing in general that x could be a note or some
other entity. (Are there good examples where it _is_ confusing?)
The tricky thing is when you have something like,
c'4 \p c' c' c'
Ok, and now for something completely different. I think there has been
one proposal to bring \[ \] in line with the post-event nature of [ ]
and ( ), but the one thing I have been thinking about recently is
whether we should not actually be going the other way round.
I've always thought that the post-event nature of lilypond is its own worst
enemy. My particular pet peeve is that it means you can't terminate a piano
pedal P with an asterisk * on the last note of a piece, since the \sustainOn
occupies the post-event location and there's nowhere for the \sustainOff to
go. I work round this with an extra voice and spacer rests, but it's not
too clever.
As mentioned by me earlier in the week, it makes automatically generating
code a bit odd, too, since you need to store the post events up until you've
written the note.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Phil Holmes m...@philholmes.net writes: I've always thought that the post-event nature of lilypond is its own worst enemy. My particular pet peeve is that it means you can't terminate a piano pedal P with an asterisk * on the last note of a piece, since the \sustainOn occupies the post-event location and there's nowhere for the \sustainOff to go. I work round this with an extra voice and spacer rests, but it's not too clever. \sustainOff should work fine. Clever enough, but likely no extra points for prettiness. As mentioned by me earlier in the week, it makes automatically generating code a bit odd, too, since you need to store the post events up until you've written the note. For accents, I find the post-event order quite appropriate. With dynamics, it starts getting strained. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
On 11 September 2012 14:04, David Kastrup d...@gnu.org wrote: Ok, and now for something completely different. I think there has been one proposal to bring \[ \] in line with the post-event nature of [ ] and ( ), but the one thing I have been thinking about recently is whether we should not actually be going the other way round. (snip) One argument might be that c( c) might look ugly, but less ugly than (c )c looks. Of course, neither is symmetric. But if our logic is strained enough that people want to invent new constructs for preserving the current _order_ of writing while differentiating the logic, maybe it would make more sense to rethink the order. Do I understand correctly that you suggest to change completely the LilyPond language so that every command that is currently post-note should be before the note? Ugh, maybe that is more logical (for you) but the postfix syntax has been used for many many years. That sounds to me like people wanting to change the electric current convention so that it is the same direction as the electron flow. http://xkcd.com/567/ Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Xavier Scheuer x.sche...@gmail.com writes: On 11 September 2012 14:04, David Kastrup d...@gnu.org wrote: Ok, and now for something completely different. I think there has been one proposal to bring \[ \] in line with the post-event nature of [ ] and ( ), but the one thing I have been thinking about recently is whether we should not actually be going the other way round. (snip) One argument might be that c( c) might look ugly, but less ugly than (c )c looks. Of course, neither is symmetric. But if our logic is strained enough that people want to invent new constructs for preserving the current _order_ of writing while differentiating the logic, maybe it would make more sense to rethink the order. Do I understand correctly that you suggest to change completely the LilyPond language so that every command that is currently post-note should be before the note? No. Just those commands that are not intrinsically attached to a note within a voice, like dynamics and phrasings. Basically those things that you'd occasionally attach to or s1*0 for lack of something more suitable. Ugh, maybe that is more logical (for you) but the postfix syntax has been used for many many years. No question about that. I assume you have seen the [GLISS] tag in the subject line. The question is whether there are some constructs for which it has been abused for many many years. At the stream event level, those events are _never_ part of a note event (as opposed to articulations). That makes the mandatory attachment at the input syntax level somewhat suspicuous. That sounds to me like people wanting to change the electric current convention so that it is the same direction as the electron flow. http://xkcd.com/567/ Except that \p\ c \! and c\p\ \! are not dual in nature. The second requires an additional artificial element. And we don't write c\time 4/8 either. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Tuesday, September 11, 2012 1:22 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Phil Holmes m...@philholmes.net writes:
I've always thought that the post-event nature of lilypond is its own
worst enemy. My particular pet peeve is that it means you can't
terminate a piano pedal P with an asterisk * on the last note of a
piece, since the \sustainOn occupies the post-event location and
there's nowhere for the \sustainOff to go. I work round this with an
extra voice and spacer rests, but it's not too clever.
\sustainOff should work fine. Clever enough, but likely no extra
points for prettiness.
{ c''1 \sustainOn \sustainOff }
--
Phil Holmesattachment: sustain.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Tuesday, September 11, 2012 1:22 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Phil Holmes m...@philholmes.net writes:
I've always thought that the post-event nature of lilypond is its own
worst enemy. My particular pet peeve is that it means you can't
terminate a piano pedal P with an asterisk * on the last note of a
piece, since the \sustainOn occupies the post-event location and
there's nowhere for the \sustainOff to go. I work round this with an
extra voice and spacer rests, but it's not too clever.
\sustainOff should work fine. Clever enough, but likely no extra
points for prettiness.
{ c''1 \sustainOn \sustainOff }
One would have to see what happens at the engraving stage (likely a wait
for a NoteColumn or MusicalColumn that never materializes because the
piece ends here. It might make sense to generally flush out another,
possibly specialized column when an explicit bar is placed: Things like
\! or \fermata or similar don't really benefit from moving across
explicit bars.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
On Tue, Sep 11, 2012 at 9:04 AM, David Kastrup d...@gnu.org wrote:
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:
On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .times.
Have to say that I think that there will be greater confusion down to
having 3 different ways to indicate a command, than there will be over
what entity the command applies to.
After all, the general form of
\command x
is easy to understand -- \command applies to the entity x, or
alternatively to any group of entities contained in brackets { }. I
don't think it's confusing in general that x could be a note or some
other entity. (Are there good examples where it _is_ confusing?)
The tricky thing is when you have something like,
c'4 \p c' c' c'
Ok, and now for something completely different. I think there has been
one proposal to bring \[ \] in line with the post-event nature of [ ]
and ( ), but the one thing I have been thinking about recently is
whether we should not actually be going the other way round.
Basically every construct that we would be tempted to use or s1*0 for
occasionally is one that is not really attached to a note, but rather to
a moment in time. You can put it in parallel music without changing
results. Most articulations with a shorthand can be attached to
individual notes in a chord: those are really intrinsically attached to
the note before, and it makes sense keeping that even if per-chord
articulations can be placed into parallel music. But things like ( ) \(
\) [ ] \p \ \! \ all happen at a moment in time in a voice. Why is a
tempo change a separate event, but a dynamic change isn't?
Specifically, I think it is because the tempo logically is an
interpretation property, and may have been just a \set property in
some earlier version. I'm not sure though.
Another argument against it would be that all of the above constructs
can benefit from a direction: ^[ is different from _[, and ^\p different
from _p. Should the direction modifier be tied to the occurence of
post-events? Valid question.
And one valid answer certainly would be this ship has sailed. But
that argument would hold equally for the invasive changes introducing
new syntactic differentiations.
I'd say this ship has sailed, but I've been saying so all along.
I'd strongly recommend implementing this and copying a few pages of
music before making any decisions. The everything postfix decision
was made after I had to copy music, and realized how jarring it was to
have to remember what goes where when copying music; I fear that your
proposal will require remembering more details.
--
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: [GLISS] differentiating pre/post/neutral commands
Han-Wen Nienhuys hanw...@gmail.com writes: But things like ( ) \( \) [ ] \p \ \! \ all happen at a moment in time in a voice. Why is a tempo change a separate event, but a dynamic change isn't? Specifically, I think it is because the tempo logically is an interpretation property, and may have been just a \set property in some earlier version. Tempo/clef are also more staff-like and ( ) is more voice-like. I'm not sure though. The main question for me is not what makes sense in the context of how LilyPond executes things but rather in the context how one inputs things. Another argument against it would be that all of the above constructs can benefit from a direction: ^[ is different from _[, and ^\p different from _p. Should the direction modifier be tied to the occurence of post-events? Valid question. And one valid answer certainly would be this ship has sailed. But that argument would hold equally for the invasive changes introducing new syntactic differentiations. I'd say this ship has sailed, but I've been saying so all along. Sure, for the new ships as well. I'd strongly recommend implementing this and copying a few pages of music before making any decisions. Definitely, and then some. The everything postfix decision was made after I had to copy music, and realized how jarring it was to have to remember what goes where when copying music; I fear that your proposal will require remembering more details. It will have to wait a bit more. I am currently in the process of reworking the parser in terms of changing where the post-event nature is located. In 2.14, it was more or less Everything that is not an EventChord for identifiers, and the parser put an EventChord around everything without post-event nature, and all music identifiers initialized via Lisp took an EventChord. Nowadays, it is everything that has the post-event type for identifiers and parser and Scheme expressions don't need any special wrappers. But the syntax still differentiates various kinds of music syntacticelly rather than by looking at the post-event type. This poses a nuisance for polymorphic music functions like \tweak which you need to write with or without - depending on usage, unless you assign to a variable, in which case this will be recognized automatically. I want this gone. Basically, music expressions should be accumulated and postevents get attached by virtue of coming next in sequence after a rhythmic event or eventchord. Regardless of _how_ they have been produced. If I can get there, the post-event nature is no longer implied in the syntax, ^ and _ could be used for attaching direction to non-post-events as well. If I get the parser in this state, syntax experiments become a matter of playing with the post-event type in scm/define-music-types.scm without needing to meddle with the parser. That's the stage I want to reach first before actually doing the syntax experiments because then the experiments become cheap. Apart from having to cater for display-lily-music, of course. But even that could likely be made to just put out things in linear order without thinking. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
grob-object information
Hello list,
for my work on the volta bracket inclusion for the new bar line interface,
I need to know how the bars are ordered in (ly:grob-object grob 'bars).
Please see the attached file.
For the \musOne, I get a grob array with eight BarLine grobs
(two for each staff) for the first volta bracket (and one for
the second volta bracket, of course):
|--volta--|
BarLine BarLine
BarLine BarLine
BarLine BarLine
BarLine BarLine
For \musTwo, I get a grob array consisting of eight BarLine grobs
(because the bracket spans eight bars in a single line) and a second
one for the second volta bracket.
|-volta---|
BarLine BarLine BarLine BarLine BarLine BarLine BarLine
BarLine
Is there any chance to get to know how the grobs are arranged?
Or more formally: how can I get the 2D structure back from a 1D vector?
Thanks in advance,
Marc
\version 2.17.2
#(define (volta-bracket::my-print grob)
(let* ((bar-array (ly:grob-object grob 'bars))
(bar-array-length (ly:grob-array-length bar-array)))
(display \n\n\nGrob array structure:)
(for-each (lambda (g)
(for-each display (list \nBar-array entry No. g :
(ly:grob-array-ref bar-array g
(iota bar-array-length))
(ly:volta-bracket-interface::print grob)))
\layout {
\context {
\Score
\override VoltaBracket #'stencil = #volta-bracket::my-print
}
}
musOne = {
\repeat volta 2 {
c4 c c c | c c c c
}
\alternative {
{ c4 c c c }
{ c2 c }
}
}
\score {
\new Staff {
\new Voice { \musOne }
}
\new Staff {
\new Voice { \musOne }
}
\new Staff {
\new Voice { \musOne }
}
\new Staff {
\new Voice { \musOne }
}
}
musTwo = {
\time 1/4
\repeat volta 2 {
c4 | c
}
\alternative {
{ c4 | c | c | c | c | c | c }
{ c4 | c | c | c | c | c | c }
}
}
\score {
\new Staff {
\new Voice { \musTwo }
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
On Tue, Sep 11, 2012 at 12:01:28PM +0100, Phil Holmes wrote: Hmm. Still getting the same problem. The following directories are missing: gub/uploads/localdoc/V2.17.2 gub/uploads/webdoc/V2.17.2 gub/uploads/webtest/V2.17.2 gub/uploads/webtest/V2.17.2/compare-etc This prevents the upload. It looks like they should be created by unlocked-doc-export: unlocked-test-export: but I can't figure out why these haven't run. Wonder whether running make unlocked-doc-export would fix it, but don't want to just go ahead without further consideration. I think it would be good to track down this bug. If you just build lilypond-test, can you follow the makefile rules? The rules are spread between GNUmakefile and lilypond.make. You're correct that unlocked-doc-export should be run. I /think/ that the command you want is: bin/gub --platform=linux-x86 \ 'git://git.sv.gnu.org/lilypond-test.git?branch=release/unstable or else maybe just make -f lilypond.make test I assume that you have the previous regtest tarball in regtests/ ? FWIW I've not pulled the git repo for gub recently. I guess that even if this would help, it would be a long old compile again... Yes. But since you completed it once, I doubt that any further work in GUB would help. ... actually, on further thought, I'm suspecting that there's some bad commit in git between 2.17.1 and current git. I would have expected that to kill the build, though. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
What do \[ and \] do?
Hi folks, I just noticed mention of these in the GLISS pre/post/neutral command thread. What do these commands do? If there's discussion about converting them to modern syntax, presumably they'll need documenting etc. and we'll need to describe them in terms thickos like me can understand on first reading. If they're difficult to describe for my kind of audience, then maybe they're too obscure to need polishing up, sanitizing and documenting, and having regression tests written for them. Just a thought, Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What do \[ and \] do?
Hello, 2012/9/11 Ian Hulin i...@hulin.org.uk Hi folks, I just noticed mention of these in the GLISS pre/post/neutral command thread. What do these commands do? http://lilypond.org/doc/v2.16/Documentation/notation/ancient-notation_002d_002dcommon-features#ligatures HTH Marek Klein http://gregoriana.sk ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What do \[ and \] do?
Hey Thicko! ;) On 11 September 2012 17:15, Ian Hulin i...@hulin.org.uk wrote: Hi folks, I just noticed mention of these in the GLISS pre/post/neutral command thread. What do these commands do? If there's discussion about converting them to modern syntax, presumably they'll need documenting etc. and we'll need to describe them in terms thickos like me can understand on first reading. If they're difficult to describe for my kind of audience, then maybe they're too obscure to need polishing up, sanitizing and documenting, and having regression tests written for them. Just a thought, I found a reference here under Ligatures known issues (for Ancient Music) 'The syntax still uses the deprecated infix style \[ music expr \]. For consistency reasons, it will eventually be changed to postfix style note\[ ... note\].' Actually they are only documented for Ancient Music as far as I can tell. Also in Appendix C of the LilyPond Grammar in the NR --snip-- 332 command_element: command_event 333| \[ 334| \] 335| \ 336| '|' --snip-- But that probably wasn't what you meant was it? :/ James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Minor release checklist
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: John Mandereau john.mander...@gmail.com; Devel lilypond-devel@gnu.org Sent: Tuesday, September 11, 2012 5:12 PM Subject: Re: Minor release checklist On Tue, Sep 11, 2012 at 12:01:28PM +0100, Phil Holmes wrote: Hmm. Still getting the same problem. The following directories are missing: gub/uploads/localdoc/V2.17.2 gub/uploads/webdoc/V2.17.2 gub/uploads/webtest/V2.17.2 gub/uploads/webtest/V2.17.2/compare-etc This prevents the upload. It looks like they should be created by unlocked-doc-export: unlocked-test-export: but I can't figure out why these haven't run. Wonder whether running make unlocked-doc-export would fix it, but don't want to just go ahead without further consideration. I think it would be good to track down this bug. If you just build lilypond-test, can you follow the makefile rules? The rules are spread between GNUmakefile and lilypond.make. You're correct that unlocked-doc-export should be run. I /think/ that the command you want is: bin/gub --platform=linux-x86 \ 'git://git.sv.gnu.org/lilypond-test.git?branch=release/unstable or else maybe just make -f lilypond.make test We're uploading as I speak. I fixed the problem by running these commands: make --file=lilypond.make LILYPOND_BRANCH=release/unstable unlocked-doc-export make --file=lilypond.make LILYPOND_BRANCH=release/unstable unlockt -test-export I assume that you have the previous regtest tarball in regtests/ ? Yes - it was there from the previous run. FWIW I've not pulled the git repo for gub recently. I guess that even if this would help, it would be a long old compile again... Yes. But since you completed it once, I doubt that any further work in GUB would help. ... actually, on further thought, I'm suspecting that there's some bad commit in git between 2.17.1 and current git. I would have expected that to kill the build, though. Don't think so. As I mentioned earlier, the commit Add support for Cyrillic in texinfo (http://code.google.com/p/lilypond/issues/detail?id=2742) killed my first run of gub and I had to re-run it after adding the fonts. Perhaps this interrupted build confuses the build. We'll see what 2.17.3 will bring... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-object information
On 11 sept. 2012, at 17:48, Marc Hohl m...@hohlart.de wrote: Hello list, for my work on the volta bracket inclusion for the new bar line interface, I need to know how the bars are ordered in (ly:grob-object grob 'bars). Please see the attached file. For the \musOne, I get a grob array with eight BarLine grobs (two for each staff) for the first volta bracket (and one for the second volta bracket, of course): |--volta--| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine For \musTwo, I get a grob array consisting of eight BarLine grobs (because the bracket spans eight bars in a single line) and a second one for the second volta bracket. |-volta---| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine Is there any chance to get to know how the grobs are arranged? Or more formally: how can I get the 2D structure back from a 1D vector? Thanks in advance, Marc shortvoltatest.ly___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel You can use Grob::get_vertical_axis_group_index (you'd have to write a Scheme binding). Or sort the list it based on ly:grob::vertical-less? (that binding is already written). Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-object information
Am 11.09.2012 20:48, schrieb m...@mikesolomon.org: On 11 sept. 2012, at 17:48, Marc Hohl m...@hohlart.de wrote: Hello list, for my work on the volta bracket inclusion for the new bar line interface, I need to know how the bars are ordered in (ly:grob-object grob 'bars). Please see the attached file. For the \musOne, I get a grob array with eight BarLine grobs (two for each staff) for the first volta bracket (and one for the second volta bracket, of course): |--volta--| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine For \musTwo, I get a grob array consisting of eight BarLine grobs (because the bracket spans eight bars in a single line) and a second one for the second volta bracket. |-volta---| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine Is there any chance to get to know how the grobs are arranged? Or more formally: how can I get the 2D structure back from a 1D vector? Thanks in advance, Marc shortvoltatest.ly___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel You can use Grob::get_vertical_axis_group_index (you'd have to write a Scheme binding). What value does that function return? A quick glance at its definition in lily/grob.cc does not fully reveal its return value, but as this is an integer, I have a 1D - 1D function, but I need 2D. Or sort the list it based on ly:grob::vertical-less? (that binding is already written). IIUC, that will sort the BarLine grobs, but I think that they *are* already sorted in the grob array, like this: |-volta-| BarLine 1a BarLine 2a BarLine 1b BarLine 2b BarLine 1c BarLine 2c BarLine 1d BarLine 2d is returned as 1a 1b 1c 1d 2a 2b 2c 2d (I assume), but if I only have the grob array, I do not have the length and width of the underlying 2D structure. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-object information
Am 11.09.2012 21:08, schrieb m...@mikesolomon.org: On 11 sept. 2012, at 22:02, Marc Hohl m...@hohlart.de wrote: Am 11.09.2012 20:48, schrieb m...@mikesolomon.org: On 11 sept. 2012, at 17:48, Marc Hohl m...@hohlart.de wrote: Hello list, for my work on the volta bracket inclusion for the new bar line interface, I need to know how the bars are ordered in (ly:grob-object grob 'bars). Please see the attached file. For the \musOne, I get a grob array with eight BarLine grobs (two for each staff) for the first volta bracket (and one for the second volta bracket, of course): |--volta--| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine For \musTwo, I get a grob array consisting of eight BarLine grobs (because the bracket spans eight bars in a single line) and a second one for the second volta bracket. |-volta---| BarLine BarLine BarLine BarLine BarLine BarLine BarLine BarLine Is there any chance to get to know how the grobs are arranged? Or more formally: how can I get the 2D structure back from a 1D vector? Thanks in advance, Marc shortvoltatest.ly___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel You can use Grob::get_vertical_axis_group_index (you'd have to write a Scheme binding). What value does that function return? A quick glance at its definition in lily/grob.cc does not fully reveal its return value, but as this is an integer, I have a 1D - 1D function, but I need 2D. Or sort the list it based on ly:grob::vertical-less? (that binding is already written). IIUC, that will sort the BarLine grobs, but I think that they *are* already sorted in the grob array, like this: |-volta-| BarLine 1a BarLine 2a BarLine 1b BarLine 2b BarLine 1c BarLine 2c BarLine 1d BarLine 2d is returned as 1a 1b 1c 1d 2a 2b 2c 2d (I assume), Are you certain that every vertical axis group will always contain the same number of bar lines? If not, it's possible that the matrix you're talking about may not have complete rows, in which case it's difficult to know how to break it. I am not 100% sure – there could be corner cases where a staff line stops before the volta bracket is closed, but this could lead to an error when compiling the .ly file. One way to check it is to look at the left or right of the spanned_rank_interval of the grobs (the values will be the same as you're dealing with items which only ever span one column). Once it goes backwards, you know that you've skipped to the next row. What kind of values does spanned_rank_interval return? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-object information
On 11 sept. 2012, at 22:29, Marc Hohl m...@hohlart.de wrote:
Are you certain that every vertical axis group will always contain the same
number of bar lines? If not, it's possible that the matrix you're talking
about may not have complete rows, in which case it's difficult to know how
to break it.
I am not 100% sure – there could be corner cases where a staff line stops
before the
volta bracket is closed, but this could lead to an error when compiling the
.ly file.
What about pieces with different simultaneous time signatures? They'd have
different numbers of bars for a given section.
One way to check it is to look at the left or right of the
spanned_rank_interval of the grobs (the values will be the same as you're
dealing with items which only ever span one column). Once it goes
backwards, you know that you've skipped to the next row.
What kind of values does spanned_rank_interval return?
The column number of a grob's left and right bound. Columns are linearly
ordered from the beginning of a score to the end, so you can use it to know
when a new staff is beginning in your array. For bar lines, the grob only
spans one column so the left and right values of the returned will be the same
- you can use either one.
In C++, if I had a vector Grob * foo that I wanted to sort into vector
vector Grob * bar, if I understand you correctly, I'd do:
int current_column = INT_MAX;
for (vsize i = 0; i foo.size (); i++)
{
int column = foo[i]-spanned_rank_interval ()[LEFT];
if (column = current_column)
bar.push_back (vectorGrob * ());
bar.back ().push_back (foo[i]);
current_column = column;
}
The same thing is doable in Scheme - I just write pseudo-code faster in C++.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: grob-object information
Am 11.09.2012 21:54, schrieb m...@mikesolomon.org:
On 11 sept. 2012, at 22:29, Marc Hohl m...@hohlart.de wrote:
Are you certain that every vertical axis group will always contain the same
number of bar lines? If not, it's possible that the matrix you're talking
about may not have complete rows, in which case it's difficult to know how to
break it.
I am not 100% sure – there could be corner cases where a staff line stops
before the
volta bracket is closed, but this could lead to an error when compiling the .ly
file.
What about pieces with different simultaneous time signatures? They'd have
different numbers of bars for a given section.
Hey, good catch!
One way to check it is to look at the left or right of the spanned_rank_interval of the
grobs (the values will be the same as you're dealing with items which only ever
span one column). Once it goes backwards, you know that you've skipped to
the next row.
What kind of values does spanned_rank_interval return?
The column number of a grob's left and right bound. Columns are linearly
ordered from the beginning of a score to the end, so you can use it to know
when a new staff is beginning in your array. For bar lines, the grob only
spans one column so the left and right values of the returned will be the same
- you can use either one.
Ok, so I try to wrap a scheme caller around spanned_rank_interval and see
how far I can get with that.
In C++, if I had a vector Grob * foo that I wanted to sort into vector vector
Grob * bar, if I understand you correctly, I'd do:
int current_column = INT_MAX;
for (vsize i = 0; i foo.size (); i++)
{
int column = foo[i]-spanned_rank_interval ()[LEFT];
if (column = current_column)
bar.push_back (vectorGrob * ());
bar.back ().push_back (foo[i]);
current_column = column;
}
The same thing is doable in Scheme - I just write pseudo-code faster in C++.
Yup, I think that's more or less what I want to achieve.
Just a side information: In lily/volta-bracket.cc the bar linformation
is obtained by
extract_grob_set (me, bars, bars);
Grob *endbar = bars.size () ? bars.back () . 0 ;
SCM glyph = endbar ? endbar-get_property (glyph_name) : SCM_EOL;
The scheme equivalent is
(let* ((bar-array (ly:grob-object me 'bars))
(bar-array-length (ly:grob-array-length bar-array))
(endbar (ly:grob-arraybar-array (1- bar-array-length)))
(glyph (ly:grob-property endbar 'glyph-name))
modulo some checks whether the array is not empty etc.
So the last element in the array is the one used for the
volta bracket, isn't it?
I found out that the last element in bar-array can be a SpanBar grob,
which leads to problems when I want to extract some other properties
that are only defined for BarLine grobs and not for SpanBar grobs.
I don't know whether it is safe just to check whether the last
element is a SpanBar; if yes, take the predecessor, if no, it
is a BarLine grob and erverything is fine.
Hopefully I explained it in a way that's understandable;
I want to know if I can achieve what I need *without* kind of
parsing the array.
On the other hand, when I need more detailed layout informations
about the staffs and stuff, there is probably no way to bypass
this ordering routine.
Regards,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)
http://codereview.appspot.com/6498077/diff/6033/lily/phrasing-slur-engraver.cc File lily/phrasing-slur-engraver.cc (right): http://codereview.appspot.com/6498077/diff/6033/lily/phrasing-slur-engraver.cc#newcode116 lily/phrasing-slur-engraver.cc:116: Grob *stub = make_spanner (SlurStub, info.grob ()-self_scm ()); Why do you use the NoteColumn here as the cause for the SlurStub? It would make much more sense to use the respective slur. Then you don't need a separate surrogate field since you can just use 'cause instead, and you can \tweak a SlurStub via its Slur event, and most importantly you don't need a special initialize from surrogate utility function but can rather use an initialize from cause function. http://codereview.appspot.com/6498077/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: simplify previous patch-set by special casing 2-line staves (issue 6506090)
This works, although in surprising ways. It was a challenge for me to figure out why the tests in 'repeat-sign.ly' come out as they do. I was very surprised by the lines marked dots in outer spaces and dots outside and assume we would prefer more centered placement. that's sort of all right, I meant them to surprise, i.e. to show the limits of the implementation. dots in outer spaces was inspired by your comment http://codereview.appspot.com/6488097#msg7 dots outside now changed behaviour and is accordingly relabelled to dots in middle. as I hinted at in http://codereview.appspot.com/6488097#msg8 I'm afraid improving this would more than such a contorted case is worth. The case dots in outer spaces is different from a four-line staff in that the user indicates eight scale-steps will fit between lines; if eight scale steps fit legibly, two repeat dots will also fit. well, we know exactly whether two dots fit or not, but the current issue arose just from that: though they fit, the user wants them outer. as a theoretical consideration, I think repeat sign is a matter of the staff and the dots, not the scale steps represented by the stafflines. (are there chromatic or microtonal notations where these steps are smaller than a third?) You could simplify at this point, and work entirely in staff-positions, until the end where you build the stencil. I also suggest using a rule prefer dots in tight spaces to dots completely outside the staff rather than the special case for 2-line staves. that rule is implemented by patch set two. otherwise I think this simplification is oversimplification as it cannot distinguish \override #'line-count = #2 from \override #'line-count = #2 \override #'staff-space = #2 then, if staff-space is taken into account, dot size must also be, see http://code.google.com/p/lilypond/issues/detail?id=2648 and anyway that simplification buys us no more than replacing gap-to-find by a constant. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Some files missing copyright/license headers; would be useful to add as they are seen
Short story: some files in the lilypond source are missing copyright/licensing headers, but for the most part this doesn't seem like a big deal. As they get edited or otherwise patched, it would be helpful to add them. Longer story: During my preparations for uploading 2.16.0 to Debian experimental, I have been cleaning up the debian/copyright file and switching to the machine-readable format,[1] which more correctly documents the actual copyright/licensing state of packages Debian distributes. [And most importantly, it makes it easier for me to keep track of things.] As a side note, I had originally thought that everything in lilypond was GPLed; however, scripts/build/mf2pt1.pl is under the LPPL1.3c+, and flower/include/yaffut.hh is under the BSL-1.0. These are both free software licenses, so no big deal. lily/include/breathing-sign.hh is copyrighted by Michael Krause, but doesn't not contain licensing information. I'm assuming this is GPL3+, but the header should probably be fixed. scripts/build/website_post.py has no copyright/license information; not sure who wrote it. I'm assuming it's GPL3+, but I do not know. elisp/lilypond-font-lock.el also is missing a license, even though it's got the copyright statement in it. The following files do not have any copyright/licensing information in them. However, they all appear to be written by Han-Wen Nienhuys (or at least, Han-Wen is the only person who appears to have committed to them). I'm assuming that they're all GPL3+ and only copyrighted by Han-Wen, or are otherwise safe to distribute. Documentation/lily_index_search.php autogen.sh elisp/lilypond-indent.el elisp/lilypond-init.el elisp/lilypond-what-beat.el flower/file-cookie.cc flower/include/file-cookie.hh flower/include/getopt-long.hh flower/include/string-convert.hh flower/include/yaffut-parameters.hh flower/real.cc flower/string-convert.cc flower/test-file-name.cc flower/test-file-path.cc flower/test-std.cc flower/test-string.cc input/regression/lilypond-book/suffix-tex.tex input/regression/musicxml/book-musicxml-testsuite.py lily/control-track-performer.cc lily/gdb.cc lily/grob-closure.cc lily/grob-property.cc lily/include/box.hh lily/include/dimensions.hh lily/include/dot-formatting-problem.hh lily/keyword.cc lily/music-function-scheme.cc lily/nested-property.cc lily/pfb-scheme.cc lily/tie-specification.cc python/auxiliar/buildlib.py python/auxiliar/manuals_definitions.py python/auxiliar/mirrortree.py python/auxiliar/postprocess_html.py python/book_base.py python/book_docbook.py python/book_html.py python/book_latex.py python/book_snippets.py python/book_texinfo.py python/convertrules.py python/fontextract.py python/langdefs.py python/musicexp.py python/musicxml.py python/rational.py python/safeeval.py scripts/auxiliar/build-coverage.sh scripts/auxiliar/build-profile.sh scripts/auxiliar/cg-section.sh scripts/auxiliar/check_texi_refs.py scripts/auxiliar/coverage.py scripts/auxiliar/doc-section.sh scripts/auxiliar/find-superfluous-includes.py scripts/auxiliar/musicxml_generate_intervals.py scripts/auxiliar/musicxml_generate_keys.py scripts/auxiliar/musicxml_generate_timesignatures.py scripts/auxiliar/node-menuify.py scripts/auxiliar/prepare-web-media.py scripts/auxiliar/readlink.py scripts/auxiliar/ref_check.py scripts/auxiliar/split-texidocs.py scripts/auxiliar/strip-whitespace.py scripts/auxiliar/tely-gettext.py scripts/auxiliar/texi-langutils.py scripts/auxiliar/texi-skeleton-update.py scripts/auxiliar/translations-status.py scripts/auxiliar/update-patch-version.sh scripts/auxiliar/update-snippets.py scripts/auxiliar/update-with-convert-ly.sh scripts/build/bib2texi.py scripts/build/catmidi.py scripts/build/create-version-itexi.py scripts/build/create-weblinks-itexi.py scripts/build/extract_texi_filenames.py scripts/build/gen-emmentaler-scripts.py scripts/build/genicon.py scripts/build/html-to-texi.py scripts/build/install-info-html.sh scripts/build/lilypond-words.py scripts/build/lys-to-tely.py scripts/build/makesnippets.py scripts/build/mass-link.py scripts/build/output-distance.py scripts/build/relative.py scripts/build/run-and-check.sh scripts/build/texi2omf.py scripts/build/www_post.py scripts/musicxml2ly.py smart-autogen.sh smart-configure.sh stepmake/autogen.sh stepmake/bin/fake-msgfmt.sh stepmake/bin/install.py stepmake/bin/make-version.py stepmake/bin/ntpwd.py stepmake/bin/stepmakeise.sh stepmake/bin/text2html.py tex/lilypond-tex-metrics.tex Hopefully my understanding matches all of yours. Don Armstrong 1: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -- The solution to a problem changes the problem. -- Peer's Law http://www.donarmstrong.com http://rzlab.ucr.edu ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
On 11/09/12 13:04, David Kastrup wrote: Basically every construct that we would be tempted to use or s1*0 for occasionally is one that is not really attached to a note, but rather to a moment in time. You can put it in parallel music without changing results. Most articulations with a shorthand can be attached to individual notes in a chord: those are really intrinsically attached to the note before, and it makes sense keeping that even if per-chord articulations can be placed into parallel music. But things like ( ) \( \) [ ] \p \ \! \ all happen at a moment in time in a voice. Why is a tempo change a separate event, but a dynamic change isn't? This is starting to sound a bit like SCORE's approach, where various different aspects of the music (notes, phrasing, dynamics, ...) are described by separate, parallel sequences: see, http://www.ccarh.org/courses/253/handout/scoreinput/ Since you mentioned articulations: one of my personal bugbears with Lilypond has been the case of an articulation that occurs part-way through a given note. Consider e.g. the case of a half-note with a \turn that should occur on the second beat of that half-note. It's something which (unless things have changed in more recent versions, which I'm not aware of) is surprisingly difficult to achieve _effectively_ in Lilypond, because the presence of the offset articulation is not taken into account when calculating horizontal spacing. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
On 11/09/12 14:15, David Kastrup wrote: No. Just those commands that are not intrinsically attached to a note within a voice, like dynamics and phrasings. Basically those things that you'd occasionally attach to or s1*0 for lack of something more suitable. In the case of dynamics, you really have 2 cases to cover: first, dynamics that coincide exactly with a particular note (the current default case in Lilypond) and second, dynamics (and this includes hairpins etc.) that are offset relative to a given note. So, whatever is decided regarding whether the dynamic command comes before or after the note, there needs to be some tidy shorthand for illustrating the offset; and it needs to be possible to attach more than one dynamic indicator to a given note. Example: consider a half-note where you have a \p dynamic falling on the start of the note; a \ hairpin that lasts a quarter-note; an \f dynamic that falls on the second quarter of the half-note; and a \ hairpin that falls across the remainder of the half-note (i.e. it also lasts a quarter-note). The most simple way to do this is to add a parallel voice containing, s4\p\ s4\f\ % ... etc. but in practice you'd probably have to put in place some tricks involving hidden quarter-notes in order to get the spacing right. So in practice you might prefer something like, c'2\p\4 \f\4 i.e. where some dynamic elements can be given a duration. If you wanted to have e.g. a half-note where a crescendo starts halfway through, you might have something like, c'2\p4 \ Or you might have a note where the dynamic changes suddenly in the middle: c'2\p4 \f (These particular syntax ideas may be unworkable in practice, but you get the idea -- dynamic events [and possibly some articulations too] can have length in their own right, and we need a way to indicate this; and horizontal spacing of dynamic elements will need to take these factors into account.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120913
For 20:00 MDT Thursday Sept 13 (really!) Documentation: Issue 2817 http://code.google.com/p/lilypond/issues/detail?id=2817: list Elysium on Easier Editing webpage - R 6488101 http://codereview.appspot.com/6488101/ Enhancement: Issue 2811 http://code.google.com/p/lilypond/issues/detail?id=2811: Patch: Uses horizontal skylines in accidental placement - R 6489086 http://codereview.appspot.com/6489086/ Issue 2717 http://code.google.com/p/lilypond/issues/detail?id=2717: Patch: Implement \hide as a shorthand for \tweak #'stencil ##f - R 6443087 http://codereview.appspot.com/6443087/ Issue 2815 http://code.google.com/p/lilypond/issues/detail?id=2815: Patch: parser/lexer: de-unionize semantic values, make all of them SCM - R 6493090 http://codereview.appspot.com/6493090/ Issue 2759 http://code.google.com/p/lilypond/issues/detail?id=2759: Patch: Don't use /dev/stderr which is only defined on some systems - R 6493106 http://codereview.appspot.com/6493106/ Ugly: Issue 2492 http://code.google.com/p/lilypond/issues/detail?id=2492: Kievan notation - improper beaming functionality - R 6305080 http://codereview.appspot.com/6305080/ 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
Doc: Add Elysium to Easier Editing (issue 6488101)
Hmm. IMO, Elysium should be listed under the text editors section, while the top recommended section should not be alphabetized. However, I'm open to a re-think of the page, wherein we drop the recommended-ness, and/or group programs differently, and/or whatever else might be good to change. I think we need to have *some* form of organization beyond pure alphabetical, though, to help users to understand the choices. http://codereview.appspot.com/6488101/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
