[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: |
Mon, 24 Sep 2012 15:01:27 +0200 |
On Sun, Sep 23, 2012 at 2:03 PM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>>
>>> 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?
i think that would be counter-intuitive.
> What about lyrics mode? Is that worth deviating from the "only
> NoteEvent" rule? How much sense makes repeating a syllable?
It happens sometimes.
>> 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.
Now i'm *totally* puzzled. What do you mean by "programs"? Do you
mean that allowing standalone durations, like c2 d 4 4 => c2 d2 d4 d4,
wouldn't cause incompatibility with old scores?
Also, i remember you saying that allowing whitespace before duration
is needed for example in music functions:
makeAquarterNote = #(define-music-function (parser location note)
(ly:pitch?)
#{ $note 4 #})
How could this function be written if we allowed standalone durations
that repeat previous pitch?
> 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.
That would be nice indeed.
cheers,
Janek
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, David Kastrup, 2012/09/21
- Re: Possible feature request for 'q' shorthand or tie syntax, Janek Warchoł, 2012/09/23
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/23
- Re: Possible feature request for 'q' shorthand or tie syntax, Werner LEMBERG, 2012/09/23
- Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/23
Re: Possible feature request for 'q' shorthand or tie syntax,
Janek Warchoł <=
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
Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/23
Re: Possible feature request for 'q' shorthand or tie syntax, David Kastrup, 2012/09/23
Re: Possible feature request for 'q' shorthand or tie syntax, Stefan Thomas, 2012/09/20