[Fluxus] max-synths

Kassen signal.automatique at gmail.com
Fri Jun 1 00:49:09 PDT 2012


On Fri, Jun 01, 2012 at 08:07:00AM +0100, David Griffiths wrote:

Hey Dave,
> 
> max-synths is really the maximum number of playing sounds at any one
> time (whether they consist of 1 or 100 nodes, no difference). This is
> mainly a "blunt instrument" to control CPU usage.
> 

Ok, so the docs are correct there about the intention.

> 
> When you lose parts of playing synth graphs which affects the sound,
> it's because there are a fixed number of them and they are getting
> recycled to use for new graphs. The number of nodes limit is about
> memory use, and partly puts a ceiling on graph complexity for CPU.
> 
> There is almost certainly something funny going on though. I haven't for
> example been able to work out the limiting factor between these key values:
> 
> * The max-synths value

I imagine this should be the main limiting factor under normal
conditions. Good thing too, as that one is adjustable from the user's
perspective.

I would, however, think that when we set out to have this be the
limiting factor on purpose by setting it to 1 it should have a audible
effect and it doesn't. I suspect it might be broken, though that alone
wouldn't explain everything I noticed.

Can I ask what you set this to in your own practice?

> 
> * Total number of nodes: controlled by the constructor of m_Graph in
> Fluxa.cpp (currently 70 of each type and 2000 terminal nodes)
> 

I'm nearly sure this is not it. I can't imagine hitting this unless
we'd set out to do additive synthesis in Fluxa or something similar.

> * The EVENT_BUFFER_SIZE=256 set in Fluxa.h - this is the ring buffer
> size for the commands sent to the synth, it's possible this is filling
> up under extreme cases.


This shouldn't explain what I was seeing as max-synths failed to be
the limiting factor, but of course it might.
> 
> I would suggest chain-sawing the above variables and posting your results!
> 
Ok, not today though as I need a working Fluxa this evening :-)

BTW, I read a article about coding for realtime systems and
difficulties there and it struck me that if you'd follow those
guidelines stubornly, regardless of how exotic the design you'd end up
with or what is "normal" for audio languages or synths you would end
up with something quite close to FLuxa. Is there any merrit to the
theory that that would be exactly what you did?

Yours,
Kas.



More information about the Fluxus mailing list