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