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
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
