Re: [fluid-dev] Re: Fluidsynth voice stealing

[Josh Green]

On Fri, 2005-10-14 at 12:02 +0200, Tim Goetze wrote:
> thinking about this (early morning thoughts by the coffee mug after a 
> loooong night) i'd say the factor to weigh could be 'number of voices 
> already in use by the same channel the new voice is on' - cutting off 
> a note played on the same instrument to make way for the next 
> one should be less perceptible than cutting an essentially monophonic 
> instrument like the bass (or, even worse, a lead voice!)
> 

Good point.  So if an active voice count was kept for each channel as
well as the maximum count, then another criteria could be
(this_channel_voice_count / max_channel_voice_count) *
synth->channel_voice_factor.  I suppose this doesn't really take into
account the act of switching instruments while voices from the previous
instrument are still playing, though.

> >Proposed changes (some stuff still needs to be researched):
> >- Improve volume level rating (keep track of voice levels?)
> 
> i don't have the fluid sources readily available, but the very first 
> implementation of the function in question did evaluate the current 
> envelope state and gain of every voice.
> 

Yes, FluidSynth does currently track volume based on the volume
envelope, I was just questioning whether thats enough.  The volume
envelope doesn't really reflect the actual volume of the voice, although
it does give a rough idea.

> >- Improve voice age rating (ticks and/or noteID)
> 
> when i worked on the above first algo, i found voice age far too 
> simplistic. one long-held pedal note can be fundamental to the 
> musical impression,  even though it might even last for 64 bars or 
> more.
> 

Hmm, true.  I believe it should still be improved though, since in its
current state a weighted factor cannot be applied.  If this was
improved, then it would at least be more configurable (a small factor
could be chosen making it less of a priority).  Maybe only voices which
are in the release stage should fall under the age criteria, or just
keep the release factor separate from the age factor.

I realized that the voices are already iterated over once (in
fluid_synth_alloc_voice) before being handed off to the
fluid_synth_free_voice_by_kill if a free one is not found.  Calculated
values that require iteration over all the voices could be done in the
first loop if it seems appropriate (such as oldest voice ticks or ID).

> [...]
> >- Add variables to voice structure for each criteria (ratings get stored
> >here for statistics)
> 
> i tend to think that dynamic calculation of the instantaneous value of 
> the criteria is preferable (if we can get along with a one- or at most 
> two-pass iteration). this keeps the voice struct clean, and 
> concentrates the complete voice killing logic in one place so it's 
> more easily understandable (versus calculation of the criteria values 
> spread all over the dsp department).

Right, I suppose they don't really need to go in the voice structure.
My original thinking on this was flawed.

> 
> fwiw, i found the overhead of instantaneous calculation to be minimal, 
> even in a busy piece; and that was way back on a k6/350 iirc.
> 

I would guess so as well, since it only occurs during note on when max
polyphony is reached.

> >- Add voice kill log to track what voices got killed and the criteria
> >ratings of the voice (the reason)
> 
> that would certainly help a lot in debugging problematic and corner 
> cases.
> 
> cheers, tim
> 

Ciao.
        Josh

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