Re: music function to be included somewhere in scm/*

[Alexander Kobel]

Hi Paul.

On 2016-12-16 16:02, Paul wrote:
> Hi Knut and everyone,
>
> Great to see your work which seems like a nice improvement.  I just have
> some thoughts on the implementation / use of properties.
>
> We are just talking about grob properties and not context properties
> right?  In that case no need to also create context properties as you do
> in your patch, since the grob properties are sufficient.

Yes, I think that's a general agreement now. AFAICS, the idea of context 
properties quickly vanished after we recognized that we can get rid of 
__ (or ExtenderEvents) entirely, at least as far as the user is 
concerned. They are now more like an implementation detail for no-extender.

> What about a way to do this with fewer than 3 separate grob properties?
>
> LyricExtender.minimum-length
> LyricExtender.no-extender
> LyricExtender.force-extender
>
> If I understand correctly, only 1 of 3 kinds of behavior can be in
> effect at a given point:
>
> 1. no extensions
> 2. forced extensions
> 3. automatically added extension depending on a 'minimum-length' number

Not quite. I can imagine that no-extender and force-extender could be 
combined. E.g., as create-extender = { one of #'auto, #'never, #'always }:

#'auto means the default: create extenders on melismata and nowhere else.
#'never means: create no extenders, period.
#'always means that extenders are enforced even on non-melismata (where, 
by definition, there should not be an extender; but there are situations 
where it makes sense to overwrite it; e.g., for a continuation of an 
extender in a second volta repeat, or in divisi lyrics).

Minimum-length [2] is orthogonal - it is more concerned with the layout. 
With some reasonable minimum-length, extenders that reduce to mere 
flyspecks are hidden. This happens often in somewhat dense choral 
settings: the extender is not printed if the syllable text is almost as 
wide (or even wider) than the distance between the respective noteheads. 
It's a threshold value that tells which existing extenders will be 
printed and visible. [1]
But this decision entirely depends on horizontal spacing, and will vary 
with line breaks, other voices, etc. IMHO, that's a whole different 
quality of a variable than the previous one (existence vs. appearance). 
And the general design principle throughout Lilypond is to separate 
semantics from layout as much as possible.

[1] One exception: on forced extenders on non-melismata (which do not 
have any natural length, obviously), minimum-length will not serve as a 
threshold, but to /set/ the length.

[2] Side Note: other proposed names for minimum-length so far:

(1) minimum-space
(2) show-length
(3) hide-below-length
(4) hide-if-shorter-than
(5) minimum-visibility
(6) visibility-threshold
(7) printing-threshold
(8) extender-threshold


> So why not one grob property (name to be determined) that can be a
> boolean or a number:
>
> LyricExtender.extenders = ##f   % no extensions
> LyricExtender.extenders = ##t   % forced extensions
> LyricExtender.extenders = 2        % a number, auto extensions
>
> For example, it could be set to a number and then use \once to set it to
> ##t to force (or ##f to suppress) a given extender.

See [1] above; we need to be able to specify a length for forced 
extenders (that do not have a natural length because there's only one 
note). Yes, something like extenders = #'(forced? length) with a boolean 
for forced? and a number for length would be sufficient (note that #'(#f 
+inf.0) amounts to #'never...), but that's quite opaque.

> Another possibility (2 properties) might be:
>
> LyricExtender.stencil = ##f                % no extensions
> LyricExtender.force-extender = ##t  % forced extensions
> LyricExtender.minimum-length = 2    % auto extensions (if force-extender
> is not ##t and stencil is not ##f)

Yes, that'll work: stencil = ##f means #'never; stencil = ##t and 
force-extender = ##t means #'always; and stencil = ##t and 
force-extender = ##f means #'auto.
However, I personally dislike to touch stencil. That's my last resort, 
but it feels hacky; IMHO stencil is a more or less internal layout 
procedure, and I should not have to abuse it for semantic purposes 
(i.e., #'never).


Cheers,
Alexander