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

[David Henningsson]

2010-08-01 19:00, Elimar Green skrev:
> 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.

Okay, changed and committed. Speaking of terminology, I found "overflow"
in the GM Guide document and also found it sounding better than
"voice-stealing".

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

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

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

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

> Thanks again for all the work you are doing :)

You're welcome :-)

// David