Re: Adds glissando stems to Lilypond. (issue4661061)

[address@hidden]

On Jul 2, 2011, at 5:29 AM, Han-Wen Nienhuys wrote:

> I disagree with what our goal is.  We should find an implementation
> that mirrors how these objects function in actual music.  Given the
> problems you outlined with my simple approach above, and my objections
> to your patch, the conclusion is that the current code does not lend
> itself to creating stemmed/beamed glissandi, and we should create new
> code.
> 

In actual music, these objects function just like note columns - they need to 
be able to carry dynamics, markups, articulations, etc..  The issue is that 
spanners in LilyPond are not conceived of as entities that continue over line 
breaks but rather entities that are re-done on each new line (which is the case 
for hairpins but not glissandi).  As a result, their dimensions are calculated 
too far downstream to factor into horizontal spacing calculations.  The new 
glissando line-breaking code and feathered beam code helps put a dent in this, 
but it is far from doing the trick in full.

I think that the goal should be to avoid creating new grobs when old grobs do 
the trick, but obviously if this denatures the old grobs beyond recognition, 
one should create new ones.

> Have you thought of creating a GlissandoBeam

Beams need to be able to connect "normal" stems and glissando stems (see the 
attachments in my previous e-mail as well as this e-mail for an example of 
this).

> (and possibly: a
> GlissandoStem) grob instead of trying to patch up existing grobs?
> From your PDF it appears that you are looking for a beam above or
> below a set of sloped lines.  The GlissandoStem just draws a vertical
> line from the GlissandoBeam until the closest (or farthest) glissando
> line.

Glissando stems need to have the full functionality of the note columns to 
which they're attached so that they can carry dynamics, markups, scripts, 
tremolos, etc...

> In implementing the GlissandoBeam, you could reuse large parts
> of the beam quanting code, but the desired slope and direction should
> be calculated by looking at the glissandi.  The GlissandoBeam/Stem
> could have a completely different set of grob interfaces, so we can be
> sure the functionality does not interfere with normal notation.
> Conversely, since they are not normal stems, they would not result in
> specialized spacing adjustments that you want to avoid.  The
> GlissandoStems could be doctored to have no width at all.
> 

I think that it's ideal for the space between two glissando stems to be the 
same between two normal stems.  The only difference is that glissando stems are 
likely not to have noteheads.  But, I can easily imagine a scenario where these 
stems carry ntoeheads.

> We can use a lot of the existing properties and callbacks, eg. for
> beam quanting, to implement them, so the actual code duplication
> should be small to nonexistent.
> 
> The GlissandoStems should have corresponding GlissandoStemEvents
> (without pitch), to represent them in the input, and a separate
> engraver (ie. not the glissando engraver) to hook things up.
> 
> Do you have more examples from literature that demonstrate how they
> are supposed to work, so I can understand the best way to implement
> them better?  Do these stems have flags?


I've included a snippet that I've written with the most recent version of my 
patch.  It shows what I'd like these things to be able to do and is reflective 
of the way these stems work in the contemporary literature.  Currently, it is 
struggling with dynamics, articulations, and flags - it barely handles tremolos 
and beams.  In general, the issue is one of direction: horizontal spacing 
depends on stem direction if stems have flags, but the direction of glissando 
stems can't be known until after line breaking.

What would be ideal is a way for LilyPond to calculate line breaks, 
re-calculate directions of certain grobs, redo horizontal spacing on the line, 
and check if the line is still permissible.  As I said before, I think this can 
be accomplished in one fell swoop via linear programming, although as Carl and 
David have attested, this is NP-hard and I don't know if it is doable on real 
computers...

Cheers,
MS

PastedGraphic-2.pdf
Description: Adobe PDF document

curved-glissando.ly
Description: Binary data