Re: python/convertrules.ly: Use bare rhythms after ties for simple cases (issue 49470049)

[dak]

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.


https://codereview.appspot.com/49470049/