Fluidsynth requires pan modulator to be set to 100% to allow panning to extreme left and right

Which version of MuseScore , what OS.
I believe to have noticed this problem too, but don't recall whether it was in 1.3 or in a current highly build. Or even in both...

Just checked the Pan control in both 1.3 and a recent build of MuseScore 2.

I can confirm that the Pan control in the mixer doesn't work in either.

The use case the OP presents is going to be a pretty common thing users will wish to do IMO.

If someone will point me to the right place in the code I will take a look and see if I can get it to work

A good starting point is https://github.com/musescore/MuseScore/blob/master/mscore/mixer.cpp#L234

FWIW it does work for me, except that totally left / right doesn't mute the other instrument but make them quieter.

It does make them quieter, but not quiet enough. Totally left/right should silence the other channel completely, at least almost.

Panning is "kind of working" (like in 1.3) in current nightly with Tim SF2 soundfont. But it doesn't work at all with the embedded SF3 soundfont (Fluid) nor with the Fluid SF2 version. I suspect that MuseScore synthesizer relies on the soundfont to enable panning. Could be that the Fluid soundfont doesn't have the right modulator.

Also on some testing it is apparent that reverb is present in both channels. Consequently if you want a part to be panned completely to one side reverb settings on the mixer will need to be adjusted to prevent it "bleeding" onto the other channel.

I will take a look at the FLuid soundfont in an editor and see what I can do to turn on panning.

After a bit of digging it has become clear that the Fluid R3 soundfont has pan settings hardcoded into the soundfont, which seem to be overriding the synth pan control.

Moreover many of the instruments are stereo (eg Piano) and have 2 samples for each note.

In terms of programmability this is a big nono.

We could change this, but the licencing status of the Fluid Soundfont seems to be a bit of a grey area, and I'm not sure how we'd stand legally by making such a major change to the soundfont.

IANAL but Fluid legal status is pretty clear. Fluid is included in Debian and its derivatives. The README states "I hereby release Fluid under the MIT license, as described in COPYING."

http://packages.debian.org/sid/fluid-soundfont-gm

OK I'll see what I can do with it.

In the meantime using a different soundfont will overcome panning problems

Progress report:

OK I have worked out what I need to do.

1. All the separate L and Right samples need unlinking.

2. One of each pair needs deleting from the instrument concerned.

3. Unused samples need purging from the soundfont

This is going to take some time.

I have no idea at present how this is going to impact the sound quality of the soundfont - so far there is very little difference provided some reverb is added to the sound.

Hope this is okay?

1. Open attached score (produced in 1.3).
2. 'Play'.

Result: Despite being fully panned to the left, sound is heard on the right.

Using MuseScore 2.0 Nightly Build (77f7d29) - Mac 10.7.5.

I thought you'd like an update on progress guys.

I am now around a third of the way through this task.

Problem is I'm extrememly busy with RL at the moment.

Will do some more soon.

OK guys, I've finally finished a mono version of Fluid R3 which I am releasing under a Creative Commons Attribution-NonCommercial 4.0 International Licence.

It badly needs beta testing before it can be included in a stable release, so perhaps you could all put it through its paces and try to break it/find any issues I've missed etc - the usual beta testing stuff :)

I am now preparing it for upload to my GitHub repository and will be submitting a pull request so that it can be included in the Nightly builds for easy testing.

Report back on any issues/errors/inconsistencies here.

Pull Request #772 now sent.

If you want to access this stuff before it gets merged you can get it here:

https://github.com/ChurchOrganist/MuseScore/tree/FluidR3Mono

I shall be producing an SF3 version once it has cleared beta.

Several issues:

1/ I don't think it's a good idea to merge a huge SF2 soundfont in the master for testing purpose. It will stick in the repository history for ever. So the beta testing will need to be carry out in a different way.

2/ The license. The original Fluid soundfont is licensed under MIT license, which is very liberal, doesn't require attribution and can be used for commercial purpose. I respect your license choice and your work but I think it's a bad idea to make the default soundfont in MuseScore unusable for commercial purpose and the attribution clause make it very unpractical to share any audio file create with the soundfont. So I would not merge any modified version of FluidR3 that is not MIT licensed.

Ah - I hadn't realised that my choice of licence would affect anything created with the soundfont.

My main concern was to prevent someone pulling it out of MuseScore and exploiting it commercially.

Regarding beta testing - maybe we can get people to download from my Github repository? I will post notices in both the Soundfont and Technology Preview forums regarding this.

At the moment the CC 4.0 licence applies merely to the beta version, and can be replaced with a suitable licence once we have established its stability.

This link is direct to the relevant directory in my Github repository:-

https://github.com/ChurchOrganist/MuseScore/tree/bfeb2da03a9f6b51604e13…

It has emerged that trying to download from my Github repository results in a corrupted file.

Here is a link to the soundfont at Dropbox:-

https://www.dropbox.com/s/46bjuuw13tlo44c/Fluid%20R3-MonoGM2-6beta.zip

