Re: Automatically identify beats

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am So., 7. Okt. 2018 um 18:00 Uhr schrieb David Kastrup <address@hidden>:
>>
>> Thomas Morley <address@hidden> writes:
>>
>> > If you have too much time, you may have a look at ‘scheme-engraver.ly’
>> > from
>> > http://lilypond.org/doc/v2.13/input/regression/collated-files.html The
>> > newer file uses the great 'make-engraver'-macro (by David Kastrup).
>> > Otoh, this macro hides an engraver _is_ a list (which is obvious, if
>> > you look in the older file).
>>
>> An engraver is not a list, just like it isn't a string like
>> "Note_engraver".  That's just how you _specify_ an engraver.  If it's a
>> list, the Scheme_engraver type will be used for actually instantiating
>> an engraver (which is bound to a particular context), initialized using
>> the list contents.
>
> Hi David,
>
> I don't understand the subtleties.
> Could you elaborate a bit using the examples below.
>
> testI =
>   #(list
>     (cons 'initialize
>      (lambda (trans)
>        (write trans))))
>
> testII =
>   #(lambda (ctx) testI)
>
> \layout {
>   \context {
>     \Voice
>     \consists #testI
>     \consists #testII
>   }
> }
>
> { R1 }
>
> testI is a list, testII a procedure using testI.
> Both return #<Translator Scheme_engraver >, though.

They don't "return" the Translator but rather cause it to be created
when specified after \consists , like a Notehead_engraver instance is
created when specifying the string "Notehead_engraver".

Basically there is the _specification_, \consists looks up (or in your
example creates) a suitable translator creator given a specification.
This translator creator is called with a suitable context to actually
create a translator instance when a context is instantiated, and that
creator instance is what you see listed rather unspecifically as
#<Translator Scheme_engraver > or #<Engraver Notehead_engraver> or
whatever else (to get to see those, create a suitable Scheme engraver
and look at the "source-engraver" argument of one of your grob
acknowledgers).

One of the more problematic bits in history was making a
\consists/\removes pair work for ad-hoc defined engravers (rather than
those registered under a name) since at the time of the \removes call,
the translator creator did not carry information about its originating
expression (particularly so if its list expression was the result of
calling a lambda function) and creating a fresh translator creator from
the same expression led to a different translator creator unsuitable for
looking up the preexisting translator creator.

-- 
David Kastrup