Re: Another time model (related to the usability thread)

[James Harkins]

Keith OHara <k-ohara5a5a <at> oco.net> writes:

> Of course specifying time in terms of durations is more convenient
> than specifying absolute time, or we would need to change every
> following note when we insert a few measures. 

Assuming that "durations" and "absolute time" are the only two options. I'm
not making that assumption. I don't know what the solution would look like
(yet), but I think any solution would involve a higher-level representation
than LilyPond code currently expresses well.

> It does come up often that we want to say 
>   full-measure-rest until the next key-change
> or
>   skip until the next rehearsal mark
> or sometimes even
>   drone D until the double-bar
> If we had an easy way to enter a duration of until-X, then ability to
> place the next note X comes naturally.  Sometimes 'X' is the end of
> the entire piece.  Would that ease the difficulties mentioned above ?

It might, if such a function would conform the full-bar rests to the time
signatures (which may be in another parallel expression). This still depends
on some external marker. If it could handle something like "... until the
next rehearsal mark - 4 bars," that could help somewhat, but it wouldn't
help every case. Suppose I need to insert a bar, 2 bars before that
rehearsal mark. Then I have to change the function invocation to "next
rehearsal mark - 5 bars." Error prone. Basically the only way is to do as
much as you can by hand, compile the PDF, and then track down the mistakes.

> LilyPond has a bunch functions of trying to help
>   #(skip-of-lenngth #(mmrest-of-length
>   \barNumberCheck\D
>   \pushToTag 
> but none seem to do the job simply (and it took me quite a while to 
> remember what they were called closely enough in order to look them up
> in the manual.)
> 
> LilyPond does some similar things for us already.  For example we
> usually enter rehearsal marks just once in some \global variable, that
> we include in << parallel >> with the variables that contain the music,
> and LilyPond will split a R1*32 rest into segments to print those marks
> correctly in the parts. 

If you insert a bar, you'd have to change R1*32 to R1*33 by hand. Or, if you
change the 10th out of the 32 bars into a 3/4 measure, I believe you would
then have to change R1*32 to "R1*9 R2. R1*22" -- highly error prone.

The skip- and mmrest-of-length functions would be slightly less error prone
for the second case, as (I suppose) you would just have to subtract one beat
from the given length. Still, there is no automatic way to change the
duration of a passage of music and have full-bar rests adjusts
automatically. (Obviously, voices that have events in them would need manual
intervention.)

~~

As I see it, the main problem is that there is no reliable way in LilyPond
to know the absolute time of any music expression. Within a music
expression, you know the time relative to the start of the expression. But
you can use the same music variable at 2, 3 or 10 different absolute time
points -- and you can make another score using the same variable (in an
include file) that places the variable at time points that are different
from the first score. Inserting a bar at m25 in one score, and inserting a
different bar at m33 of the second score, would make a complete hash out of
the variable's source code in the include file.

The level of complexity involved to ask Frescobaldi or another editor to do
this is nightmarish to consider. The editor would have to divide --
automatically -- variables into sub-variables, and somehow associate the
automatically-generated variables with one and only one score. I don't think
it's worth it (assuming it's even possible -- and I have serious doubts
about that).

That's why I said I think LilyPond's input structure might be too low-level
for this use case. The LilyPond language is clumsy at expressing this
macro-level of bar-and-meter structure -- clumsy, because it requires
redundancy in the manual input. And I'm not sure that it's worth messing
around with the LP language itself, because it expresses the information
required to engrave a score quite well. It doesn't express the information
required to /edit/ the score conveniently. If there were an alternate input
language that /does/ express editing information more straightforwardly,
this language could write LP code for engraving -- similar to the way that
FAUST (Functional AUdio STream language) expresses DSP algorithms at a high
level and writes C++ for them, or Emacs/org-mode exports its own markup
syntax to LaTeX, HTML, Markdown etc.

hjh