Re: Automatically identify beats

[David Kastrup]

Thomas Morley <address@hidden> writes:

> I try to repeat/summarize in my own words:
>
> Defining some code like #(define my-code ...) will not create a
> translator, before \consists has done its work in some context.
>
> But with (for example)
> \layout {
>   \context {
>     \Voice
>     \consists #my-code
>   }
> }
> an unnamed and unregistered translator is created.

Not really.  This creates a context definition, and the context
definition actually still contains the expression after \consists, a
string or a list or an anonymous function.

It's when the Translator_group (typically an Engraver_group) component
of a context is called upon initializing an actual context that a
context creator is looked up (if we have a string) or created from a
list or an anonymous function with a single context argument that
returns such a list.

The details for a Scheme_engraver changed over some iterations, but that
is how things happen these days.

> Assumed 'my-code' is suitable, ofcourse.
>
> Below some musing.
> Don't read unless you're very interested ;)
>
> So the two codings below will not create any engraver.
>
> testI =
>   #(list
>     (cons 'initialize
>       (lambda (engraver)
>         (newline)
>         (pretty-print (list 'from-initialize: (cons 'engraver engraver)))))
>     (cons 'acknowledgers
>       (list
>         (cons 'note-head-interface
>           (lambda (engraver grob source-engraver)
>             (pretty-print
>               (list
>                 'from-acknowledgers:
>                 (cons 'engraver engraver)
>                 (cons 'source-engraver source-engraver))))))))
>
> testII =
>   #(lambda (ctx) testI)
>
>
> But as soon as I do:
> \layout {
>   \context {
>     \Voice
>     \consists #testI
>     \consists #testII
>   }
> }
>
> Two translators are created.

Nope.  A layout definition is created (as a copy of $defaultlayout) and
contains a context definition internally containing testI and testII as
part of a series of context modifications.  But there is no translator
or translator creator or anything other than the original expressions in
it.

> Which can be checked with some code you once tailored for me
> http://lilypond.1069038.n5.nabble.com/catching-layout-content-tc213339.html
> Ofcourse adjusted to fit here, thanks again for it.
>
> #(define all-Voice-translators
>   (assoc
>     'Voice
>     (map
>       (lambda (x)
>         (if (ly:context-def? (cdr x))
>             (cons (car x) (ly:context-def-lookup (cdr x) 'consists))
>             x))
>       (sort
>         (ly:module->alist (ly:output-def-scope $defaultlayout))
>         (lambda (p q) (symbol<? (car p) (car q)))))))
> #(newline)
> #(format #t "\nAll Voice-translator:\n~y"
>   (cdr all-Voice-translators))
>
> Though:
> #(pretty-print (ly:get-all-translators))
> doesn't show them.
>
> Is this expected?

ly:get-all-translators gets the _globally_ registered translators, those
you can access with a _string_ as reference (should be a symbol,
really).

> So _registering_ them makes testI/II translators,

No, translator creators (which are functions called with a "context"
argument).  Some years ago, those were actual translators without a
working context and LilyPond created a copy when instantiating a context
and then and changed the context in the copy.  That scheme was not
suitable for registering Scheme-defined translators/engravers so it had
to be changed.

Since the implementation details changed under the hood in that time and
basically nobody was actually affected, most of those details are pretty
academical and are of interest basically to answer questions of the "but
how could this possibly work with user-defined engravers" kind.  That no
longer has the simple answer "badly".  Scheme_engraver is no longer
listed as an engraver (which it was in 2.16 or possibly even 2.18 or
so), and several individual Scheme-defined engravers _are_ listed (and
previously weren't).  Which is a consequence of changing "badly" into
"it's involved".

-- 
David Kastrup