Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MusicXML: full measure rests export fails #98

Open
FelippeRoza opened this issue May 22, 2017 · 3 comments
Open

MusicXML: full measure rests export fails #98

FelippeRoza opened this issue May 22, 2017 · 3 comments

Comments

@FelippeRoza
Copy link
Collaborator

FelippeRoza commented May 22, 2017

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:

  <part-list>
    <score-part id="P1">
      <part-name />
    </score-part>
  </part-list>
  <part id="P1">
    <measure number="1">
      <attributes>
        <divisions>1</divisions>
        <time symbol="common">
          <beats>4</beats>
          <beat-type>4</beat-type>
        </time>
        <clef>
          <sign>G</sign>
          <line>2</line>
        </clef>
      </attributes>
      <note>
        <rest />
        <duration>4</duration>
        <voice>1</voice>
      </note>
      <note>
        <rest />
        <duration>4</duration>
        <voice>1</voice>
      </note>
    </measure>
  </part>
</score-partwise>
@FelippeRoza
Copy link
Collaborator Author

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.

@uliska
Copy link
Collaborator

uliska commented May 24, 2017

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.

@FelippeRoza
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants