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 -----
Re: [fluid-dev] New voice overflow code committed
2010-08-04 11:59, Bernd Casper skrev:
> Hi David,
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.
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
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)
I'm also wondering if you have tried the latest changes
synth.cpu-cores=2 (or more) and seen if that gives better
for you? It should.