MS 2.2 AppImage on Linux Mint 64bit: 2.0.x score gives synthesizer output artifact with new soundfont

• Mar 28, 2018 - 04:11

I've been eager to try out the new MuseScore_General soundfont with 2.2, so I downloaded the Appimage and started playing with it. The new clarinet sound is a lot better, and the viola no longer has the pitch bend in certain notes (although the vibrato almost fooled me). I also tried a full orchestral score created with 2.1 and it seemed to play OK. But when I tried a score created with 2.0.3 , I noticed an effect that I can only compare to the effect of an endless cumulative reverb - a background sound like an infinitely sustained chord that gradually builds up.

Was this expected? What would be the procedure for updating 2.0.x scores to play correctly in 2.2 with the new soundfont?

Comments

• Mar 28, 2018 - 08:25

It's not expected and there should be no problem opening 2.0.x files in 2.2. The score or an excerpt of the score to reproduce the problem would be really helpful.

Reply

• Mar 28, 2018 - 18:00

See attached score. The effect I mentioned shows up at about meas. 30ff after the loud passage.

IIRC I also noticed some odd artifact (sounds like an intermodulation product) in the WW parts in meas. 5-6 which you might check out. Also the viola pitch bend in the FluidR3 font had been noticeable at meas. 95ff (rehearsal number 5) - I was hoping to find out if it sounded any better with the new font.

I tried to upload a .mp3 made with 2.0.3 and the FluidR3 font, but the file was too big (>10 MB). However, you can access it (if need be) at
https://www.dropbox.com/sh/nh0btd8fbyydh9u/AABDSjQCn6ndiTIZk4i4VYqWa/Co…

Hope this helps. - dhfx

Attachment Size
DHF-ConcertOverture-Nov2016-score.mscz 176.85 KB

Reply

• Mar 28, 2018 - 18:53

Indeed, the E4 and D4 of the clarinets are stuck. This “should not happen”… unless the input to the sanitisation routine is somehow broken.

I tested with my versions of the playback fixes, to make sure it does not just happen because of lasconic’s changes, and can reproduce it.

I will investigate why.

Reply

• Mar 28, 2018 - 21:28

(As usual, «…» denote XML tags.)

The «Note» tag in the affected measure has an extra structure under it; for four out of six notes (all in voice 1, and the first in voice 2) reads:

      «Note»
        «Events»
          «Event»
            «pitch»0«/pitch»
            «ontime»0«/ontime»
            «len»900«/len»
            «/Event»
          «/Events»
        «pitch»[…]«/pitch»
        «tpc»16«/tpc»
        «/Note»

The “stuck” notes read…

      «Note»
        «track»1«/track»
        «Events»
          «Event»
            «pitch»0«/pitch»
            «ontime»0«/ontime»
            «len»0«/len»
            «/Event»
          «/Events»
        «pitch»62«/pitch»
        «tpc»16«/tpc»
        «/Note»

… instead (note the «len» tag is 0 here).

Removing the entire «Events»…«/Events» tag fixes the playback. (I have no idea why this is there in the first place, or what it is doing, or what it is supposed to do.)

One guess: if the length is 0, we get the note-off event before the note-on event. I’ll have to recompile MuseScore with some debugging output enabled to see what precisely is going on here, though.

Reply

• Mar 28, 2018 - 22:15

We do get the note off event before the note on event, in the specific case of len == 0, since commit 05172ca28bc5332eed9c32f18c5182364bdf3216 (which was a bugfix, ensuring the note off event comes before the next note’s note on event).

I’ve already got a proposed fix, in an estimated ten minutes of compiling I can test it.

Reply

• Mar 28, 2018 - 22:24

The questions then, to me at least, would be (a) what caused both these things in the first place: the extra «Events»…«/Events» structure, and the length value of 0; and (b) how can this be fixed in the offending score, e.g. by loading it into 2.2 and writing it out again as a new file (keeping the earlier version intact). I would want to do this anyway to fix the mixer settings.

Reply

• Mar 28, 2018 - 22:38

I can reproduce creating the problem(atic Events tags) by using the Piano Roll editor and setting length to 0 on a note there.

On IRC it was mentioned that MIDI import would also possibly do that to you.

The Events tag is not necessarily buggy, but it produces bad output from the score to the synthesiser / MIDI writer (the note_off event is 1ms before the corresponding note_on event) due to a bugfix from 2012. My fix was merely to ensure that the note_off event can never come before its corresponding on event. You only hear the problems in 2.2 because we now actually have a pass fixing the MIDI output ;)

Reply

• Mar 28, 2018 - 23:42

