About issue 34 Am Mo., 19. Okt. 2020 um 08:40 Uhr schrieb Jacques Menu <[email protected]>:
> LilyPond can be characterized the following way, please excuse any important > omission or error: > - the implementation is one-pass, meaning that the work done when > handling a file goes straight from the characters level to graphics and MIDI > output, without any intermediate stop; > Some aspects of the current state of the Lily implementation are a bit > saddening: > - solving the famous #34 issue is nearly impossible in the current > one-pass setup. > > There have been very interesting discussions about all this at the Salzburg > conference last January, which lead me to dream of things being done another > way in an ideal world: > - go for a multi-pass implementation, in which an internal > representation of the score is built in memory in a first move. Then other > moves produce graphics and MIDI output from this representation, which could > also be used to convert LilyPond to MusicXML or other formats; > Multi-pass would help solve the #34 issue: a representation of the whole > score in memory can be used to spot the places where one has to add grace > skips as of today, before executing the graphics creation pass(es). This is > the way xml2ly adds such skips automatically to avoid the issue in the > LilyPond code it generates. I can't fully imagine the advantages of a multi-pass implementation. Nevertheless, what you wrote sounds not like _solving_ issue 34 but to have a better workflow for the recommended workaround. Maybe https://sourceforge.net/p/testlilyissues/issues/34/?page=1&limit=25#2eca points to an automatic implementation of a work around, if further developed... Cheers, Harm
