lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request


From: David Kastrup
Subject: Re: Feature request
Date: Mon, 24 Sep 2012 14:44:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Mats Bengtsson <address@hidden> writes:

> On 09/24/2012 10:55 AM, address@hidden wrote:
>>>>    \beaming { c8[ c] c r c[ c c c] }
>>> >
>>> >Ouch.  Of course.
>>> >
>>>> >>but yes, that would be great.
>> This could probably be
>>
>>    \beaming {8[ 8] 8 8 8[ 8 8 8] }
>>
>> So we have another result of GLISS.
> Actually, I like David's original proposal better if the semantics of
> the construction is to both typeset the particular music and to use it
> as a template for a beaming rule.

The disadvantage would be that you lose the option of using a more
abstract specification like above, whether or not adorned with a
placeholder pitch like c or not.

> \relative c' {
> \time 8/8
> \use_as_template_for_beaming{ c[ d e] f [ g a] g[ g] } |
> f e d e d c d d |
> \use_as_template_for_beaming{ c16 [ e ] g [ e ] f4 g[ a] g16 [ e] d[ c] } |
> ...
> \time 3/4
> \use_as_template_for_beaming{ c8 [ e g c ] g [ e] } |
> ...
>
> }
>
> This would allow the user to specify concrete example in a familiar
> syntax and at the same time save some typing. Obviously, the actual
> name of the function should be something more compact.
>
> However, it's not exactly clear what the semantics should be, since in
> the above example, we want the beaming rules to be added to the
> existing rules, but perhaps the default beaming rules should be
> removed at the first time \use_as_template_for_beaming is used.

The proposal so far has not specified whether the default beaming rules
for a given meter or the current beaming rules should be affected.  The
focus has been on the inner logic.

> Also, what happens if a user specifies contradictory rules?

Rules are not additive, I'd say.  How to interpret the given measure(s)
is something that will require working out and finetuning.  It is of
course a challenge to make this both sufficiently straightforward and
powerful.

> I'm sure there are lots of situations where the result would be fairly
> non-intuitive, in spite of the seemingly intuitive syntax.

Sure.  But _if_ we can come up with simple and sufficient rules, chances
are that the user will be able to figure it out on his own by
experimentation and example.

And he'll have the chance to have it continue working if we change the
internals for the umpteenth time.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]