Re: divisi parts and another general question

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hi David,
>
>> Here is one difference: #{ ... #} creates copies of music
>> identifiers referenced via \... inside.
>> 
>> That's not relevant for anything you mentioned explicitly, but it
>> _would_ have triggered issue 2263 in case you were using _chord_
>> _repetition_ in connection with \relative.
>
> I definitely use a lot of chord repetition, and I always (= 99% of the
> time) use \relative. In fact, until only recently, most of my code had
> \relative {} instead of the now-promoted \relative x {} [where x is
> the first note in the music expression]. (I am slowly updating my old
> code to fix this.)

I do not remember that we promoted \relative x, actually.  What I wanted
to promote at one point of time was having \relative { ... } be
equivalent to \relative f { ... } since then the first note inside can
_always_ be specified as if it was absolute:

\relative c' { f' } -> f''
\relative c' { g' } -> g'
\relative f { f' } -> f'
\relative f { g' } -> g'

Since \relative f looks contrived (it's not easy to explain what makes f
special), being able to leave off the pitch and have it secretly
replaced by f would make sense.

Of course, it would appear that enough legacy code with \relative {
... } is around to make that change somewhat painful.

> Furthermore, I can report with total confidence that the bug I
> encountered was an octave displacement problem — I remember that
> vividly, since it was so irritating (and inexplicable).
>
> So it seems that
>
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2263>,
>> previously
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=1110>.
>
> were/was almost certainly the problem(s).
>
> Can you say with 100% certainty that this issue is now solved, and
> hence that I will get identical results the my function and the
> simpler function (which I prefer)?

Yes.  I completely reimplemented the whole of chord repetition after the
EventChord changes (issue 2240) made it possible to distinguish chords
and single notes in music expressions (rather than just in the parser).
That was not just further touchup work on a flawed implementation.  I
don't know of any remaining code in LilyPond that gets confused by
copying nowadays (as of 2.16).

Independently, you can by now (not sure about the version) write #music1
and #music2 inside of sequential music in #{ ... #} and in that manner
avoid the copying that takes place when writing $music1 and $music2.  It
is not really all that important, and since LilyPond often works
destructively on music expressions, copying more than necessary is to be
preferred over copying less than necessary.  One difference, however, is
that point-and-click for $xxx expressions points to the call of the
music function whereas point-and-click for #xxx expressions points to
the original music expression.

> p.s. I'm relieved to have proven to myself that my memory was to be
> trusted on this after all!  =)

The repeatchord debacle could not just be triggered by music functions.
Even just sticking something in a music variable before doing \relative
on it would have been sufficient.  So writing the function without any
copying (as the Scheme version did) would only have prevented one way of
blowing up on the old repeat chord implementation.

Given the amount of friendly words that I lost over the repeatchord
feature and its original implementation on the developer list, it is
somewhat embarrassing that I did not make the connection here.

-- 
David Kastrup