lilypond-devel
[Top][All Lists]
Advanced

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

Re: simultaneous rehersal marks, tempo indication, and text marks


From: David Kastrup
Subject: Re: simultaneous rehersal marks, tempo indication, and text marks
Date: Mon, 27 Feb 2012 16:33:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Neil Puttock <address@hidden> writes:

> On 27 February 2012 13:48, Graham Percival <address@hidden> 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




reply via email to

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