Another time model (related to the usability thread)

[James Harkins]

Picking up on a comment of Kieren's, which I think doesn't need to hijack David's financial support thread...

I find LilyPond's model of time to be the most inconvenient aspect of the input format -- so inconvenient that it alone may be enough to drive people away.

Time is represented exclusively in terms of Inter-Onset Intervals. This is great for streams of events, but perfectly wretched for multiple streams that must coordinate.

Example: Suppose I'm writing an orchestral piece with, oh, 40 staves. The music changes meter every 2 or 3 bars. One extended passage is a duet between two soloists; all other players rest.

If I (wisely) use a global variable to coordinate the meter changes, I have to write the metrical structure in spacer rests. For the parts, I have to a/ write scheme to convert spacers to full-bar rests, after extracting only the segment of the global variable corresponding to the required bars, or b/ replicate the metric structure in dozens of staves, simply replacing s with R. (IIRC there's also some finagling involved in full-bar rests for meters like 5/8.)

Now let's say that we don't live in a perfect world and I didn't write everything in perfect form on paper before engraving. Then I decide that one 2/4 bar should actually be 3/4. So now I have to change s2 to s2. in the global variable AND I have to change some representation of time (whether a literal R or a scheme function invocation) in EVERY part. These are likely to be in separate include files, making it a time-consuming and fragile operation (leaving aside the inevitable arithmetic errors that result when counting beats over frequent meter changes).

This is in sharp contrast to Finale, where a full-bar rest is simply a bar with nothing in it. Change the meter for the measure stack, and the full-bar rests adjust automatically. And I haven't even mentioned inserting or deleting bars, which is trivial in Finale.

In some ways, this is a worst-case scenario for LilyPond's input format. It's also a completely realistic scenario for "new-music" composers working with large ensembles, and LilyPond handles it embarrassingly poorly. It drove me batty when I was working on a /trio/. I can't imagine dealing with this in an orchestral score. (Unless there's some magic trick I don't know about, which is entirely possible.)

It may be that LilyPond code is too low-level an abstraction for this use case, and that a kind of meta-code is what's needed. I guess Denemo is a step in that direction.

I don't have a concrete proposal, but in the context of recent discussions, I thought this is worth pointing out as an area which a convert from Finale or Sibelius is likely to run into and think, "But that's... insane" (likely inserting various obscenities in place of the ellipsis).

hjh