Reinhold Kainhofer reinh...@kainhofer.com 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
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
On 1/27/12 5:27 AM, David Kastrup d...@gnu.org wrote:
Possibly I am just paranoid about the transpose problem: people can
likely accept that { c e g \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
Carl Sorensen c_soren...@byu.edu 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
On 1/27/12 6:20 AM, David Kastrup d...@gnu.org 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
David Kastrup d...@gnu.org 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
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
LGTM
http://codereview.appspot.com/5576053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
- Original Message -
From: Julien Rioux jri...@physics.utoronto.ca
To: lilypond-devel@gnu.org
Cc: bug-lilyp...@gnu.org
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:
- Original Message -
From: Phil Holmes m...@philholmes.net
To: lilypond-devel@gnu.org; Julien Rioux jri...@physics.utoronto.ca
Cc: bug-lilyp...@gnu.org
Sent: Friday, January 27, 2012 1:38 PM
Subject: Re: make doc problem
- Original Message -
From: Julien Rioux
David Kastrup d...@gnu.org 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 (#{ c e g q #} uses its own
parser, and generation by Scheme is also possible)
David, you wrote Friday, January 27, 2012 2:01 PM
David Kastrup d...@gnu.org 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 (#{ c e g q #} uses its own
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
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 rather go
14 matches
Mail list logo
