Re: [fluid-dev] New voice overflow code committed

[Elimar Green]

On Sat, Jul 31, 2010 at 2:00 PM, David Henningsson
<address@hidden> wrote:
> Okay, so I found the bug I talked about in my previous mail, and
> committed the new voice overflow code.
>
> The new ones brings in five new weight settings (voice.overflow.*) for
> prioritizing volume, age, and special weights for drum channel,
> sustained and released (those three were according to the old code):
>
> synth.overflow.age       FLOAT [min=-10000.000, max=10000.000, def=1000.000]
> synth.overflow.drum-channel FLOAT [min=-10000.000, max=10000.000,
> def=4000.000]


I think synth.overflow.percussion might be more in line with existing
terminology.  There may be more than one drum channel too, when we get
into supporting different MIDI modes.


> synth.overflow.released  FLOAT [min=-10000.000, max=10000.000,
> def=-2000.000]
> synth.overflow.sustained FLOAT [min=-10000.000, max=10000.000,
> def=-1000.000]
> synth.overflow.volume    FLOAT [min=-10000.000, max=10000.000, def=500.000]
>
> The numbers for volume and age were chosen arbitrarily, so please play
> around with them and let me know your favorite defaults.
>

Is there any way, besides listening to the results, to indicate when a
voice overflow occurs and what was replaced?  It seems like that would
be really useful in tuning those parameters.  This is why I thought
having a voice overflow log would be nice, though more work of course
;)  I suppose a semi quick and dirty method would be to printf
debugging statements when enabled or something.

> As a side note, I also added the possibility to have polyphony up to
> 65535 voices (which should be enough even for jOrgan users!) and that
> the polyphony can increase on-the-fly, which did not work before. Having
> so many voices might mean some overhead (and memory usage) even if
> they're not used though.
>

I think the way it worked before (or at least should have worked) is
that the initial value for the polyphony set the maximum allowed value
(and the memory requirements), you could then adjust it to be less
than the system maximum.

With this new change, does that mean that the memory allocation is
always for 64k voices?  That is probably a significant amount of
memory if so (64k * sizeof (FluidVoice) at least).

> Now I rely on you to be my testers! :-)
>
> // David
>

Thanks again for all the work you are doing :)

Cheers.

Elimar