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

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> On 26/09/2012 14:34, David Kastrup wrote:
>> David Kastrup <address@hidden> writes:
>>
>>> Werner LEMBERG <address@hidden> writes:
>>>
>>>>>> It would be tremendously helpful if you can show possible syntax
>>>>>> *alternatives* instead of just pretending to be a naysayer.
>>>>> I've posted actual working definitions for that purpose.
>>>> It seems I've missed that, lost in the many examples you've given to
>>>> demonstrate what doesn't work.
>>>>> They would definitely simplify the kind of entry you are asking for.
>>>> Please repeat.
>>> Sigh.
>>>
>>> at =
>>> #(define-music-function (parser location time event music)
>>>   (ly:duration? ly:music? ly:music?)
>>>   "Place @var{event} at a relative duration @var{time} in relation
>>> to @var{music}."
>>>   #{ << { \skip $time <>$event } $music >> #})
>>>
>>> {
>>>   \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 \!

here.

> In your example, what you want is note with "p", hairpin start, hairpin
> end. But what you have to write is hairpin start, hairpin end, note with
> "p".
>
> So, yes, such hacks as workarounds are certainly possible, but IMO they
> currently don't really fit well with the general concepts of the lilypond
> language (i.e. all dynamics are written using postfix notation)...

If you don't even bother to reply, how am I supposed to guess what your
problem with my approach is?

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

-- 
David Kastrup