Dear Karim,
I don’t have Dorico unfortunately, but you might ask that to Daniel or his colleagues at Steinberg’s forum on Dorico.
https://www.steinberg.net/forums/viewforum.php?f=246
In that forum, I have also requested some functions that we couldn’t managed with Finale and Sibelius and received a positive reply 
Best,
Keita
Hi Karim,
I’m pleased to say that these two MusicXML files import into Dorico with basically no problems; there are no validation errors thrown by these files, so thank you for making such excellent progress.
I’ve attached screen grabs of how each file looks when imported into Dorico at the moment.
I would be very interested to see some extended accidentals and try them out in Dorico as well to check that export of microtonal music is working as expected.
Daniel
Karim, one thing I notice that you might want to consider: when exporting notes with ties, you don’t need to restate the tag on each note in the chain of ties: you do need to ensure that you give the value, as this specifies the alteration in pitch, but the element seems to be mostly interpreted by importing applications as a request to show a printed accidental. Dorico has an option to remove all of these additional accidentals, but other applications don’t. I’m not sure if this is something you can easily take into account, but if so, I think it would be worth doing.
Daniel,
Many thanx. I am pleased to know this works on Dorico (even the nested tuplets, that makes, Finale and Dorico only to support these.)
And thank you for the accidental+ties tip. I will look into that ASAP.
I will let you know very soon.
Best
K
Hi there. About the accidentals:
2. Invalid values
sharp-three
in lots of places. The element uses an enumeration of valid values, and the correct value is sharp-3, not sharp-three (i.e. the digit, not the word). The OpenMusic developers should ensure they are encoding only the accidental types that are specified in the enumeration:
http://usermanuals.musicxml.com/MusicXML/MusicXML.htm#ST-MusicXML-accidental-value.htm
=> Actually the accidental we are trying to encode here is a 7/8th tone up, which would correspond, following the naming convention of MusicXML, to ‘three-quarters-sharp-up’ (but this accidental seems not to exist)
I’m not sure sharp-3 is actually what we want either.
Yes Jean,
Thanx to point this out, … the sharp-three isn’t available and it is not meant to be the sharp-3 sign. It is in fact the 7/8th tone up that unfortunately doesn’t exist in the musicxml definition (c.f Jean’s screenshot above) . It did and it exists in fact. Maybe the musicxml guys should update their fonts. By the way, it is really unfortunate that the same thing happens with micro-intervals, meaning, that it is really not very well supported unfortunately even if we follow strictly the musicxml standard definitions. Lately a friend asked me to write (export) 1/4 flat sign, and apparently n his Finale 2010 edition this doesn’t display at all if exported although the accidental tag complies with mxml defs. Anyhow, we will continue the effort to do compliant mxml files (of course beside the 7/8 tone accidental and other standby issues such as nested tuplets, and the sort … :-))
Best
K
I’m able to get the 7/8 sharp and the flats from etf import in Finale 2015, but I need to use a custom font with
all microtonal sharps and flats, set a non-standard key signature including all 1/8 sharps and flats.
I usually prefer 1/8 flat over 7/8 sharp. Would if be possible to also export 1/8-tone flats through etf/mxml
if OM can show them?
I may start using mxml when rhythms get more precise, so it’s good both formats are still there.
Best
Ruben
This is great Ruben. But can you tell us what font you use. And also can you try exporting the 1/8th scale in xml and then importing it back to Finale. If this works, can you send me the xml file in order to cross check it ?
For sharp/flat substitution this is indeed possible. I can send you back a .lisp file that does the trick but once i have your xml file in order to be sure all this is working.
Best
K
I give you some test files. I made a version of Tamburo with some extra signs, “TamburoRuben13.ttf”, and used that to create the microtonal template “Finale2014MicroTemplate.musx”.
My trick has been to open the exported etf and the template, copy the measures into the template and make sure the non standard key signature is applied to the whole document. Then all the 1/8-tone flat becomes available. There is some mystery about the symbol font settings which I just contacted Finale about. This works for me, I’m getting the 7/8 sharps right.
I tried the same trick with mxml, and it doesn’t work. But the only problem was the 7/8 sharp becoming a double sharp. If you have some lisp code to get a flat instead, that would be great.
Best
Ruben
MxmlOM.zip (1.96 MB)
Thanx a lot Ruben.
unfortunately i don’t have Finale. However, can you try this xml file and tell me if the 1/4 flat shows up ?
Any how will tell you how to fix accidental tabula exports by default for mxml and etf.
Best
K
mmquart1.xml (6.7 KB)
I’m making some screen captures of this. “ImportedToFinale.tiff” shows how it looks when opened in Finale 2014.5. There are no flats and also some cunfusion about the sharps. “ShowAccidentals.tiff” shows that there are a lot of naturals. The 7/8 flat in the etf documents had no accidental at all until the non standard key signature was set up, but with this xml just naturals.
“CromaticTest1.tiff” is from yesterday, an export from OM 6.10.1 to Finale. The sharps seem right, except the 7/8 sharp.
Best
Ruben
xml-test2.zip (2.11 MB)
Thank you for all the great work on this, Karim.
MusicXML 3.1 will have much more complete support for microtonal accidentals as part of an overall improvement in SMuFL font support. In fact that is what is being worked on right now. It’s at https://github.com/w3c/musicxml/issues/109 in our GitHub issue tracker, and the pull request is at https://github.com/w3c/musicxml/pull/130.
Hello all,
Is there an in-progress build of OM with the enhanced XML export functionality, or some other means of patching with the enhanced export code? It would be of great benefit to my current project! If not, I shall simply transcribe by hand.
Best,
Nige
Hi Nige,
What do you mean by enhanced XML export functionality ?
I have fixed most of the problematic issues. The code is waiting to be included in the Kernel of the new release of OM. (it should be compile din an image in order to override the already existent code.)
Now what works and what doesn’t :
Now what doesn’t work :
Now if you need the code (work in progress i will post it here as a lisp patch).
But please be aware this is ONLY temporary…
Best
K
Dear Karim,
Many thanks for your very quick response!
Please do provide your work-in-progress code - I’ll happily take my chances and also I can report on the success with which Sibelius imports the XML exports.
Many thanks again, and best wishes,
Nige
… and here is the temporary code. [to be put in the patches folder]
and use it only with the export-musicxml function (see post above).
Best
K
export-mxml-new-vers5.lisp (65.5 KB)
Dear Nige,
Thanx i will really appreciate to see also compatibility with Sibelius. Hope It will work for you. (didn’t test nested tuplets on Sibelius).
Soon i will be working to fix the 1/4 tone issue. apparently it is not due to our export code but to the parser’s support in Finale and others (such as musescore, etc…) .
Anyhow, all feedback will be appreciated.
Best
K
Thanks for this, Karim.
Here are the results from the export-function you included previously. Transcribe by hand it is! Not such a chore really, as I have to do this in Illustrator anyway!
This is slightly off-topic, but I would love a function to export groups of measures, or individual measures in SVG/EPS format from VOICE/CHORD-SEQ and so on. That would be very useful for me.
Thanks again for your help,
Nige
I think the Finale import may be getting confused because 1) the nested tuplets don’t seem to add up, and 2) OpenMusic doesn’t seem to be exporting some of the tuplets correctly.
For 1), what does that lone 9 mean in the first nested tuplet? To add up in the larger tuplet, it seems like it would need to be 9:2. Apparently OpenMusic is exporting it as 9:6. If it’s 9:6, it doesn’t seem the nested tuplets add up into the 26:24.
If OpenMusic is exporting the 2nd nested tuplet as 12 in 15 instead of 6 in 5, that would also cause a problem for the importers. Similarly for the remaining tuplets, which all seem to be off by the same 2 to 3 ratio.
If I am misunderstanding something please let me know. If you could please post the MusicXML exported from OpenMusic for this example, that could also help figure out where the problems may be.
Dear Michael,
Thanks for following this up.
I’ve transcribed the structure of the first bar, which I’m attaching, but we’ve arrived at the same conclusion.
Please find attached the XML file as well.
Best,
Nige
Test_export.xml (388 KB)