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
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 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 su
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
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 re
I have to go in "hold the horses" mode now since I have a deadline for a
LilyPond talk paper
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 apolog
David Kastrup writes:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> If I write
>>> myC =
>>> #(define-music-function (parser location) () #{ c #})
>>> then I can't currently write
>>> <\myC>4 or similar. It would just not work. And there is no way to
>>> define this function, #{ #
David Kastrup writes:
> David Kastrup writes:
>
>> If I write
>> myC =
>> #(define-music-function (parser location) () #{ c #})
>> then I can't currently write
>> <\myC>4 or similar. It would just not work. And there is no way to
>> define this function, #{ #} or not, in a manner that could wo
David Kastrup writes:
> If I write
> myC =
> #(define-music-function (parser location) () #{ c #})
> then I can't currently write
> <\myC>4 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 ou
"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 typesetti
Am 21.01.2012 20:17, schrieb Carl Sorensen:
On 1/21/12 11:47 AM, "Marc Hohl" 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 wo
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
_
"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 typesetti
> 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.
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 distincti
"m...@apollinemike.com" writes:
> On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
>
>> "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 broadcas
2012/1/21 Graham Percival :
> 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 countdow
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
> "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
"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.
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
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
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
On 1/21/12 11:47 AM, "Marc Hohl" 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 anyt
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
"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
Am 21.01.2012 19:41, schrieb David Kastrup:
Marc Hohl writes:
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, "David Kastrup" wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
Marc Hohl writes:
> Am 21.01.2012 18:44, schrieb Carl Sorensen:
>> On 1/21/12 10:37 AM, "David Kastrup" 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 ta
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
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, "David Kastrup" 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 mu
On 1/21/12 11:16 AM, "David Kastrup" wrote:
>Carl Sorensen writes:
>
>> On 1/21/12 10:37 AM, "David Kastrup" 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
Carl Sorensen writes:
> On 1/21/12 10:37 AM, "David Kastrup" 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
>>iter
"m...@apollinemike.com" writes:
> On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
>
>> Carl Sorensen byu.edu> writes:
>>
>>> On 1/21/12 9:45 AM, "Graham Percival" percival-music.ca> wrote:
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
> I would very much prefer the wo
On 1/21/12 10:37 AM, "David Kastrup" 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 instea
Carl Sorensen writes:
> On 1/21/12 9:45 AM, "Graham Percival" 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 stab
On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
> Carl Sorensen byu.edu> writes:
>
>> On 1/21/12 9:45 AM, "Graham Percival" 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
>>>
On 1/21/12 10:24 AM, "Graham Percival" wrote:
>On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote:
>> On 1/21/12 9:45 AM, "Graham Percival" wrote:
>>
>> >IMO, significant API changes should not happen right before a
>> >release. Version numbers are cheap; why not have 2.18 in March
On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote:
> On 1/21/12 9:45 AM, "Graham Percival" 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,
Carl Sorensen byu.edu> writes:
> On 1/21/12 9:45 AM, "Graham Percival" 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
> >
> >IM
On 1/21/12 9:45 AM, "Graham Percival" 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
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 conti
Graham Percival 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'
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 candidat
42 matches
Mail list logo
