I'd be willing to test:

  * SoundFont compatibility, particularly the proper rendering of
    SoundFont 2.1 modulators, etc., since I use these quite frequently
    in my own SoundFonts.  I should be able to quickly tell if something
    gets broken in this department.
  * Voice-stealing logic.
  * Reverb & Chorus effects.

You know, I have yet to find another SoundFont-compatible softsynth that
renders all of the SoundFont spec as accurately as FluidSynth (or even
close), so hats off to all of you who have contributed to FluidSynth
over the years!  Now if only I could run it as a VSTi, but that's
another matter ;)

-~Chris


On 07/11/2012 01:57 PM, David Henningsson wrote:
> Something I've been thinking of for a while, and the recent thread
> reminded me of that thought...
>
> FluidSynth is quite a versatile program/library, and we all want
> different things out of it. No one of us has the full picture, or uses
> FluidSynth to all the different things it can be used for.
>
> Making sure that none of all these use cases break, is one of
> FluidSynth's biggest challenges, and maybe sometimes it can cause us
> to be overly cautious.
>
> Here's a proposal that might help us with that challenge.
>
>  * Before every release, a release candidate tarball will be released.
>
>  * You agree to install and test the tarball in the way(s) you have
> signed up for. You are also welcome to test the svn trunk, this is
> optional but can be very helpful.
>
>  * If your test succeeds, you report back on a wiki page we will use
> to track tests and testers.
>
>  * If your test fails, you both report that on the wiki page, and on
> the mailinglist.
>
>  * Your benefit will be the fantastic glory of having your name on the
> wiki page ;-)
>
>  * Your real benefit will be that it will be less likely that
> FluidSynth will be buggy for your use case, i e, you - and others who
> use FluidSynth in the same way - will be able to upgrade safely.
>
> Obviously we'll try to fix bugs that come up, especially if they are
> regressions from a previous version of FluidSynth, but there are no
> guarantees given.
>
> The imagination is the limit of tests to choose, but here are some
> examples:
>
>  * Testing that the tarball builds for your favorite operating system
> and build environment
>
>  * Testing a certain backend driver (jack, alsa, pulseaudio, coreaudio
> etc)
>
>  * Testing that low-latency does not regress, i e, that you can run
> without xruns with at least the same latency as you could before.
>
>  * Testing a specific program or binding you use together with
> FluidSynth (jOrgan, QSynth, SDL bindings, etc etc)
>
>  * Testing that "fast render" can still render as fast as it could in
> the previous version
>
>  * Testing that some soundfont file still renders to the same sounds
> (or better)
>
>  * Testing the internal midi player (with your favorite song), and/or
> sequencer
>
>  * etc etc
>
> What do you think? It obviously won't be much of a tester program
> without a bunch of testers, so is this anything you think would make
> so much sense, that you would be willing to run a test or two yourself?
>
> // David
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>


_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

Reply via email to