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

[Carl Peterson]

On Dec 2, 2013 9:40 PM, "James Harkins" <address@hidden> wrote:
>
> 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.
>
>
> 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.
>

I think that low-level vs. high-level is the key. GUIs can throw in behind-the-scenes data structures to handle things like adding arbitrary measures. Or they can use a format like MusicXML to store things natively at the measure level, then convert/update the LP representation as needed. You really can't do that using LP directly without a serious refactoring of the usual way people define parts and music, at least if I'm understanding things correctly.