Re: Plans for changing chord repeat implementations
David, On 29 January 2012 02:26, David Kastrup d...@gnu.org wrote: Nicolas Sceaux nicolas.sce...@gmail.com writes: Le 26 janv. 2012 à 11:00, David Kastrup a écrit : The bad news is that absolute pitch friends would have to call the \q function (any better name for it?) explicitly. Since q is an input convenience, and relative pitch is also an input convenience, I don't think that there would be much of an affected user base. I do use absolute pitch mode, together with the q shortcut, so the affected user base is non-nil. URL:http://codereview.appspot.com/5595043 What would be the impact of your solution on this kind of code? Is it just about adding e.g. \q before the block? The user impact is now down to nil. There is no longer any relation of the implementation to \relative. Since you don't need to call it manually except for special considerations (like letting it retain articulations in some passage), \q is now called \chordRepeats. I don't think that there are nightmarish corners in the implementation and behavior any more. So we need to make any tweaks to the NR since ...There is no longer any relation of the implementation to \relative... http://lilypond.org/doc/v2.14/Documentation/notation/single-voice#chord-repetition an @warning or @knownissue? Regards -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
James pkx1...@gmail.com writes: So we need to make any tweaks to the NR since ...There is no longer any relation of the implementation to \relative... http://lilypond.org/doc/v2.14/Documentation/notation/single-voice#chord-repetition an @warning or @knownissue? It is more like removing warnings or knownissues for existing uses. But new uses are worth some more explanation. I'm currently on it. I'm pretty almost everybody should prefer the new behavior, not just because it does no longer mess with the parser/lexer and/or backend and/or fall apart when copying \relative passages, but because it is much more flexible and predictable to use (you can already see in the changed regtest an application that has not been possible previously: fingering repetition only in tabulature, while not removing the initial fingering spec in the main score). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
Nicolas Sceaux nicolas.sce...@gmail.com writes: Le 26 janv. 2012 à 11:00, David Kastrup a écrit : The bad news is that absolute pitch friends would have to call the \q function (any better name for it?) explicitly. Since q is an input convenience, and relative pitch is also an input convenience, I don't think that there would be much of an affected user base. I do use absolute pitch mode, together with the q shortcut, so the affected user base is non-nil. URL:http://codereview.appspot.com/5595043 What would be the impact of your solution on this kind of code? Is it just about adding e.g. \q before the block? The user impact is now down to nil. There is no longer any relation of the implementation to \relative. Since you don't need to call it manually except for special considerations (like letting it retain articulations in some passage), \q is now called \chordRepeats. I don't think that there are nightmarish corners in the implementation and behavior any more. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
Le 26 janv. 2012 à 11:00, David Kastrup a écrit :
The bad news is that absolute pitch friends would have to call the \q
function (any better name for it?) explicitly. Since q is an input
convenience, and relative pitch is also an input convenience, I don't
think that there would be much of an affected user base.
I do use absolute pitch mode, together with the q shortcut, so the
affected user base is non-nil. \relative is to save characters, but `q'
is more than that, it also improves to maintain and read code, so it's
not surprising to see absolute mode and `q' together. Here is a real
word example copied from my code base:
{
R2. |
sol' do'' mi''8-pincé q q q q q |
q q q q q q |
q sol re' si' fa'' q q sol re' re'' si'' q |
q sol re' si' fa'' q q sol re' re'' si'' q |
q4 r2 |
r8 sol re' si' fa'' q q q q |
sol' do'' mi''8 q q q sol re' do''4 sol fa' si' |
sol mi' do''4 r2 |
sol' do'' mi''8 q q q q q |
q q q q q q |
r2 la' mi''4 |
fa' mi''8 q q q q q |
q q q q r4 |
}
What would be the impact of your solution on this kind of code?
Is it just about adding e.g. \q before the block?
Nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Plans for changing chord repeat implementations
Nicolas Sceaux nicolas.sce...@gmail.com writes: Le 26 janv. 2012 à 11:00, David Kastrup a écrit : The bad news is that absolute pitch friends would have to call the \q function (any better name for it?) explicitly. Since q is an input convenience, and relative pitch is also an input convenience, I don't think that there would be much of an affected user base. What would be the impact of your solution on this kind of code? Is it just about adding e.g. \q before the block? Yes, that would be all. Otherwise you would get an error message telling you to do so once q hits the iterators (the sole purpose of its iterator would be to create that error; \q/\relative would replace all traces of q with the final chord so that one would no longer see the history). I am not particularly happy about that, but a) \relative needs its own sequencing, so if we sequence in the parser, we have two competing ways of creating sequences. b) sequencing in the parser needs to either do a lot of copying just-in-case, or face breakage when music functions and iterators and other stuff modify music (which they are permitted to do). c) sequencing automatically at the last possible moment (when iterating) differs even more with sequencing in \relative mode, and has its own set of surprises. As you can see mentioned in the hand-waving comments already (and the bug I want to fix is just the tip of the iceberg), this is all rather shaky. Making the sequencing explicit (and relative as a user-made sequencing point seems like one reasonable spot where doing this automatically seems to make good sense to me, while I don't see a similarly obvious place when \relative is _not_ being used) makes the feature and its implications and side-effects straightforward. Right after \relative is a good time. I don't see anything equally convincing in absolute music, in particular that one must _not_ apply \q _before_ \relative, and one usually does not know in advance whether music is going to pass through \relative yet. And if you delay completely to iteration time, it will not just show identical chords when using \relative, but also across using \transpose and similar. Which also seems awkward. Maybe I am picking the wrong balance point for awkwardness here. No idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
