Re: [GLISS] differentiating pre/post/neutral commands

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

>> But things like ( ) \( \) [ ] \p \< \! \> all happen at a moment in
>> time in a voice.  Why is a tempo change a separate event, but a
>> dynamic change isn't?
>
> Specifically, I think it is because the tempo logically is an
> interpretation property, and may have been just a \set property in
> some earlier version.

Tempo/clef are also more staff-like and ( ) is more voice-like.

> I'm not sure though.

The main question for me is not what makes sense in the context of how
LilyPond executes things but rather in the context how one inputs
things.

>> Another argument against it would be that all of the above constructs
>> can benefit from a direction: ^[ is different from _[, and ^\p
>> different from _p.  Should the direction modifier be tied to the
>> occurence of post-events?  Valid question.
>>
>> And one valid answer certainly would be "this ship has sailed".  But
>> that argument would hold equally for the invasive changes introducing
>> new syntactic differentiations.
>
> I'd say this ship has sailed, but I've been saying so all along.

Sure, for the new ships as well.

> I'd strongly recommend implementing this and copying a few pages of
> music before making any decisions.

Definitely, and then some.

> The everything postfix decision was made after I had to copy music,
> and realized how jarring it was to have to remember what goes where
> when copying music; I fear that your proposal will require remembering
> more details.

It will have to wait a bit more.  I am currently in the process of
reworking the parser in terms of changing where "the post-event nature"
is located.

In 2.14, it was more or less "Everything that is not an EventChord" for
identifiers, and the parser put an EventChord around everything without
post-event nature, and all music identifiers initialized via Lisp took
an EventChord.

Nowadays, it is "everything that has the post-event type" for
identifiers and parser and Scheme expressions don't need any special
wrappers.  But the syntax still differentiates various kinds of music
syntacticelly rather than by looking at the post-event type.  This poses
a nuisance for polymorphic music functions like \tweak which you need to
write with or without - depending on usage, unless you assign to a
variable, in which case this will be recognized automatically.

I want this gone.  Basically, music expressions should be accumulated
and postevents get attached by virtue of coming next in sequence after a
rhythmic event or eventchord.  Regardless of _how_ they have been
produced.

If I can get there, the post-event nature is no longer implied in the
syntax, ^ and _ could be used for attaching direction to non-post-events
as well.  If I get the parser in this state, syntax experiments become a
matter of playing with the post-event type in scm/define-music-types.scm
without needing to meddle with the parser.

That's the stage I want to reach first before actually doing the syntax
experiments because then the experiments become cheap.  Apart from
having to cater for display-lily-music, of course.  But even that could
likely be made to just put out things in linear order without thinking.

-- 
David Kastrup