Is it possible that MS deals with a unison of 2 voices by sounding only the first voice, disabling the second by setting the note length to 0? That would explain where the zero length came from. It would also explain some other things I've observed, say with handing off a note from one voice to another with an overlap, where the second voice turns out to not be sounded.

Looking at the XML code also brings something else to mind. The actual duration of a note is the nominal duration (quarter, eighth, etc.) multiplied by the length value of 0 to 1000. I have wanted at times to put a fixed separation between notes (the place where this problem occurs is in fact an example) and the only way I found was to go through laboriously with the pianoroll editor, replacing the length of 1000 by 900, 950 etc. depending on the nominal duration, so as to lop off roughly the same time interval at the end of each note. There should be a more efficient way of doing this for an entire selection of measures instead of note-by-note. (I realize that this issue should be a separate topic; I have proposed it in the past as a feature request but with no result so far.)

Reply

• Mar 29, 2018 - 01:41

mirabilos is more the expert on this since he worked on this code, but I can provide some information:

No, MuseScore doesn't set the length of notes to zero. Now that we know you used the Piano Roll editor, it is a virtual certainly that it's something you did there that triggered the glitch. Possibly what you did was legitimate and a bug in the editor actually caused the problem, but anyhow, the editor is the only thing that could have caused the spurious zero-length event. Just delete the notes and re-add them and all is well.

In previous releases, MuseScore dealt with overlaps by not dealing with them. So you'd get a note-on for the note that starts first, then a note-on for the second, then a note-off for the one that ends first, then a note-off for the one that ends second. Due to how MIDI works, the first note-off would actually cut both notes short. The fix for 2.2 as I understand it is that we now force a note-off for the first note before starting the second, so there is no overlap. This should allow both notes to sound for what will at least appear to be full length, even though technically the first is actually cut off just before the second starts. Should be better all around.

Reply

• Mar 29, 2018 - 10:37

What Marc said, plus: there is no possibility of unison between two voices on the same MIDI channel, because they literally strike the same key, i.e. the note is sounding only once. If you truly want to hear an unison, you will have to assign a separate MIDI channel for the second voice (although I was adviced that, when using the same instrument for both, the audio isn’t that great).

But, yes, effectively, the way you notated them, there will be only one, not two, of each Oboe and Clarinet sounding at that point in the score (and once they play different notes, you have two again); this may make them appear less loud in this part of course…

We’re still working out how to make the MIDI channel assignment easy for the average user.

Reply

• Mar 29, 2018 - 11:08

True for Piano and many other instruments, but not true on e.g. Guitar, there most pitches are available several times on different strings and frets. Also not true for staves that combine 2 instruments like SATB closed score or violin 1+2, although there this should really be different channels

Reply

• Mar 29, 2018 - 03:59

Marc: I did as you suggested - in the clarinet and oboe staves, I selected voice 1 in the 4 unison measures (16-19) , raised voice 1 an octave to separate the voices, and then looked at each staff in the pianoroll editor. Sure enough, voice 2 was corrupted in both (since I originally copied one staff into the other). Deleted the offending notes in the score, re-entered them, went back into the pianoroll editor to set the duration to 900 to give a separation from the next note, then lowered voice 1 in each staff back by an octave to restore the unisons. And that fixed it.

BTW, something I noticed is that when 2 accidentals are stacked one above the other in the same staff, 2.2 does not need to offset them horizontally (providing they are spaced vertically); this mod was originally planned for release 3.0, IIRC. Nice work!

Reply

• Mar 29, 2018 - 04:37

Excellent! FYI, the accidental stacking algorithm was heavily reworked for 2.0 and hasn't changed since. It works great on notes occuring at the same time on the same staff, regardless of voice. The improvement coming in 3.0 is that an accidental on one note will be allowed to overlap the previous note.

Reply

• Mar 28, 2018 - 20:08

Thanks to you both for the quick turnaround. So I know that I could just silence one voice in those unisons - but the workaround shouldn't be necessary, it worked OK before. And did anyone hear anything weird in the WW notes in meas 5-6?

Reply

• Mar 28, 2018 - 21:33

Of course, one change that needs to be made to earlier scores is to change the instrument sound levels in the mixer to compensate for differences between the old and new soundfonts - I realized I hadn't mentioned this. But I had once suggested that it would be useful to have some kind of numerical input/readout field for the "knob" controls on the mixer panel, even if only to allow manual noting down and restoration of the settings.

Reply

• Mar 28, 2018 - 21:37

I fully agree with that, please file it as a new (separate) feature request issue.

The numeric value is in the .mscx file and can be changed there no problem, but… that’s cumbersome. Also, adjusting those knobs in the application would be easier if they had a “live” updating number…

Reply

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