I have updated to Version 4.0.10.1044 (Jan 28 2022). I noticed this really annoying fader lag problem in the original version 4 as well and it does not appear to be fixed in the latest update.
There appears to be a lag in the Play mode mixer window and the standalone mixer window. Moving faders in either window, the other took seconds to update.
Because this slow update, even one of them is closed, the faders are still slow to respond and any adjustment after the initial drag/release will delay subsequent adjustments.
Please see a recording here on youtube: youtube dot come / watch?v=800-3hZWss8
It looks like you are a new user and I welcome you to the forum.
Does your work with music notation involve heavy usage of the faders? I am confused by the circumstances under which fader lag is so important as to make Dorico 4 of questionable utility to you. In any event, members of the Dorico team check every comment on this forum and are responsive to user’s needs to the extent possible within the constraints of time and team size and the relative priority of competing goals.
Thanks. I’m indeed a new user to Dorico. I heard many great things about Dorico on forums, blogs, Youtube, etc. I was really excited to use this to learn music composition as a hobbyist. I come from Cubase, which works quite well for me playing with virtual instruments and synth.
To my surprise, within a few weeks of using Dorico 4, I ran into multiple bugs. They are not some complex features. In my other post the bug was changing VST caused FX channel to disconnect (fixed in the latest update), but the other VST playback issue didn’t get fixed. As a reminder, VST is a big selling point of Dorico.
This fader lag is even more puzzling. Sure it’s a notation software, but again, the direction and the big revolutionary feature is how well it integrates with MIDI recording/playback and VST. And fader is such a basic functional unit of these.
I’m probably being harsher than I should. But as a software engineer myself, I despise such obvious issues in an expensive professional software from both a usability point of view and the technical aspect. How are these fader synchronizations implemented? The fact that it work in such a cumbersome way, makes me think there’s some really ugly underlying software code. These are the kind of technical debts that take a long time to payback and eventually engineers leave because the software is so crappy to work on. I as a customer just spent the money feels like I probably should have waited.
I am unable to comment on the programming/coding front but have had years of experience with Dorico’s main competitors (Sibelius and Finale) and find Dorico to be faster and more logical and, honestly, a real joy to use after becoming familiar with its somewhat differently focussed user interface. I hope and expect you will find the same but leave it to those more knowledgeable than myself to respond more completely to your concerns in the programming area.
As you are coming from Cubase which is quite different (like all DAWs), I recommend watching some of the excellent videos and starter projects included in the “new users start here” posting at the top of this forum and then work on some smaller projects just to get a good feel for how the various aspects of Dorico work together. Lillie Harris is Dorico’s documentation guru and her “First Steps” guide is an excellent introduction and can be found at https://steinberg.help/dorico-manuals/dorico-first-steps/. The “demo” piano project attached there is also an excellent place to start becoming really comfortable with the user interface. (Those materials were first written for version 3.5 but will work just fine with Dorico 4.)
Thanks for your feedback, @lofe. We addressed the more important issue with the performance of the Mixer faders in Dorico 4.0.10, which concerns their affect on the actual sound.
It is not intended that as you pull the fader in either of the Mixer displays that the fader will also move correspondingly in real-time in the other. But the position of the fader should update immediately in the other display after the end of the drag, and indeed that works reliably for me.
This is implemented using the standard property-binding mechanism in Qt Quick, with no additional trickery or complexity. You don’t need to be concerned that there is some significant underlying technical debt in this area.
Thanks guys for chiming in. If you can not reproduce the problem on your side. I wonder what options or other causes could impact this delay.
On the programming side, the Qt programming model used in this case is signal/slot. When the signal fires, the slot function gets called and executes. This execution can be synchronized (direct call) or async (queued). If it’s synchronized, whatever the fader is updating might be taking a while on my system, about 1 to 2 seconds after a drag the slider. During that time, the whole UI is blocked until the slot call is finished.
I think the solution is either make the signal/slot call queued connection, or do whatever the fader is updating (model in MVC) in a separate thread.
We’re quite familiar with how Qt’s signals and slots work – we’ve been building large-scale commercial applications based on Qt for over a decade. Another factor at play here is that the underlying data that the Mixer presents is maintained in the VST audio engine, which is a separate process, and Dorico communicates with that process through an IPC protocol. When you drag a fader, Dorico is updating its own model of the mixer data so that the UI is responsive, and sends messages to the audio engine asking it to update the fader value. The engine reports back the actual value that has been set periodically, but while the fader is being dragged, Dorico does not reset the fader to that value, so that it doesn’t feel like the program is fighting you and the fader is juddery or unresponsive. Once you have released the fader, Dorico then receives the final level set in the audio engine, and updates the fader position at that point. That is the part that appears to be taking a longer time on your system, which has very little to do with the Qt signals/slots mechanism (other than the fact that the mechanism ultimately used to relay that final value to the fader comes by way of a signal).
Thanks for explaining more details. Here are some more data I found, which might be a bit surprising. I used Intel vTune profiler to just profile where I change the fader. The total collection time is about 27 seconds. I didn’t do anything for the first 18 seconds, then I started to move the fader (drag, release, drag again…repeat).
From the profiler these events are fairly clear on the timeline. We see the CPUs are mostly idle till about 19 sec. Then we see relatively high usage in one thread. If we look at the function with most instructions and time spent, it’s mostly in std::locale::_Locimp::_New_Locimp.
On the right side, there are call stacks from Qt to the Dorica functions, then into msvcp140.dll. If I include system calls (second image), it shows most time spent are in malloc in ntdll.dll. So I suspect in the code there are some string or stream manipulation that uses std::locale and creating new object repeatedly. The 3rd image shows almost all system calls are from the std::locale function.
I hope these information is helpful to pin down what might cause the fader drag slow down.
Please don’t bump: it’s considered impolite on this forum, though I understand you are eager for more information. I don’t have an update for you as yet. I will update this thread as and when I do.
As someone who has been doing performance optimization and compiler work for over a decade, I hope with this simple demo of finding performance issues in Dorico, it’s clear that a tool like Intel VTune Profiler is extremely useful.
It used to cost hundreds of $$$ per license, now it’s FREE. Please use it and your software will be better.
I can echo the value of running your code in a profiler. You never know what you will find until you do, and you can often greatly increase speed / responsiveness and reduce CPU load with minor changes. These generally pay off in other ways as well. Low level functions like string manipulations, memory allocations and locking especially can benefit from profiling. The tools are pretty good for that now.
