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

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> However, the idea of creating another shortcut (p seems to be a good
> name) appeals to me.  I would design p to repeat chords as well as
> pitches.

When writing <c e> c q p, what does p repeat and why?  How will it be
represented in music lists so that the usual manipulations of music
lists will not get confused?

We had a few confusions with q (represented as an event-chord with a
duration).  What will p be for pitches?  A NoteEvent without pitch?

> As for the "pitch names aren't that long" argument, i say that: - for
> me 3 letters is long enough to warrant a shortcut, especially because
> these letters tend to be spread all over the keyboard (e.g.  gis).

That's not even a readability problem (which was argued for chords), it
is an entry problem.  As such it is better solved by the editor than by
anything else.

> Also, "full english" names are much longer (fsharp) - it seems to me
> that a shortcut will allow greater flexibility, both with manual
> source manipulation as well as music functions.

There is no point in not using the short English names in note entry.
The full names don't make sense for much more than key declarations, if
at all.

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

> I was amazed myself when i wrote this example :)

It would not have worked before my reimplementation.

> As for "you can enclose single pitch in <>" argument, i say that this
> is a nice hack, but it still looks like a hack.  From a user
> perspective (i'm speaking in my own name here), writing <a> looks like
> "huh?".  Also, it's additional 2 characters to type, both with shift!

But you were out to save _so_ many awful characters in typing, surely
those two characters would pale in comparison?  Are we trying to beat
APL in input compression?

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

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.

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

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

-- 
David Kastrup