Open FelippeRoza opened 7 years ago
Apparently it works sometimes when bar division is explicitly declared with the symbol '|'. The lilypond compiler is somehow 'smarter' and is able to distribute the rests and notes to the appropriate measure without the bar symbols.
This is a correct interpretation, and having to specify barchecks (the |
) is one known limitation.
The problem for Frescobaldi/python-ly is that when you have any music expression it is hard to know where it will finally end up in a score. When LilyPond parses an expression it definitely knows that.
However, python-ly does have support for calculating lengths (notice the "Pos:" entry in the editor's status bar?), and figuring out if it is possible to make python-ly's exporter smarter in this regard would also be a valuable part of your project.
Right. I will try to figure out how Frescobaldi calculates the position of the element and how this can be used to solve this problem.
I spend the weekend working in the multi-measure rest feature in order to make it able to deal with \compressFullBarRests, but something was going wrong. Then I realized that the current method to deal with multi-measure rest fails with some notation.
The following ly code is compiled with Frescobaldi generating a 2 bar sheet:
{ R1 R1 }
But it exports to MusicXML a single measure with two rests: