[Top][All Lists]

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

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

From: Bernd Casper
Subject: Re: Re: [fluid-dev] New voice overflow code committed
Date: Thu, 5 Aug 2010 11:48:58 +0200

Hi David,
many thanks for response. No, I haven't tried multi-core CPU usage already - this was because I didn't study the FS API alright. It was my guess, FS would automatically use all CPU kernels available, for default. I'm not at the console computer presently, but as soon as I have test results, I'll inform you.
Many thanks and regards

----- Folgende Nachricht wurde empfangen -----

Empfänger: bca
Zeit: 2010-08-04, 22:21:09
Betreff: Re: [fluid-dev] New voice overflow code committed
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]