lilypond-devel
[Top][All Lists]
Advanced

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

Re: Some engraver brainstorming


From: David Kastrup
Subject: Re: Some engraver brainstorming
Date: Mon, 10 May 2010 17:07:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Reinhold Kainhofer <address@hidden> writes:
>
>> Am Samstag, 8. Mai 2010, um 14:28:18 schrieb Werner LEMBERG:
>>> > So how about the ultimate tweak: using a separate engraver?  We
>>> > can't have overlapping slurs with a single engraver, for example.
>>
>> Actually, by extending the engraver a little bit it should be
>> possible. I have had that on my list for quite some time...
>
> That's the same for glissandi.  But there is not much of a point
> extending every engraver a bit and making its code more complex if the
> same can be done with a more or less universally working approach for
> all spanning engravers.

There are two different issues here to address/kill.

Issue 1 is making spanning engravers (or engravers that can do just one
job between the start and the end of the moment) work for multiple
parallel tasks.

Issue 2 is being able to deal with those parallel life times properly:
letting programmed tasks and user tasks make sure that the intended
instance of an engraver is addressed for a specific task.

Some of the lack of enthusiasm for dealing with issue 1 may be explained
by the necessity of addressing issue 2.  For example, we don't have
nested slurs, but then what to make of

<c( d( e(> <d) e) f)>

This particular one does not want to get a solution in terms of nesting,
but likely first in, first out.  Unless it doesn't...

So the solution would be to use "selectors".  A selector basically just
sets a sorting criterion, and applies to a single "entity".  If we apply
it like a \tweak, we'd write:

<c( address@hidden( address@hidden(> <d) address@hidden) address@hidden)>

Syntactically, postfixing might look nicer.

<c( d(@1 e(@2> <d) e)@1 f)@2>

That's assuming @ as a shorthand.  Maybe a case for GLISS, though
upwards-compatible.  If the syntax is too contentious or the decision
should be postponed, \select 1 might be used, which may at first be the
same as \tweak #'selector #1.

The selector itself would, in input syntax, likely be symbol or number
and be compared with eq? or at most eqv?.  That makes it reasonably easy
to create unique selectors programmatically (like the appoggiatura code
creating its own ties internally, currently in conflict with user ties).

A selector basically has the effect of routing the translator interface
to a separate engraver instance (where supported by the engraver,
otherwise it will be ignored).  But all without changing the context.


Programmatically, I was intending to do something like a template type

Engraverfactory<GlissandoEngraver> NewGlissandoEngraver;

for definining an Engraver acting on selections.  That would make it
quite easy to quickly test the concept on various engravers.

I am not sure that this is the best permanent solution, however, since
it is somewhat lacking in transparency.

-- 
David Kastrup




reply via email to

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