Ce forum permet à des personnes du monde entier de communiquer, c′est pourquoi les messages échangés sont en anglais.
-
I've created presets in Polyphone using a sine wave sample with 72 dB, 48 dB, and 0 dB attenuation, then rendered a 1-s tone of each with Fluidsynth, then put the wav files through Audacity's spectrum analyzer.
The difference in the peaks is only about half as much as the numbers provided to Polyphone, and I don't understand why. Is this a suitable way to verify the effect of the attenuation parameter? Thanks.
-
Hello,
Could you please do the same test with fluidsynth?
At the beginning of Polyphone I tested the sound engine against fluidsynth and I was surprised the same way. I don't remember exactly how I did but the factor 0.5 was added to reproduce the fluidsynth behaviour. An error is not excluded.
Regards,
Davy -
Davy, le -Hello,
Could you please do the same test with fluidsynth?
At the beginning of Polyphone I tested the sound engine against fluidsynth and I was surprised the same way. I don't remember exactly how I did but the factor 0.5 was added to reproduce the fluidsynth behaviour. An error is not excluded.
Regards,
DavyThanks for the reply. I'm not sure what you mean. The test I performed used Fluidsynth. The role of Polyphone in the test was merely SoundFont editor.
I thought of one possible variable affecting attenutation: the note velocity in my MIDI files was the editor's (Aria Maestosa) default of 80. I changed it to 127 and got results similar to the first test.
-
Ok I read your message too quickly.
For sure, the attenuations set in Polyphone are correct (I already tried to save with Polyphone and open with Swami for instance). But as I said, when I listened to the result between Polyphone and Fluidsynth I also remarked the additional factor 0.5 for the attenuation. I have no answers where it comes from but for consistency I also added it in the sound engine of Polyphone. Maybe you should ask the fluidsynth team directly.
The final attenuation depends also on the velocity, that's why you need to test with 127 (full velocity). A lower velocity may also alter the sound with a low pass filter.
Davy -
Preset/Instrument level attenuation should attenuate 0.4 dB for every 1 dB that you specify (and this is what FluidSynth does). The reason for doing this is compatibility... this is how Creative/E-MU designed their synth engines (I have personally measured dB levels to verify this), and the thousands of SoundFonts out there expect this behavior.
-
Hey thanks for the information!
I will change the multiplier, for compatibility . -
Davy, le -Ok I read your message too quickly.
For sure, the attenuations set in Polyphone are correct (I already tried to save with Polyphone and open with Swami for instance). But as I said, when I listened to the result between Polyphone and Fluidsynth I also remarked the additional factor 0.5 for the attenuation. I have no answers where it comes from but for consistency I also added it in the sound engine of Polyphone. Maybe you should ask the fluidsynth team directly.
The final attenuation depends also on the velocity, that's why you need to test with 127 (full velocity). A lower velocity may also alter the sound with a low pass filter.
DavyNow that Polyphone is known to be incorrect relative to the Creative/E-MU implementations, somebody should tell the Swami developers that their program is incorrect too. Would you prefer to do it or should I? -
Swami uses FluidSynth under-the-hood, so it should already be handling this correctly.
-
The synthesizer output is one way that a SoundFont is presented. Another way is as numeric values in an editor. Polyphone has the problem that when the editor says the attenuation is 10 dB, the synthesizers actually use 4 dB. The UI should be changed to say 4 dB in that case.
I understood from Davy that Swami shows the same attenuation value as Polyphone. If that is correct, Swami's UI should also be changed to show the actual attenuation that the synthesizer will use. -
I see what you are saying now, sorry. Yes, to have the SoundFont editors reflect the *actual* attenuation that will occur rather than the numeric value stored in the SoundFont is a good idea.
-
This is indeed a good idea for consistency between the unit and the value displayed. This can easily be done since this is just "cosmetic", at the ui level.
But this might be surprising for users. I know for example which amount I should add or remove to modify the intensity of the sound, and including the 0.4 factor will imply a new learning with these values. Moreover, all other parameters dealing with dB are impacted (modulators, envelops, ...).
My question would be: is this fix worth the effort to re-learn the handling of attenuations?
Being rather rigorous I would fix the interface. But for sure we will got a lot of questions and some users will like to see the same values between all other soundfont editors.
Davy -
Davy, le -This is indeed a good idea for consistency between the unit and the value displayed. This can easily be done since this is just "cosmetic", at the ui level.
But this might be surprising for users. I know for example which amount I should add or remove to modify the intensity of the sound, and including the 0.4 factor will imply a new learning with these values. Moreover, all other parameters dealing with dB are impacted (modulators, envelops, ...).
My question would be: is this fix worth the effort to re-learn the handling of attenuations?
Being rather rigorous I would fix the interface. But for sure we will got a lot of questions and some users will like to see the same values between all other soundfont editors.
DavyWhat do you mean by this? As far as I know, the 0.4 dB factor only applies to instrument and preset level attenuation values. It shouldn't affect dB calculations for things like velocity curves, etc.My question would be: is this fix worth the effort to re-learn the handling of attenuations?
Being rather rigorous I would fix the interface. But for sure we will got a lot of questions and some users will like to see the same values between all other soundfont editors.
I agree. Perhaps the editable value should remain as it is, but then the actual amount of dB attenuation could appear next to it in parentheses. This is the solution I would prefer as a SoundFont designer. -
You could perhaps have two viewing modes affecting all fields together:
* display as raw integer soundfont values
* display as conventional units
Connectez-vous ou inscrivez-vous pour participer à la discussion.
Polyphone a besoin de vous !
Polyphone est gratuit mais il y a des coûts associés à son site web et à son développement. Un petit coup de pouce aidera beaucoup.
Faire un don
Apprenez les bases
Voir le tutoriel
Haut de
page
page