[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Context_def -> Context progress
From: |
Erik Sandberg |
Subject: |
Context_def -> Context progress |
Date: |
Wed, 1 Nov 2006 12:59:34 +0100 |
User-agent: |
KMail/1.9.5 |
On Monday 16 October 2006 23:41, Erik Sandberg wrote:
>
> I have a clearer plan for context defs now: We could represent each context
> def as a Context object, which is used as a template for new contexts.
> E.g., the Voice context_def in engraver-init.ly defines a Context object
> with various engravers and properties in it, and when a new Voice is
> created during interpretation, the template voice is clone()d, and linked
> into the context tree.
>
> This requires a good mechanism for context cloning, which preserves
> translators and context properties. This can be achieved using signals,
> much like the AnnounceNewContext mechanism: Context::clone sends a
> CloneContext event, containing a reference to the newly created context.
> When the translator group hears this event, it clones itself and all
> translators, and connects the clones to the new context (this should be
> sufficient to preserve \consists etc.)
>
> This suggestion does still not make clear how to separate
> translator-specific and context-hierarchy-specific information, but we can
> wait with that separation.
>
> Plan:
> - create a Context::clone, which copies nothing.
> - replace lots of references to Context_def with references to a Context
> which references that context_def.
> - add hooks for translator groups (CloneContext event)
> - incrementally stuff out from context def to context and translator group.
> This includes the commands \consists, \remove, \type,\override, \revert,
> \set and \tempo.
Hi,
I have started working on this, a first refactoring is attached. Many
references to Context_defs have been replaced with references to a Context
('template context'), and a new Context::instantiate intends to replace
Context_def::instantiate in the future.
In addition, I changed the protection of context keys so that unprotect and
creation happens in the same scope. I also changed some constness, to make
key unprotection const correct.
The work so far only aims on softcoding context-def definitions
as music expressions, this is not much related to the original problem of
separating definitions for contexts and translators. I think the latter can
be done by creating a context-init.ly, which is a translator-neutral common
base for {engraver,performer}-init.ly and recording-group-emulate.
My idea is that in
\context { \name "Staff" \consists "Foo_engraver" }
the { ... } is a music expression, and \context is a music function, which:
- creates a special context (a 'template context').
- interprets the expression in the template context. During interpretation,
the template context is treated as a bottom context with no parents or
children. No listeners will listen to the context, so any non-\applycontext
music will have no effect, and will probably give warnings.
- return the template context in its final state.
However, while I wrote this, I have been thinking about an alternative
solution to the same problem, which is cleaner but less efficient: We could
let context_def simply be a music expression which is inserted before any
music in the context. So e.g., \context Staff { c4 } would be equivalent to
creating a new, blank context and interpret { \Staff c4 } in it.
A problem with this approach is that all property, \override and \consists
operations have to be re-iterated for each newly created context. This
doesn't need to take much time (quote-like constructs could be used to cache
the result of music interpretation), but the problem is that the size of
music streams would explode: Each Staff creation will send a bunch of
\consists and \set events to the new context, this may result in grotesque
music stream sizes if << \\ >> is used a lot. This weakness is at the same
time a strength, because music streams will be completely self-contained in a
natural way (currently they rely on knowledge about context_defs). The
concept of context_defs will be kept entirely on the iterator side, which is
very nice IMO. OTOH, it may be more difficult for non-lilypond applications to
distinguish between e.g. staff contexts and voice contexts, since that info
is not part of the CreateContext stream event.
Any comments / ideas / opinions?
--
Erik
es-061101.diff
Description: Text Data
- Context_def -> Context progress,
Erik Sandberg <=