Carl Sorensen <[email protected]> writes: > On 5/10/10 9:07 AM, "David Kastrup" <[email protected]> wrote: > >> David Kastrup <[email protected]> writes: >> >>> Reinhold Kainhofer <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
