[Top][All Lists]
[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: |
Sun, 23 Sep 2012 10:34:56 +0200 |
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
- Re: Possible feature request for 'q' shorthand or tie syntax, (continued)
- Re: Possible feature request for 'q' shorthand or tie syntax, Jim Long, 2012/09/20
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/20
- Re: Possible feature request for 'q' shorthand or tie syntax, Jim Long, 2012/09/20
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/21
- Re: Possible feature request for 'q' shorthand or tie syntax, Werner LEMBERG, 2012/09/21
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/21
- Re: Possible feature request for 'q' shorthand or tie syntax, Francisco Vila, 2012/09/21
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/21
Re: Possible feature request for 'q' shorthand or tie syntax, Janek Warchoł, 2012/09/21
Re: Possible feature request for 'q' shorthand or tie syntax, Janek Warchoł, 2012/09/24
Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/24
Re: Possible feature request for 'q' shorthand or tie syntax, Janek Warchoł, 2012/09/24
Re: Possible feature request for 'q' shorthand or tie syntax, James, 2012/09/24
Re: Possible feature request for 'q' shorthand or tie syntax, Marc Hohl, 2012/09/23
Re: Possible feature request for 'q' shorthand or tie syntax, James, 2012/09/24
Re: Possible feature request for 'q' shorthand or tie syntax, Marc Hohl, 2012/09/23