You couldn’t 
That’s one of the frustrations of OP, who couldn’t post that link.
No bug, as far as I see, at least not on Dorico’s side. Just no implementation of a workaround to circumvent missing features of another program.
Thanks for the replies. I appreciate it. My background is in hardware/firmware/software engineering (incl. data i/o) and I have managed large forums, data centers, etc. I have also been a point person for quality and customer experience at multiple companies. And, while I may express some frustration, my feedback is not hostile in any way. I hope it will lead to some improvement. I have an investment in Dorico and I would like it to work properly. I would also like to be able to recommend it to others – and the tuplet tremolo problem is a significant blocker because of the need to import legacy scores.
Regarding trust/forums: the current forum trust levels and the logic behind how they are being used needs to change. It shouldn’t be hard for users to post basic bug reports. And if the underlying software is Discourse, then the trust levels should be highly configurable…and can be configured to be more intelligent and user-friendly.
My current Steinberg forum user experience is poor and there are major barriers to posting/collecting product feedback. Statistically, every extra barrier in the path of collecting product feedback (or extra click in a click-through process) causes significant data/user attrition. For onboarding and quality/experience feedback, the goal should be to collect as much feedback as possible and for it to be as easy as possible for users to provide it vs. favoring forum gamification.
Regarding trust and ACLs:
Examples of more useful trust/validation criteria:
- product ownership/licenses
- duration of product ownership
- validated/known email address that links to product ownership/licenses
- duration of forum membership
- known IP info tied to product ownership
- validated bug reports and other useful posts (as flagged by X admin user)
Examples of poor trust validation criteria, especially when the forum is the primary product bug-reporting interface and intended feedback channel:
- number of forum posts
- other forum behavioral activity, such as liking or viewing posts
Arbitrarily gamifying post counts and other irrelevant behavioral criteria doesn’t serve the critical path feedback-gathering mission and detracts from overall user value to the company. PM/Marketing should be all over this issue and working to make sure that they get every scintilla of user/product feedback. It’s almost as good as printing money.
As for the MusicXML file, the Finale image in my above post is after importing the file into Finale. If Finale can import tuplet tremolo in a MusicXML file correctly, Dorico should also be able to do it. It is a finite engineering problem and concrete parsing task vs. mysterious MusicXML black magic or demand for a crazy feature. Make a more generic importer that does a better job. And Dorico is the only path for Finale users, so there is additional impetus to ensure MusicXML functionality and Finale parity (a user satisfaction issue, given the forced crossgrade).
Further, if MusicXML has variable formatting, then Dorico could (and may want to) ask users what to do with certain data types when ambiguities arise. In each case, it just needs 1 pattern to know how to parse additional similar instances. For example, consider Excel – there is an import wizard that includes a step to identify delimiters. And yes, there is a MusicXML preferences section, but it doesn’t handle this case or the import would work properly.
Similarly, Dorico might benefit from a MusicXML import wizard that could look at the file, preflight content, help users choose the correct preferences, etc. It could flag the tuplet tremolos as a unique data component and ask the user to indicate the preferred notation – maybe either fully or partially barred, etc. For example (as Dorico generates them):
There are many things that an import wizard could do to make the import process much smarter, instead of telling the user nothing and dumping out a blank score. It’s a poor, time-wasting implementation. It could even show a sequential preview - like printing a PDF.
As I mentioned, beyond not importing tuplet tremolo correctly, Dorico also adds extra beats that violate the established time signature – and that points to other internal state and code intelligence failures. Doesn’t the importer know that it’s in 3/4 time? If so, why would it add 5 beats in a measure? Where is the consistency checking? Where is the code that says – “oh, I had a meter overrun - was it because of cumulating dotted quarters instead of dotted half notes on tremolos? do I need to recheck the input? should I do additional consistency checking? should I query the user’s preference?” etc. – instead of just running open loop with insufficient internal checking and correction. In the beginning of the import process, Dorico knows there are tremolos, knows that the meter is 3/4 and it still assigns the wrong note values for the tremolos. It’s not a MusicXML problem. It’s basic note/time certification and/or parser range failure.
There are multiple problems with how the import process is failing – no error reporting, no user feedback, wrong note values, wrong tremolos, wrong beats per measure, blank staves, etc.
Also, on top of all of those issues, what happened to the Notation Options for tremolo beaming that used to be present in version 2 (from the older post)? Am I missing them somewhere? If not, why were they removed?
Dealing with tuplet tremolo in MusicXML would seem to be a core functionality bug/issue, not black magic, and Dorico does not appear to be parsing it properly as a finite problem. It is a commonly-used textural item in string and wind playing and it should work. Dorico should be the smartest and best at what it does – which is to do professional scoring.
Anyway - thanks again for the replies. I will wait to hear back from Dorico regarding the file. Maybe there is some arcane combination of options that will make it work - that would be great. I am a Dorico novice and fan, and I could be wildly wrong. Hopefully I am. But, at a minimum, there is an import clarity/usability problem. Otherwise, I hope they can fix this issue with MusicXML import and also make other ease-of-use improvements.
“Statistically” this is considered one of the most responsive help forums available anywhere. I am sorry if you are having difficulty accepting it.
Posting your resume as a preamble to a rant doesn’t count for much; there are many very accomplished and qualified contributors here who do not need to cite their credentials; their contributions and solutions speak for themselves.
The reality is that when any user can’t post a basic bug report (the intended purpose of this forum), has to try multiple times, can’t even include a link to other in-forum content and has to create a scroll of 5 posts to include relevant images that are no longer in the direct context of the original post – not to mention all of the wasted time – collectively, those issues constitute a very poor user experience (by any standard). I almost didn’t even try to post the bug again – but I took more time today to do it to try to help.
Besides the obvious Dorico import bug, the forum ACL restrictions need to change to improve UX/CX. And if you had a problem with my use of the word “statistically,” there is a whole industry around the science of UX- and click-induced user abandonment. If you’re not familiar with it, it is a very interesting topic. Try googling phrases like: “% user abandonment per click”
I’m sorry you took issue with my post…which was not a rant or intended as hostile in any way. I stand by remarks and they speak for themselves without your further ad hominem editorializing. So, please turn it down a notch. If you don’t have anything helpful to add, it’s OK to just move on and not post.
My straightforward comments represent real problems relating to Dorico/MusicXML and the forum implementation, none of which criticized other posters or the intended helpfulness of Steinberg employees, like Ulf. And, in fact, I have noted Steinberg’s helpfulness in my earlier interactions.
And the point of posting minimal background info was to provide the context that I fully understand trust levels, ACLs, forum use/deployment/customization, data i/o, interchange standards, file parsing, and many issues relating to UX, CX, user feedback management and other relevant topics. I was just trying to save time and also indicate that I can do technical debug, if needed (as I have done in the past). I’m sorry it was an issue for you.
You’re welcome to disagree, but your attitude and negative commentary are not helpful. So, whatever the issue is, please do not project intent, towards me or otherwise, where none exists.
Thanks.
Thanks for reporting this issue, and I’m sorry that you’ve had problems with making the post here on the forum. It would indeed be good if we could take a new poster’s existing Steinberg licenses into account when determining their initial trust level. I’m not sure whether that’s something we could build into Discourse as a plug-in or something, but I’ll bring it up to the people who manage the forum software as a point for discussion.
Regarding the specific issue of how to handle two-note tremolos from Finale, to expand a little on my previous reply on this topic (linked earlier in this thread), it’s a tricky one to handle, because we would have to use a heuristic for detecting them, and any time you are relying on heuristics to interpret data in MusicXML rather than being able to reliably import the data as written, you open up the possibility that you’ll drag in false positives and create harmful effects elsewhere.
We haven’t up to this point prioritised this issue sufficiently highly to actually work on it, but please rest assured that it is on our backlog and we do plan to address it in future.
(No one has been forced to crossgrade to Dorico. It’s true that MakeMusic recommended Dorico as an alternative, but Sibelius also offers an attractive crossgrade price, and of course MuseScore is free.)
Daniel - thanks - sounds good! One request - until Steinberg resolves the trust level customization(s), would it be possible to change my user class so that I can post bug reports with links and images? If so, that would be very helpful. I wanted to post links to W3C in this post and couldn’t. It’s very frustrating.
Regarding the problem:
I just took a look at the XML output vs. the 4.0 W3C spec. I haven’t parsed MusicXML before, so forgive any errors. I reprocessed the original file through Finale and took at look at the exported data vs. W3C v4.0. It looks like the problem has to do with Finale’s (likely) incorrect export format in v2014 (using MusicXML 3.0) and v27.4 (using MusicXML 4.0) of the definition for the tuplet-number element. Instead of using it for number of notes, they appear to be using for number of beats - not correct per the spec.
W3C says (can’t post the link): The tuplet-number element indicates the number of notes for this portion of the tuplet.
There are 2 key elements that also relate to time-modification :
The tuplet-actual element provide optional full control over how the actual part of the tuplet is displayed, including number and note type (with dots). If any of these elements are absent, their values are based on the time-modification element.
The tuplet-normal element provide optional full control over how the normal part of the tuplet is displayed, including number and note type (with dots). If any of these elements are absent, their values are based on the time-modification element.
For 3/4 tuplet tremolo of 2 notes per measure (showing dotted half note value), tuplet-actual shows:
<tuplet-actual>
<tuplet-number>3</tuplet-number>
<tuplet-type>16th</tuplet-type>
</tuplet-actual>
tuplet-number should be 2 in this context. There are 2 actual notes, not 3, and they should be barred as 16ths.
tuplet-normal shows:
<tuplet-normal>
<tuplet-number>3</tuplet-number>
<tuplet-type>quarter</tuplet-type>
</tuplet-normal>
This section is also incorrect and might be causing import confusion.
In this context, it shows a 3 for tuplet-number, and, according to W3C, I think tuplet-normal should show 12 16ths so that it is a common layout reference vs. the tuplet-actual definition. Or, maybe it should fall back on time-modification to show 2 beats in the span of 3. Anyway, it looks wrong, but would be easy enough to fix on import, since the file uses defined tuplet elements instead of using only time-modification.
Also, the file includes the app name and version numbers in order to set a case flag for the parser. And, the note heads are defined correctly as unfilled/open in this 3/4 case. Hopefully, it would also do the right thing for note heads in other time signatures. Testing issue.
I am going to try to patch the 3/4 xml data and will let you know the outcome. I will also take a look at a natively-generated tuplet export from Dorico 6 in MusicXML.
asherber - thanks. I disagree on ownership, technical and business terms. Sibelius is an Avid software rental and not an option. I actually own a “perpetual” mbox license and when it hit the end of the year, all the “perpetual” features were gimped, including Sibelius (Artist → First). I own the car, but they repossessed the wheels. In terms of output, complexity, etc., MuseScore is not a comparable option. So, Finale users had little choice, as has been hotly debated on the Internet for a long time. MakeMusic left its users with only 1 real option and recommendation. And, since Steinberg benefited (substantially) from picking up the MakeMusic userbase, there is at least an ethical (if not business…or contractual?) duty to try to help those users remain compatible…and not without (substantial) compensation. I think the crossgrade price was $149 – and…hmm…how many users – maybe at least 50K? (just a guess - could be more - who knows?). So, the deal could have been in the range of ~7.5M+ to Steinberg. Or in other words, “here - we’re going out of business - take care of our users and their aggregate $5-10M+ dollars…plus another $3-5M+ every time they upgrade.”
That may be a feature of the mbox license, as opposed to Sibelius. I have a perpetual Sibelius license that I bought several years ago, and all of the functionality still works as expected.
Looking at the badges on your avatar, it seems you earned the “Basic” trust level a few hours ago and should be able to post links and images.
My colleague from support helped there out already
Thanks for fixing the forum issue!!! 
I have been poring over the W3C MusicXML spec and trying to figure out the minimum set of changes / errors in the existing file – including finding the minimum set of correct MusicXML import preferences for Dorico. The spec allows for flexible ways to manipulate note duration, including with certain overrides, and it is definitely a headache-inducing cat-herding exercise.
As above, I don’t think Finale’s export model is correct, but it is, at least, consistently incorrect (and identifies its intent with tuple elements, as above). And I have to do some retesting with Dorico for xml import vs. settings. As in the 2019 tuplet post, it looks like Beam Groups needs to be checked.
Also, I seem to be encountering issues with Dorico where it has trouble cleanly re-importing a MusicXML file over an existing imported instance. So, I have had to close the window and start cleanly every time.
Anyway - I have been iterating on a single measure and have gotten to the point where it imports correctly from MusicXML. So…now I have to see if I can zero in on the exact failure now that I have the working config.
I couldn’t get Dorico to have full beaming with dotted half notes. So, I had to abandon the tuplet sections of the xml and just use tremolo and time-modification. In the preferences, I am down to telling Dorico to enforce note duration, beam groups and tuplet placement on xml import.
Here is the result:
Here is the current version that works:
<measure number="1" width="255.625">
<print>
<system-layout>
<system-margins>
<left-margin>173.75</left-margin>
<right-margin>0</right-margin>
</system-margins>
<top-system-distance>751.875</top-system-distance>
</system-layout>
<staff-layout number="1">
<staff-distance>74.375</staff-distance>
</staff-layout>
</print>
<attributes>
<!-- use 4 divisions per quarter note to indicate note duration - or 16ths -->
<divisions>4</divisions>
<key number="1">
<fifths>1</fifths>
<mode>major</mode>
</key>
<!-- Set the meter to 3/4 time -->
<time>
<beats>3</beats>
<beat-type>4</beat-type>
</time>
<staves>1</staves>
<clef number="1">
<sign>G</sign>
<line>2</line>
</clef>
<transpose number="1">
<diatonic>-1</diatonic>
<chromatic>-2</chromatic>
</transpose>
</attributes>
<!-- show the dynamics below the staff -->
<direction placement="below">
<direction-type>
<dynamics default-x="113" default-y="-74" halign="center">
<mp/>
</dynamics>
</direction-type>
<sound dynamics="69"/>
</direction>
<!-- definition for the 1st note of the tuplet tremolo -->
<note default-x="96.875">
<pitch>
<step>B</step>
<octave>5</octave>
</pitch>
<!-- set the note duration to half a measure - or 6 16th notes based on granularity in division -->
<duration>6</duration>
<voice>1</voice>
<!-- we want tuple tremolo dotted half notes with open note heads, so type half with a dot tag -->
<type>half</type>
<dot/>
<!-- the tuple element isn't necessary - just indicate 2 actual dotted half notes in the place of 1 normal one -->
<time-modification>
<actual-notes>2</actual-notes>
<normal-notes>1</normal-notes>
</time-modification>
<stem default-y="-17.5">down</stem>
<staff>1</staff>
<notations>
<!-- indicate 16th note tremolo beaming and slur -->
<ornaments>
<tremolo type="start">2</tremolo>
</ornaments>
<slur number="1" placement="above" type="start"/>
</notations>
</note>
<!-- definition for the 2nd note of the tuplet tremolo -->
<note default-x="190.625">
<pitch>
<step>A</step>
<octave>5</octave>
</pitch>
<!-- set the note duration to half a measure - or 6 16th notes, based on granularity in division -->
<duration>6</duration>
<voice>1</voice>
<!-- we want tuple tremolo dotted half notes with open note heads, so type half with a dot tag -->
<type>half</type>
<dot/>
<!-- the tuple element isn't necessary - just indicate 2 actual dotted half notes in the place of 1 normal one -->
<time-modification>
<actual-notes>2</actual-notes>
<normal-notes>1</normal-notes>
</time-modification>
<stem default-y="-20">down</stem>
<staff>1</staff>
<notations>
<!-- end the tremolo beaming and slur -->
<ornaments>
<tremolo type="stop">2</tremolo>
</ornaments>
<slur number="1" placement="above" type="stop"/>
</notations>
</note>
</measure>
If I use the same XML file as the image above and turn off Beam Grouping in preferences, the note durations default back to 3/4 slurred dotted quarters and the tuplet tremolo beaming disappears (see below).
So, in this case, does the preference flag point to an issue where Dorico does not natively follow the MusicXML spec without prompting?
Now that I have a better understanding of MusicXML and a working example with the required app preferences, I am going to look for the minimal patch set of note changes for the Finale export to make it compatible. I would like to try to leave the existing tuplet xml structure mostly unchanged, if possible.
Is Dorico capable of showing full tuplet tremolo beaming or only mid-group slashes? I guess I’ll find out one way or another.
I find that, the better one can actually use Dorico, the quicker one can fix those music.xml export/import errors. How to correct the note value, how to input tremolos and different two note tremolos into the popover and so on. It is an illusion that music.xml export/import will work without translation errors.
Fixing and converting these translation errors into Dorico language is actually a fun bit. I like that part, because it saves me from inputting the music anew and at the same time let me already create something new.
Yes, you can change the appearance of multi note tremolos:
I misspoke when I posted this morning: it turns out that we do in fact already have some heuristics in our MusicXML importer to try to handle the peculiar way in which two-note tremolos are exported by Finale. (To be fair, the oddness of the encoding only reflects the fact that Finale doesn’t have support for two-note tremolos, and so they are always faked by way of automated workarounds courtesy of TG Tools’s Easy Tremolos or Tremolos plug-in, so the MusicXML export itself is arguably not to blame – though it would certainly have been better for the MakeMusic team to implement those heuristics on the export side, so that exported MusicXML would include properly-encoded tremolos in more circumstances, but that ship has well and truly sailed at this point.)
However, there are some limitations in the current heuristic, as exposed by the cases discussed here. We will look into trying to enrich the heuristics in order to handle more cases as soon as we can. As before, I can’t promise when this will be, however.
k_b - Thanks - that is exactly what I needed in order to be able to see the translation from my non-working file – or at least a working scenario. The problem is that I can’t import at all because of the tuplet tremolos. There are a lot of them and they cause the majority of the score to be blank after import fails. It’s another potential issue that would be great to fix, if possible. But thanks - I will take a look to see what Dorico generates in different modes. The main issue will be whether or not there is a tuplet/beam version vs. time-modification/tremolo. As I mentioned above, I think the presence of the tuplet element in Finale MusicXML export is a good thing because of the intent it represents. It’s just a matter of translating it to meet the spec so that it is compatible with Dorico.
dspreadbury - No worries - sounds great! Maybe I will have some more data by then. I have noticed some weird things with Dorico import, as I mentioned above. I am going to re-test the double import scenario to see if it was just a wild setting issue. I was making lots of changes to try to make it work. I also saw import hang at 16% on one run. Anyway, there may be some import robustness issues that are not specific to tuplet tremolo issues.
I was glad to see that there was some meaningful xml error feedback once I got past some initial issues. However, there were a number of instances where there were xml validity issues and I got no feedback - just said invalid. So, another suggestion would be to make sure the initial validity checker also provides feedback when parsing fails.
Tuplets have been known to cause import difficulties even without tremolo.
I can understand why there might be a problem with tuplets. In general, music notation represents significant analog complexity on a variable landscape – so not easy. If it were easy, everyone would do it. 
But, a large portion of the tuplet tremolo problem may be finite, including importing from any version of Finale that implements the tuplet element.
There are always exceptions in analog parsing, but hopefully, Steinberg will have fixes over time as they have mentioned.
Also, I have discovered other issues in my attempt to understand this problem. When I import an original 11.5Mb xml file into Dorico and then try to re-export, it becomes 38.5Mb. I’m not sure why that’s happening yet, except that I know Dorico had problems on import and the file may be filled with error-related spew from the failed import. And, after I import the xml, save it as a .dorico file, then try to export it as MusicXML, there is some set of variables where Dorico gets stuck at 16%, and I have to force-quit the app with the task manager. At that point, Dorico seems to be in a soft crashed state. Even when I quit the app, there is a process that doesn’t terminate and it still shows up in the task manager.
And it looks like I am not able to import the same xml file twice into the an open Dorico instance. I have to restart the app/window. So, it doesn’t appear to do clean imports via MusicXML, but I am not 100% certain yet about this issue. Yesterday, I was mostly iterating trying to figure out tuplet tremolo. I still have to do other specific testing to see if this issue is real or not.
But…MusicXML import/export seem to have some robustness issues that may warrant additional focus. It feels like there are a number of bugs in this area.
The link from k_b above for tremolo formatting was very interesting/helpful. It seems that as long as Dorico can interpret that a tuplet tremolo is present, all of the visual formatting is under the control of the Engraving Options – which makes sense if that is the user preference…but probably overrides specific options in MusicXML (options defined in the ornaments and/or beam elements, for example). However, the Engraving Options reformat the score dynamically – so maybe less of an issue.
The Engraving Options dynmically reformat after hitting Apply.
Choosing “All lines joint stems” shows:
Choosing “Outermost line joins stems” shows:
Choosing “No lines join stems” shows:
I tried to do some testing with the preferences, but saw that, Dorico did not display the correct tremolo unless I checked “Beam Groups” to tell it to obey the xml spec. So, Dorico is not interpreting the xml correctly on its own and may also be overriding it with the Engraving Options even in the case where Beam Groups is unchecked. So, the preference inheritance may not be correct – but I haven’t verified this issue - too many other issues yesterday + digesting MusicXML.
As above, the main thing I am trying to figure out is the minimal delta between Finale’s incorrect export definition for tuplet tremolo vs. what Dorico will see as valid. Finale does some unusual things – like defining the tuplet tremolo division element to be 240 in 3/4 time. Why would you need to 240 divisions to a quarter note? 
…maybe 64th notes as an extreme, which would still only be a division value of 16 (per quarter note). But…still experimenting. Maybe I’m missing something.