How difficult would it be to have FluidSynth generate (or come
packaged with) a test sf2 file which would be played by FluidSynth
and listened to programmatically for any problems? The script could
run during package configuration or with a command line parameter
like --calibrate. A pseudo-code example (without knowing much about
FluidSynth unfortunately) could be:
# Test all possible settings and add the ones that work to
~/.fluidsynth/goodsettings.cfg
for output_device = 1 to 3
for setting3 = best_quality3 to worst_quality3 step -1
for setting2 = best_quality2 to worst_quality2 step -1
for setting1 = best_quality1 to worst_quality1 step -1
if test_sf2(output_device, setting1, setting2,
setting3) = TRUE then add_settings_to_list(output_device, setting1,
setting2, setting3)
next setting1
next setting2
next setting3
next output_device
The test_sf2 function would play the test sf2 using the settings
supplied by the for/next loops and listen for high latency and
distortion. Distortion could hopefully be detected by the script if
the test sf2 was something simple like a square or sine wave by
looking for variations in amplitude (skipping or popping). Latency
could be detected by calculating the time between sending the MIDI
note data and getting an audio response from the device. If an error
was returned then the settings would be discarded obviously.
Once the list of acceptable settings has been generated, the one to
use as the default settings would automatically be chosen based on
what are considered sane settings. In other words, if setting1 was
the highest/best and setting2 was the lowest/worst then that would
not be the preferred configuration. Rather the settings that were
closer to being balanced would be chosen. An example would be:
Settings 1: high sample rate (good), high latency (bad)
Settings 2: low sample rate (bad), low latency (good)
Settings 3: medium sample rate (okay), medium latency (okay)
The script would choose Settings 3 as the default settings. The user
could then list/modify the default settings from the command line or
by editing the FluidSynth config file in their home directory.
A few things that would need to be considered would be:
Testing the various available output options (JACK, ALSA, OSS, etc.).
Checking for the presence of jackd and starting it when testing JACK.
Finding a way to programatically listen to and analyze audio sent to
the various output devices.
Saving separate lists of good settings for each output option.
Choosing (or allowing the user to choose) the default output device.
Allowing the user to easily change the default output device.
Allowing the user to easily change the default saved settings.
Allowing the user to override the saved settings and specify all
parameters manually.
Creating user-oriented documentation of these features.
I know that's probably going to be a terrible amount of work, so
maybe it's better just to leave it alone.
KEVIN FISHBURNE
Eight Virtues
www:
e-mail:
phone: http://sales.eightvirtues.com[1]
address@hidden
(770) 853-6271
Louis B. wrote:
The below email was sent just to me but I would like to share it
with the list.That is a really good idea, but a better idea might be
to have a "startfluid" script that is provided either by the
distribution or is part of the fluid synth team that works like the
startx script. ie it starts up fliud in the best manor with a GM
sound set. I think it would be best to have _one_ script that could
be run by all the different midi apps that want fluid started. PB
could then call start_fluid which would just start fluid with the
best possible config for that distribution. in an ideal world there
would be no distribution differences.Just an idea any way. what do
think about a startfluid script?LouisOn Thu, May 21, 2009 at 11:38
PM, Joan Quintana <> wrote:
If QSynth crashes, I think that the problem is that, in setup, jack
audio driver is selected. When you start QSynth it starts without
-l option: doesn't try to start jack. So, if jack is not running,
it crashes. Solution: first start jack; or use alsa audio driver
directly.In your case, a possible solution is: PB is launched by a
script. This script first attempts to start fluidsynth, and later
start PB. This script could be these two lines long, or 10ths
lines: for instance, detect soundcards available... this script can
also read a configuration file... PB could be great, but bash
scripting and programming coud make it better.
_______________________________________________ fluid-dev mailing
list address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Links:
------
[1] http://sales.eightvirtues.com
[2] mailto:address@hidden