[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Elimar Green
Subject: Re: [fluid-dev] New voice overflow code committed
Date: Sun, 1 Aug 2010 18:17:44 -0700

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]