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

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>>> Actually, if we have -{ ... }, we don't need `z' at all: 
>>>
>>>   c'1-{ s4 s\< s2 s\! }
>>>
>>> fully does the job, by registering the fact that a final `s' comes at
>>> a moment which is equal the anchor's duration (sloppily formulated).
>> 
>> If it does, so does
>> 
>> << c'1 { s4 s\< s2 s\! } >>
>
> Yes.
>
>> Or are you planning to limit the total "visible" duration of the
>> construct to the "base"?
>
> Yes.
>
>> (in your case 3/2)
>
> No.  The `base' note has a length of 1/1.

s4 + s4 + s2 + s2 is 3/2.  You are asking for the last 1/2 to be
silently ignored, as opposed to what you want below:

>> So what happens with
>> c'1-{ s4 s\< s1 s\! } c4 c4 ?
>> 
>> Does the crescendo end far after the following quarter notes?
>
> No, my idea is that everything `longer' than the base not gets ignored
> (causing a warning).

Except when you think they should not cause a warning.

> I know that we are talking about syntactical sugar.

The association to cavities is hard to avoid...

> What Graham suggests can be always written with << ... >> constructs.
> However, I share his feeling that many people (including me) are quite
> uncomfortable with using parallel music for attaching a crescendo to a
> note.  Actually, for complicated situations, << ... >> is certainly
> more appropriate, but for simple cases I want a simpler notation.

But the notation is not actually simpler at all, and it abuses existing
constructs.  It is exactly the sort of thing that makes LilyPond
unsuitable as a reusable representation for music rather than a
write-only format that only humans and LilyPond itself can hope to
understand, if they are lucky.  It would not have a reasonable Scheme
representation as Music expressions.

I am working hard to get expressions like { s4 s\< s1 s\! } parseable
and recognizable without context, and obliterate the need to write - for
anything except accent shorthands.  This is pretty much unavoidable if
you want to get music functions and other expressions to behave
consistently and independently from how the results of calling them are
going to be used.

One intermediate result is that our Scheme tutorial these days says
something like


    2.8 Inline Scheme code
    ======================

    TODO: the example for this section is ill-chosen since
    F = -\tweak #'font-size #-3 -\flageolet
       (note the `-' marking it as a post event) will actually work fine
    for the stated purpose.  Until this section gets a rewrite, let's
    pretend we don't know.

       The main disadvantage of `\tweak' is its syntactical inflexibility.
    For example, the following produces a syntax error.

    F = \tweak #'font-size #-3 -\flageolet

    \relative c'' {
      c4^\F c4_\F
    }

    Using Scheme, this problem can be avoided.

And the initial TODO stating that the example is ill-chosen is _doubly_
inaccurate since indeed, not even "For example, the following produces a
syntax error" is true any more.  It just works as expected.  And I am
getting the code where even writing

c4\tweak #'font-size #-3 \flageolet

without any spurious - signs will work since the post-event property of
\flageolet will transparently pass through.  But to make things work in
that natural manner, I need a consistency between how expressions are
written and what they mean.

This sort of "let's throw a few existing elements into the blender and
let them mean something almost, but not quite, entirely different, when
combined in a particular manner" approach is absolute poison for being
able to create syntactic elements that can be reliably interpreted,
translated and combined with a straightforward relation between input,
meaningful content (which is required for MusicXML export, for example),
and output.

It will still take some time until I have the parser where it provides
the consistency and power I am striving for with all of the ultimately
unnecessary complexity driven out, and then it will be quite more
infeasible on a technical level to sabotage the existing framework
because it would be much more obvious what sort of things are a bad
match to then existing facilities and a cause for major usability
regressions.

And it will be much less stressful for me to be able to state "you can't
have that because it would break what we have, just try for yourselves"
rather than having to state "it is a bad idea to do that since it would
stop me from getting us where I see us wanting to go".

Yes, locking others away in a "fuzzy" discussion list and hoping that
they won't manage work out the details of something which they then will
want to see implemented might take away some of that stress.  And then
saying something like "uh, that is hard, I don't think it could be
done".  Which probably would be a lie since if you disregard priorities
and sanity, most things can be done.  The problem is that there is
always a price to pay, and in some cases the price is on the ability to
do work that is ultimately quite more important, and on the complexity
and maintainability of the results.

I don't really see that a more democratic process in such highly
involved technical matters can lead to acceptable results both on a
technical level as well as the feeling of active involvement.

I am still months away from the point where I can say "see how this all
falls into place nicely" and yes, at the current point of time it is
hard to get more people involved at non-crossroads purposes since much
of the work I do at the moment can be described as a gradual redesign
and so it does not make too much sense to teach others the current
situation as a starting point.

-- 
David Kastrup