Re: [GLISS] why the hell all this fuss

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Fri, Sep 7, 2012 at 9:42 AM, David Kastrup <address@hidden> wrote:
>> Janek Warchoł <address@hidden> writes:
>>
>>> On Thu, Sep 6, 2012 at 9:55 AM, David Kastrup <address@hidden> wrote:
>>>> I don't see why you should not be able to do this using music functions.
>>>
>>> Hmm.  You may be absolutely right.  Maybe all we need is to write such
>>> functions and ship them with LilyPond!
>>
>> at =
>> #(define-music-function (parser location t e m)
>>   (ly:duration? ly:event? ly:music?)
>>   #{ << #m { \skip $t <>$e } >> #})
>>
>> \new Voice {
>>   \at 1*1/3 \p
>>   \at 1*2/3 \<
>>   \at 1\!
>>   c'1
>> }
>
> Thanks!  This shows how much i have to learn - didn't think it would
> be so easy.
> However, i see two problems with this function, and i suppose they're
> not easy to fix within current framework:
> 1) it is "prefix".  I'm pretty sure that users will get confused as to
> why sometimes you write \p after a note, and sometimes before it.

The main reason is that it is _attached_ to the note, like accents are.
The attachment for dynamics is rather loose: basically it just plays at
the same time in the Voice.  This attachment is no longer valid when
time-shifting.  One could doubt the wisdom of turning commands like
dynamics into post events in the first place: things that make also
sense time-shifted might be conceptually better represented as
standalone events.

Coming back to your proposal: It would be possible to create an empty
post-event wrapper that can actually contain timed music, thus writing
something like

\new Voice {
  c'1
  \at 1*1/3 \p
  \at 1*2/3 \<
  \at 1\!
}

and have \at as an event function.  I doubt we would be doing people a
favor, though.  It turns out that \at can actually time-shift arbitrary
music if you just replace the ly:event? tag with ly:music?  (postevents
are just one particular case of music, and not treated specially as a
command line argument).  This makes sense in a number of cases but would
really get strained if you had to do it in postevent syntax.  In
particular if you don't want to attach it just to a single note but
rather a sequence, which would make sense for dynamics.

> (of course if you understand what the function actually does,
> everything becomes clear - but i think it's important to have syntax
> that looks consistent and intuitive without reading function
> definitions (is the word "transparency" appropriate here?))

The problem is to avoid syntax that reads a bit more "intuitive" for
some use cases and gets totally intractable for others.

>>>>> My rough idea would look something like this
>>>>> (this is just a musing, not a proposal for discussion yet):
>>>>>
>>>>> { b2 \<@0.5 a2 address@hidden } meaning { << b1 { s2 \< s2 \! } >> }
>>>>
>>>> Looks like a case of the cure being worse than the problem.  Apart from
>>>> not being related in any obvious manner.
>>>
>>> I'm not sure i understand what you had in mind.
>>
>> I wanted to express that I'm not sure I understand what you had in
>> mind.  I can't figure out how your proposed syntax is going to mean what
>> you state it would.  Durations are different, there is a different
>> number of notes...
>
> ooops!  That's embarassing!  I've mixed two different examples from my vault.
> I intended to write this:
>   { b2 \<@0.5 a2 address@hidden } meaning { << { b2 a2 } {  s4 s2 \< s4 \! } 
> >> }
> (i don't insist on having decimal numbers.  It's just that the idea
> was not to specify a delay duration, but a percent of the "parent"
> note duration, and decimal numbers look better for this)

Decimal numbers are "inexact".  With computers, you'll find that 0.5 and
0.5 will likely add up to result in 1.0, but you'll be lucky if 0.4 and
0.6 add up to 1.0.  For music, the concept of simultaneousness is
sometimes important: if a dynamic change happens one microsecond after
the attack of a note, it is too late to affect the attack itself.  This
will significantly change the MIDI and, if done judiciously, also the
print (where losing the direct attachment to a note may cause quite
different alignments).

-- 
David Kastrup