Isolated durations in music sequences now stand for unpitched notes

Isolated durations in music sequences now stand for unpitched notes

This allows for things like

\new RhythmicStaff { 4 4. 8 4 | 4 \tuplet 3/2 { 2 4 } 4 }

"unpitched" simply means that this is rendered as a normal NoteEvent,
but the pitch information is missing and has to be filled in by some
other means (RhythmicStaff is an exception since it ignores specified
pitches anyway).


Contains commits:


    Run scripts/auxiliar/makelsr.py


    Give examples of \RhythmicStaff without explicit pitches


    Regtest for rhythmic sequences.


    Let \displayLilyMusic deal with pure rhythms


    Pitchless durations inherit previous pitch when scorifying
    
    This turns { c4 4 4 4 } into { c4 c4 c4 c4 } and
    \drummode { tamb4 4 4 4 } into \drummode { tamb4 tamb4 tamb4 tamb4 }.


    Isolated durations in music sequences now stand for unpitched notes
    
    This allows for things like
    
    \new RhythmicStaff { 4 4. 8 4 | 4 \tuplet 3/2 { 2 4 } 4 }
    
    "unpitched" simply means that this is rendered as a normal NoteEvent,
    but the pitch information is missing and has to be filled in by some
    other means (RhythmicStaff is an exception since it ignores specified
    pitches anyway).


    Interpret #{ -3 #} as postevent rather than negative number
    
    Since #{ 4 #} is interpreted as duration rather than number, interpreting
    negative integers as numbers rather than fingering is not really helpful.


    Use #{ 4 #} and #{ c #} for duration/pitch in optional-args regtest


    Let #{ 4 #} be a duration while #{ 4 \cm #} stays a length
    
    An UNSIGNED not followed by a NUMERIC_IDENTIFIER inside of #{ ... #}
    is interpreted as a duration rather than a number.  Also, inside
    of #{ ... #} no "numeric expressions" using binary operators +-*/ are
    interpreted.
    
    The behavior of (signed and unsigned) integers and numeric expressions
    in assignments and as function arguments rather than inside
    of #{ ... #} is not affected.

[dak, 2013-11-08 17:52:59]

Be more thorough.  A bit of enthusiasm for this one, please.

[dak, 2013-11-09 14:48:44]

A bit more documentation

[Trevor Daniels, 2013-11-09 17:12:51]

I like this.  Maybe we ought also to make a
small change to the LM.  One possible place
is where ties are introduced
http://www.lilypond.org/doc/v2.17/Documentation/learning/ties-and-slurs
As the LM does not mention drummode that's
probably all that is required.

https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy
File lily/parser.yy (right):

https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy#newcode649
lily/parser.yy:649: | FRACTION
I don't like the mixed tabs and spaces here

[benko.pal, 2013-11-09 18:46:29]

https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm
File scm/music-functions.scm (right):

https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm#ne...
scm/music-functions.scm:780: ;;; that don't interpret them is harmless.
does that mean that

<c e>2. 4.

is turned into

<c e>2. e4.

