Export options

Am I correct in thinking that there’s no way to export an entire composition – one that contains multiple flows/movements – as a single MIDI or MusicXML file? Try as I may, I can’t convince Dorico to do anything but output a separate file for each flow.

Also, although there are options for NOT exporting MIDI output to a separate folder, I can’t find any way to tell Dorico to do the same for audio export. MP3 files always get stuffed into some new folder on my disk.

Am I missing something obvious?

That’s correct: Dorico always exports each flow as a separate MIDI or MusicXML file. MIDI doesn’t have the concept of multiple pieces of music within the file, so Dorico would have to do something like insert a period of silence in the MIDI file. MusicXML does support the ability to have multiple pieces within the same compressed MusicXML file, but so far as I know no other software can import such documents correctly, so we haven’t gone to the effort of supporting this in Dorico’s own MusicXML export.

Daniel:

I’m not sure I understand the constraint. E.g., like MIDI, MP3 doesn’t “understand the concept of multiple pieces of music within a single file”. Sure. However, it’s possible (and Dorico supports the function) to export an entire composition, multiple flows and all, as a single audio file. FWIW, I’ve configured Dorico to insert no pauses between flows, but regardless, I’m not sure why the issue of interflow silence would be a showstopper. Simply inserting a silent measure or two could easily be done within the MIDI spec. Algorithm: i) write MIDI data specified by flow #1 to .MID file; ii) increment time stamp (if a period of silence is needed) or otherwise append any MIDI equivalent of a series of rests to the file; iii) append MIDI data specified by the next flow. Done in one.

Hey, I’m not trying to argue, just trying to understand why it made sense to make a seemingly arbitrary design decision – limiting exported MIDI data to the contents of a single flow – that creates a burdensome constraint.

At this point, I’m ready to just forget about the whole “flow” concept. I don’t see enough of a benefit (over the obvious alternative of creating a separate project for each movement of a longer piece) for a composer who wants to isolate components of a composition. I’m aware that, as a new user, I may be missing something fundamental, but at this point, flows just seem like yet one more unwelcome, unnecessary, source of complexity, constraints, and overhead.

What I’ll probably do now is simply streamline the project by merging everything in this lengthy composition into a single flow. And then just forget about flows in general. I don’t see anticipate loss of functionality in doing so, so that seems like the course of least resistance.

Unless I really am missing something obvious – which is definitely possible – that you can point out…

Anyway, thanks for your help. As I’m sure you’re aware, tackling an application of this complexity is a bit of a roller-coaster ride and any expert guidance is VERY MUCH appreciated.

It’s quite possible that you don’t need to use flows if you typically work with completely through-composed music with no breaks and no separation between sections (be they movements, numbers, scenes, or whatever). Flows are typically helpful when you are working on a multi-movement or multi-section work that has distinct sections, and especially so if you want to produce performance materials that highlight these distinct sections with new titles, reset of bar numbers, time signatures, key signatures, rehearsal marks, and so on.

But if you’re simply using flows to provide arbitrary breaks in your work that don’t need to be presented as separate sections, it probably is working against the grain of the software to use flows in this way.

No design decision we make is arbitrary – we don’t flip a coin to determine what we work on and how it should work. We made the decision to make MIDI and audio export work on flows because this is often a very useful way to work – particularly when taking these files into other applications that don’t have the same kind of concept of multi-movement or multi-section works, or when sharing the files with people who need to consume them, for example for the purposes of rehearsal (if you have a multi-movement work, it’s much more convenient to be able to start playing the third movement simply by opening that file and playing it back than trying to find it in a single, longer file – particularly since neither MIDI nor audio natively provide any means of identifying these kinds of section boundaries).

That’s not to say that your use case is invalid or unimportant, but to date we have not chosen to implement the ability to export all the flows in a project as a single MIDI, audio or MusicXML file (the latter being especially impractical and unlikely), but we certainly could do in future if there is sufficient demand from our users.

1 Like

EDITED (sorry for the length, but I cover a lot of ground):
Actually, my piece is divided into different movements. Rather, I think my use case is distinguished by the fact that I’m using Dorico as a (sometimes collaborative) composition and arrangement tool, not as a way to generate parts for live players. I simply don’t have the option to hire those kinds of resources. So playback and export to other programs (esp. via “portable”, editable MIDI or MusicXML files) is a higher priority than the ability to generate professionally engraved parts.

So, yeah, flows make logical sense to me as a way of structuring a longer piece. But as currently implemented, they seem to be interfering with my ability to share an entire multi-movement piece with colleagues who might be using other software.

