Neil Puttock <[email protected]> writes:
> On 27 February 2012 13:48, Graham Percival <[email protected]> wrote:
>
>> What would be involved in making a clean solution for this? I
>> imagine that a separate TextMark engraver (just like the
>> RehearsalMark engraver and MetronomeMark engravers) would do the
>> trick, but that's a bunch of icky C++ code. Is there any way to
>> use scheme to create a new engraver that behaves like an existing
>> engraver (i.e. TextMark), but has its own data (so it doesn't
>> merge the rehearsal mark event with the "text mark" event?)
>
> Attached is a scheme engraver I hacked up a few years ago. It
> naturally has a few limitations, particularly if you use multiple
> \mark \default commands at the same timestep.
[...]
> \layout {
> \context {
> \Score
> \remove "Mark_engraver"
> \consists #multi-mark-engraver
> }
> }
>
> markDown =
> #(define-music-function (parser location text) (markup?)
> (make-music 'MarkEvent
> 'direction DOWN
> 'label text))
Ok, here is one idea. If you do
git grep ASSIGN_EVENT_ONCE
you get about a gazillion results. We have a tweak engraver that is
fairly general and just takes a look at events having a 'tweak setting,
moving it to grobs that are caused by them (more the other way round,
but you get the gist).
Now the question is whether we can have a Scheme engraver taking a look
at a "duplicate" field, catch all events passing by with it set, and
create a fresh engraver instance if it finds something like that, using
the last engraver that was responsible for processing the same kind of
event as a template, and realigning the resulting grob to the
"non-duplicate" grob as one possibility.
We have a lot of engravers that can't deal with more than one thing at
one time step. An engraver/mechanism that could fudge in multiplicity
without requiring every engraver instance to be multiple-aware could be
a quite useful building block.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