?  while I actually like not copying articulation, not copying chords make the
new feature (which I'm enthusiastic about) a bit less useful, e.g. writing tied
chords as

<c e>2. ~ 4.

would really be neat, making it more similar to the shorthand when duration is
omitted.

[dak, 2013-11-09 18:51:38]

https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy
File lily/parser.yy (right):

https://codereview.appspot.com/22120043/diff/40001/lily/parser.yy#newcode649
lily/parser.yy:649: | FRACTION
On 2013/11/09 17:12:52, Trevor Daniels wrote:
> I don't like the mixed tabs and spaces here

There are no mixed tabs and spaces in the patch or its immediate context.  A few
lines later there is a spaces-only line, probably introduced during a time where
LilyPond globally configured spaces-only mode for Emacs and this file did not
yet contain a use-tabs override (as the Bison file is indented in a tabs-style
mode customary for such files).

I don't think it is a good idea to reformat unrelated stuff in this patch.

[dak, 2013-11-09 19:05:29]

https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm
File scm/music-functions.scm (right):

https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm#ne...
scm/music-functions.scm:780: ;;; that don't interpret them is harmless.
On 2013/11/09 18:46:30, benko.pal wrote:
> does that mean that
> 
> <c e>2. 4.
> 
> is turned into
> 
> <c e>2. e4.
> 
> ?

No.  It means that

f1 <c e>2. 4.

is turned into

f1 <c e>2. f4.

> while I actually like not copying articulation, not copying chords make the
> new feature (which I'm enthusiastic about) a bit less useful, e.g. writing
tied
> chords as
> 
> <c e>2. ~ 4.
> 
> would really be neat, making it more similar to the shorthand when duration is
> omitted.

You need to use q here.  Sorry, but it would not do to turn

<< \new Staff { <c e>4 }
   \new RhythmicStaff { 4 4 4 4 }
>>

into

<< \new Staff { <c e>4 }
   \new RhythmicStaff { <c e>4 <c e>4 <c e>4 <c e>4 }
>>

since then every note stem in RhythmicStaff would have two heads.  The
main feature is being able to write naked rhythms.  In the contexts
where they are of interest, it should be no problem if they inherit an
arbitrary pitch, but they can't magically turn into chords.

Yes, that makes the "shorthand" aspect less nice than the "pure
rhythm" aspect.  But the latter is something that LilyPond has some
need of, and where the former is really wanted, one could write an
explicit control sequence for doing the rewriting.

It would also be possible to _never_ repeat pitches automatically (so
that you always need some macro for doing that kind of rewrite), but I
see no particular advantage for that.

[janek, 2013-11-10 11:48:13]

Awesome!!

could you push it in a branch, so that I could read the commits in sequence?

On 2013/11/09 19:05:29, dak wrote:
> You need to use q here.  Sorry, but it would not do to turn
> 
> << \new Staff { <c e>4 }
>    \new RhythmicStaff { 4 4 4 4 }
> >>
> 
> into
> 
> << \new Staff { <c e>4 }
>    \new RhythmicStaff { <c e>4 <c e>4 <c e>4 <c e>4 }
> >>
> 
> since then every note stem in RhythmicStaff would have two heads.  The
> main feature is being able to write naked rhythms.  In the contexts
> where they are of interest, it should be no problem if they inherit an
> arbitrary pitch, but they can't magically turn into chords.

Good point.
However, what about restricting the "pitch inheritance" to the current context,
or the current music expression (code block inside {} )?  I.e. in

  \new Staff { <c e>4 4 4 4 }

the pitches would be inherited, while in

<<
  \new Staff { <c e>4 }
  \new RhythmicStaff { 4 4 4 4 }
>>

they won't, because LilyPond wouldn't look back further than the beginning of
current context/expression.  Do you think that would be doable?

best,
Janek

[ckenneth721, 2013-11-10 12:04:57]

On 2013/11/10 11:59:58, ckenneth721 wrote:

Hey

[dak, 2013-11-10 12:11:09]

On 2013/11/10 11:48:13, janek wrote:
> Awesome!!
> 
> could you push it in a branch, so that I could read the commits in sequence?

dev/issue3648

> On 2013/11/09 19:05:29, dak wrote:
> > You need to use q here.  Sorry, but it would not do to turn
> > 
> > << \new Staff { <c e>4 }
> >    \new RhythmicStaff { 4 4 4 4 }
> > >>
> > 
> > into
> > 
> > << \new Staff { <c e>4 }
> >    \new RhythmicStaff { <c e>4 <c e>4 <c e>4 <c e>4 }
> > >>
> > 
> > since then every note stem in RhythmicStaff would have two heads.  The
> > main feature is being able to write naked rhythms.  In the contexts
> > where they are of interest, it should be no problem if they inherit an
> > arbitrary pitch, but they can't magically turn into chords.
> 
> Good point.
> However, what about restricting the "pitch inheritance" to the
> current context,

Like q, expansion is done while scorifying.  There are no contexts at
that time.  Doing it in the parser (like durations are, and which q
once was) would cause a bloody mess with \relative (which it did with
q).  Doing it, say, at iteration, namely _yet_ _another_ time would be
quite a nuisance and it would not be clear just which iterator would
be responsible for keeping state.

> or the current music expression (code block inside {} )?  I.e. in
> 
>   \new Staff { <c e>4 4 4 4 }
> 
> the pitches would be inherited, while in
> 
> <<
>   \new Staff { <c e>4 }
>   \new RhythmicStaff { 4 4 4 4 }
> >>

And with

pling = #(define-music-function (parser location m) (ly:music?)
           #{ $m 8. 16 \times 3/2 { 8 8 8 } #})

then for \pling c'4 the pitch would get inherited, while for
\pling { c'4 } it wouldn't?

We had _all_ of that "restrict to one music expression" discussion in
relation to q.  If you feel argumentative, dig out the hundreds of
mails about that feature and reargue them in private.  Unless you come
up with something new, I don't see why the conclusion should be
different.

> they won't, because LilyPond wouldn't look back further than the
> beginning of current context/expression.  Do you think that would be
> doable?

I am not interested in restarting this discussion.

[ckenneth721, 2013-11-10 13:15:53]

On Nov 10, 2013 5:11 AM, <dak@gnu.org> wrote:

> On 2013/11/10 11:48:13, janek wrote:
>
>> Awesome!!
>>
>
>  could you push it in a branch, so that I could read the commits in
>>
> sequence?
>
> dev/issue3648
>
>  On 2013/11/09 19:05:29, dak wrote:
>> > You need to use q here.  Sorry, but it would not do to turn
>> >
>> > << \new Staff { <c e>4 }
>> >    \new RhythmicStaff { 4 4 4 4 }
>> > >>
>> >
>> > into
>> >
>> > << \new Staff { <c e>4 }
>> >    \new RhythmicStaff { <c e>4 <c e>4 <c e>4 <c e>4 }
>> > >>
>> >
>> > since then every note stem in RhythmicStaff would have two heads.
>>
> The
>
>> > main feature is being able to write naked rhythms.  In the contexts
>> > where they are of interest, it should be no problem if they inherit
>>
> an
>
>> > arbitrary pitch, but they can't magically turn into chords.
>>
>
>  Good point.
>> However, what about restricting the "pitch inheritance" to the
>> current context,
>>
>
> Like q, expansion is done while scorifying.  There are no contexts at
> that time.  Doing it in the parser (like durations are, and which q
> once was) would cause a bloody mess with \relative (which it did with
> q).  Doing it, say, at iteration, namely _yet_ _another_ time would be
> quite a nuisance and it would not be clear just which iterator would
> be responsible for keeping state.
>
>  or the current music expression (code block inside {} )?  I.e. in
>>
>
>     \new Staff { <c e>4 4 4 4 }
>>
>
>  the pitches would be inherited, while in
>>
>
>  <<
>>    \new Staff { <c e>4 }
>>    \new RhythmicStaff { 4 4 4 4 }
>> >>
>>
>
> And with
>
> pling = #(define-music-function (parser location m) (ly:music?)
>            #{ $m 8. 16 \times 3/2 { 8 8 8 } #})
>
> then for \pling c'4 the pitch would get inherited, while for
> \pling { c'4 } it wouldn't?
>
> We had _all_ of that "restrict to one music expression" discussion in
> relation to q.  If you feel argumentative, dig out the hundreds of
> mails about that feature and reargue them in private.  Unless you come
> up with something new, I don't see why the conclusion should be
> different.
>
>  they won't, because LilyPond wouldn't look back further than the
>> beginning of current context/expression.  Do you think that would be
>> doable?
>>
>
> I am not interested in restarting this discussion.
>
>
> https://codereview.appspot.com/22120043/
>

[janek, 2013-11-10 18:06:04]

2013/11/10  <dak@gnu.org>:
> On 2013/11/10 11:48:13, janek wrote:
>> could you push it in a branch, so that I could read the commits in
>> sequence?
>
> dev/issue3648

thanks!
LGTM.

>> Good point.
>> However, what about restricting the "pitch inheritance" to the
>> current context,
>
> Like q, expansion is done while scorifying.  There are no contexts at
> that time.  Doing it in the parser (like durations are, and which q
> once was) would cause a bloody mess with \relative (which it did with
> q).  Doing it, say, at iteration, namely _yet_ _another_ time would be
> quite a nuisance and it would not be clear just which iterator would
> be responsible for keeping state.

ok, i see the problem.

> And with
>
> pling = #(define-music-function (parser location m) (ly:music?)
>            #{ $m 8. 16 \times 3/2 { 8 8 8 } #})
>
> then for \pling c'4 the pitch would get inherited, while for
> \pling { c'4 } it wouldn't?
>
> We had _all_ of that "restrict to one music expression" discussion in
> relation to q.  If you feel argumentative, dig out the hundreds of
> mails about that feature and reargue them in private.  Unless you come
> up with something new, I don't see why the conclusion should be
> different.

I have just today read some of the discussion about q, but i don't
have anything new to propose.  So, for me the discussion is closed.

It may be a good idea to put your explanations in a comment - maybe an
addition to the already existing comment describing
expand-repeat-notes! ?

thanks!
Janek

[dak, 2013-11-12 10:23:56]

Some more thoughts about the chord issue: I agree that it sounds somewhat icky
to have repetition not extend to chords, in particular when having a music
function with a body like
#{ #music 4 4. 8 #}
and calling it with either \rhythm c or \rhythm <c e>, it will be quite a
nuisance that the first works and the second doesn't.

Now if we want to have this to hold for chords as well, we have to make sure we
don't get into trouble with functions or contexts expecting to deal with pure
rhythms when chords creep in unasked for.

One way to do that is to provide a cleanup function that just removes pitches
and collapses chords.

That does not help with Pitch_squash_engraver: Pitch_squash_engraver also needs
to reduce rhythms to a single notehead.  If you take a look at the output of
\new RhythmicStaff <c e>1 this just won't do.  It may well be argued that
Pitch_squash_engraver should at least remove duplicate noteheads with identical
properties:
\new RhythmicStaff << e1 \\ c >> arguably could display two noteheads but
paradoxically doesn't, while using a chord delivers two.

So the problem is that having a duration also work on a chord would require us
fixing quite a few things elsewhere: this is less robust than explicitly calling
functions for replacements and rerhythming.

It still would not be fun in connection with TabStaff, not repeating string
numbers and stuff, and such repetition is really not feasible.

Of course the problem is that we have to make a decision what to support:

a) we don't commit ourselves either way: it is undefined what a pure duration
after an intervening chord will do.

b) just single pitches, no chords: that's what this patch proposes.

c) also chords: this patch needs more work, supporting code must be written,
Pitch_squash_engraver has to be changed etc etc.

The problem is that with both options b) and c), we'll soonish have music
depending on this behavior.

