[Musicxml Export] - Export unsupported symbols as "symbol"
This is much like a feature request. When going through the palettes, I found lots of symbols and lines and articulations are not able to be exported into Musicxml. Some are not implemented, while some have no Musicxml equivalents. Fortunately, all of them are SMUFL glyphs, having the standard SMUFL names. So, to ease development, can we include these as a "symbol" element under "direction"? For example, when we input a l.v. symbol as either a line or an articulation, or a wide vibrato as an articulation, the former two are not implemented, while the latter are not available. If we just use the symbol or other-direction to attach them with the note, braille music transcription software can still be implemented to recognize and convert them correctly into braille, and the Musicxml file is much more complete. Is there a way to create a sheet or table for the mapping so that I can make the list myself, then submit to one of you to apply (I can try the symbols one by one and put them into the list, but as a non-programmer, I can't go into the complicated real programming code)? Thank you in advance!
Haipeng
Comments
Relates to #270643: [EPIC] MusicXML import/export issues and #281511: [EPIC] Braille friendly musicxml export
I just went through the palette and the symbols list, and found the only place we should implement the "symbol" element is the symbol section where all SMUFL symbols are listed and categorized. This section is not available in the standard palette, so the first and the easiest thing is simply copying the symbol into Musicxml with the unchanged Bravura name. Some of these symbols can be implemented as standard articulations or technical elements, but this needs deeper implementation, and we can do the easiest way first, and then go step by step.
Haipeng
In reply to I just went through the… by hhpmusic
@hhpmusic, would you prefer the symbol or other-direction element be used for this purpose? It seems that "symbol" is used to insert arbitrary SMuFL glyphs in text whereas "other-direction" is used to insert a SMuFL glyph somewhere that is not text (e.g. to create a new kind of articulation).
I think if the user has added a symbol from the Symbols section of the Master Palette (shortcut: Z) then we should use MusicXML's "other-direction" element, but if the user created staff text (shortcut: Ctrl+T) and then added a special musical symbol (shortcut: F2) then we should use MusicXML's "symbol" element?
In reply to @hhpmusic, would you prefer… by shoogle
I agree the symbol is to be used in text. For other-direction, here's a risk as the attached, thus every note in a chord has a different symbol, then the other-direction will not work correctly. I suggest to use other-notation, other-articulation, other-ornament and other-technique, according to the categories of the master palette. This may be a bit complicated, but if to be easy, other-notation can be enough. Since it's attached to a note, the attached example will be correctly exported.
I have submitted a pull request with a partial fix for this issue: https://github.com/musescore/MuseScore/pull/8425
This fix should allow to export
Symbolelements attached to notes or measures, but it doesn't deal with symbols which are found in text elements. The situation with them is that in-text symbols are not stored as special symbols but are internally just plain Unicode characters with the proper font being enabled for the relevant text fragment. Therefore it seems we would need to detect the relevant text fragments by font name which seems not quite reliable and future-proof. I'll try to figure out whether there are better options available.In reply to I have submitted a pull… by dmitrio95
Thank you! Unicode symbols in text block is partially ok for me. Of course, turning them into appropriate glyph names in Musicxml is always preferrable.
Fixed in branch master, commit 7704d1cfbb
_Partial fix #298623: export Symbol elements to MusicXML
Exports Symbol elements to MusicXML as or
tags, depending on a type of the symbol's parent element._
Automatically closed -- issue fixed for 2 weeks with no activity.