Please note the branch at my Github repository referred to above has now been deleted.

Please use the dropbox location to download the file.

Do I understand from the deafening silence that all is OK?

Or are people just not testing the soundfont :)

Hmm, just did an initial test, with Promenade Example: panning to the far left or right and I can still hear quite a bit (and IMHO too much) on the other side.
Comparing with the builtin SF3 font I actually spot only a tiny, if any, difference in panning?

OK Jojo

I've done some testing this morning with the following findings.

Using the Synthfont player, both the new mono version of Fluid and the old SF2 version respond properly to panning messages - a hard left or hard right pan setting resulting in only the left or right speaker playing sounds.

In both MuseScore 1.3 and the nightly builds there is a very limited panning effect - no more than about 30° either way.

So either there is some limit placed on it in the code, or it is a limitation of the Fluid soundfont player (or the result of the customisation).

I shall do some more investigation.

Tested using a self build based on commit 646397a

@ChurchOrganist In order to solve this issue #21814: Playback of SF3 features loud pops, we had to push a new version of the soundfont, and Werner pushed your beta6 mono version since it makes sense to use a mono version.

So questions for you:

1/ Are you ok to change the license to MIT ? If not we will have to revert to a non mono but attenuated MIT version made by ABL, or do it ourself, which is perfectly fine as well.

2/ If you are ok chaning the license, do you have a better version? If yes, can you upload it somewhere?

Sure there is no problem putting an MIT licence on it if you are happy with it overall - I was going to change it to MIT for the released version anyway.

I'm afraid I still can't track down the cause of the panning error, but I suspect it is related to the change from a graphical screen co-ordinate to MIDI data.

It would be really helpful if we could create a flowchart which shows which sections of the program are called from where.

I suspect that only Werner would be able to do this?

OK thank you for the green light on the license.

Regarding the panning, I'm not sure I understand your suspicion. The MIDI value passed to the seq and the synth for PAN is between 0 and 127. I just verified it here https://github.com/musescore/MuseScore/blob/master/mscore/mixer.cpp#L237
This value is passed to fluid "correctly", meaning here https://github.com/musescore/MuseScore/blob/master/fluid/fluid.cpp#L194 event.DataA is 0A and DataB between 00 and 7F.
These values ends up here https://github.com/musescore/MuseScore/blob/master/fluid/chan.cpp#L101 and set PAN_MSB (but not LSB) to 0 to 127. What Fluid does with it is a bit unclear to me. But I guess it gets it here https://github.com/musescore/MuseScore/blob/master/fluid/mod.cpp#L112 and multiply the modulator value by this value, if the modulator match the PAN cc.

So it's possible that there's bug in Fluid?

I'll have a play on Ubuntu Studio and try to work out what is happening.

I can now confirm that this is a problem in Fluidsynth.

A simple test using Ubuntu Studio with the Virtual MIDI KEyboard connected via QJackCtrl to QSynth revealed that Fluidsynth does not pan to the extremes of left and right, the right speaker is still active when the Pan controller is set to 0 and vice versa when set to 127.

I have changed the issue title to reflect this and set the status of the issue to active.

It is now up to the programming team to decide whether they want to alter Fluid's code to rectify this.

Just done some more testing in Ubuntu Studio to make sure the panning was not a freak caused by the VirtualBox sound system.

It definitely seems to be FluidSynth at fault neither QSynth nor MuseScore will pan to extreme left or right.

I've just been looking into the possibility of filing an error report with the FluidSynth developers, but there seems to be no easy way of doing this.

I am therefore leaving this for someone else to chase up when they have the time.

https://lists.nongnu.org/archive/html/fluid-dev/2012-06/msg00026.html

Looks like there is no bug in fluid, and moreover no need for us to discard R3's stereo samples either. I reckon we just patch our own Fluid to force full panning at all times, but others' opinions may differ (i.e. we could also patch R3). It looks like libsndfile is nearly building with cmake as well, so if we just patch our own Fluid then we could probably leave our R3 completely unmodified (afaik, the only modifications we ship are the mono split and the volume attenuation, yes?)

Here is a quick patch to fluid to force full panning, even on stereo soundfonts. Also of interest is listening to the difference in Piano sample toggling between the stereo and mono soundbanks; there is probably much less difference with the other GM sounds though.

https://github.com/akdor1154/MuseScore/compare/fluidDefaultPan?expand=1

From the article.......
Fluidsynth's panning implementation is correct. In the SoundFont spec, instruments are given a set of default modulators that can be overridden by the SoundFont designer if he/she so desires. One of these is the CC

10 -> pan amount, which is set to 500 (50%) by default. Antoine, you will need to change this modulator value to 1000 (100%) at the instrument level to achieve the effect you desire (both samples panned hard to one side). You can make this change per assigned sample, but it's usually most convenient to change the modulator in the instrument's global zone.

If we patch Fluidsynth then other soundfonts may not behave properly - it would be best therefore to leave Fluidsynth as it is and just change the pan modulator value to 100% in Fluid.