I'm leaning towards a): tell people not to rely on particular behavior after a
chord for now.

[benko.pal, 2013-11-12 15:35:42]

On 2013/11/12 10:23:56, dak wrote:
> a) we don't commit ourselves either way: it is undefined what a pure duration
> after an intervening chord will do.
> 
> b) just single pitches, no chords: that's what this patch proposes.
> 
> c) also chords: this patch needs more work, supporting code must be written,
> Pitch_squash_engraver has to be changed etc etc.
> 
> The problem is that with both options b) and c), we'll soonish have music
> depending on this behavior.
> 
> I'm leaning towards a): tell people not to rely on particular behavior after a
> chord for now.

how does a) differ from b) patch-wise?

[dak, 2013-11-12 16:46:21]

On 2013/11/12 15:35:42, benko.pal wrote:
> On 2013/11/12 10:23:56, dak wrote:
> > a) we don't commit ourselves either way: it is undefined what a pure
duration
> > after an intervening chord will do.
> > 
> > b) just single pitches, no chords: that's what this patch proposes.
> > 
> > c) also chords: this patch needs more work, supporting code must be written,
> > Pitch_squash_engraver has to be changed etc etc.
> > 
> > The problem is that with both options b) and c), we'll soonish have music
> > depending on this behavior.
> > 
> > I'm leaning towards a): tell people not to rely on particular behavior after
a
> > chord for now.
> 
> how does a) differ from b) patch-wise?

