Re: Possible feature request for 'q' shorthand or tie syntax

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Thu, Sep 20, 2012 at 07:45:41PM +0200, Nicolas Sceaux wrote:
>> 
>> Le 20 sept. 2012 à 19:21, Graham Percival a écrit :
>> 
>> >> A single note name is not that much longer to type than q.  If it is
>> >> really important to you, place the single note in a chord:
>> >> <des> is perfectly repeatable by q.
>> > 
>> > What would we lose if every note was automatically a (single-note)
>> > chord?
>> 
>> That behavior is intended, so that you can write:
>> 
>>   c <e g c'> g q c q g q
>> 
>> And the idea, if you wanted to repeat the previous single note, is
>> to enclose it between < >.
>> q repeats the last chord, not the last note.  That's why it's named
>> chord repetition symbol.
>
> I thought the behaviour was intended to simplify things like
>   <c e g>4 q q q
>
> I'm particularly asking about making every note into a chord
> because that would make David's favorite <> construct a *lot* more
> consistent.

Uh no, it wouldn't.  <> is not nothing, it is a chord.  It _is_
inconsistent in that it is not included in chord repetitions, but the
reason for that is not to mess up the calculation of durations: q4
counts as a quarter note, and if it were to stand in for <>, its
duration would change upon expansion.

The most important reason _not_ to make every note into a chord is that
if you make every note into a chord, <c e g> become <<c> <e> <g>>.  Now
you can make a special exception that inside of chords, notes are not
made into a chord, but where does that leave you if you use music
functions or variables for generating content _inside_ of chords?  Do
you want to prohibit that?  How would you then use \tweak inside of a
chord?

In 2.14, only the last argument of a function could actually be music:
it was parsed differently than the other arguments.  In a post-event,
the last argument was a post-event.  In a chord, the last element was a
chord constituent (and could not be a variable or anything other than a
directly entered note).  This severely limited the usefulness of music
functions, and music functions behaved differently in different
contexts, and their arguments were provided differently in different
contexts.  Please read the "Changes" section of 2.16 for more details.

> At the moment, we have no note at a time unit: <> single note at a
> time unit: c'4 multiple notes at a time unit: <c e g>4
>
> If c'4 was actually a shortcut for <c'>4, then we could have a
> consistent notion that every time unit in every voice is a chord;
> that chord may contain 0, 1, or many notes.

That was the state before issue 2240.  Check that issue and "Changes"
for the reasons for _changing_ it.  There was quite the discussion on
the mailing list as well.

One could most certainly make q apply to notes as well as chords, and
indeed that was what the _first_ implementation of q actually did if you
bother to check.  This was changed after quite a bit of discussion,
again because users discussed priorities and agreed on this course of
action.  There was a discussion about _that_ as well, and a consensus,
along with a history of several versions of the original patch.

-- 
David Kastrup