There is actually no real benefit in using stereo samples for most instruments - if you think about it nearly all of them are actually monophonic sources, the exceptions being some keyboards, ensemble sounds and tuned percussion, all of which have a limited stereo image, but need specialist set up of the instrument to prevent ridiculous things like a piano occupying the entire stereo soundstage when the speakers are several feet apart :)

The interesting thing about the standard Fluid Soundfont is that the samples you would expect to be stereo are not.

We may, therefore, just as well save on memory and download bandwidth and use the mono variant.

I will start work on altering the pan modulators shortly - it won't take long.

I think I've changed my mind on this....

I've just been looking at the Soundfont 2.1 spec.

Nowhere does it say that the panning amount should be 50% (500). I think there has been a logic error on the part of the Fluidsynth team brought about by the fact that Controller 10 (Panpot) is a positive bipolar device running from -50% to 50%. the range between -50 and 50 is of course 100 which in Soundfont terms is 1000, central panning (0) being represented by 500

I quote from the soundfont spec.....

8.4.6 MIDI Continuous Controller 10 to Pan Position

Source Enumeration = 0x028A (type=0, P=1, D=0, CC=1, index = 10)
Destination Enumeration = Initial Attenuation
Amount = 1000 tenths of a percent
Amount Source Enumeration = 0x0 (No controller)
Transform Enumeration = 0 (Linear)

The MIDI Continuous Controller 10 data value is used as a Positive Bipolar source; thus the input value of 0 is mapped to a value of -1, an input value of 127 is mapped to 127/128 and all other values are mapped between –1 and 127/128 in a linear fashion. There is no secondary source for this modulator; thus its effect is the same as the effect of multiplying the amount by 1. The amount of this modulator is 1000 tenths of a percent panned-right.

The product of these values is passed through a “Linear” transform (or is left uninhibited) and is then added to the Pan generator summing node.

Maybe we should patch Fluidsynth after all

Opinions?

I mostly don't understand your post... Where would you patch fluidsynth? CC10 is sent to fluidsynth as a number between 0 and 127 by MuseScore and I think fluidsynth expect it like this. Do you think it's wrong? Or are we talking about 2 different things?

There are two levels in a soundfont.

The first is the interface which responds to MIDI messages, in the case of Controller 10 (PanPot) these range from 0 to 127.

The second level is how the actual synth interprets the midi message, and this is the layer I am talking about.

Controller 10 is implemented by means of 1000 tenths of a percent, this ranges form a value of from 0 to 1000 representing -50% to 50% so sending a Controller value of 0 would be interpreted as -500, sending a controller value of 64 would be interpreted as 0 and sending a value of 127 would be interpreted as 500. This is because the PanPot controller is positive bipolar - in other words it centres on 0 as in this pic:-

The Fluid team have forgotten that this is a bipolar controller and have given it a default value of half its range - 500 instead of 1000

Consequently the synth, although capable of responding to the full range of Panpot messages is currently only using half the range because the default heas been set too low.

The patch mentioned by akdor1154 recitfies this by changeing the panning amount to the full 1000

Is that any clearer?

The alternative is to change the modulator settings in the soundfont.

This would have to be done for every soundfont used with Fluid to be able to pan fully left and right

I don't think that explanation is completely accurate, but I don't have enough of an understanding of fluid's pan algorithm to offer a thorough alternative! Somehow, the same number is being used both as a stereo width and as a pan value (I guess if any two numbers were put into the Pan value and multiplied [= modulated] then we'd see this behaviour).
The problem with R3 is not that fluid sets its default too low, it's that this default never gets used and the font's own, very small pan values get used instead. I think what would be desired behaviour (for our use of Fluid) is the wide default is applied to all soundfonts - users are currently advised to just grab a custom soundfont if their favourite instrument is not in fluidgm, and without this behaviour, such soundfonts may also pan "incorrectly". My patch implements this behaviour in a simple but maintainable (if we ever pull changes from Fluid) way.

Indeed, as I've not (and do not intend to) examined Fluid's algorithm. My explanation is based purely on the Soundfont 2.1 spec.

It is clear that Fluidsynth is not following the Soundfont 2.1 spec exactly, and most soundfonts will not pan properly because of this.

Can you submit a pull request akdor?

Wow.

Great.

Regards,

See PR #1172

ahhhhh. Zita is a culprit in this too! More info when I get home and play some more...

I would expect it to be normal for there to be sound from both channels in the Reverb return. It should only be the "wet" signal, however. There should not be any of the "dry" signal present.

I won't have time to do a build to test this until the weekend.

An easy way to test the focus of the panning is to switch off the reverb send completely.

OK I've tested this out now.

There is a very slight bleed into the opposing channel for a fully dry signal in Zita.

It is only -40dB, however, and some noise-floors are higher than that!

It has become very clear during this testing that the mixer reverb and chorus controls are now redundant, and I shall be opening another issue regarding this.

I strongly recommend then akdor that you reopen the pull request you sent.

Fixed in d79ce4f

Automatically closed -- issue fixed for 2 weeks with no activity.