The Documentation is more or less in-between.  It's not helpful for figuring out
the difference.  If people experiment and find out the current behavior and
start relying on it, we can later tell them "your own fault, where in the
documentation did it promise to work?"

That's sort of subfabulous.  I have thought a bit more about RhythmicStaff, and
I am less convinced than previously that all problems caused by chords creeping
in unintentionally would be salvageable: the Pitch_squash_engraver can't really
fix the Midi.  It would need a companion performer.  And so on.

Of course, it makes sense to say then in the context of RhythmicStaff: _do_
specify a starting pitch, or probably preferably, a drum type.

So this patch leaves open questions, and people might give themselves answers
consistent with the current behavior.  Overriding those answers later with a
convert-ly rule seems unfeasible: this is really a bit too invasive and complex
to change using convert-ly.

The current behavior is reasonably predictable and reasonably straightforward. 
With regard to chords, it's not entirely lovable.  I'm not sure making it more
complex is a good idea, though.

[janek, 2013-11-12 21:58:13]

2013/11/12  <dak@gnu.org>:
> It still would not be fun in connection with TabStaff, not repeating
> string numbers and stuff, and such repetition is really not feasible.

I don't understand what you mean here.

> Of course the problem is that we have to make a decision what to
> support:
>
> a) we don't commit ourselves either way: it is undefined what a pure
> duration after an intervening chord will do.
>
> b) just single pitches, no chords: that's what this patch proposes.
>
> c) also chords: this patch needs more work, supporting code must be
> written, Pitch_squash_engraver has to be changed etc etc.
>
> The problem is that with both options b) and c), we'll soonish have
> music depending on this behavior.
>
> I'm leaning towards a): tell people not to rely on particular behavior
> after a chord for now.

