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

[Tim Goetze]

[Josh Green]
>Currently the channel is indeed taken into account, but the somewhat
>opposite effect is implemented.  A drum channel instrument has a higher
>priority than other channels when it comes to selecting a voice to kill.
>Seems a bit wrong, since a rapid series of percussion with long decays
>will kill other instruments if the max polyphony is reached.  It might
>be nice to have channel priority though (simply lowest channel = higher
>priority?)  If a weight were assigned to this the user could assign
>instruments with higher priority to lower channels (perhaps exclude the
>DRUM channel from this criteria and have its own).

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

>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.

>- 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.

[...]
>- 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).

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.

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