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

[Joseph Rushton Wakeling]

On 17/09/12 13:38, David Kastrup wrote:
> 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.

Actually, this is an interesting question for people to examine in scores -- 
when you have cresc/decresc etc. like this in one part, is it more normal to 
synch the horizontal placing of the hairpins with rhythms in other parts, or to 
just have even horizontal spacing?  Doesn't seem a trivial question, as what may 
seem theoretically logical (space with surrounding musical material) may not 
actually work in practice for a conductor.

(Obviously without other musical events taking place in parallel, the spacing 
needs to be even, or proportional to whatever lengths are involved.)

It might also be worth reconsidering minimum lengths of hairpins.  This is 
tricky anyway particularly as minimum length can include preceding dynamic marks 
-- really, there needs to be a minimum length for the hairpin itself regardless 
of any other dynamical elements.

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

Well, I suppose there could be an issue in that by writing this kind of stuff 
with parallel musical events, << {} {} >>, you miss an indication that certain 
events are associated with certain notes, and that might affect the ability of 
the backend to infer spacing.

But while I think it's always good to have playful and creative discussions 
around any aspect of Lilypond, to me this seems a pretty good example of how 
syntax discussions need to be tempered by first defining the scope of musical 
notation that Lilypond is trying to address, and then detailing how well 
Lilypond addresses that notation, and _then_ identifying what syntax changes are 
necessary to correct problems.

Here we have something where the existing syntax really isn't bad, but even 
better syntax won't address the really extant problem.