This probably is a good idea.  At least i prefer to a) over b).

[janek, 2013-11-12 22:01:42]

2013/11/12  <dak@gnu.org>:
> So this patch leaves open questions, and people might give themselves
> answers consistent with the current behavior.  Overriding those answers
> later with a convert-ly rule seems unfeasible: this is really a bit too
> invasive and complex to change using convert-ly.
>
> The current behavior is reasonably predictable and reasonably
> straightforward.  With regard to chords, it's not entirely lovable.  I'm
> not sure making it more complex is a good idea, though.

While i would love having the repetition work with chords, i'm
underqualified to judge how feasible implementing this would be.  I
don't want to put pressure on you - decide according to your
judgement.

best,
Janek

[dak, 2013-11-13 13:22:06]

On 2013/11/12 21:58:13, janek wrote:
> 2013/11/12  <dak@gnu.org>:
> > It still would not be fun in connection with TabStaff, not repeating
> > string numbers and stuff, and such repetition is really not feasible.
> 
> I don't understand what you mean here.
> 
> > Of course the problem is that we have to make a decision what to
> > support:
> >
> > a) we don't commit ourselves either way: it is undefined what a pure
> > duration after an intervening chord will do.
> >
> > b) just single pitches, no chords: that's what this patch proposes.
> >
> > c) also chords: this patch needs more work, supporting code must be
> > written, Pitch_squash_engraver has to be changed etc etc.
> >
> > The problem is that with both options b) and c), we'll soonish have
> > music depending on this behavior.
> >
> > I'm leaning towards a): tell people not to rely on particular behavior
> > after a chord for now.
> 
> This probably is a good idea.  At least i prefer to a) over b).

Ok, I think we'll let this more or less get in in the current form (just to get
feedback) and I'll do a followup patch that will give a _warning_ when a raw
duration is used after a chord.  Basically this will mean that you are not
supposed to use
\new RhythmicStaff { 8 8 4 2 } but rather something like
\new RhythmicStaff \drummode { tamb 8 8 4 2 }
which also is nicer in midi.  This would not affect any music commands
interpreting rhythms: the pitch insertion (which would then complain about
preceding chords) only runs during scorification.

I am going to rework the documentation/code examples appropriately; I don't
think that requires restarting the countdown (the examples make fewer
assumptions in that manner).

[janek, 2013-11-13 13:59:48]

LGTM.

2013/11/13  <dak@gnu.org>:
> On 2013/11/12 21:58:13, janek wrote:
>>
>> 2013/11/12  <dak@gnu.org>:
>> > It still would not be fun in connection with TabStaff, not repeating
>> > string numbers and stuff, and such repetition is really not
>
> feasible.
>
>> I don't understand what you mean here.
>
>
>> > Of course the problem is that we have to make a decision what to
>> > support:
>> >
>> > a) we don't commit ourselves either way: it is undefined what a pure
>> > duration after an intervening chord will do.
>> >
>> > b) just single pitches, no chords: that's what this patch proposes.
>> >
>> > c) also chords: this patch needs more work, supporting code must be
>> > written, Pitch_squash_engraver has to be changed etc etc.
>> >
>> > The problem is that with both options b) and c), we'll soonish have
>> > music depending on this behavior.
>> >
>> > I'm leaning towards a): tell people not to rely on particular
>
> behavior
>>
>> > after a chord for now.
>
>
>> This probably is a good idea.  At least i prefer to a) over b).
>
>
> Ok, I think we'll let this more or less get in in the current form (just
> to get feedback) and I'll do a followup patch that will give a _warning_
> when a raw duration is used after a chord.  Basically this will mean
> that you are not supposed to use
> \new RhythmicStaff { 8 8 4 2 } but rather something like
> \new RhythmicStaff \drummode { tamb 8 8 4 2 }
> which also is nicer in midi.  This would not affect any music commands
> interpreting rhythms: the pitch insertion (which would then complain
> about preceding chords) only runs during scorification.
>
> I am going to rework the documentation/code examples appropriately; I
> don't think that requires restarting the countdown (the examples make
> fewer assumptions in that manner).
>
> https://codereview.appspot.com/22120043/

[dak, 2013-11-14 14:49:41]

Implement chord repetition, make RhythmicStaff examples more defensive in return