Would an "all controls" gang on the mixer help with overload problems?
I don't know enough about how the MuseScore mixer works to know whether this suggestion makes sense.
In the Mixer there is an overall gain control. However it occurs to me that the signals could be distorted due to digital overload before they get to that overall gain control. If that were the case, then it might be useful to have a way of controlling all the individual sliders in parallel, to avoid that kind of overload.
I am currently testing using the MuseScore OpenScore version of the Planets - https://musescore.com/openscore/scores/5271023 which can definitely drive my poor little computer into overload states - with distortion.
This may be unavoidable give the hardware we have and the current load it is trying to run.
There are too many** channels in the Mixer for this piece for it to be easy to lower the levels on each of them quickly - particularly if what is really needed is just a global reduction.
It would be interesting to have views and more information about this.
** Wouldn't it be useful to have a number for each channel, so that the total number of channels could easily be seen? Maybe there is that feature already - but I've not seen it.
Comments
Don't forget there is a master gain in the Synthesizer.
I think you might be confusing two different sense of the word "overload". If it's just a matter of your system not being able to keep up with the demands of the processing power required for playback, volume has nothing to do with it. It takes no more processing power to deal with loud signals than quiet ones. Volume is only relevant if the issue digital clipping - but in that case,e it would be 100% reproducible, same passage of any given piece very time, no matter how powerful your computer is.
In reply to I think you might be… by Marc Sabatella
You're probably right. You are correct that the actual signal level makes no difference - as long as the levels are less than maximum, and that summing them doesn't take them over the limit which would cause effectively some form of truncation and clipping.
What I don't know is how MuseScore allocates its timing in complex scores. Even though all the notes in a chord should be played at the same time, this of course does not quite happen as the computer has to work out what to play before any actual audio output is produced. It is possible (likely?) that the processes calculating what has to be done, and those which output the audio work asynchronously. Timing issues would probably normally be resolved by buffering.
I am trying to figure out why it is that sometimes MuseScore seems to give these crackling effects - which are not absolutely reproducible - so as you note that shouldn't be caused by summation in the mixer or any part of the MS system.
Nevertheless I have vague feelings that the problems do arise more often on certain types of score than others.
Something just doesn't sound right. I can get processor overload effects in other software - e.g. Logic, possibly Final Cut Pro (though on this computer there are few problems with FCP). To get processor related problems in Logic - which the software will eventually detect and warn about - I have to load up many sound libraries and have very many channels active. Otherwise the processor just does it.
If the issues with the crackling are due to processor issues, the MuseScore would appear to be running a lot less efficiently than other software on the same computer for these to become noticeable so quickly. I don't know whether possible processor issues are the reason for the crackling, or if there are simply one or more bugs causing this distortion.
It is still a mystery.
In reply to You're probably right. You… by dave2020X
When you hit play, MuseScore pre-calculates a data structure containing the MIDI data, then spits it out to the synthesizer one event a time. MIDI is inherently sequential -m it has no concept of two things happening at the same time. A chord is always one note right after the other.
MuseScore calculates this data structure - or chunks of it, anyhow - before it ever starts playing. In theory, it stays ahead of the synthesizer thread (not a separate process as far as I know, but I'm no expert) and keeps calculating data before it is needed, but it doesn't always succeed.
As I related elsewhere, one thing that has been discussed over the years is that macOS in particular seems to be not very efficient about paging, and the applications' pages are being swapped in while it is still doing its calculations. I don't know enough about macOS to know how to coerce it to keep a process' pages in memory. I gather other applications have figured out that trick.