[Top][All Lists]
[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: |
Sun, 3 Jul 2011 00:06:26 +0200 |
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
Re: Adds glissando stems to Lilypond. (issue4661061), address@hidden, 2011/07/03
Re: Adds glissando stems to Lilypond. (issue4661061), address@hidden, 2011/07/16
Re: Adds glissando stems to Lilypond. (issue4661061), address@hidden, 2011/07/16
Re: Adds glissando stems to Lilypond. (issue4661061), Carl . D . Sorensen, 2011/07/05
Re: Adds glissando stems to Lilypond. (issue4661061), Reinhold Kainhofer, 2011/07/05
Re: Adds glissando stems to Lilypond. (issue4661061), mtsolo, 2011/07/17