[Musicxml Export] - Tbox and Vbox after measure 1 don't export

• Jul 5, 2019 - 00:48
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S2 - Critical
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project
Tags

Hello,
For a long time, Musescore can't export titles and other information entered as tbox or vbox after measure 1. This happens in scores with multiple movements, e.g.:
https://musescore.com/user/13502736/scores/5329984
I have to look into the uncompressed mscx file to get all things back after the conversion. Could this be solved? The box information after measure 1 can be simply exported as words attached to the topmost staff, unless the coming MNX is published with more explicit flow of system-wide or page-wide texts.

Regards
Haipeng


Comments

Priority P1 - High

Bumping this as I'm going to be needing this too. I have no idea the right way to export such text, but ideally it would be something exiting MusicXML tools can read.

FWIW, my use cases isn't just titles on movements, but "scores" that are actually more text than music - educational materials. So, a paragraph of text, a short musical example, another paragraph of text, another short example, etc.

In reply to by Marc Sabatella

Main reason for not importing/exporting tboxes and boxes is that no real equivalent exists in MusicXML. The options are:

  • credit-words: having a fixed page position, interaction with the systems undefined
  • words: attached to a note

Both are reasonably easy to export but hard to import. See https://music.stackexchange.com/questions/44717/does-musicxml-support-a… for a more detailed explanation.

Please find attached examples of large texts in system text and vbox in MuseScore and MusicXML. The latter files required editing, as MuseScore currently does not yet supports this. I would be interested to know whether this is useful to you.

For my purposes, exporting is all I really care about. I think Haipeng and I are both interested in Braille translations, and as long as the info is there in MusicXML to work from, it's better than nothing. I'd want the relative location relative to the music to be preserved, since for me it's text interpersed with music. So, "words" I guess is what I'd want, although I'm not sure which note to attach to - the last note before the text, or the first note after presumably. Whichever a Braille converter is more likely to place between the measures, I guess.

I also prefer the common blocks, since they will always be exported. Putting them at the measure they are at the Musescore ile, attaching to the first note or rest of the first voice. Unless MNX is published, we have to render this way.

Haipeng

In reply to by hhpmusic

Haipeng,

what do you mean "prefer the common blocks" ? So far I understand you'd like the tbox and vbox to be exported as MusicXML words.

Does any of the MusicXML files I have attached works correctly for you ?

Do you need to have the system distance exported ?

Regards, Leon,

Sorry I typed something incorrectly at that time. I prefer to render the boxed text as words, since the credit block will be ignored by the braille translation software currently, and we also can't determine its exact position, either at the top or bottom of a page or system. The system distance can be exported as back-translation, but is of no use to braille transcription currently. In the future, It should be put into the sequence in MNX.

Haipeng

FWIW, for me personally, handling of text frames (and text within vertical frames) is the biggest remaining issue in MusicXML export. For my purposes, treating any text in a frame (after the header as "words") attached to the first note encountered after the frame is what would make sense.

BTW, despite the recent change in https://github.com/musescore/MuseScore/pull/5509, I would not actually want all frames before the first measure to be necessarily considered part of the header. My main use case here is producing educational materials. My title frame is just the title etc. Right after that I will almost always have a text frame containing ordinary non-header-type text I would want attached to the first note of the score, just as I would want the text of any subsequent frames attached the first note after that frame. Here is a typical example:

https://musescore.com/marcsabatella/triads?from=notification

Conceptually, the header is just the first frame with the title text "Triads". The next frame (with the text "a chord is a set of three or more notes sounding together" is not part of the header, it's the beginning of the actual content. Not sure if there is any way to differentiate my use case from that of the Lieder Corpus, though, and I will grant their usage is probably the more common and hence important to support. Not sure how Braille conversion tools will see the difference. But if it were possible to have an option to control this, that would be nice. Or, I wonder if the Lieder Corpus folks would mind having these frames handled both ways - adding to the credit words but also appearing as words on the first note?

Pull request 5509 exports all text in vertical frames above the first system as credit-words, to support the OpenScore Lieder Corpus style. As far as I can tell it does not export the text frames used in the Triads example.

Using vertical frames for the credit-words and text frames for other text could be a way out, although I would not consider it a very elegant solution. I expect it will be hard to explain the different behaviour to users.

The vbox texts are for title pages as far as I can infer from the scores I have got; while the tbox handles texts on music pages including those outside staff. So implementing vbox as credit page attachments will generate text-only pages correctly, but will not if attached to the first notes. On the contrary, converted tbox texts attached to the first notes can be put correctly on the music pages as long as their spacing values are correct.

Haipeng

Still working on this, exporting text frames as words implemented (which took a lot more effort than I had expected). Now working on exporting vertical frames as credit-words, which is easier. Unfortunately, Marc's Triads file exposes several shortcomings in the existing implementation, besides simply exporting the frames a number of additional bug fixes will be required.

Also implemented exporting vertical frames as credit-words. This exposes a number of (existing) issues:
#299660: [MusicXML export] spurious newlines in words caused by font changes
#299661: [MusicXML export] breaks in horizontal frames not exported
#299662: [MusicXML export] horizontal frame not exported
#299663: [MusicXML export] new page not exported
#299664: [MusicXML export] x offset not exported for text in vertical frames
Result of exporting Marc's Triads file attached for reference. Would like to receive feedback on the results so far, but will still create a pull request for the current status (even though it is not perfect yet, it doesn't hurt to have it included).
Current state of the code available in https://github.com/lvinken/MuseScore/tree/291758-musicxml-tbox-vbox-exp….

Attachment Size
Triads.musicxml 33.28 KB

Thanks for your work on this! I imported the Triads.musicxml file into MuseScore, and while initially it looked like everything was attached to the first measure, now I see that's just because the system breaks were lost on export. Which I assume is #299661: [MusicXML export] breaks in horizontal frames not exported. Probably not an issue for me in practice, my reason for wanting MusicXML export on a score like this is more about converting to Braille, and I don't think the original line breaks are very relevant for that.

Thank you Leon! Marc, do you mean the loss of system or text line breaks? If it's text line breaks, it'll be of no problem; however, if system breaks (thus print new-page or print new-system) are lost, this is still a problem, since we need these breaks to be included as special indications in braille so that blind musicians can easily communicate with sighted teachers or colleagues.

Haipeng

I believe the issue is neither about "normal" system nor text line breaks, but specifically about breaks I had attached to horizontal frames. Normal system breaks are exported, but given the fact that the text in the horizontal frame are now converted to ordinary words, there probably is no clean way to force a break after them in MusicXML.

So the music will still break in the expected places normally, just the special formatting I had done to position text nicely on the page won't be preserved, which again won't be relevant for me (or for most people).

Further investigation shows that the current MuseScore (i.e. without my tbox/vbox changes for this issue) does not export breaks to MusicXML if the break is in a horizontal frame. This applies to all breaks (system, page and section). To be fixed independently of pull request 5606.