[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Proposal: FluidSynth tester program

From: S. Christian Collins
Subject: Re: [fluid-dev] Proposal: FluidSynth tester program
Date: Wed, 11 Jul 2012 14:09:12 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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 ;)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]