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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
