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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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.
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
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.
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
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
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
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
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
41 matches
Mail list logo
