On Jan 27, 2012, at 8:10 PM, Keith OHara wrote:
> On 2011/11/28 09:11:47, mike_apollinemike.com wrote:
>> If the hairpins stop before span bars but
>> extend all the way when span bar's don't exist
>> (including when they are not
>> present because of the RemoveEmptyStaffContext),
>> then I'd much
On 2011/11/28 09:11:47, mike_apollinemike.com wrote:
If the hairpins stop before span bars but
extend all the way when span bar's don't exist
(including when they are not
present because of the RemoveEmptyStaffContext),
then I'd much rather go with
your patch, as it is much less invasive than mi
David, you wrote Friday, January 27, 2012 2:01 PM
David Kastrup writes:
It would be possible to let q set a parser variable that will optimize
this pass away when unset. The drawback would be that ChordRepeat
events entering via different channels (#{ q #} uses its own
parser, and generat
David Kastrup writes:
> It would be possible to let q set a parser variable that will optimize
> this pass away when unset. The drawback would be that ChordRepeat
> events entering via different channels (#{ q #} uses its own
> parser, and generation by Scheme is also possible) would not count
- Original Message -
From: "Phil Holmes"
To: ; "Julien Rioux"
Cc:
Sent: Friday, January 27, 2012 1:38 PM
Subject: Re: make doc problem
- Original Message -
From: "Julien Rioux"
To:
Cc:
Sent: Thursday, January 26, 2012 11:00 PM
Subject: Re: make doc problem
On 26/01/20
- Original Message -
From: "Julien Rioux"
To:
Cc:
Sent: Thursday, January 26, 2012 11:00 PM
Subject: Re: make doc problem
On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote:
On 22/01/2012 20:58, Julien Rioux wrote:
Thanks, you're quite right CPU is not the limiting factor for the
bu
LGTM
http://codereview.appspot.com/5576053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Since we didn't have any patches on the official countdown for
next Sunday (2pm GST), let's add Carl's latest Critical fix:
empty strings: tabStaff insists on stringnumbers and looses notes
http://code.google.com/p/lilypond/issues/detail?id=2256
http://codereview.appspot.com/5576053
- Graham
___
David Kastrup writes:
> 2) do it in a specific music function either explicitly called, or
> called automatically at an appropriate time.
>
> This is totally straightforward and controllable. It also means that it
> is ok to work with a reference to the previous chord since no arbitrary
> proces
On 1/27/12 6:20 AM, "David Kastrup" wrote:
>
>
>Let's not get there.
Fine with me.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen writes:
> As I've been watching this thread, the idea came to me that perhaps we
> ought to do away with q and replace it with a naked duration.
Same issues as with q regarding the lifetime of input, so this
suggestion is more or less orthogonal to the problems I discussed except
f
On 1/27/12 5:27 AM, "David Kastrup" wrote:
>
>
>Possibly I am just paranoid about the transpose problem: people can
>likely accept that { \transpose c d { q } } does not transpose.
>And it is not like there is a place where inserting \q could make it
>work.
I totally accept that. In my mind, q
Ok, since I am about to doing another user interface change, I present a
summary of the proposed way of tackling it, and the reasons behind it.
There are basically three different approaches of how to make q work,
all with advantages and drawbacks.
1) do it in the parser, like the last duration o
Reinhold Kainhofer writes:
> On 2012-01-27 00:00, Julien Rioux wrote:
>> On 26/01/2012 11:13 AM, Reinhold Kainhofer wrote:
>>> On 22/01/2012 20:58, Julien Rioux wrote:
Thanks, you're quite right CPU is not the limiting factor for the
build. Disk access and usage of swap when compiling
>
14 matches
Mail list logo
