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
Summary of \relative { q } ... analysis. (was: Plans for changing chord repeat implementations)
Ok, since I am about to doing another user interface change, I present a
summary of the proposed way of tackling it, and the reasons behind it.
There are basically three different approaches of how to make q work,
all with advantages and drawbacks.
1) do it in the parser, like the last duration of notes is maintained in
the parser. This is essentially what it done right now. At the current
point of time, a _reference_ to the last chord is kept. This is also
entered into the ChordRepeat event for the sake of relative.
Using the reference is _bad_ since any music function is allowed to
change its arguments, and the reference would change alongside.
However, this reference is _also_ used inside of \relative to make sure
that a chord repetition will have the same octave as its
already-converted preceding chord. This only works as long as no
construct creates a _copy_ of the music expression, in which case
\relative stops working.
So the reference has to go for two reasons: it is a bad idea to be
affected by arbitrary processing changes. And the one change that it
_needs_ to be affected from, that when using \relative, is not reliable.
The first problem means _copying_ the required data, in this case
basically the list of pitches. The second problem is not solvable
cleanly except if \relative reestablishes the chord/predecessor
relations since the input might have been arbitrarily juggled around
since q has been input. Creating a copied chord or a list of pitches
for every chord has a performance impact, and _if_ we are going to have
\relative redo the work anyway, this impact will not just be wasted in
case we were not actually using q after all, but also _when_ we were
using it, but inside of \relative.
2) do it in a specific music function either explicitly called, or
called automatically at an appropriate time.
This is totally straightforward and controllable. It also means that it
is ok to work with a reference to the previous chord since no arbitrary
processing stages (like in the parser) will intervene between taking the
reference and using it. It also means that we can _replace_ the
ChordRepeat event with an EventChord, meaning that any subsequent
processing never gets to see a chord repetition.
That means that legacy music functions of the user don't require
changes to accommodate chord repetitions: it is easy to make sure that
they never get to see them. After \relative seems to be a good time to
call \q automatically (one could be cute and call it \absolute instead,
meaning that a user wanting to use q should have had his music passed
through either \relative or \absolute).
3) do the chord repetition right before iteration time (iteration itself
is too time-centric rather than order-centric to work well). I think
that is too late since it means that \transpose and other stuff will not
get material to work with when they encounter q before their first
chord: the repeated chord will be expanded at a time where it won't be
transposed anymore. In a nutshell, we q should not be expanded _before_
\relative, but not _after_ \transpose either. So we could run it after
every \relative, and before every \transpose (and similar commands), and
at iteration time. And so on. Every time will have a performance
impact.
Strictly speaking, if we run at iteration time, we don't need to run
after \relative. Why \relative? Because that is a time and processing
order that people already are comfortable associating with input context
(in this case, relative pitch tracking).
I don't think we can get around either 2) or 3). Having q work without
asking even in absolute mode would require either option 1) (in a manner
that can be overriden by \relative later) or 3), and 1) needs to work on
explicitly created lists of pitches or chord copies, whereas 2) and 3)
don't need that.
Possibly I am just paranoid about the transpose problem: people can
likely accept that { c e g \transpose c d { q } } does not transpose.
And it is not like there is a place where inserting \q could make it
work.
So the question is: where should q be automatically called in order to
be relevant just before iteration? Something like
toplevel-music-handler? Does that catch everything?
Having an explicit function \q _available_ will be useful since it means
you can prevent user music functions from seeing ChordRepeat at all.
But _if_ there is a good point where one can call it reliably
automatically before iteration, we could save the necessity for calling
it explicitly for absolute music (and the necessity of putting a call
inside of \relative).
Suggestions?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Summary of \relative { q } ... analysis. (was: Plans for changing chord repeat implementations)
On 1/27/12 5:27 AM, David Kastrup d...@gnu.org wrote:
Possibly I am just paranoid about the transpose problem: people can
likely accept that { c e g \transpose c d { q } } does not transpose.
And it is not like there is a place where inserting \q could make it
work.
I totally accept that. In my mind, q is a copy of the chord output, not a
copy of the music input.
Suggestions?
As I've been watching this thread, the idea came to me that perhaps we
ought to do away with q and replace it with a naked duration.
As far as I can see, it is potentially problematic to support
{c e g a b q}
Because the chord to which q refers can be arbitrarily back in the music
stream.
Sane use of q would be
{c e g q q}
So what if a naked duration just meant to repeat the previous chord or
note, with the given duration, i.e.
{c4 d e 8 c e g8 4}
Would be equivalent to
{c4 d4 e4 e8 c e g8 c e g4}
Then one gets the ability to reuse a chord immediately (which is the usage
that Nicolas demonstrated) without having to save a pointer to the last
chord indefinitely.
It also makes the syntax work on both chords and non-chords, which seems
to me to be a reasonable design objective. It treats durations and
pitches in the input stream in an equivalent manner. It has the potential
downfall of making the input stream more confusing to read.
Another limitation of this is that it likely won't copy articulations,
etc. But \q could.
I don't know if this is feasible in the parser, but it seems like it ought
to be.
Just a thought for your consideration.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Plans for changing chord repeat implementations
Hi, the default chord repeat code contains stuff like ;; If previous-chord has an length property, then it means that it ;; has been processed by a music iterator. In other words, the chord ;; has been memorized from an other music block, which is certainly not ;; what the user has intended, as anywy the result will be buggy. ;; In that case, raise a warning. Ok, this is all sort of madness. Music functions are _free_ to change their arguments and quite a number of them do, not just \relative. It does not do to keep just a pointer to a chord since by the time one actually uses it, it can be trashed in a number of ways. Having a music iterator run over it is just one of many possibilities. Copying the whole chord just because it might get used is expensive and unnecessary. _If_ we try doing this in the parser (and I don't see a really good other place that is reasonably convenient for the user), we should not copy the chord, but just the list of pitches. After all, this is what the documentation of q as far as I can see _claims_ is copied. There is the added complication that a chord can contain more than just pitches: it is possible to have drum types instead. And of course anything sneaked in as rhythmic events via music functions. Of course, when running through \relative or a similarly applied music function that runs over a whole expression in one go would be able to work just with pointers. I have taken a look at the regtests and rest of LilyPond. The only cases where q is being used is either inside of \relative or explicitly for testing absolute mode. So I lean towards removing repeated chord tracking from the parser altogether. You would need to explicitly run a music function for doing the last chord substitutions. to_relative could be made to set a flag when encountering a repeated chord, so that \relative would automatically run the repeated chord substitutor at the end when it was required. That would mean _no_ problems with chords changing under the parser, _no_ need to extract pitches or other information just-in-case, no input syntax change when used simultanously with \relative, and no performance impact when the user does not actually use that feature. It would also reopen the door to extract more than just pitches. 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. Machine-generated output would rarely have to use q. -- 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
