You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
The text was updated successfully, but these errors were encountered: