Changing to [talk] tag as the discussion is more at a "floating ideas"
level now.
Graham Percival <gra...@percival-music.ca> writes:
> On Wed, Sep 26, 2012 at 03:44:27PM +0200, David Kastrup wrote:
>> Reinhold Kainhofer <reinh...@kainhofer.com> writes:
>>
>> >>> {
>> >>> \at 4 \<
>> >>> \at 1*2/3 \!
>> >>> c'1\p
>> >>> }
>> >> [12 days later, and no followup again]
>> >>
>> >> Let's just continue pretending me to be a naysayer then.
>> >
>> > You demonstrated that a solution is possible, but quite inconsistent with
>> > the lilypond language: You have to write the dynamic BEFORE the note,
>> > although it should be printed AFTER the note...
>>
>> It is conceivable to cook up stuff that would allow to write something
>> like
>>
>> c'1\p-\at 4 \< -\at 1*2/3 \!
>
> Really? Wow, I wish you had replied with this when I wrote "
> Now, if a music function can apply to the
> current note, i.e.
> c1-\at{ s4 s s\f s }
> then I'd be much happier." on 2012 Sep 13:
> http://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg00597.html
Well, this was a half-written part unfortunately. What is missing is
"but I consider this an excessively bad idea".
I apologize for that. The reason I consider this an excessively bad
idea is that this would turn an "articulation" into something that
creates independent music events at an independent point of time.
That would mean that the rhythmic event iterator as well as the event
chord iterator would need to contain the full complexity of the
simultaneous music iterator.
It would also turn a "post-event" into something which only sometimes
and more by accident has a relation to the preceding event.
For example, if you use \at to delay a slur or accent to a later point
of time, and this later point of time actually has a noteevent in the
current context, the slur or accent would attach itself to the unrelated
noteevent. If you do this using explicit parallel music, the effect is
somewhat predictable to the user and can be thought of as intentional.
But as a post-event on some other note? The normal expectation would
be, I think, that it still anchors to the original note, just with an X
offset based on timing (incidentally, being able to specify horizontal
offsets in terms of timing rather than staff spaces _does_ sound like
something that could be interesting, even though it is not likely going
to transfer well to Midi).
So again, I apologize for that half-written sloppy reply, as it fails to
convene the "this is definitely the wrong way to take" meaning I
intended to express, and the explanation is also missing.
>> If you don't even bother to reply, how am I supposed to guess what
>> your problem with my approach is?
>
> Evidently Reinhold isn't the only person who doesn't "even bother
> to reply".
In this particular case, it has been actually Werner who did not reply
after asking again. I confused the two after Reinhold jumped in with a
vigorous retort.
>> In my opinion, dynamics are one case where using postfix syntax was a
>> mistake, exactly because they are not inherently associated with a
>> particular note but rather a moment of time.
>
> Are you speaking of the implementation or the music? I consider
> dynamics to be associated with moments of time within a voice.
So do I. The post-event syntax does not really do justice to this
association.
>> It is _that_ choice which
>> does not really fit well with the general concepts of the LilyPond
>> language, and in consequence dynamics are the _dominant_ example for use
>> of <> and/or s1*0. So my preferred path to a remedy would rather be to
>> un-postevent stuff that does not really fit the postevent category
>> rather than to mess with the timing relations of postevents.
>
> Hmm. Something like this:
> \p \accent( c4 \legato fis8. \f )d16
> ?
> (additional spaces added to demonstrate which commands go with
> which notes)
The \accent is pertaining to the note as such, so unless we are going
for abolishing _all_ postevents (which would simplify the logic but at a
cost of awkwardness I think too much), I'd leave it where it is. Slurs
are somewhat ambiguous beasts: in LilyPond, they are firmly connected to
moments of time rather than individual notes, but that's not necessarily
obvious.
On the user list (I think), there was an interesting proposal: to leave
( as a postevent, but make ) a standalone event. That would turn the
above into
\p c4 \accent ( \legato fis8. \f ) d16
assuming that I got all relations of your above example right. You can
switch the order of \accent and (, and the order of \f and ) if you
want, then.
If we take a look at where '<>' is used in our documentation, we have
<>^\markup ...
which should rather be a non-postevent per-Staff mark placing command
(we don't have something like that right now I think).
<> )
which would become unnecessary if ) were turned into a standalone event
<>-. (used without need in a contrived example for demonstration, so
does not really count)
<< \music <>-. >> (ugh, mostly contrived in the Scheme tutorial).
And a few other slur-related things where admittedly having to use <>(
while being able to just write ) is not exactly an aid in consistency.
At any rate, it is somewhat arguable that a slur needs an "anchor" to
attach to logically. I don't really see that with dynamics, and usually
\! is used in the meaning "at the end of the preceding note" rather than
"at the beginning of this note", so quite a few of the uses are
syntactically awkward and need attaching to an actually unrelated note,
at worst, one occuring in a different musical phrase.
At any rate, the discussion of \at and stuff working as postevent more
or less focuses on "I want to specify a delay after the _onset_ of the
_preceding_ note", so that the events are spelled out in somewhat
time-linear order. If you have to specify delayed events first, the
order is not given, and if you write as a non-postevent afterwards,
you'd have to go backwards in time to move before the _end_ of the
preceding element.
There is a construct "count time from the _beginning_ of the preceding
note in the text":
<< c1 ... >>
but that required going backwards and inserting <<, so it is not really
popular.
"preceding note" is a rather fuzzy context when the preceding note is
not actually a note, so I don't really want to arbitrarily extend the
reign of postevents to cater for everything of that nature and then
some. An explicit << is cumbersome to write, but at least it is quite
unambiguous. Various wrappers are possible (I showed "\at" and
"\after"), but the linearity-destroying \at seems to me to offer the
best compromise in readability so far, at least when one needs to stack
several delays. There might still be some variant of argument order for
"\after" I overlooked, but the basic point is that when more complex
constructs are involved, it makes sense explicitly marking the reference
point with << or \at or \after or whatever instead of relying on
postevents which don't work on everything and are not intended to do so.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
