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