lilypond-devel
[Top][All Lists]
Advanced

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

Re: [GLISS] non-timed or non-musical events "z" "y"


From: Joseph Rushton Wakeling
Subject: Re: [GLISS] non-timed or non-musical events "z" "y"
Date: Mon, 17 Sep 2012 13:13:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0

On 13/09/12 08:11, David Kastrup wrote:
If it does, so does

<< c'1 { s4 s\< s2 s\! } >>

Stepping back from syntax for a second, the problem with the above (as currently implemented) is that the spacing will not produce correct output from a visual engraving point of view. This applies also to articulations, ornamentations, etc. which do not fall exactly on the note.

Consider e.g.

    c'4 c'4\turn << { c'2 } { s4 s4^\turn } >>

Now, what you _want_ here is that the spacing for the final c'2 to be such that it's clear that the \turn falls on the second quarter. That means that the spacing of the c'2 probably needs to be larger than it would be otherwise, and the \turn needs to fall halfway through that space.

What you actually _get_ is that the spacing of c'2 is entirely unaffected, and the \turn falls in a location just to the right of the note-stem which makes it look as if it's been accidentally placed a bit off.

AFAICS this happens because Lilypond considers "skip" elements s to be irrelevant for spacing purposes.

The same applies to your example with the crescendo starting on the 2nd beat of the c'1. You don't get sufficient horizontal spacing following the note to be able to appreciate the nuances of the hairpin's placement: in practice, it would most likely be read as starting on the note itself.

Further, the quarter-beat positions do not fall evenly in that horizontal space, so if you have e.g. a \< \> on the same note, it may look like one is longer than the other. Try e.g.:

    << { c'1 } { s4 s\< s\> s\< s\! } >>

... where each of the hairpins should last one quarter-beat, but actually they are all of different horizontal widths, and the \> could easily be mistaken for an accent.

So to me, the problem is not with the existing syntax per se, but the fact that the existing syntax _doesn't produce the desired output_ and needs lots of complicated tweaks to get right.



reply via email to

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