Re: Document <> and improve other simultanous music documentation. (issue 6248080)

[dak]

On 2012/06/04 04:10:55, Keith wrote:
> lgtm


http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simultaneous.itely
> File Documentation/notation/simultaneous.itely (right):


http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simultaneous.itely#newcode94
> Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e
}  c1\f
> On 2012/06/03 12:53:24, dak wrote:
> > On 2012/06/02 19:29:26, Keith wrote:
> > > That example gives me a headache.
> > Compared to yours?

> I think either yours or mine would be fine, actually. They are pretty
similar.
> That's why I copied your comment on my similar suggestion

http://codereview.appspot.com/6197068/diff2/1:10002/Documentation/notation/simultaneous.itely
> and pasted it here.

In either case, we have the problem that we need to illustrate putting
something on a music construct "not under our control".  I like the
ending slur best for that purpose since it does not have the "tamper
with the first iteration" flavor.  Putting a markup up is also somewhat
in that style, while demonstrating a "standalone" post-event rather than
just a spanner end.  The staccato point is one step further.

The music construct "not under our control" has the disadvantage that
pretty much everything we can bring up here is beyond the scope already
discussed in the current section.  And in the context of a small
example, we'll always have the "why not just write it out?" question.

Perhaps a simple music variable is a construct that is easier for the
unwary reader to take in and interpret without knowing its impact.  But
to not trigger the "why not just write it out?" question, its content
likely should be more complex than what I put in the repeat.

In contrast to your example, I tried using fewer symbol constructs to
reduce the "Is this Perl?" effect, and I decided not to put an example
for putting an articulation at the _end_ of a sequence, where it will
likely combine with the next note event.

I am not happy with the complexity we show here, but it is pretty much
unavoidable since _this_ is the place where people will look for the
respective information regarding chords, and the simultaneous music
section is where they will look for simultaneousness (so the example I
put there regarding rearrangement of musical material contains both <>
as well as s with a non-zero duration).

So yes: I made a number of choices and tradeoffs that are a judgment
call.  And I am not overly enthused about them.  But I don't see
alternatives (including changing nothing) right now that I see as an
improvement.

http://codereview.appspot.com/6248080/