On Sun, Aug 1, 2010 at 11:21 AM, David Henningsson <launchpad....@epost.diwic.se> 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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
