Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
that all articulation events will be pulled out of NoteEvents or
RestEvents and broadcast at the iterator level.
There is such a thing as a chord articulation.
Why couldn't this distinction be captured via a different event name?
ChordArticulationEvent versus ArticulationEvent, for example.
Where would be the point?
To not make the distinction in the parser.
It is different input anyway, so the distinction is already there in the
input. If you would drop that distinction in the rules that early, you
would end up with chords being allowed as chord constituents.
I think that changing the parser should be a last resort if we can't
figure out a way to represent information through different event
classes.
I have trouble understanding what you call parser here.
What would really help are some before/after examples (ly code and/or
music streams and/or brief text like before the patch, you could not
do X, after, you can or this patch will allow me to experiment with
implementing X) would help a great deal. As if it were going into
the Change Log, for example.
It's a bit hard since the whole design (perfected by the
rhythmic-music-event) was intended to make no user-visible difference.
The music expression has just become predictable. You get an EventChord
iff ... has been in the input. You get articulations on NoteEvent
for pitch-postevent regardless whether or not this is part of a chord.
Why can't we treat c as shorthand for c?
Because inside of chords, it isn't a shorthand for c. And music
functions like \tweak need to work inside of chords as well (\tweak
currently even _fails_ if you apply it to c where LilyPond considers it
a shorthand for c and the corresponding passage in the NR is _really_
embarrassing to LilyPond as a system). See
URL:http://code.google.com/p/lilypond/issues/detail?id=2037#c3 for an
approach to make c as c work which ultimately went up in flames. It
is not like I did not seriously try that approach. It is a total
maintenance nightmare (and has logical fallacies you can't really iron
out) unless you forbid music functions inside of chords altogether.
It also makes user level programming tasks at the input side (and that's
really what music functions are) much harder and more intransparent if
you don't have predictable relations between input and music
expressions, and if you have to strip multiple layers before getting at
the information you actually wanted and that was straightforward in the
input.
Music expressions _represent_ the input, as opposed to stream events
which represent the typesetting task.
Having a compulsory wrapping around singletons is just as predictable
as no wrapping at all.
Except that inside of chords, there is no such wrapping, and a music
function does not know in advance where it is going to get used.
As for articulations being on a NoteEvent whether or not this is part
of a chord, I agree that this is a very good idea, but I think this
can be accomplished by wrapping everything in an event chord and
farming out the work to iterators.
Uh, we _are_ farming this out to the rhythmic event iterator. That was
its point. It was the missing link.
If you use \displayMusic on something that you might want to put into a
chord, you don't get wrong input. Tacking around a construct does
not change the structure of its inside. It is not necessary to tack
around a construct to make a \tweak work (which is a user-visible
change).
Why couldn't tweak make this distinction in the music function itself?
Why should it? Why should we strive to make programming a reliably
working music function as hard as possible?
The music function could check if its input is an EventChord and, if
so, feed it the first entry in the 'elements list of the EventChord.
This seems like a less intrusive change than changing the parser.
And what if there is more than one element?
Anyway, see above for an attempt to make a less intrusive change and get
inside chord functions work with the same argument parsing semantics as
normal music functions (after all, one does not know the difference).
It failed. A special inside-of-chord-mode for parsing music function
arguments is a total maintenance hog. Nobody will understand the code,
and more importantly, nobody will understand the behavior.
I have been deadlocked for about a month on further parser work by this.
You can use #{ #} for constructing material that ends up _inside_ of a
chord. Something like
\displayLilyMusic \displayLilyMusic ##{ c-. #}
does not go up in flames but just does what one would expect.
This is indeed an interesting case. Again, though, I would expect
this to fail, precisely because #{#} manipulates the
Re: 2.16 release candidate 3 imminent
After reading through this e-mail, I'm ok with the patch with one caveat about regtests (see below). On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: Music expressions _represent_ the input, as opposed to stream events which represent the typesetting task. If this is truly the distinction, then I understand the need for the change. I didn't realize that music expressions needed to be one-to-one and onto representations of the input. And you currently _can't_, I repeat _can't_ write a music function (unless it gets a music argument created by the parser instead of just passed in from elsewhere) that can work like the input c inside of a chord as well as outside. Because outside, you need to produce c, and inside, you need to produce c. But without a music argument? No. Writing a music function called as \semitonesabovec #5 (or something like that) that will work both inside as well as outside of chords is just _impossible_ right now. It will be trivial afterwards. This is the part that I have the most trouble imagining, not because I don't trust you, but because I don't follow the code well enough to know how it would result in this. I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, see if was an event chord or a note event, and act on it accordingly. So, for example (in pseudocode): #(define (bar music) (do-some-stuff-to music)) foo = #(define-music-function (parser location music) (if (eqv? (ly:music-property music 'name) 'EventChord) (bar (car (ly:music-property music 'elements))) (bar music))) The idea that a music function would be unmakable before this commit and makable after is, in my mind, the most solid argument for making this change. Like I say above, I'd need to see this in a regtest. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, see if was an event chord or a note event, and act on it accordingly. but the argument is the same, it's the environment of the function result that's different. the point is to not have to write two versions of each function, one to be used within chords and one outside. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: After reading through this e-mail, I'm ok with the patch with one caveat about regtests (see below). On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: Music expressions _represent_ the input, as opposed to stream events which represent the typesetting task. If this is truly the distinction, then I understand the need for the change. I didn't realize that music expressions needed to be one-to-one and onto representations of the input. And you currently _can't_, I repeat _can't_ write a music function (unless it gets a music argument created by the parser instead of just passed in from elsewhere) that can work like the input c inside of a chord as well as outside. Because outside, you need to produce c, and inside, you need to produce c. But without a music argument? No. Writing a music function called as \semitonesabovec #5 (or something like that) that will work both inside as well as outside of chords is just _impossible_ right now. It will be trivial afterwards. This is the part that I have the most trouble imagining, not because I don't trust you, but because I don't follow the code well enough to know how it would result in this. I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, Please reread the above paragraph, in particular where I say without a music argument. see if was an event chord or a note event, and act on it accordingly. Without an argument you can look at, you can't choose your action accordingly. #(define-music-function (parser location music) (if (eqv? (ly:music-property music 'name) 'EventChord) (bar (car (ly:music-property music 'elements))) (bar music))) _Without_ a music argument. The idea that a music function would be unmakable before this commit and makable after is, in my mind, the most solid argument for making this change. Like I say above, I'd need to see this in a regtest. You can make a music function that will either work in chord context, or in music list context. And it can ask its music argument which of the two it is. I think \parenthesize does that. But that only works if there _is_ a music argument. It is possible that the operation of the music function parenthesize can be simplified in future, but it may require special behavior on EventChord anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 22, 2012, at 10:25 AM, David Kastrup wrote: Please reread the above paragraph, in particular where I say without a music argument. Sorry - I missed that. This is exactly the type of function that I'd like to see in the regtests. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 20:17, schrieb Carl Sorensen: On 1/21/12 11:47 AM, Marc Hohlm...@hohlart.de wrote: I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! I'm not sure you actually will find it great (although I think it is more consistent). If we don't want to have string numbers show up in the music, but we need them for the tabstaff, right now we can do c e g\3\2\1 In the future,c e g\3\2\1 won't assign the string numbers to the tabstaff. (And in fact, I can't find this usage documented in the NR). Yes, I stumbled upon it while we were discussing some other problems concerning tablature, and I used this method to prevent the sting numbers showing up. \override StringNumber #'stencil = ##f yielded in errors (but I think this has changed recently), and simply setting \override StringNumber #'transparent = ##t still influenced the spacing for obvious reasons. Instead, as would be done regularly in lilypond, we would do \once \override StringNumber #'stencil = ##f c\3 e\2 g\1 This is consistent with how things are handled in lilypond, so I think we ought to move in this direction. As setting the stencil to false seems to work now, I agree with you that this is the more lilypondish way to go. Thanks for your explanations! Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes:
After reading through this e-mail, I'm ok with the patch with one
caveat about regtests (see below).
On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
Music expressions _represent_ the input, as opposed to stream events
which represent the typesetting task.
If this is truly the distinction, then I understand the need for the
change. I didn't realize that music expressions needed to be
one-to-one and onto representations of the input.
They are an intermediate level. They don't _need_ to be anything.
Music functions are a useful tool for manipulating music at a level much
closer to input than stream events are. They are employed in _several_
layers in the parser: for postevents, for base material, inside of
chords. If they can do their work context independent, you don't need
to make them cater for different contexts.
In the context of writing music functions, #{ ... #} is a useful tool.
Since it fires up its own parser, its result is not context dependent.
You can't, for that reason, currently employ it usefully in chord
context.
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
If it isn't, try
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
If it isn't, try
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
Actually, neither will it with the change. But it will be a one-liner
to make it work when it was impossible previously. I'll do that
one-liner presently.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
Actually, neither will it with the change. But it will be a one-liner
to make it work when it was impossible previously. I'll do that
one-liner presently.
Well, it was a bit more juggling in order to make sure that the parser
complains when an unsuitable music identifier gets used inside of
chords.
URL:http://codereview.appspot.com/5440084/diff2/19032:14005/lily/parser.yy
But it still was a _trivial_ change to make. It would have been trivial
before that, admittedly, but there would have been no obvious way to
actually set the music identifier to a value that could be used here, so
there would have been little point in doing so.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
I have to go in hold the horses mode now since I have a deadline for a LilyPond talk paper URL:http://chemnitzer.linux-tage.de/2012/info/index?cookielang=en coming up today (I already bargained an extension), and I need to get that finished in order to get it into print. So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
checking 2240 (was: 2.16 release candidate 3 imminent)
On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. We seem to have a failure to communicate here. I shall be blunt, although I am not angry with you. I will not be doing any manual investigations about 2240 (or any other patch, for that matter). Part of the reason that we're in this miss is that we keep on saying oh, I'll do it manually just this once. If we had gotten serious about automating development tasks a year ago, we'd have saved at least 100 hours of developer time. I'm totally serious about that estimate; if anything I think I'm being conservative. I will therefore not do any manual fiddling around to test a patch or staging. Anything that fails the automatic process is rejected; if the process needs to be fixed, then fix the process. With respect to this patch, you have 4 options: - modify Patchy to do the appropriate build stuff. - recruit somebody else to modify Patchy for you. (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) - skip the review process by manually marking it as Patch-review yourself. I do not object to this, but be aware that you are therefore vouching for the patch in a much more serious way. - abandon the patch. Choice is yours. (although of course there is no problem if nothing happens on this for a few days while you do other things) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240 (was: 2.16 release candidate 3 imminent)
On Jan 22, 2012, at 12:44 PM, Graham Percival wrote: (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) See spot run! Run spot run! I have compositions coming out the ears - will be able to work on LilyPond actively in a weekish. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 21/01/2012 2:48 PM, Graham Percival wrote: On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make sure that you actually try those version in 2.14.0 or 2.12.3 or whatever -- I wouldn't want to blindly assume that those tests actually worked when they were added to git. - Graham Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Can I push patches on the countdown for Jan 22 by now? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's what I suspected. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Sure, go ahead. Can I push patches on the countdown for Jan 22 by now? Colin's in Alberta, so he's 2 hours behind you. :) His last email didn't specify an exact time, but IIRC he generally uses 20:00 MST. I think it would be nice to wait until he gives the ok. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 12-01-22 10:19 AM, Graham Percival wrote: On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's what I suspected. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Sure, go ahead. Can I push patches on the countdown for Jan 22 by now? Colin's in Alberta, so he's 2 hours behind you. :) His last email didn't specify an exact time, but IIRC he generally uses 20:00 MST. I think it would be nice to wait until he gives the ok. - Graham Go ahead, Julien: with Graham's blessing, there's no need to wait for a few hours. 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
2.16 release candidate 3 imminent
All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Graham Percival gra...@percival-music.ca writes: All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. For similar reasons, it needs to be in a release candidate before release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. But I'm not going to kick up a fuss about it. I've marked 2240 as Critical. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. If we still want to have that policy, I believe that subversion numbers are cheap, but stable version numbers are expensive. I think we'd be best to try to get this into 2.16. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I disagree. I think that stable should mean *stable*, i.e. no syntax changes necessary for *that series of major version numbers*. I reject the notion that we shouldn't release a new stable version after a few months if there's no regressions in the new version. Other tools can advertise works with lilypond versions 2.14.0 and 2.17.23 if necessary. Look, this reminds me of some essay I skimmed recently by an economist who was worried that if the US paid off its debt in full, the bond market would collapse and that would have negative consequences for the world economy. I see no reason to worry about what might happen if we have too many stable releases unless that actually becomes a possibility. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 10:24 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I disagree. I think that stable should mean *stable*, i.e. no syntax changes necessary for *that series of major version numbers*. I reject the notion that we shouldn't release a new stable version after a few months if there's no regressions in the new version. Other tools can advertise works with lilypond versions 2.14.0 and 2.17.23 if necessary. OK, I'm fine with that. Look, this reminds me of some essay I skimmed recently by an economist who was worried that if the US paid off its debt in full, the bond market would collapse and that would have negative consequences for the world economy. I see no reason to worry about what might happen if we have too many stable releases unless that actually becomes a possibility. Well, you were the one who mentioned having 2.16 in two weeks and 2.18 in March. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 6:14 PM, Keith OHara wrote: Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? I was asking myself a similar question lately now that I've gotten deeper into the non-parser-related aspects of 2240. After playing around with iterators and such, I'm convinced that all the articulation stuff can be written to be slicker independent of any changes to the parser. Meaning that, without any changes to the representation of event-chords, we could get rid of the script engraver and fingering engraver and just keep the new fingering engraver, doing all necessary massaging at the iterator level. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? Especially given the perspective David addressed earlier that part of LilyPond's code base getting better will be it getting more uniform and boring, how is this move away from uniformity (meaning creating two channels for of handling rhythmic events) beneficial? I think the question boils down to: is there an inherent difference between c and c and, if so, what is it and why is it meaningful? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change that should not occur during a stable release series, and it paves the way for making the music function work continue smoothly enough that backporting further enhancements into a stable 2.16 series would be feasible. IMO, significant API changes should not happen right before a release. Version numbers are cheap; why not have 2.18 in March 2012? Backporting is a huge hassle. Earlier, we expressed a need to have stable mean *stable*, i.e. no syntax changes necessary for some period of time. Strictly speaking, this is not a syntax change. If you write LilyPond, no Scheme, the output should be the same. I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. I certainly would have been more than happy to have that inconsistency abolished. The way to do that would be to _stop_ the tabstaff engravers from listening to string events and instead have them look in the articulations for them. If the string events become unlistened to, the rhythmic music iterator will leave them in the articulations. Alternatively, make a listener/engraver for per-chord string indications (which, like fingerings, can be typeset with less need to keep them close to the notehead). We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. I don't think they will be affected unless they do Scheme juggling. The one thing that _will_ be affected is XML output. If we still want to have that policy, I believe that subversion numbers are cheap, but stable version numbers are expensive. I think we'd be best to try to get this into 2.16. And it definitely needs to be in a prerelease for that. If the prerelease makes it obvious that this won't work, it will have to be backed out, something which I would find rather unhappy (since it would mean that parts of the music function syntax changes that belong together logically would be spread across two stable releases). If you take a look at the stats, you'll find that apart from the implementation of the rhythmic music iterator (which is rather boilerplate), most of the changes are _reductions_ in size. In particular the parser. It will also make the programmer's guide simpler. I am starting on that now. commit 0e9b4d86388b83bfbd217b0d77d6759f2ef81cef Author: David Kastrup d...@gnu.org Date: Thu Dec 1 18:32:15 2011 +0100 Don't wrap EventChord around rhythmic events outside of music lists. 9 files changed, 212 insertions(+), 222 deletions(-) commit 10c40a07236febc9279a5faadbcdc15dc3bb1c82 Author: David Kastrup d...@gnu.org Date: Sat Jan 21 14:24:01 2012 +0100 Let \relative run through articulations for the sake of pitched trills 1 files changed, 1 insertions(+), 0 deletions(-) commit 84144db390bac765fcd0e80403b548ca4e90a59f Author: David Kastrup d...@gnu.org Date: Fri Jan 20 21:38:09 2012 +0100 Define a post-event music type and let post-event? and ly:event? use it. 5 files changed, 37 insertions(+), 68 deletions(-) commit c4760f3c4a5ec896231e285363c8f10e59a07c53 Author: David Kastrup d...@gnu.org Date: Thu Jan 19 18:58:38 2012 +0100 Fixes to Rhythmic-music-iterator 4 files changed, 38 insertions(+), 9 deletions(-) commit efb9bc79e3714ce06ef48b148850de29625ddb18 Author: Mike Solomon m...@apollinemike.com Date: Wed Jan 18 20:12:13 2012 +0100 Implements rhythmic-music-iterator 3 files changed, 109 insertions(+), 0 deletions(-) -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: On Jan 21, 2012, at 6:14 PM, Keith OHara wrote: Carl Sorensen c_sorensen at byu.edu writes: On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote: On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote: I would very much prefer the work on Issue 2240 (aka 2070) to make it into 2.16. It is a significant API change IMO, significant API changes should not happen right before a release. We wanted stable versions to have a significant lifetime so things like LilyPondTool and Frescobaldi didn't need to always keep changing. The implication is that issue 2240 changes the interface (but not the input syntax because there is no convert-ly rule) in a way enables improvements user code (presumably Scheme) that we will want so badly that we cannot wait for 2.18. Does anybody know what 2240 improves ? I was asking myself a similar question lately now that I've gotten deeper into the non-parser-related aspects of 2240. After playing around with iterators and such, I'm convinced that all the articulation stuff can be written to be slicker independent of any changes to the parser. Meaning that, without any changes to the representation of event-chords, we could get rid of the script engraver and fingering engraver and just keep the new fingering engraver, doing all necessary massaging at the iterator level. That is a backend aspect. 2240 is not concerned with improving the backend: its changes to the backend are just designed to keep LilyPond produce the same graphical output given the same textual input. The advantage is in a much more straightforward relation of input to music expressions. That makes experimenting with and programming LilyPond more simple. One example from the notation manual: For the `\tweak' command to work, it must remain immediately adjacent to the object to which it is to apply after the input file has been converted to a music stream. At times, LilyPond may insert additional items into the music stream during the parsing process. For example, when a note that is not explicitly part of a chord will be placed in a chord by LilyPond, so notes to be modified with `\tweak' must be placed inside a chord construct: \tweak #'color #red c4 \tweak #'color #red c4 Guess what: both work just the same now. \tweak is a music function. Music functions inside of chords were special: they got chord constituents as arguments and were expected to produce them again, as opposed to normal music functions that received notes only wrapped in EventChord. If you were serious about making your music functions maximally useful, you needed to check what you got and behave accordingly. Now music functions can get _multiple_ music arguments. Will only the last be chord constituents when we have a chord music function? What if optional arguments are in between? Actual the optional argument scanning was so complex that it was only implemented for main music functions, not for chord constituent music functions. Because chord constituents are not artificially wrapped in EventChord unless they are actually placed in a chord, the difference is _gone_. _All_ music functions will work predictably inside of chords like outside. They don't see different input. They don't need to produce different output (of course, if they produce something inside of a ... chord that has no place inside of such a chord, LilyPond will complain). If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Especially given the perspective David addressed earlier that part of LilyPond's code base getting better will be it getting more uniform and boring, how is this move away from uniformity (meaning creating two channels for of handling rhythmic events) beneficial? I think the question boils down to: is there an inherent difference between c and c and, if so, what is it and why is it meaningful? The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? Why does \tweak c require chord brackets to work? Why does \displaySchemeMusic produce oodles of layers for simple input? Issue 2240 makes the relation between input and resulting music expressions much more straightforward. And the everything-is-an EventChord mantra gave you a false sense of
Re: 2.16 release candidate 3 imminent
Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. If nobody listens to string number events, they will stay articulations except when placed explicitly on chords like c\3 and then you deserve what you don't get. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. That would be the case. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 11:16 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. If nobody listens to string number events, they will stay articulations except when placed explicitly on chords like c\3 and then you deserve what you don't get. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. That would be the case. Great! I'll make tabstaff engraver stop listening to string number events once your patch is pushed. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g \3\2\1 once these changes are implemented? The former displays circled string numbers in a normal staff, whereas the latter doesn't. Tablature staffs are identical, of course. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 7:12 PM, David Kastrup wrote: If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. I think it this is good - this is what will help scrap the fingering and script engraver. It seems like this is a separate problem from wrapping notes in event chords or not: if all articulations are in an articulations list, then they can all go to the new fingering engraver. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Why couldn't this be solved on the iterator level? The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. And the everything-is-an EventChord mantra gave you a false sense of security: you thought if stuff worked with single notes, chords would be covered as they are the same. Poppycock. When c-. works, that does not mean that c-. will also work. Because suddenly it becomes quite different even though both are in a chord. I'm not quite getting what you're saying here... With the current setup, the music expressions reflect the input, the Stream Events (and thus everything passing through engravers) reflects the old behavior that was previously hand-cranked in the parser. You can now synthesize single NoteEvents and have them work as expected. I think that expected behavior depends on how we define it. If there were synthesized articulation events that fell outside of an EventChord, LilyPond would not know what to do with them. Similarly, if we simply say that a NoteEvent makes no sense outside of an EventChord, then there is no expected functionality for a dangling NoteEvent. I'm not at all saying that this is a bad proposal, but rather that as I'm learning more about how iterators do their thing, I'm realizing that all articulations can be in a list attached to a rhythmic event and that event chords never need to carry articulations. Some of this comes from my continued limitation in understanding what this patch does - I get the general concepts in your e-mails, but it is very difficult to understand how LilyPond works without seeing lily code. So, *** What would be really helpful is an e-mail that has almost no text explanation but that shows before and after examples of how this will change LilyPond. This can be syntax before versus syntax after or music stream before versus music stream after. I know that adds an extra burden to your work, but I'd greatly appreciate it! *** Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Marc Hohl m...@hohlart.de writes: Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g \3\2\1 once these changes are implemented? The latter would not display anything anywhere. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 19:41, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: Am 21.01.2012 18:44, schrieb Carl Sorensen: On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote: I have actually found out that I promised too much about string numbers appearing on isolated notes: since the string number events _are_ listened to (likely by the tabstaff engraver team), the rhythmic music iterator _does_ broadcast them instead of leaving them as articulations. The tabstaff engraver team listens to *both* string number events *and* articulations. Combining the two is a bit of a pain. That's why I asked earlier to get some consistency. If we can get string number events to always be in articulations, we don't need to broadcast string number events. If the rhythmic music iterator can make them always show up as articulations, that would be great. I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! Thanks, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: On Jan 21, 2012, at 7:12 PM, David Kastrup wrote: If you wrote note^postevent previously, the postevent ended up in articulations of the NoteEvent when written inside of a chord, or as an EventChord companion when not written in a chord. Now it ends up in articulations, period. I think it this is good - this is what will help scrap the fingering and script engraver. It seems like this is a separate problem from wrapping notes in event chords or not: if all articulations are in an articulations list, then they can all go to the new fingering engraver. They won't be in an articulation list if they are on a chord. Then they are separate events inside of EventChord. It is conceivable that we let EventChord _also_ take articulations as a property. It is not all that clear to me who will be responsible for interpreting them, but it would likely not be hard to just let the event chord iterator broadcast them without thinking. This would, however, be a more fundamental change. The current syntax changes don't create music events that could not previously also occur (just not everywhere). EvantChord+articulation would be new. My question is this: what is the basic advantage of having rhythmic events not wrapped in event chords? I understand that it can be used to wedge a distinction between c and c, but how is this distinction useful? URL:http://code.google.com/p/lilypond/issues/detail?id=1110#c26 Why couldn't this be solved on the iterator level? There was no distinction between c and c at the iterator level anymore. Either case you had an EventChord around it. The problem that I have been tackling is more: is there an inherent difference between c-. and c-. and, if not so, why the heck do they look utterly different in the music expression depending on whether inside of or outside? I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. There is such a thing as a chord articulation. I'm not at all saying that this is a bad proposal, but rather that as I'm learning more about how iterators do their thing, I'm realizing that all articulations can be in a list attached to a rhythmic event and that event chords never need to carry articulations. What do you do with c e g\p then? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Le 21/01/2012 17:19, Graham Percival disait : All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? Two weeks seems a reasonable time-window for the FTP mary-go-round as well as polishing and merging translations. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 1/21/12 11:47 AM, Marc Hohl m...@hohlart.de wrote: I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! I'm not sure you actually will find it great (although I think it is more consistent). If we don't want to have string numbers show up in the music, but we need them for the tabstaff, right now we can do c e g\3\2\1 In the future, c e g\3\2\1 won't assign the string numbers to the tabstaff. (And in fact, I can't find this usage documented in the NR). Instead, as would be done regularly in lilypond, we would do \once \override StringNumber #'stencil = ##f c\3 e\2 g\1 This is consistent with how things are handled in lilypond, so I think we ought to move in this direction. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 21/01/2012 11:19 AM, Graham Percival wrote: Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. Once the fix for (lilypond-book fails with html input) is in, I'll fix 2223 (Regtests for lilypond-book are not running). I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: suffix-lyxml: looks suspicious, no image of music tex-twocolumn: fails, lilypond snippet is fullpage-wide. texinfo-language-detection: has a weird @lydoctitle popping up -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make sure that you actually try those version in 2.14.0 or 2.12.3 or whatever -- I wouldn't want to blindly assume that those tests actually worked when they were added to git. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote: I absolutely agree that everything should be in an articulations list, but I think this can be done while preserving event chords. It just means that EventChords will no longer contain articulation events and that all articulation events will be pulled out of NoteEvents or RestEvents and broadcast at the iterator level. There is such a thing as a chord articulation. Why couldn't this distinction be captured via a different event name? ChordArticulationEvent versus ArticulationEvent, for example. What do you do with c e g\p then? \p is an AbsoluteDynamicEvent and is not treated like articulations. What would really help are some before/after examples (ly code and/or music streams and/or brief text like before the patch, you could not do X, after, you can or this patch will allow me to experiment with implementing X) would help a great deal. As if it were going into the Change Log, for example. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
that all articulation events will be pulled out of NoteEvents or
RestEvents and broadcast at the iterator level.
There is such a thing as a chord articulation.
Why couldn't this distinction be captured via a different event name?
ChordArticulationEvent versus ArticulationEvent, for example.
Where would be the point?
To not make the distinction in the parser. I think that changing the parser
should be a last resort if we can't figure out a way to represent information
through different event classes.
What would really help are some before/after examples (ly code and/or
music streams and/or brief text like before the patch, you could not
do X, after, you can or this patch will allow me to experiment with
implementing X) would help a great deal. As if it were going into
the Change Log, for example.
It's a bit hard since the whole design (perfected by the
rhythmic-music-event) was intended to make no user-visible difference.
The music expression has just become predictable. You get an EventChord
iff ... has been in the input. You get articulations on NoteEvent
for pitch-postevent regardless whether or not this is part of a chord.
Why can't we treat c as shorthand for c? Having a compulsory wrapping around
singletons is just as predictable as no wrapping at all.
As for articulations being on a NoteEvent whether or not this is part of a
chord, I agree that this is a very good idea, but I think this can be
accomplished by wrapping everything in an event chord and farming out the work
to iterators.
If you use \displayMusic on something that you might want to put into a
chord, you don't get wrong input. Tacking around a construct does
not change the structure of its inside. It is not necessary to tack
around a construct to make a \tweak work (which is a user-visible
change).
Why couldn't tweak make this distinction in the music function itself?
The music function could check if its input is an EventChord and, if so, feed
it the first entry in the 'elements list of the EventChord. This seems like a
less intrusive change than changing the parser.
You can use #{ #} for constructing material that ends up _inside_ of a
chord. Something like
\displayLilyMusic \displayLilyMusic ##{ c-. #}
does not go up in flames but just does what one would expect.
This is indeed an interesting case. Again, though, I would expect this to
fail, precisely because #{#} manipulates the material. If we define c as
shorthand for c, then this would be like doing \displayLilyMusic
\displayLilyMusic c , which I would also expect to fail.
I'm playing devil's advocate because it is an important change and I want to
make sure that its benefit outweighs the cost of adding exceptions into the
code base that facilitate the in/out of EventChord distinctions.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
2012/1/21 Graham Percival gra...@percival-music.ca: All release-Critical issues have patches which are either on a current countdown, have been on a previous countdown, or don't make sense to be on a countdown at all and will thus be pushed in a few hours. Unless any problem are found with the current countdown'ing patches, 2.15.27 release candidate 3 will probably come out on Monday. Sounds great even despite the fact that Julien discovered new regressions. There seems to be a desire to wait for 2 weeks instead of 1 week, so that's what I'll announce? +1 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
