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

[Elimar Green]

On Sun, Aug 1, 2010 at 11:21 AM, David Henningsson
<address@hidden> wrote:
>> 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.
>
> Okay, changed and committed. Speaking of terminology, I found "overflow"
> in the GM Guide document and also found it sounding better than
> "voice-stealing".
>


Yeah, I like "overflow" better as well.


>>
>> 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.
>
> Actually, there is one already, when compiled with enable-debug:
>
>  FLUID_LOG(FLUID_DBG, "Killing voice %d, index %d, chan %d, key %d ",
>            voice->id, best_voice_index, voice->chan, voice->key);
>
> I added it for my own debugging (hmm, perhaps "index" is not anything a
> casual user would have use for...).
>


Cool.  Seems like a user would at least know when a voice gets killed.
 A nice addition would be the various scores that the killed voice
had, to know why it got killed and aid in adjusting the various
overflow weights.


>>
>> 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.
>
> Actually synth->nvoices was set to synth->polyphony and not 4095 (the
> previous maximum).
>

Yes, which I think is a settings parameter.  So assigning the relevant
settings value prior to instantiating the synth would set 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).
>
> The array will be reallocated, and new voices created, when the
> polyphony is updated.
>

Great!  This was avoided previously, since it couldn't be done in a
thread safe manner.  If you happened to resolve that, then cool! :)

>> Thanks again for all the work you are doing :)
>
> You're welcome :-)
>
> // David
>

Cheers.

Elimar