[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:
synth.voice-steal-algo
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
signature.asc
Description: This is a digitally signed message part
- [fluid-dev] Re: Fluidsynth voice stealing, Josh Green, 2005/10/13
- [fluid-dev] Re: Fluidsynth voice stealing, Toby, 2005/10/14
- Re: [fluid-dev] Re: Fluidsynth voice stealing, Norbert Schnell, 2005/10/14
- Re: [fluid-dev] Re: Fluidsynth voice stealing, Josh Green, 2005/10/14
- Re: [fluid-dev] Re: Fluidsynth voice stealing, Josh Green, 2005/10/14