Re: Some engraver brainstorming

[David Kastrup]

Carl Sorensen <address@hidden> writes:

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

Within one voice, that is.  Most of the infrastructure is already there
because engravers already have to work in parallel in different voices
already.

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

[...]

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

That's more or less what I was going to with my original implementation
idea: have a EngraverFactory template type that was just delegating
everything to its subordinates.

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

But in a two-voice glissando, we also don't want to try avoiding
collisions.  So while I agree with your point in principle (namely that
in some cases a boiler-plate EngraverFactory might not lead to the best
possible results), I should think that in many cases, the boiler-plate
will work out just fine since most of the multi-engraver problems are
already existent as multi-voice problems.

To be honest, a chord glissando with crossed notes _is_ a multi-voice
problem.  So it is actually a shortcoming of Lilypond that we can't
single-stem multiple voices.  This should likely be addressed
separately.

Maybe all of the problems for which @x would be nice to have should be
addressed as a shortcoming with dealing with multiple voices.  But how
to start a slur in one voice and end in another?

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

No idea here.

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

Nothing implemented yet here.  Still storming.

-- 
David Kastrup