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

[Janek Warchoł]

On Fri, Sep 21, 2012 at 3:37 PM, David Kastrup <address@hidden> wrote:
> 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?

i'd say that it should repeat <c e>, because "p repeats last notelike
thing, and in this case it's actually q, so { <c e> c q p } => { <c e>
c q q } => { <c e> c <c e> <c e> }". But see below.

> How will it be
> represented in music lists so that the usual manipulations of music
> lists will not get confused?

I don't know.  But if one of the answers to your question above is
easier to handle, let's choose it and "call this a feature".

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

I have no idea what would work best.  I say we just choose the most
reasonable implementation and "call its result a feature".
Or maybe you mean that there is no reasonable implementation?

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

hmm. maybe.

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

maybe.

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

>> 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?
so, thank you! :)

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

<tongue-in-cheek> why not?  </tongue-in-cheek>
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.

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

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

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

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

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

cheers,
Janek