Playback issue with octave line bug?

• Aug 9, 2021 - 10:41

In this piece, if you play from bar 57 and wait, it has been doing strange cutting-out things with the sound at bar 70 or so. Do you get this as well or is it just mine?

Attachment Size
Ice and snow and fish in Finland.mscz 37.4 KB

Comments

• Aug 9, 2021 - 11:45

The piano treble clef is using notes with Velocity type = User, while the piano bass clef uses the default Velocity type = Offset. You're on your own if you start tinkering with the velocity type.

Reply

• Aug 9, 2021 - 12:32

"Ok I have now changed them both to user from around bar 70"
I don't think so. You seem to have changed both staves to Offset (which is correct).
You also need to reset the Velocity to zero for all the notes, and instead rely on the velocity which is set by dynamics (p, mp, mf, f) and the effect of hairpins and cresc lines.

And the advice from Jojo is so sensible: define your dynamics and hairpins as Dynamic range = Staff if you want to have the right hand playing at a different dynamic from the left hand.

In summary:
a) select all notes
b) toggle the Play checkbox off and on, to ensure that all notes will play
c) toggle the Velocity type to User, then back to Offset for all notes
d) reset the Velocity to zero for all notes (you still have lots of notes with individual non-zero Velocity)
e) add extra dynamics and hairpins in those places where you want different volume for upper and lower staff - and set their Dynamic range = Staff (instead of Part)

Reply

• Aug 9, 2021 - 21:47

You definitely have a problem, but you need someone with more knowledge than I have. Having played the score a few times, the distortion seems to be a cumulative effect which happens after playback has continued for at least 20 bars. But if you stop the playback and play just the distorted passage again, the audio for that passage is fine - until the glitches start again further into the score.

Short of resources? I closed all the many open programs on my laptop, and tested the playback with only MuseScore running. But the distortion problems occur even under that test condition.

Anyone else got any advice?

Reply

• Aug 9, 2021 - 23:18

If the goal is to achieve unusual special effects that a human musician would also need to see dynamics for, then use dynamics for sure.

if the goal is just a more "human" playback, with a subtle but natural bringing out of individual melodic lines, then for me velocity is smarter - and always with "offset" (which is to say, relative), not the "user" (absolute). The nice thing about doing it that way is it remains good even if you change the overall dynamic of the passage.

Reply

• Aug 9, 2021 - 23:24

There's a bug I've seen a couple of times before that seems to apply to passages in which octave or pedal lines are extended over a long period of time. I'm not sure if anyone has fully figured out the source. If you do a search of the forums and/or issue tracker, maybe you'll find something.

Hmm, I wonder if it has to do with the way MuseScore tries to calculate MIDI data in "chunks" , and somehow the octave marking is throwing that off?

Anyhow, the problem does go away if you remove the octave line, not that this really helps.

Reply

• Aug 10, 2021 - 15:21

I found just now that if I removed the octave line and transposed all the relevant notes up an octave to sound the same it still did the problem, so perhaps it's not the octave line that's causing it.
And yes when I removed the octave line without transposing the notes up it was fine, but is there no way this can be fixed?
I also tried recreating that section on a different score but it still did it.

Attachment Size
Ice and snow and fish in Finland.mscz 36.98 KB

Reply

• Aug 11, 2021 - 15:34

Seems to occur by using the MuseScoreGeneral soundfont. By using another soundfont (tested it with the Salamander C5 light) it doesn't occur for me.
Maybe it's caused by that?

Reply

• Aug 12, 2021 - 15:27

Okay, I did some testing, and here is what is happening:

  • The piano in MuseScore_General emulates the damperless region on an acoustic piano, whereby the top octave and a half of the piano has no dampers on the strings. This means the notes in this region continue to ring out when the key is released.
  • The passage in the example score features rapid chords played in the damperless region, quickly exhausting FluidSynth's available polyphony (i.e., the number of "voices" or samples that can be played simultaneously).
  • When a synthesizer runs out of voices, it's supposed to kill off the oldest voice to make room for the new voice, but that is not happening here. This is an old bug that has long been fixed in upstream FluidSynth, but MuseScore is still using an ancient, buggy version of FluidSynth for playback.

So, this issue can only be truly fixed by updating the FluidSynth engine in MuseScore, or finding and backporting the voice allocation fix. It may also be possible to increase the synthesizer polyphony within MuseScore's code, which won't fix the bug, but will at least help keep from hitting the polyphony limit so soon. This, of course, would come at increased CPU usage.

Until then, the workaround options are:

  1. Use a SoundFont that doesn't emulate the damperless region and/or uses fewer synthesizer voices per note. Stereo samples count as two voices, so a piano SF2 with mono samples will use 1 voice per note and with stereo samples will use 2 voices per note. The piano in MuseScore_General uses 2 stereo samples per note at lower velocities (= 4 voices per note) to create a more natural sustain, as the PP through mF dynamics are all emulated using forte piano samples.
  2. Use an instrument in SFZ format instead of SF2 format, as SFZ files are played back using a different synth engine (Zerberus).

Reply

Do you still have an unanswered question? Please log in first to post your question.