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

[David Kastrup]

Janek Warchoł <address@hidden> writes:

>>> An example which shows that when you have shortcuts you don't even
>>> need functions for automated manipulation:
>>>
>>> bong = { q16 q q q q16 q8. }
>>> { <c' e' g'>2 \bong  <c' f' a'>2 \bong  <d' g' b'>2 \bong }
>>
>> But bong does not include the original chord of the sequence.
>
> Is it bad that it doesn't?
> This is actually nice in my opinion.

It means that bong is not rhythmically/thematically complete.  So it is
more like "etc" than "phrase" in its meaning.

>>> I was amazed myself when i wrote this example :)
>>
>> It would not have worked before my reimplementation.
>
> well... doesn't it mean that your reimplementation was good?

More like that the underlying mechanisms chosen in the reimplementation
lead to semantics that make enough sense to people that they _try_
whether they work, even if they are amazed that they do.

> i'd say it's a matter of lookahead.  If i have to write <cis> instead
> of cis to use the repetition, it means that *every time* i have to
> look ahead to see if it's worth it.  If i don't need <>, i can just
> use repetition whenever i want, without additional planning.

Guess how much typing you would have been able to save just now when
being able to write "q" for each "to" in that paragraph.  Typing is
fast.  I think we need a more compelling reason.

>>> As for "implied pitches" (ie.  c2 4 4 => c2 c4 c4) i'm with David: bad
>>> results far outweigh typing benefits in my opinion.
>>
>> Well, it could be made to work by letting spurious durations create
>> NoteEvent without a pitch (ergo nothing going wrong with \relative), and
>> have a final pass duplicate pitches, like done with repeat chords.  One
>> advantage would be that you could specify rhythms as { 4 4 4. 8 }, for
>> example.
>
> so we wouldn't have to use 's' or some placeholder notes to write
> rhythms for http://lsr.dsi.unimi.it/LSR/Item?id=654 and things like
> that?  that would be nice!

It certainly would figure in the category "more compelling reason" for
me.

>> For something like RhythmicStaff where pitches get squashed anyway,
>> it might come in handy.  It would _not_, however, repeat chords,
>> since you can't magically change a NoteEvent to an EventChord without
>> changing the whole structure.
>
> pity.

We have q to repeat chords, and for matching constructs to rhythms, one
would employ more complex code anyway.  Even while one restricts oneself
to "single note with last pitch", one would still have to decide about
"last pitch".  Consider chords at all?  If so, pick their first pitch as
reference?

What about lyrics mode?  Is that worth deviating from the "only
NoteEvent" rule?  How much sense makes repeating a syllable?

>> I definitely don't like the ambiguity for function argument parsing
>> if 4 can not just signify an unsigned number and a duration, but also
>> a music argument on its own.
>>
>> The worst consequence most likely would be that if _now_ people
>> confuse the order of pitch, duration, and other stuff, they usually
>> get a syntax error.  After this change, they would get additional
>> notes interspersed instead.  We would be losing a lot of redundancy
>> in input, and that would likely cause a _lot_ of surprises.
>
> good point.  So, i still think that we shouldn't allow "c2 4 4"
> despite some really nice benefits it could bring us.

Well, it won't affect previously valid programs.  And it would have some
nice side effects, including
c4~ | 1~ | 2.
with or without bar checks or spaces, and reasonably straightforward
underpinnings and semantics.

>>> As for "ties with durations", this seemed interesting initially, but:
>>> - if i understood David correctly, the type of the tie syntax element
>>> cannot have durations
>>
>> Nope.  The problem with that is that a tie becomes an event that is a
>> property of the _previous_ note, and even if we found a way to tell the
>> tie a duration, it would have nowhere to go with it.
>
> Well, that's more or less what i meant :P

See above.  c4~1~2. would work without any special tie or space
semantics, given that particular syntax extension.

The problem is that so would c2 c'~4 and people might be confused that
it will be equivalent to c2 c'2 ~ c'4 (this interjection before the
following period intentionally left blank).

It will be harder to trace to the respective input location than an
error message would.

In short, there are a number of side effects to consider.  There are,
however, also a number of benefits.  A natural manner of expression for
rhythms as such (not just in the syntax of the \tempo command...)
without the need of yet another lexer mode certainly has independent
appeal, whether or not filling in note values with a final pass like q
does.

>>> - if it would be possible to change tie "syntax" so that it could have
>>> a duration, i'd prefer it to mean something different.  See another
>>> thread.
>>
>> I prefer avoiding too many strange and different meanings.
>
> Sure, as long as there is another concise way of expressing something.

If you want to clobber the meaning of ties, I consider it reasonable to
make them redefinable in a user document, so that you can write

"~"=
#(define-event-function (...))

and bear with the consequences of the changed meaning.  At the current
point, the syntactic class of most one-letter postevents is hardwired,
and where you can change them, you need to do so using some artificial
name.  This can probably just be normalized to the straightforward names
in most cases (where there is no conflict with Scheme identifiers like +
or - or so).  That things like "(" are not accessible symbols from the
Scheme reader does not preclude us from using them as module variable
names.

-- 
David Kastrup