lilypond-devel
[Top][All Lists]
Advanced

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

Re: Adds glissando stems to Lilypond. (issue4661061)


From: address@hidden
Subject: Re: Adds glissando stems to Lilypond. (issue4661061)
Date: Tue, 5 Jul 2011 09:58:41 +0200

On Jul 5, 2011, at 6:10 AM, address@hidden 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

reply via email to

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