On Jul 5, 2011, at 6:10 AM, carl.d.soren...@gmail.com wrote:
> Looking at the details of the code, it seems fine.
>
> But I tend to agree with Han-Wen's concerns.
>
> I'm wondering if it's possible to avoid code dup by making a
> base_stem_engraver of which glissando_stem_engraver and stem_engraver
> would be children.
>
> I probably don't have the right terminology for this (in fact I'm sure I
> don't), but I'm thinking of what happens with ligature_engraver and
> mensural_ligature_engraver.
>
This is a good idea, although I think that the overlap is significant enough
that they can co-habitate one engraver (I can see them varying in one function
call maximum). But the logic is exactly this.
I absolutely agree w/ Han-Wen that solutions should be generic, and I feel that
this problem is the subset of the larger problem that the simple spacer is
agnostic of the spacing in other lines. This fouls up a few scenarios:
1) Glissando stems are grobs whose directions change based on horizontal
spacing, causing certain elements to change direction, which causes different
stencils (think tremolos / articulations) & extents that could subsequently
effect the value of the line forces calculated in
Constrained_breaking::initialize (). A better way to say this is that these
forces should not be static but rather contingent on the distribution of stems
on neighboring lines.
2) Certain arpeggio substitutes, such as chord braces and chord slurs, change
their width in response to the distance between staves, which changes based on
horizontal spacing. Currently, this distance between staves is calculated way
downstream from the simple spacer.
3) textLengthOn and textLengthOff. Currently, there is no way to
automatically space lines such that (a) a4^"really really really really really
really really really long" doesn't fall towards the end of a line; or even
better (b) a function distributes spacing error across subsequent lines such
that other quarter notes around a4^"really really really really really really
really really long" have similar distances that get more "normal" as the
quarters get farther away from this distance. This function calculates a sort
of force can be accessed via the same system of penalties used for
ties/slurs/beams.
All of these issues would be solvable in the following scenario. Note that the
following scenario is VERY inefficient, but there are shortcuts that could be
taken to cache certain values.
1) In any given score, there are always 2**(n-1) line breaking configurations
possible, where n is the size of the vector breaks (see line 396 of
simple-spacer.cc).
2) Each of these configurations is subject to various callbacks that determine
how to handle glissando stems, distribute spacing error, widen/shorten
arpeggios, etc. The properties that are changed based on these functions would
be marked internally as `volatile', and their values would not be cached until
after a good spacing was chosen. For example, in glissando stems, stem
direction, stem tremolo direction / extent / stencil, articulation direction /
extent / stencil are all volatile.
3) Make the lines_ of a constrained breaker a sparse binary tree (see below)
of matrices, not a single matrix, that stores the information above. Each node
of the tree would branch off into break/noBreak for a single point in breaks.
The above approach is, of course, absurdly large as it would require
1125899906842624 line-breaking matrices for a 51 measure score (2**(51-1)).
However, a lot of caching can happen based on where there are and aren't
volatile grobs. It is for this reason that I say "sparse" binary tree (or a
binary tree where, if after node n all paths lead to the same result, node n
represents all of these paths). This can be made even sparser because certain
paths will invariably start the same, diverge, and meet back up at certain
places - their similarities can be represented by one data structure that holds
a group of node indices and the shared result for these indices.
Thoughts?
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