And that’s why interoperability – the ability to flexibly generate portable output – is so important to me. Right now, it’s a challenge to transfer a Dorico project to, say, Ableton Live, or even a common MIDI media player like VLC. It’s not a dealbreaker if a piano has a brighter sound when a MIDI file is played back on a different computer with a different MIDI synth. But unexpected instrument substitutions, like piano for bass or tom-tom for tuba (both real examples culled from my current Dorico project) are a problem. Exported drum tracks are even more unpredictable unless I stick to a limited GM drumset.

To be fair, this isn’t solely Dorico’s problem. I understand that it’s a common complaint – and MusicXML doesn’t seem to be the answer.

FWIW, there are a few applications that are better at generating output that plays (more or less) correctly in other applications. But the only first-tier product that does this significantly better than Dorico for me is Finale – which was never a contender for me for reasons you’re likely well aware of. Notion and MuseScore, despite lacking key functionality, seem best at exchanging content with other programs. I keep copies of those programs on my system to help resolve translation caused by other programs. Sometimes importing Dorico MIDI output to Notion or MuseScore and then saving that program’s output in a portable format lets me generate a file that others can play & that sounds much like what I composed in Dorico.

Re: “arbitrary,” we may need to disagree on that one. Speaking as an ex-software engineer, it seems that it would take little effort to add a check box to the MIDI Export window that says “Export selected flows in a single file.” From my perspective, in fact, not supporting this option is actually inconsistent with Dorico’s audio-export functionality. So it doesn’t seem logical to me.

Now that I’m on the topic, I’d like to also suggest the ability to generate a PDF, MIDI file, or MusicXML output that contains a range of bars (or even an arbitrary selection). Similar to the way that Word or Adobe Reader lets you select a Print region. If, for example, I’m working on a tricky passage in the middle of a longer composition, it would be nice to be able to email an audio, printed, or MIDI copy of that passage to a colleague for comment or redlining. Right now, I can duplicate that feature by first importing Dorico output into a DAW, audio-editing program, or even the pro version of Acrobat. But it seems like this would be a simple feature to implement as native Dorico functionality.

So our main disconnect, I think, is that I’m primarily using Dorico as a (sometimes collaborative) compositional tool, not as an engraving program – not to say that Dorico’s outstanding engraving features aren’t tasty icing. So that’s why, from my perspective, the program seems limited in arbitrary ways. I don’t mean to demean your design decisions or the underlying concept upon which those decision are based. And I don’t believe that my suggestions would bloat the program or dilute its focus. In fact, they might make Dorico more attractive to a whole class of old-school composer users like me, who are looking for a tool to help to facilitate score-based note-by-note composition and orchestration – rather than manipulating beats and loops in a DAW. I’m more like Wendy Carlos than Billie Eilish.

.

Since you’re an ex-software engineer, I would imagine that you’ve also run across plenty of people in your career who have an opinion about whether or not something would be easy to implement in the systems you’ve worked on or designed, even people who say they are ex-software engineers, and you probably allowed yourself at the least a wry smile…

I honestly don’t know how difficult it would be to implement export of all flows into a single MIDI file with some artificial silence inserted between each one. It’s obviously not a multi-week task, but it would certainly be a multi-day one, plus the time required for testing, the costs associated with localisation and documentation, and the opportunity cost of the time spent working on this meaning that this chunk of our limited development time cannot be spent elsewhere.

I am certainly not opposed to us adding this feature. It’s a reasonable request. But it’s also not in general a high priority for us, since it is not a commonly-made request over the five-plus years of Dorico’s availability. So please be assured that I have added it to our backlog for consideration for future implementation.

1 Like

Hi Daniel,

Just wanted to jump in and say my company and I have to find workarounds to this current implementation reguarley. I thought it would be helpful to provide a ‘real life’ example of how this feature could greatly improve our workflow recording music for media.

We use flows extensively to record small variations of tracks that we are recording. The first flow is the full track, then subsequent flows will be small 2-10 bar variations of said track. This works very well in that it allows us to keep everything in the same file and well labelled. We manually continue the bar count and rehearsal marks through all the flows so they can be recorded in one long Pro Tools session. (As an aside, if there were an option to contiune bar numbers and rehearsal marks across flows that would also save us a lot of time!).

