[Top][All Lists]

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

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

From: David Henningsson
Subject: Re: [fluid-dev] New voice overflow code committed
Date: Wed, 04 Aug 2010 22:21:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Thunderbird/3.0.6

2010-08-04 11:59, Bernd Casper skrev:
> Hi David,
> thinking about this polyphony stuff, I wonder if FS could provide the 
> following addition to the current polyphony solution.
> In the past two years I worked with FS, I always did run more than one 
> instance of FS to ensure low latency and avoid polyphony cutouts. In my 
> experience, the systems run a soundfonts divided into two to four (with 2-4 
> FS instances) parts much better than only one big soundfonts in one instance 
> of FS. Synchronization already is nearly perfect, so far. Right now I've an 
> organ here running 20 instances of FS at the same time, without problems, on 
> an AMD DualCore system.
> In olden days, there were polyphony solutions which could raise the polyphony 
> that way, that the overflow messages were led to the hardware MIDI-out, and a 
> second hardware synth could be fed and run with the overflow messages.
> Would it be senseful and possible, to adapt this idea on software level, as 
> kinda "multi-instance usage"? In case FS recognizes overflow, automatically 
> and dynamically to start a new instance and to re-route the overflow messages 
> to that new instance, instead of cutting them out? The user would need a 
> switch, to decide how many FS instances he would allow. A default of 4 would 
> be great.
> Regards
> Bernd.

Hi Bernd,

Copied in the list on your post, hope you don't mind.

The idea is interesting but I think it would be better to, before every
note-on, to check if there are enough voices available, and if not, to
dynamically increase (e g double) the polyphony.

I'm also wondering if you have tried the latest changes with -o
synth.cpu-cores=2 (or more) and seen if that gives better performance
for you? It should.

// David

reply via email to

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