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