Because currently one is unable to export flows as one MIDI file, when it comes to creating Pro Tools sessions for these tracks we have to do some fairly time consuming work arounds. If there are no tempo changes in the flows then it’s not an issue because you can set one tempo and that will work for all the flows. However (as is the case on the project we are working on right now), if any of the flows have a different rit. or accelerando, this causes an absolute headache trying to create the Pro Tools session. You have to do a complex work around of copying and pasting tempo maps back and forth in Pro Tools, rather than just importing a single midi file to map out the entire piece of music start to finish.

The time spent mucking around with that process far exceeds how long it would take to simply tick ‘Export All Flows as One MIDI File’. As this is a problem we run into on just about every project where we use flows this way, then we would whole heartedly support seeing this feature implemented.

Thanks

1 Like

But why would you use separate flows for this if you want continuous bar numbers? Unless you need to be able to shuffle the order of the cues, why not just use rehearsal letters and system/frame breaks? Is it just for the flow titles?

Thanks, Daryl, it’s helpful to know that you too would find this a userful improvement.

Yes exactly. You are able to set a ‘template’ for the flow titles, which create a clear distinction between the different flows in both the full score and parts. You are also able to easily delete or add them should the need arise.

Thanks for all the replies. Every message has been helpful.

By characterizing my suggestion as not being a huge coding effort, I by no means meant to suggest that it could be done in somebody’s lunch hour. But since Dorico already generates single-flow MIDI files, I think it was a fair assumption that coding, documenting, and testing this option would not consume a prohibitive amount of resources. Admittedly looking from the outside in, it doesn’t seem an unfair assumption that all that would need to be done would be to add a few steps to the existing MIDI-export procedure to append the content of the already generated MIDI files and then insert a handful of MIDI events to create any needed gaps. That was the rationale upon which my characterization was based. I’m sure that Dorico is designed and documented in accordance with best practices, so as to minimize undesirable ripple FX of presumably localized maintenance tasks. If my assumptions are correct, I could give you pseudo-code in a half-hour. However, I’m also well-aware of what you say about assuming things about other people’s software – so I hope I’m not being too cringeworthy here!

But I think focusing on that comment misses the point. From a user standpoint, this feature appears to be a no-brainer and its omission, esp. in light of the fact that it IS implemented for the otherwise-similar audio-export function, seems surprising & inconsistent.

That’s about all I have to say. Having decided to abandon the use of flows due to this constraint, I guess the point is now moot to me. Unfortunate that one small omission renders a major feature useless in some use cases. But when it comes to music software in general, “learning curve” is often a codephrase for “devising workarounds”, regardless of product. Overall, Dorico will do the job for me, single-file output or not.

D

It is surprising to me that the feature would be that useful - :slight_smile: Not implying that anyone is wrong here, just that my no-brainer may not be your no-brainer.

In practice for me, exporting separate audio files works better as you effectively get a play list with flow names that they can easily audition, skip etc. in the car, phone or wherever with no special software required.

Plus - seems like a trap that can bite you when someone says “send the rough or send MIDI”… IMO the quality of sound DOES influence people. I know absolutely that it influences my own writing, and just how wrong that legato Cello passage or whatever can sound without the right expression map etc. It can cause issues without good reason.

But that’s just one person’s perspective on the use of flows to dash off audio variations.

In the unsolicited FWIW column - one possible use case for Dorico Elements or the IPAD version IMO, is that they can use them to playback, comment, and view Pro version scores (though without all the same editing features). I’d rather have NO conversion if possible, as “weirdness finds a way” to sneak in there, to misquote Jeff Goldblume.

gdball, you make good points. But remember that there are other scenarious – such as exporting a piece into your or someone else’s DAW – in which an editable format is useful. In my case, generating BOTH audio and MIDI transcriptions can make sense, one to show downstream collaborators what I intended a draft to sound like, the other to give them the opportunity to develop the piece further. Online collaboration has exploded in popularity since the pandemic began, but I’ve been doing that for decades. I still remember faxing hand-written pencil&paper scores. Of course, I also used to program in FORTRAN and ALGOL, so I guess that makes me an OG user!

One can import MIDI code into a DAW one flow at a time relatively easily (and then export a MIDI composite from the DAW).

There is a limit to how much time the Development Team can (or should) spend on capabilities with a limited user demand, as convenient as that might be for those few. Doubtless Dorico does market research to determine user demand and will take the two users who have expressed an interest here into account.

1 Like

The ability to export Dorico’s customized rehearsal marks via the midi file and import it into Digital Performer would be useful. For me, having to add markers in Digital Performer after I have clearly marked the form in Dorico (e.g., [A (Intro)], [E (Solo 1x)]) is an added step in the production process. Thanks.