There is a problem that has been signalled on ‘Net about Dorico’s Mixer. Someone there called the Mixer “useless”, I would only indicate that there is a huuuge delay between what Dorico plays and what Mixer shows. I did a very simple experiment: opened BBCSO CORE template from Spitfire, input 5 notes for solo flute, opened Mixer and hit Play. Notes were long gone (about 2-3 seconds) when Mixer began showing their signal. The importance of this situation changes depending on what will be done once the music is composed. If the score is exported as MIDI to a DAW (Cubase, Logic) the behaviour of Mixer is secondary, if the score is supposed to be fully mixed with all bells and whistles or when it is to be exported as audio stems to a DAW Mixer becomes a very important tool. And in my situation this tool is not working practically at all, except for setting up the levels. Having said so I think that having a Mixer that does not show values of its faders’ positions or changes contradicts its purpose. Sometimes it is important to adjust precisely the levels of MIDI or VST volumes and now it is being done “on instinct” so in opposition of “precisely”, so a value display will help a lot.
I admit that I have searched both 'Net and Steinberg fora for eventual solutions but I found none. If I overlooked any of them, I will appreciate directing me there. If not and there is knowledge about existing solution, any and every help will be appreciated.
Daniel’s comment will be very much appreciated as well.
Finally, just a question: when there is an active instrument connected to a VST in the Mixer it is represented by its MIDI track and the VST it uses. In Play it is shown as a MIDI track with controllers. One of them is CC#07 - the general volume which should correspond to MIDI volume fader position (value) in the Mixer. When I set up CC#07 value in the Play track its changes are not reflected in the Mixer, i.e. the fader is not moving. So the question is, which of the two will be exported in MIDI file, the one in the track or the one in the Mixer? Also, if I have CC#07 automated in Play and then move the fader in Mixer, what happens? Some of simpler VSTs still use CC#07 to automate output, so this information is important. Also, if I do not do any CC#07 automation, the exported MIDI file will contain the value from the Mixer or the default value from the Play track?
Dorico is installed on Mac Pro 2020 with Catalina, 96GB of RAM, 16 cores and SSD so speed or computing power should not be an issue.
The Mixer doesn’t currently support any kind of parametric automation. The audio fader, which corresponds to the output of your VST instrument, doesn’t generally respond to MIDI controllers, so you wouldn’t see any movement of that fader in response to controller changes anyway: it’s not normally the output level that you’re controlling with MIDI controllers.
As for the apparent lag in the signal shown by the Mixer, I’m not sure what to make of that. I’ll talk to Paul and Ulf about it and see what they think. I’m not 100% sure how the metering actually works technically: I think Dorico is receiving the levels from the audio engine and is updating the Mixer as close to real-time as it can, notwithstanding that it will be prioritising the real-time audio playback over UI updates.
I was taking about MIDI faders, not VST faders. So, could you, please, give me the clue about the issue I am recalling now: in Play a MIDI track is shown with controllers. One of them is CC#07 - the general volume which should correspond to MIDI volume fader position (value) in the Mixer. When I set up CC#07 value in the Play track its changes are not reflected in the Mixer, i.e. the MIDI fader is not moving. So the question is, which of the two will be exported in MIDI file, the one in the track or the one in the Mixer? Also, if I have CC#07 automated in Play and then move the corresponding MIDI volume fader in Mixer, what happens?
If you have cc7 automation changes, then these will be used in Playback and midi export. The presence of automation data will cause the fader positions to be ignored. We expect in the future to automate the mixer to make this clearer.
Thank you, this clarifies the subject.
And all the best in 2021.
I’m unable to reproduce this problem with BBCSO. I’ve created a minimal example and the VU meters are responding in real time for me. Can you attach a minimal project that shows the problem for you?
I have tried to reproduce the situation, but there must be something more to this problem. First, the project is not small, quite the opposite, it is relatively big and has a video attached to it. Today Dorico hanged on me at least 6 times before I even succeeded to open the project and 3 times when I closed it. I had to restart the computer. As this situation with Mixer did not happen for the first time, when it happens again I will make a video with sound to illustrate the whole problem. Now, if you want I can send you the project “as is” but without video. For now it has only a few notes because the technicalities made me continue it directly in Cubase.
As I hint, when I observed the instruments loading process on BBCSO Spitfire player it was slow-to-very-slow, but CPU was busy on the level of 3%, so almost idling.
If the project uses a lot of samples then what you may be describing as a hang is just Dorico waiting for the BBCSO player to load the samples. Dorico has no control of what happens inside the BBCSO player, and also has no way of knowing whether the player is still loading sounds. So one possibility is that the auto-save timer is executing, which tries to save the state of the plugin, but the plugin may not allow that as the samples are still being loaded.
The level of the CPU usage is irrelevant here as loading samples depends on the speed of disk access, so you would expect the CPU usage to be very low. Dorico has control over the loading of the sounds - they will load as fast as BBCSO player will allow. It does sound slower than I would expect for a computer of your power, but I haven’t used the BBCSO enough to know what performance to really expect. Have you tried changing the preload settings? Some people on this thread have had various performance problems in different hosts: Trouble Running BBC SO? – Support Centre
Hello @PaulWalmsley, I’m not the OP but I can reproduce - it just never bothered that much. It wouldn’t be a minimal project though.
I have a project with 21 VST instances which is CPU intensive on my machine (Dorico + VST Engine) - above 80% and the needles drag. Here it is if you happen to have the libraries.
I agree with the developers’ seeming priorities though - give me good sound, and I shouldn’t be using my eyes to mix. It is specific to Dorico proper though - meaning that if I’m using a multi-sample plugin that has its own metering, I will see the lag in Dorico but not the plugin.
FWIW, there is another DAW whose performance monitoring shows the amount of CPU consumed by each plugin - and that allowed me to identify a single instance of an insert that was consuming something like half of the CPU for the DAW’s audio engine. I think plugins are part of the reason for different user results sometimes and that kind of information could help frustrated users find what is different about their system.
EX: I am pretty certain that an issue we corresponded about before (MIDI streaming from Dorico to DAW) was ultimately about the CPU not being able to keep up, and it was that blasted plugin plus some tuning to prioritize more horses to the audio engine.
Edit, okay apparently the project is too big. I will email if you want it, but you’ll need the sample libraries, etc.
I don’t have many sample libraries, so it’s unlikely I’m going to have the same ones, so alas I don’t think I’ll be able to make use that, but thanks for the offer. As far as CPU usage during playback goes, it’s not so much about how much CPU a plugin uses, but whether the 21 plugins (plus FX) can do all the processing they need to in the small time interval they are allocated. What you see in DAWs as CPU usage is usually more a measure of ‘how long did it take to calculate everything vs how long is the time slice’.
If you have a small buffer size (eg <256) then that requires a lot more work, because the whole audio pipeline has to be processed via every plugin 200 times every second. So increasing the buffer size is one way of reducing CPU usage, at the expense of latency. Unfortunately we don’t have any good way at the moment at measuring the contribution of an individual plugin to the overall processing time.
In my machine I have the Apple’s original, probably the fastest on the market 8TB SSD, so I am not sure the issue is there, but your point is valid and I will check tomorrow the load speed outside Dorico.
I will also check the preload settings as you suggest and if anything of merit is found I will publish it here. Finally, I also suspect Spitfire player of not being fast enough, but that can easily be checked by setting up in Cubase exactly the same confing as in Dorico and compare loading/saving speeds. I will try to do all tomorrow and come back to forum with results.
Not related directly to the problem with the lag between the playback the Mixer indication, but really would be nice if we have better Console!
To me is still strange, why the Cubase’s Mix Console wasn’t fully adopted alongside with the audio engine?!
There are some much things that are “must to have” in Dorico, too… I really miss the Control Room where I can insert plugins like Sonarworks Reference and SuperVision. The Control Room could be routed to different Audio Output, just for listening, and the plugins inserted there don’t affect the Audio Export. This is still not possible in Dorico.
The mixer in Dorico doesn’t have loudness scales…
I hope this would be improved soon, too!
- The loading and unloading speed monitored outside Dorico is equally slow,
- I have limited pre-load to minimum of 3000 samples and, obviously, all uploads in much shorter time, but also Dorico closes fast and with no hanging. Before these changes I had to force quit it and until I killed synsopos manually I could not restart Dorico…
Comparison Dorico - Cubase tomorrow.
It is the continuation of an experiment I talked about in my previous post.
Conditions: an original BBC SO Core template from Spitfire, project empty, no players, no staves, 22GB of samples (full BBCSO Core library), Mac Pro 2020, 96GB Ram, 8TB SSD, 16 cores.
Experiment 1 - pre-load size 3000 samples.
A.Open project with full load of VSTs: Cubase 31.30s, Dorico: 54.10s
B.Save project: Cubase below 1s, Dorico 5s
C.Quit app: Cubase 3.78s, Dorico 6.75
Experiment 2 - pre-load size 12888 samples (default for Spitfire player)
A.Open project with full load of VSTs: Cubase 1min 02s, Dorico: 1 min 34.20s
B.Save project: Cubase below 1s, Dorico 5s
C.Quit app: Cubase 3.78s, Dorico 6.75
And a practical question: when I remove a VST instrument in Play its samples seem to be offloaded but its slot stays. I did it in one of my pieces that used BBCSO Core template and as I removed 20+ VSTs the whole set became messy and difficult to read. Is there any particular reason these empty slots must stay instead of just simply disappearing?
If you click the trash can icon in the action bar at the bottom of the VST Instruments panel you should find that the rack entry is removed.
But only entries that are at the end of the list. Intermediate entries can’t be hidden at present because of how the slots are numbered.
I have the problem with Mixer filmed with sound. Would you like to have a look at it? Five notes played by horns finish, then 13sec nothing and the Mixer begins to show signal that lasts 20sec before dying. There must be something wrong that either I did when setting up the score or, I dare say, something happens in Dorico.
Yes, please post the video here.
The file is found too big to be pasted here. Any other option?