python/convertrules.ly: Use bare rhythms after ties for simple cases

python/convertrules.ly: Use bare rhythms after ties for simple cases

Obviously also:

Run scripts/auxiliar/update-with-convert-ly.sh

[Trevor Daniels, 2014-01-10 17:35:10]

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/fundame...
File Documentation/learning/fundamental.itely (right):

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/fundame...
Documentation/learning/fundamental.itely:1054: r8 e4 d c8 ~ | 8 b16 a b8 g ~ 2 |
Didn't we decide a while ago to attach ties
to notes without an intervening space?  There
are obviously lots more like this too.

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
File Documentation/learning/templates.itely (right):

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
Documentation/learning/templates.itely:62: BassMusic = \relative c' { c2\p c4 c
}
This is wrong.  Why should we not use the
new facility you introduced in 2.19 and
let the first note specify the octave?

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
Documentation/learning/templates.itely:82: BassMusic = \relative c' { c2\p c4 c
}
See above

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
Documentation/learning/templates.itely:126: SopranoMusic = \relative c' { a' a a
a }
See above

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
Documentation/learning/templates.itely:127: AltoMusic = \relative c' { f' f f f
}
See above.
I'll not bother identifying any more

[dak, 2014-01-10 17:53:46]

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/fundame...
File Documentation/learning/fundamental.itely (right):

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/fundame...
Documentation/learning/fundamental.itely:1054: r8 e4 d c8 ~ | 8 b16 a b8 g ~ 2 |
On 2014/01/10 17:35:11, Trevor Daniels wrote:
> Didn't we decide a while ago to attach ties
> to notes without an intervening space?  There
> are obviously lots more like this too.

Well, of course: this is a pattern.  Now the thing is that if you attach ties to
notes without an intervening space (or at least let them stand if they were so
before), we have possibilities

r8 e4 d c8~ | c8 b16 a b8 g~ g2 |
r8 e4 d c8~ | 8 b16 a b8 g~2 |

I am actually most worried about things like

r8 e4 d c8-.->~ | 8 c8 b16 a b8 g-.->~4~4 |

which I considered to read better as

r8 e4 d c8-.-> ~ | 8 c8 b16 a b8 g-.-> ~ 4 ~ 4 |

Obviously, the point of this full patch is to figure out where we want
the rules to go.  It's also conceivable to do a "space after ~ only if
there was one before" rule.

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
File Documentation/learning/templates.itely (right):

https://codereview.appspot.com/49470049/diff/1/Documentation/learning/templat...
Documentation/learning/templates.itely:62: BassMusic = \relative c' { c2\p c4 c
}
On 2014/01/10 17:35:11, Trevor Daniels wrote:
> This is wrong.  Why should we not use the
> new facility you introduced in 2.19 and
> let the first note specify the octave?

The question is rather why this file is marked "version 2.16.0".  Oh wait,
because this \relative conversion was _not_ applied to the learning manual.  So
yes, the upgrade from 2.16.0 _will_ require using \relative c' here.  Which is
correct.

It would seem that when you added the respective template lines, you should have
updated the version number of the file as well.

Now of course, in analogy to the last conversion, I should exempt the learning
manual from this automatic conversion.  But you still should fix the version
header to 2.18.0 or so, assuming that no other rules applied.

[Trevor Daniels, 2014-01-10 20:39:03]

On 2014/01/10 17:53:46, dak wrote:

> Now the thing is that if you attach ties to
> notes without an intervening space (or at least let them stand if they were so
> before), we have possibilities
> 
> r8 e4 d c8~ | c8 b16 a b8 g~ g2 |
> r8 e4 d c8~ | 8 b16 a b8 g~2 |

  r8 e4 d c8~ | 8 b16 a b8 g~ 2 |  % my preference
 
> I am actually most worried about things like
> 
> r8 e4 d c8-.->~ | 8 c8 b16 a b8 g-.->~4~4 |

  r8 e4 d c8-.->~ | 8 c8 b16 a b8 g-.->~ 4~ 4 |  % my preference
 
