Johan Vromans <jvrom...@squirrel.nl> writes: > On Mon, 15 Aug 2016 10:22:14 +0200 > David Kastrup <d...@gnu.org> wrote: > >> That's not really surprising. The "repeats are shown" just by changing >> the bar line type, ... > > That is the explanation of the current behaviour. > > What I want to say is that it would be nice if instead it would > be like the repeats were actually present in the individual staffs, > just as the printed output shows it.
The printed output shows that Default_bar_line_engraver (responsible for coordinating the system-wide bar line shapes) lives at Score context usually. The printed output does not show a repetition of elements. Calculation of the length of music depends on knowing which parts are repeated and which not. If the music does not contain any repeat expressions but only gets typeset in parallel to music which does, there is just no way to reset its playback to the respective locations it had been without every single music iterator getting a way to rewind to an arbitrary location. Even if it turns out that the location does not even correspond to an actual note event (like when notes are split using the Completion_heads_engraver). With an actual repeat expression, at least the music structure follows the repetition, giving reliable points to restart the iteration. So in short: extending this "repeat bars appear across all contexts governed by the same Default_bar_line_engraver" effect to actual unfoldings of repeats is not likely to happen. In Midi, a special performer just replicating some timed part of the finished Midi stream (rather than replaying everything) would be sort-of imaginable but it would also be a recipe for notes started but not ended and vice versa. And the effect would be limited to Midi. So I also consider this pretty far into the "not going to happen" realm. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user