We know that Play mode is to be fleshed out and that optimizing for gains in speed across the board is always a concern, but I was wondering whether I could ask the team (and hear from fellow users) their thoughts regarding the audio export speed. I haven’t taken the time to inspect all the moving parts, but even with modest setups I’ve been encountering less-than-ideal bounce times. Is this something that can/will be improved? Is there any chance we could get quick or “economic” bounces, for when we don’t need a very precise or high-quality output?
I believe from this thread that this is something which the team is working on. I agree, export does seem to take a longer time than might be expected; but for me it never fails.
I’m well aware of that issues, but that’s not what I mean. I’m interested in the speed of the process itself.
Audio export takes as long as it takes, unfortunately there is nothing that the devs can improve on.
At least, audio export shall always be faster than real-time, but you can never tell how much faster.
But the user can also influence the export speed. Export is always done with the audio parameters
as set under Edit > Device Setup. A lower sample rate results in faster export speed and vice versa.
The thing is, it doesn’t. It should, you’re right, but I’m consistently coming across bounces that take longer than playback time, hence this thread. As I said in my original post, I haven’t had the time to do my own troubleshooting — and playback is a department where each end user’s mileage will vary — so I find it completely reasonable that it’s not quite Dorico’s problem but maybe a bottleneck between the VSTs’ output and Dorico’s engine, but still, I wonder if that can be optimized or how one can even present that data to you.
For Mac users, I think a big improvement would simply be showing the progress of the export, which currently works only on Windows: hopefully Paul will have time to revisit this area soon, though he has a lot of other things on his plate.
Yes, that would be useful
But not essential. It always exports in the end.
It would be great if you could provide a sample project where you think export takes longer than realtime. If you don’t want to post it publicly, please send to “u dot stoermer at steinberg dot de”. I then can have a deeper look together with the devs.
On a semi-related observation, I am spoiled by the speed of midi export - “boom” it’s there! I guess the midi data is just waiting to be written with little processing. It’s so fast I that I think for a second nothing happened, but it’s sitting there on the desktop waiting for me!
MIDI is a completely different world compared to audio.
Imagine a piece containing e.g. an organ player pressing down one key and holding it for 5 minutes.
The MIDI file would look trivial, just one note on with a length of 5 minutes and a note off. This can be coded in a dozen bytes.
Then you do an audio export of that piece and the audio engine has to generate audio for the duration of 5 min, i.e. generate roughly 40000 samples each second, so that ends up with dozens of MEGA bytes.
You can’t seriously compare these two worlds.
MIDI is text. Therein lies the difference. A novel of hundreds of pages is not a particularly large file. But a symphony in audio form is megabytes.
Simple benchmark: 30 seconds piano piece exported (44.1/16bit with alll FX routing disabled) from CUBASE - 7 seconds
same MIDI file loaded and exported from DORICO (all FX routing diabled) - 13 seconds.
the VST used in both cases was PianoTeq 6.02
Oh, I’m not comparing… just bringing up how different the two are, because, as you point out it’s just ascii (text).
Thanks. I was going to do one of these with Pianoteq and Vienna Ensemble against Halion inside Dorico as well as testing against a DAW as you did. That’s one third of the work done!
Allow me to bump this thread with some news. I haven’t been able to do the tests I wanted to do, but I have, for the first time since using Dorico, exported an audio file faster than its duration.
I’m working to beat a deadline and putting in a gruesome amount of hours. I have to admit Dorico has been scary at times; it feels like the project is falling apart and any action takes a tremendous amount of time. (No tool should be slower than a composer’s sleep-deprived brain at deadline week, but here we are.) Dorico actually collapsed under its own weight and crashed. Decided to pause for dinner instead of pushing on, but, since I’ve always had problems with audio export (I’ve gone as far as needing to leave it overnight to render), I decided to use the break to try and render the up-to-date version.
It rendered in a quick trip to the kitchen. I was actually skeptical that it rendered, so I exported it again, this time following the process. It rendered faster than real time again, and for the first time the meters in Vienna Ensemble seemed to be displaying activity that was faster than real time.
I probably never needed to render an audio file after a cold start. And if I did, odds are I was in a rush, looking towards some specific end, and wasn’t too mindful of the whole process. In hindsight it seems tremendously silly, and I actually don’t want to shout hoorah before this is done and dusted, but it seems to be than Dorico’s performance is simply deteriorating over time, affecting every aspect.
Since this thread yielded mostly blank stares, I find it reasonable to assume that this is a bad interaction with my system. If that is the case, what could I do towards diagnosing the issue? Is there anything useful in the diagnostics report? In the OS system activity?
We managed to find and fix some of the audio export performance issues for 2.0, and then we manage to fix a couple more just after the 2.0 release (in particular for users affected by the hanging at 90-95%). We’ve done quite a lot on audio export for the next update.
In general, it’s not unexpected that the performance of an application may deteriorate if you have it running for a long duration and are doing a lot of editing. For instance caches do get bigger (which can speed some things up, but at the expense of more memory usage, which then may counter the performance gain), also you can get heap fragmentation (rather than all the memory being allocated together, it ends up scattered around, which means that your CPU’s low level caches don’t perform as effectively). Long-running apps do often occupy more memory, and if you don’t have lots of it then that can slow down performance. Restarting an app you’ve had running for a long time can really give quite a performance boost.
It’s not expected that Dorico would crash, unless you really have run out of memory (which is generally quite unlikely as it will start using the paging file first and that will feel incredibly slow). If you have crash reports then we do like to see them as most of them do correspond to actionable bugs (and we’ve fixed quite a few of these for the next update too). The most useful thing to send us after a crash, is the crashlog itself and then run Dorico again and create the Diagnostic report, as that also contains the application log for the previous run, so it can give us a better idea of what was happening when it crashed.
I came across a similar problem: Today Cubase (10 Pro on indows 10) started to show 6 times the needed time for the export, this project normally needs 5 minutes (now it needed over 30). I restarted Cubase and the problem was gone. After one export test the problem was back. I can’t really figure out, what’s causing it.
You’ll get better luck posting this on the Cubase forum!
Thanx, I will.