[Top][All Lists]

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

Re: [GSoC] Implement cross-voice dynamic spanners (issue 304160043 by ad

From: dak
Subject: Re: [GSoC] Implement cross-voice dynamic spanners (issue 304160043 by address@hidden)
Date: Fri, 21 Oct 2016 07:38:05 -0700
File lily/include/spanner-engraver.hh (right):
lily/include/spanner-engraver.hh:111: if (is_manager_)
On 2016/10/21 13:22:53, dak wrote:
Ok, this is_manager_ concept seems like a bad fit with regard to the
data structures.  It means that every engraver instance here has all
functions and data structures needed to manage multiple engravers.

What are alternative means of doing this?

The simplest would likely be to have the multiple spanner class be
templated on
the class it is controlling.  It would then create actual engravers as
To get equivalent behavior, it might seem that one engraver instance
should be
created right away.  However, since the multiple-spanner-ready
engravers need to
be prepared to be created later than that anyway, I think I'd just
create them
as needed even for the default one.

The advantage would be that the hierarchy would be much cleaner:
currently I
feel that there is code distributed up and down, making it harder to
responsibilities and consequently also for figuring out how to work
this into
slurs and others.

Now the question is how such a rearrangement would best be organized:
we don't
want the code fall dead, but the time allotment for the project also
basically over.  See a perspective here time and motivation getting

Sorry that's a bit confused as Spanner_engraver is already templated on
its controlled class.  The point is that the controlled class is derived
from Spanner_engraver<Class> which has the advantage that this can
provide the same machinery as Engraver but do it differently.  But it
has the disadvantage that the actually running "master" Engraver is
running multiple instances.  So maybe one needs to shoehorn the
one-spanner engraver in question between a single master Engraver
instance (so necessarily being a separate type from the individual
engravers not sharing inheritance) receiving and redistributing the
events and have some interface class in closer relation to the
individual engravers (either being derived from the individual engraver
class and exercising its interfaces while using virtual functions to
take over the underlying Engraver functions, or by being its base class
instead of Engraver and reimplementing the base functionality).

reply via email to

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