lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Janek Warchoł
Subject: Re: Possible feature request for 'q' shorthand or tie syntax
Date: Fri, 21 Sep 2012 13:25:54 +0200

Hi all,

there's a lot of emails in this thread so i'll post a general reply.

First, i was puzzled myself that q only repeats chords.  I didn't know
that it was intentional (missed the discussion, sorry) and i was going
to suggest to change this behaviour myself.

I understand Marc's argument about "um-pah" accompaniment, and i no
longer think that the meaning of q should be changed.

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.

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

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 }

I was amazed myself when i wrote this example :)

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!

As for the idea of "translating c into <c> internally" (i know that
this description is probably imprecise/wrong), it seemed elegant
initially, but David's reply convinced me immediately.

As for "implied pitches" (ie.  c2 4 4 => c2 c4 c4) i'm with David: bad
results far outweigh typing benefits in my opinion.  Having no
whitespace between pitch and duration is a nice convention, but
David's music function example immediately convinced me that we want
the flexibility that allowing whitespace gives 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
- 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.

cheers,
Janek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]