> which I considered to read better as
> 
> r8 e4 d c8-.-> ~ | 8 c8 b16 a b8 g-.-> ~ 4 ~ 4 |
> 
> Obviously, the point of this full patch is to figure out where we want
> the rules to go.  It's also conceivable to do a "space after ~ only if
> there was one before" rule.

My preference would be no space before ties, one space after.
That leaves ties properly associated with the note to which
they are a post event, but with a clear separation from the
following note.
 

> On 2014/01/10 17:35:11, Trevor Daniels wrote:
> > This is wrong.  Why should we not use the
> > new facility you introduced in 2.19 and
> > let the first note specify the octave?
> 
> The question is rather why this file is marked "version 2.16.0".  Oh wait,
> because this \relative conversion was _not_ applied to the learning manual. 
So
> yes, the upgrade from 2.16.0 _will_ require using \relative c' here.  Which is
> correct.

It's wrong because the change puts the notes into a
different octave than before.  The conversion doesn't
work going backwards (nor should it be expected to).
 
> It would seem that when you added the respective template lines, you should
have
> updated the version number of the file as well.

With hindsight.  But we never do that when editing
doc files as a rule.

> Now of course, in analogy to the last conversion, I should exempt the learning
> manual from this automatic conversion.  But you still should fix the version
> header to 2.18.0 or so, assuming that no other rules applied.

OK.  I'll do that.

Trevor

[t.daniels_treda.co.uk, 2014-01-10 20:56:26]

tdaniels wrote Friday, January 10, 2014 8:39 PM

>> It would seem that when you added the respective template lines, you
> should have
>> updated the version number of the file as well.
> 
> With hindsight.  But we never do that when editing
> doc files as a rule.
> 
>> Now of course, in analogy to the last conversion, I should exempt the
> learning
>> manual from this automatic conversion.  But you still should fix the
> version
>> header to 2.18.0 or so, assuming that no other rules applied.
> 
> OK.  I'll do that.

Actually this seems to be a consequence of not bumping _all_
version numbers to the current release.  Before, when editing
doc files, we always assumed Lily code being added should
use the syntax of the current release in master.  But now this
assumption may trigger inappropriate conversions, as here.

This needs to be thought through again.

Trevor

[dak, 2014-01-10 21:19:38]

On 2014/01/10 20:56:26, t.daniels_treda.co.uk wrote:

> Actually this seems to be a consequence of not bumping _all_
> version numbers to the current release.

No, it is a consequence of not bumping the version number to the syntax used for
adding material.

A \version header of xx.yy.zz means "this will do the right thing when compiled
with version xx.yy.zz".

Always.

If that is not the case, either the file contents or the version header or both
have to be adjusted.

> Before, when editing
> doc files, we always assumed Lily code being added should
> use the syntax of the current release in master.

Sure.  Nothing else makes sense.  But that means that if you want to add stuff
_not_ consistent with the version header, you should
a) run convert-ly on the file (which should, if everybody did proper
maintenance, not change anything apart from bumping the version header)
b) add the new code
c) make the version number match the new code if it does not already do so.

> But now this
> assumption may trigger inappropriate conversions, as here.
> 
> This needs to be thought through again.

The above is crystal clear to me.  If it isn't obvious to others and not spelled
out clearly in CG, it should be put there.

[dak, 2014-01-10 21:37:15]

On 2014/01/10 20:39:03, Trevor Daniels wrote:

> My preference would be no space before ties, one space after.
> That leaves ties properly associated with the note to which
> they are a post event, but with a clear separation from the
> following note.

So: c'4~ 2~ 2 rather than c'4~2~2 or c'4 ~ 2 ~ 2

The thing is that the symmetric forms are sort of idiomatic: I was
pitching for a form that reflects the musical usage rather than the
underlying events produced by LilyPond, so its a c'4 subdivided by
ties into a quarter, a half, and another half note.

This does not, I admit, match what \displayLilyMusic will crank out,
and \displayLilyMusic should likely pick something close to the
internal representation over elegance anyway.

> > On 2014/01/10 17:35:11, Trevor Daniels wrote:
> > > This is wrong.  Why should we not use the
> > > new facility you introduced in 2.19 and
> > > let the first note specify the octave?

