[Top][All Lists]

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

[fluid-dev] Re: Fluidsynth voice stealing

From: Josh Green
Subject: [fluid-dev] Re: Fluidsynth voice stealing
Date: Thu, 13 Oct 2005 13:48:10 -0700

On Thu, 2005-10-13 at 15:35 +0200, Norbert Schnell wrote:
> Hi Josh!
> On 13 Oct 2005, at 10:58, Josh Green wrote:
> > I'm CCing the FluidSynth devel list on this..
> First of all I discovered that my modifications of the voice stealing  
> algorithm don't work properly... Ooops!

No damage done yet :)

> Our observation is that with a high polyphony, the CPU use of  
> FluidSynth gets up quickly.
> Using it in the framework of Max/MSP usually means using it with many  
> other processing in the same audio thread.
> So, we'd like to limit the polyphony and use a well adapted voice  
> stealing.
> Yes, "well adapted" to the musical material. I have the strong  
> impression that voice stealing for song MIDI files mixing drums,  
> harmonic and solo instruments could be rather different than for  
> sound textures or Bach fugues or whatever and also depends on the  
> used soundfont...
> So, beyond different weights I'd even propose different  
> "modes" (including the classical "kill-the-oldest", which is not bad  
> is many situations).
> For now there seems to be this urgent problem in the current voice  
> stealing algorithm:
> Notes which are just starting don't get the needed priority because  
> they don't sound yet.
> This is bothering for ongoing chords: The second note of the chord  
> might right away kill the first before being killed by the third and  
> so on. The result is that only one note sounds instead of a chord.
> Well, so far the observations. Sorry, for the bogus code. I'll come  
> up with something better soon.
> Don't feel overvalued. I'd be with you in this, proposing:
>   1. introduce different voice stealing modes (I would propose an API  
> and code)
>   2. having the current algo as default (and evolving step by step)
>   3. adding different algos (I'd provide the "kill-oldest-code")
> How this can be organized properly?
> Cheers
>    Norbert

I like the idea of having different voice stealing algorithms.  I can't
think of a good way to expose this API externally though, since it
should be relatively fast and often requires poking around in internal
structures which aren't publicly defined (or probably shouldn't be :)
If you can think of a good way to create a pluggable voice stealing
callback, I'm all ears.
For now lets just keep it simple and define a new enumeration settings
variable like:


We can then add code into the current fluid_synth_free_voice_by_kill()
to check this setting before running the voice stealing logic (could
break it up into multiple functions for each algorithm).

I'd like to try and come up with a solution for the voice age.  It seems
right now it is just not weighted correctly, since it should be a pretty
high priority rating in determining voices to kill.  If the oldest voice
# could be kept track of, it would be simple.  I'm also not sure whether
the voice ticks should be used in the calculation (voice age), or voice
note #.  If we can get this right though, it may work correctly in your
case as well.

Current list of proposed voice stealing algorithms:
default         // The current algorithm (with improvements)
oldest          // Oldest voice gets killed
quietest        // Quietest voice gets killed

How does this sound?
        Josh Green

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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