Percussion synthesizer
Maybe this has already been reported, but a search reveals a number of problems that may be related but no solutions.
It concerns the pitch of unpitched percussion: a contradiction in terms. The problem manifested itself as percussion from a new soundfont being visible on the vu-meter but inaudible. The suggested cures for similar problems I found in the forums were of the form “get better loudspeakers” etc.
This might have been a partial cure but it would also require bat's hearing - the sounds being produced 5 octaves too high.
The cause is what appears to be a serious bug in the synthesizer. My reading of the SF specifications is that if scaleTuning, coarseTune and fineTune are all 0, then the sample is reproduced without any pitch shift. This certainly seems to be case for at least some synthesizers, such as Coolsynth and Timidity. But it is not the case for the synthesizer in MuseScore.
The specification for scaleTuning is that “A value of zero indicates that MIDI key number has no effect on pitch”. The implementation in the Musescore synthesizer is subtly different “A value of zero is taken to be the default value of 100 with a constant MIDI key number of 60”
This will give equivalent results if and only if
byOriginalPitch is 60 or 255 (-1) and overridingRootKey is unset or -1, or
overridingRootKey is 60.
As a number of soundfont editors arbitrarily preset byOriginalPitch to 60 and not many people are prepared to spend the time required to set up their own soundfonts, this problem may not manifest itself very often.
If, however, byOriginalPitch is set to 0 (a perfectly valid number, the nearest to the recommended value of -1 which not all soundfont editors allow) the sound is produced 5 octaves too high (middle C ~8 kHz at the limit of audibility).
Many soundfonts, do not use a scaleTuning of zero, but use overridingRootKey (e.g. TimGM6mb) or byOriginalPitch (e.g. Musyng Kite) to “tune” every note so these are unaffected by the bug.
The workaround is somehow let people know that they need to set byOriginalPitch to 60 for unpitched percussion in Musescore.
Tiny Trouble
Comments
Is it possible to give a link to a particular soundfont with this problem??
So I can research this further.
In reply to Is it possible to give a link by ChurchOrganist
I have attached a zip file with a description of a procedure to reproduce the problem, three micro soundfont examples all of which seem to be legal and work on other synthesizers and only one of which works with MuseScore, and a demonstration score.
Thanks
Tiny
In reply to I have attached a zip file by TinyTrouble
Thank you for providing me with this information in such detail :)
In actual fact your assumption that byOriginalPitch should default to 0 is wrong....
I quote from the Soundfont 2.1 specification....
The BYTE byOriginalPitch contains the MIDI key number of the recorded pitch of the sample. For example, a recording of an instrument playing middle C (261.62 Hz) should receive a value of 60. This value is used as the default “root key” for the sample, so that in the example, a MIDI key-on command for note number 60 would reproduce the sound at its original pitch. For unpitched sounds, a conventional value of 255 should be used. Values between 128 and 254 are illegal. Whenever an illegal value or a value of 255 is encountered, the value 60 should be used.
As you may already know, MuseScore uses FluidSynth's engine to render soundfonts, and FluidSynth's behaviour is perfectly consistent with the Soundfont 2.1 specification.
Although the MuseScore version of FluidSynth is customised, root specification issues such as this should ideally be posted to FluidSynth support and not MuseScore - not that we're not interested, but it is beyond the remit of our development team to start changing a fundamental aspect of FluidSynth.
I would be interested to know which other synthesisers you have tested, however.
Incidentally Viena recommends a RootKey (byOriginalPitch) value of #46 for your sample and it's usually a good idea stick with Viena's defaults when creating Soundfonts unless it is obvious that it has screwed up the calculation - after all that is what the Set Root and Correction to Calculated Values button is for - more problems are caused by leaving it at Viena's default of #0 such as the one you mention.
One of the problems I have had with the default FluidR3 soundfont has been the original author's omitting to enter root key and pitch correction data with subsequent detrimental effects on some instruments' tuning.
Personally I am going to try entering a value of 255 in this field for your sample to a) see its effect on Viena and b) its effect on FluidSynth.
Let us know how you get on with the FluidSynth people in this regard.
In reply to Thank you for providing me by ChurchOrganist
Thank you for your detailed reply. I will not be taking it up with FluidSynth because all my test soundfonts work perfectly with FluidSynth. The problem is with MuseScore.
I would like to point out that I did not make the “assumption that byOriginalPitch should default to 0” that you accuse me of. I said “If, however, byOriginalPitch is set to 0 (a perfectly valid number, the nearest to the recommended value of -1 which not all soundfont editors allow)”. (For the explanation of the -1 rather than 255, see the attached document). I have not yet found a soundfont editor which will allow 255 to be specified.
Furthermore, the statement “Incidentally Viena recommends a RootKey (byOriginalPitch) value of #46 for your sample and it's usually a good idea stick with Viena's defaults” seems to be a blatant attempt to muddy the waters. Things would not have been much better had I set the “recommended” value (one of my test sound fonts had 40 and MuseScore failed miserably on that).
Finally the statement that “FluidSynth's behaviour is perfectly consistent with the Soundfont 2.1 specification” is something I have to agree with. I have tested clean installs of both v1.720 and v2.0.2.4 of FluidSynth and found it correct on the examples I attached to my last message. But FluidSynth’s behaviour is not the same as MuseScore’s behaviour.
I was raising a question about the behaviour of MuseScore which is completely at odds with the Soundfont 2.04 specifications (for more details see the attached file). I do not deny that the MuseScore behaviour could be useful under certain circumstances but making a non-standard behaviour not just the default but the only option does not seem to be wise.
I have extended the tests and I can confirm that the problem is not limited to percussion. Setting scaleTuning to a value other than 100 for some splits of a flute also caused MuseScore to throw a wobbly.
“I would be interested to know which other synthesisers you have tested, however.”
We could start with Viena (FluidSynth) which ChurchOrganist did use to look at the Soundfonts that gave MuseScore indigestion, although he did not own up that those soundfonts worked perfectly correctly with Viena. We could continue with FluidSynth versions 1.720 and 2.0.2.4, both of which have no problems at all with my test soundfonts. The same can be said for Polyphone, CoolSynth and Timidity. Is MuseScore unique in this respect?
I appreciate that people like ChurchOrganist are devoting a great deal of their time to helping all users (whether they have donated or not) and, without them, programs like MuseScore would not be available to the vast army of freeloaders. I could have just complained, but I investigated the problem, verified that it was a problem unique to MuseScore and determined a simple workaround which could be used by others. Not being a MuseScore developer, I could not tie down the fault in the code to get it fixed. All I ask is that the workaround be published to stop other people wasting days of effort trying to get perfectly correct percussion soundfonts to work with MuseScore.
In reply to Thank you for your detailed by TinyTrouble
I think you are confusing FluidSynth with Synthfont.
The soundfont engine in Viena is not FluidSynth but SynthFont
And the versions you mention are consistent with SynthFont versions but not FluidSynth of which the latest version is 1.1.6.......
http://sourceforge.net/projects/fluidsynth/files/
If you think about it there's no way MuseScore as Open Source software could use SynthFont as its soundfont engine as SynthFont is proprietary.
FluidSynth, the soundfont engine in MuseScore was not written by the MuseScore team. It has been customised to suit MuseScore's purposes, but the core code was written by the FluidSynth team, who can be contacted via the link above.
I'm not trying to dodge the issue here but if you want this resolved, and I think it would be a very good thing for this to happen, then you need to contact the FluidSynth team.
I will personally give you my support if it is needed, but you have already done the research necessary to present your case to the FluidSynth team.
In the meantime I will try to make your workaround as widely known as possible within the MuseScore community, although many users are unwilling to even open a Soundfont in Polyphone or Viena.
I also think you should report this in the issue tracker as it is possible one of the MuseScore developers will be able to hack the FluidSynth code to find a solution - maybe you have that expertise yourself, in which case you simply create your own fork of MuseScore on GitHub to access the code. You will need to sign the MuseScore CLA in order to officially present pull requests however.
I haven't had time to read your PDF yet, but will certainly do so when I have some time.
In reply to I think you are confusing by ChurchOrganist
Mea culpa !
Yes I confused FluidSynth with SynthFont when I started editing the text - the result of total frustration with qSynth, based on FluidSynth, which no longer worked on my (new) machine and so I could not check that my soundfonts still worked with a FluidSynth implementation other than MuseScore - I cannot remember that there were any problems on my old machine.
However I have still not raised a ticket for FluidSynth because 1) I am not a registered developer therefore cannot and 2) because the issue has already been raised and was fixed in 2010.
Ticket #26 Incorrect Pitch When Alternate Values Used for “Scale Tune” 2010-05-26
The error was a well commented brainstorm in fluid_voice.c which was apparently fixed in r205
I cannot determine whether the error is due to MuseScore using a pre r205 version of fluid_voice.c, or due to the bug crawling back into FluidSynth unnoticed or whether the MuseScore version is different.
In reply to Mea culpa ! Yes I confused by TinyTrouble
Ok I'm going to raise this in the issue tracker with a link to this discussion.
One of the development team will look at it in due course.
Issue #87066: FluidSynth plays Incorrect Pitch When Alternate Values Used for “Scale Tune” raised.
In reply to Ok I'm going to raise this in by ChurchOrganist
Hi I have just found that you have already found the bug (and workaround) yourself back in April 2015 (https://musescore.org/en/node/52271):
"OK, found it :) it seems Fluid responds to a Global Scale Tuning value of 0 by playing everything as middle C! Synthfont and Viena OTOH do not."
I wonder how many more non reports there are lurking in the forums?
Happy new year
Tiny Trouble
In reply to Hi I have just found that you by TinyTrouble
Indeed! I had not connected it with your report though.
It has been reported in the issue tracker, and we just have to wait until someone competent in that area of code has time to merge the latest FluidSynth source with our customised version.
Not a job for me - MIDI is my speciality, apart from sound design :)
You seem pretty clued up - do you by any chance write C++ code and are familiar with the Qt library?
In reply to Indeed! I had not connected by ChurchOrganist
The lack of connection was probably my fault - if I had done more testing first, I would have found that the basic problem was with any scaleValue not equal to 100 (as I reported for the flute samples in my soundfont and you had found for your clarinet) and nothing to do with percussion as the title suggested.
I do try to avoid C++ in much the same way as most of the world tries to avoid other potentially lethal, debilitating infections such as AIDS, Ebola, SARS, etc.
Some time ago I did start writing soundfont based synthesizer in C but the deeper I went, the more inappropriate the rather archaic MIDI / SF structure became. But that is for another forum.
What I am about to embark on is plugins. This will be very tentative as there seem to be some problems with MuseScore 2.0.2 - I am able to reproduce some reported problems with Doubletime, but I am also able to use it successfully. My first attempts will be be either automatic single and multi-measure simile generation and numbering, or, more exciting, converting portamento, fall, scoop, etc into MIDI controllers using the bend function.
Sadly the effect is even worse than you thought.
I have discovered during my integration of Mike Scorsch's Marching Percussion into the default soundfont that there is no setting of byOriginalPitch (scaletuning in Viena) which does not affect the pitch of a sample related to the key it is mapped to.
This is the reason that the original Drumline soundfont bass drums do not play back in the correct order as reported recently in a forum post - the drums aren't numbered backwards - the MuseScore synth engine is applying pitch shift based on the key they are mapped to which make it appear that is the case.
I suspect it its also the reason for complaints that various components of drumkits are too quiet - a sample is played back at a frequency too low for most loudspeakers to respond to, the result is loss of volume.
EDIT
Correction - in order to prevent MuseScore's synth from applying pitch shifting you need to specify a Global Scale Tuning value (byOriginalPitch) of 0 and a Root Key value of 60.
Taken me a whole morning to finally figure this out!
Even so, there is something weird happening to the sample playback the attack is way off compared to playback in Viena.