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

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> 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,

Let's keep that in mind.

> 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.

So what would be required here seemingly would be linearization of the
spacing in absence of note columns which convey proper timing through
their note values, however non-linearly spaced.

> 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.

I would not say "the problem is not with the existing syntax" since that
is what people were concerned with.  However, I don't see that a
different syntax would warrant different resulting music expressions
here, so regardless of how the input looks, it would seem that our
backend does not cope well in the resulting spacing currently.

Bug squad, do we have an issue with that already?

-- 
David Kastrup