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: Sat, 08 May 2010 19:01:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, May 8, 2010 at 9:28 AM, Werner LEMBERG <address@hidden> wrote:
>>
>>> So how about the ultimate tweak: using a separate engraver?  We
>>> can't have overlapping slurs with a single engraver, for example.
>>> But if we write something like
>>>
>>>   <c( address@hidden( g> <address@hidden) f)>
>>>
>>> and use @1 with the scope of a tweak, and let it use the engraver of
>>> subvoice 1 (a subvoice having its own engraver copies that get to
>>> handle basic events just from its own subvoice), then it becomes
>>> possible to use parallel slurs in one voice.
>>
>> I like this.  Up to now noone had ever such an idea, and your
>
> This is false.  I had the idea earlier and unleashed it on the world.
> It was called the Thread context, and it was a disaster, because it
> would die or be created at unexpected times.

What were the consequences of these unexpected changes?

> I you dive deep enough into the git history, you can find its
> remnants.

One thing that I currently see with engravers is that (like the
glissando engraver) they have bookkeeping for one active instance of
what they are engraving, and this bookkeeping is there even when they
are idle.

Basically, there is no way to figure out when an engraver is not keeping
a record of anything worthwhile.  And that might make it hard to figure
out when one can get rid of it.

Anyway, maybe the design can be changed to accommodate Threads or
whatever one wants to call them while causing less of a disaster than
the current workaround using hidden notes is.

Maybe it would already help to have a tweakable property that tells a
spanning event (slurs, text spanners, beams, glissandi...) to listen on
a different voice for its closing event.  That would make it possible to
mostly juggle with ad-hoc voices for this sort of functionality.

I've also found that \change Voice = ... gives an error message when in
the middle of a voice.  There is outcommented code in the change
iterator for supporting this, but it apparently suffered bit rot already
and is not workative.

-- 
David Kastrup




reply via email to

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