Some wild considerations and a question

[Jacques Menu]

Hello folks,

Sorry, this message is rather long…


I’ve been wondering what design decisions would be made, should someone start a 
project like LilyPond today, with the years-long experience we have behind us 
in this field.

LilyPond can be characterized the following way, please excuse any important 
omission or error:
        - its native syntax is TeX inspired;
        - the ground code is written in C++, with lexical and syntactical 
analysis done with flex and bison, respectively;
        - the extension language is Scheme, from the Lisp family of languages;
        - 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;
        - building LilyPond on various operating systems relies on GUB and 
Python. 

I appreciate using Lily a lot, and I’m glad that Han-Wen Nienhuys and Jan 
Nieuwenhuizen started it years ago, and that others continue to offer great 
support for its maintaince and evolution. 
Manual tuning of graphics-only scores input with the mouse is tedious, and I’m 
a programmer after all.

Some aspects of the current state of the Lily implementation are a bit 
saddening:
        - Scheme is not easy to read nor write for most users, who can 
fortunately get help from the very useful and active users group;
        - the extensive use of Scheme code in the implementation is very 
flexible and powerful, but implies performance limitations;
        - the developpers and maintaince people we are lucky to have have had 
much work recently with GUB and the move from Python 2.x to 3.y;
        -  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:
        - keep the TeX inspired syntax, of course;
        - switch to another, easier to read and write extension language. 
Someone suggested Lua, for example, which would be a good candidate it seems;
        - rely more on C++ in the implantation for speed, keeping the extension 
language mainly for users in their files;
        - 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;
        - rely only on C++, flex, bison and the extension language. Eliminating 
the need for GUB and Python would greatly simplify porting LilyPond to various 
environments, including web sites, phones and tablets.

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’m ready to participate, should other people aim at such an ideal world.


Now to my question. 

We often have to add things such as short skips and cadenzas to avoid having 
so-called events at the exact same time moment in the score. 
This is illustrated by \HiddenMeasureAndBarLine in the attached file: 
commenting its use out at line 47 shows the problem.

Would it be meaningful, useful and not too hard to implement, to allow for 
several events at a given time moment, and a way to sort them depending on the 
user's needs? This would make it possible for the user to control the order in 
which LilyPond would handle events occurring at this time moment.
If so, such a feature could be added to the above wish list…

A nice day!

JM

RepeatNTimesPlacesAtTheEnd.ly
Description: Binary data