On 04.04.2014 16:32, Urs Liska wrote: > But lilypond probably could assist a frontend with a map from musical >> flow to paper-flow. If the GUI knows that on page 3 are measures 27-42 >> and the front end tracks an action, where I modified one slur-shape or >> one pitch, the front-end could trigger a compilation of measures 27-42 >> and not the whole score. >> Its just an idea ... > > Maybe that map wouldn't even be possible. I _assume_ that an editor > might get that information by itself through point-and-click. But > having the information directly would of course ease things. With delayed expressions - they are used for table of contents - it should be possible to get page infos related to grobs and there musical positions. ... and now I have to take care not to start to play schemedoku again ;)
> What seems very useful to me would be something like this: > > - compile a score similarly to using lilypond-book-preamble, i.e. in > individual files per system. > - write out something like a LaTeX .aux file with information about > measures in the systems. Editors can parse this file to know about the > piece. An editor should then also be able to display these individual > files like one score (maybe as a continuous page). > - Enable Lilypond to compile just a given system. This would probably > work similar to skipTypesetting but with the difference that the > system is laid out exactly as in the full context. Am I right that - > once the line breaking has been done - a system is a quite independent > entity for LilyPond? > > That way an editor could provide a continuous view of the score and > let LilyPond recompile any given system without having to redo > everything else. > And it would be sufficiently straightforward to let LilyPond (or the > editor) protest when the line breaking doesn't work anymore (e.g. the > recompiled line gets longer and would need different line breaks). > > For a "music entry mode" this could even be extended by a compilation > mode that doesn't care at all about page breaking. Let the lines be > ragged right and simply add measures until the line is full. This > should reduce a noticeable part of the compilation time. Or lilypond shall just encode (ragged) all measures visible in a view to scroll only horizontal the whole piece. More on this on monday ;) Have a nice weekend! _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
