Re: [fluid-dev] Voice-stealing logic, and more

[David Henningsson]

On 2010-06-30 01:13, Elimar Green wrote:
> Hello David,
> 
> Sounds like some progress! :)  

Yeah. To give you (and myself!) a rough overview, here are some work items:

* Refactor envelopes, lfos and resonant filter into separate classes [DONE]

* Move source files into new directory structure [Done, except for
Makefile.am]

* Refactor voice class into voice and rvoice, whereas rvoice stands for
the hard real-time, dynamic part of the voice and the voice stands for
generators, modulators, midi interpretation. [DONE]

* Make event queue for thread boundary, so the voice can send updates to
the rvoice [DONE]

* Refactor mixer class out of fluid_synth for buffers, reverb and
chorus, i e most of fluid_synth_one_block [IN PROGRESS]

* Make fluid_synth support different thread scenarios: single-thread,
mutex-protected, both scenarios with and without rendering in parallel.
Should we keep the existing queue mechanism? [TODO]

That should be it for having a stable synth core without reordering
problems. IMO, enough for a release.

In addition, I think we could:

* Make fast-render super-fast by reworking core thread implementation
and the fluid midi player callback. The new mixer class is prepared for
rendering more than one block at a time, thus reducing the amount of
synchronization.

* Libfluidsynth has lots of dependencies, so split libfluidsynth into
two libraries, where the new "libfluidsynthcore" library should be
enough for more embedded use cases, such as dssi. It should only depend
should on libc, and optionally glib for thread support (e g, without
thread support for iPhone).

> There have been discussions concerning
> the voice stealing algorithm in the past.  Here is a link to a
> relevant thread in the list archives:
> 
> http://lists.nongnu.org/archive/html/fluid-dev/2005-10/msg00017.html
> 
> In summary, the thought was to add settings for the various weightings
> of the voice stealing algorithm and possibly have voice stealing
> algorithm presets (which could just set the weighted values).
> 
> Other improvements to the existing voice stealing algorithm
> (copy/pasted from that thread):
> - Improve volume level rating (keep track of voice levels?)
> - Improve voice age rating (ticks and/or noteID)
> - Add settings for selecting voice stealing presets and setting custom
> weighted rating values
> - Add variables to voice structure for each criteria (ratings get stored
> here for statistics)
> - Add voice kill log to track what voices got killed and the criteria
> ratings of the voice (the reason)

Right. The question is whether we can make the decision with "static"
data only, i e no data from the rvoice. Today the voice-stealing
algorithm looks for static data only, except for one piece of
information coming from the volume envelope. Can we live without that or
replace it with something else, that would be great.

> I'm excited that you are delving into this stuff.  I may have a little
> time in the coming weeks to put towards FluidSynth.  So let me know if
> there is anything in particular that could use researching or
> implementing.  Cheers!

Thanks! Well, I'll just finish the mixer (hopefully today or tomorrow),
then I think the first thing you should do is to get accustomed to the
new code and structure. See if you understand everything, if you need to
slap my face for not following code conventions (I keep forgetting about
them) ;-) , and if there seem to be any problems with the new stuff.
Think. Just so we get everything really right this time!

>> One of my design patterns is to split some of the behemoth objects into
>> smaller objects, in order to improve cohesion and readability. 

Sorry for my wording here. Some of the objects are a bit too big IMO,
but "behemoth" was probably a bit exaggerated.

// David