Re: Some engraver brainstorming

[Carl Sorensen]

On 5/10/10 9:07 AM, "David Kastrup" <address@hidden> wrote:

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

My initial thought was that, instead of creating a separate engraver
instance, we add an array capability to the engraver.  That way, the
engraver is aware of all the spanners that are being created, and can
properly handle such things as collision avoidance.

For example, in a chord glissando with "crossed" notes, we don't want to try
to avoid collisions.

For another example, in figured bass, I think we need to be aware of all the
existing bass figures with continuation lines in order to properly align the
figures.

But I have not tried to implement this, so my comments are not based on
experience, but on general expectations.

Thanks,

Carl