> > The question is rather why this file is marked "version 2.16.0".
> > Oh wait, because this \relative conversion was _not_ applied to
> > the learning manual.  So yes, the upgrade from 2.16.0 _will_
> > require using \relative c' here.  Which is correct.

> It's wrong because the change puts the notes into a
> different octave than before.

No, it doesn't.  The conversion makes sure that the output compiled
with the current version of LilyPond matches what you would get when
compiling the unconverted file with the specified version, namely
2.16.0.

> The conversion doesn't work going backwards (nor should it be
> expected to).

Since the original header declared 2.16.0 and the current version is
2.19.1, it only needs to go forward.


> > It would seem that when you added the respective template lines,
> > you should have updated the version number of the file as well.

> With hindsight.  But we never do that when editing doc files as a
> rule.

I don't know what "we" do "as a rule", but I've been doing a lot of
syntax changes to LilyPond, and I make the version numbers match what
I write every time.  If you don't do that, stuff goes South when
convert-ly is run the next time.

So if "we" don't do that "as a rule", we need to change the rules.
Nothing else will work.

> > Now of course, in analogy to the last conversion, I should exempt the
learning
> > manual from this automatic conversion.  But you still should fix the version
> > header to 2.18.0 or so, assuming that no other rules applied.
> 
> OK.  I'll do that.

Perhaps run convert-ly -ed on the file and make sure that this _only_
affects the new additions by checking the output of git diff.  Then do
git reset --hard (to erase those conversions) and bump the version
manually.

[dak, 2014-01-13 20:34:24]

Don't touch spacing around ~, leave forced accidentals alone

[Trevor Daniels, 2014-01-13 22:59:21]

We'll need a tracker issue to add some
explanatory text about isolated durations
to the LM (unless I've missed it), and
there is one place, marked below, where
this change should not be made.

Trevor

https://codereview.appspot.com/49470049/diff/20001/Documentation/notation/rhy...
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/49470049/diff/20001/Documentation/notation/rhy...
Documentation/notation/rhythms.itely:434: a2~ 4~ 16 r r8
This example should not be modified, else
the following paragraph explaining the use
of isolated durations does not sensibly
follow on.

[dak, 2014-01-14 04:40:01]

On 2014/01/13 22:59:21, Trevor Daniels wrote:
> We'll need a tracker issue to add some
> explanatory text about isolated durations
> to the LM (unless I've missed it),

Uh, I think in a comparable situation we decided that the LM should not be
converted along with the rest since that would lead to use of a feature before
its explanation.  I forgot to revert the LM changes here.

> and
> there is one place, marked below, where
> this change should not be made.

Ok.

>
https://codereview.appspot.com/49470049/diff/20001/Documentation/notation/rhy...
> File Documentation/notation/rhythms.itely (right):
> 
>
https://codereview.appspot.com/49470049/diff/20001/Documentation/notation/rhy...
> Documentation/notation/rhythms.itely:434: a2~ 4~ 16 r r8
> This example should not be modified, else
> the following paragraph explaining the use
> of isolated durations does not sensibly
> follow on.

Will fix once I am awake again.

[Trevor Daniels, 2014-01-14 08:58:41]

On 2014/01/14 04:40:01, dak wrote:

> Uh, I think in a comparable situation we decided that the LM should not be
> converted along with the rest since that would lead to use of a feature before
> its explanation.  I forgot to revert the LM changes here.

It's not quite the same.  The LM is fine with these
changes.  Unlike the NR the change makes nothing 
inconsistent.  It's just that they should be explained
first.  So best to leave them in and I'll make sure
some text gets added soonish. 

Trevor

[dak, 2014-01-14 14:11:15]

restore alignment for parallelMusic, small NR fixup

[Trevor Daniels, 2014-01-14 17:33:42]

LGTM
I'll raise an issue for LM documentation

[dak, 2014-01-28 14:36:02]

Rebase, rerun scripts/auxiliar/update-with-convert-ly.sh

[dak, 2014-01-29 08:43:43]

Fix report by James