Re: Summary of \relative { q } ... analysis.
David, you wrote Friday, January 27, 2012 2:01 PM
David Kastrup writes:
It would be possible to let q set a parser variable that will optimize
this pass away when unset. The drawback would be that ChordRepeat
events entering via different channels (#{ q #} uses its own
parser, and generation by Scheme is also possible) would not count
then.
Ok, I guess I have my implementation strategy then. Hard-earned 70€
or whatever the bounty was, but I think I will feel reasonably sure
that the results will not come back to bite me.
Anybody have a problem with me ripping all the configurable bits from
the lexer? Meaning that the chord repeat symbol will be q, period, like
r is a rest, period. Since I don't retain q state in the lexer any
more, it does not seem like that the effort for the remaining piece of
configurability makes any sense if nobody uses it anyway.
Reducing complexity in lexer/parser is always good. I like your
strategy.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Summary of \relative { q } ... analysis.
David Kastrup writes:
> It would be possible to let q set a parser variable that will optimize
> this pass away when unset. The drawback would be that ChordRepeat
> events entering via different channels (#{ q #} uses its own
> parser, and generation by Scheme is also possible) would not count
> then.
>
> Ok, I guess I have my implementation strategy then. Hard-earned 70€
> or whatever the bounty was, but I think I will feel reasonably sure
> that the results will not come back to bite me.
Anybody have a problem with me ripping all the configurable bits from
the lexer? Meaning that the chord repeat symbol will be q, period, like
r is a rest, period. Since I don't retain q state in the lexer any
more, it does not seem like that the effort for the remaining piece of
configurability makes any sense if nobody uses it anyway.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Summary of \relative { q } ... analysis.
David Kastrup writes:
> 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).
It would seem like the combination of an explicitly callable function
together with putting it into toplevel-music-functions (where things
like {xxx\\yyy} apparently are also resolved) should do the trick in a
suitably backward-compatible manner. I guess the performance impact of
another pass through the music, given suitable callbacks, should be
small.
It would be possible to let q set a parser variable that will optimize
this pass away when unset. The drawback would be that ChordRepeat
events entering via different channels (#{ q #} uses its own
parser, and generation by Scheme is also possible) would not count then.
Ok, I guess I have my implementation strategy then. Hard-earned 70€ or
whatever the bounty was, but I think I will feel reasonably sure that
the results will not come back to bite me.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Summary of \relative { q } ... analysis.
On 1/27/12 6:20 AM, "David Kastrup" wrote: > > >Let's not get there. Fine with me. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Summary of \relative { q } ... analysis.
Carl Sorensen writes:
> 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.
Same issues as with q regarding the lifetime of input, so this
suggestion is more or less orthogonal to the problems I discussed except
for picking option 1.
> 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 8 4}
>
> Would be equivalent to
>
> {c4 d4 e4 e8 8 4}
Spaces are not relevant in the parser (and since $x needs to get
separated from further input by a space, this is actually not just a
technicality). So the above input is already valid and equivalent to
{c4 d e8 8 4}
I think that this is a bit of a drawback... Now you might want to
change this into "naked durations _not_ possibly belonging to the
previous input element". In my opinion, we have more than enough
ambiguities in the LilyPond grammar already. I don't really like that.
> It also makes the syntax work on both chords and non-chords, which
> seems to me to be a reasonable design objective.
Uh, the previous discussion revolving around q has made quite explicit
that people don't _want_ that, and q was explicitly changed at one time
in order to not do it. It is common to have a fat chord (cumbersome to
enter) followed by a brief monophonic phrase of one or two notes, then
the same fat chord again. Involving non-chords does not actually save
typing (c or q is pretty much the same effort).
> 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.
For humans _and_ LilyPond.
Let's not get there.
--
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" wrote:
>
>
>Possibly I am just paranoid about the transpose problem: people can
>likely accept that { \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
{ a b q}
Because the chord to which q refers can be arbitrarily back in the music
stream.
Sane use of q would be
{ 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 8 4}
Would be equivalent to
{c4 d4 e4 e8 8 4}
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
