On Dec 2, 2013 9:40 PM, "James Harkins" <jamshar...@gmail.com> 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.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to