[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Re: Fluidsynth voice stealing
From: |
Tim Goetze |
Subject: |
Re: [fluid-dev] Re: Fluidsynth voice stealing |
Date: |
Fri, 14 Oct 2005 12:02:24 +0200 (CEST) |
[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
- [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