Hi Kassen, On 05/31/2012 09:46 PM, Kassen wrote: > Dear dave, > > I find max-synths in Fluxa a bit suspicious. In particular I was > happily jamming along when adding a extra mooglp caused some highhat > accents to be lost. No problem, I thought, I'll just increase > max-synths. That did not help, not even for a generous increase. I > then read the docs which talk about "synth graphs", which I take to > refer to the node pulled by "play" and any children it may have > -recursively- as one such "graph".
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. > I always assumed we cycle based on the number of nodes, not on the > number of such graphs. That idea is strengthened by how adding a extra > filter node to graph A would affect graph B. However, it does not > explain how max-synths for generous amounts or for a value of 1 (to > test) wouldn't affect what I hear. 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 * Total number of nodes: controlled by the constructor of m_Graph in Fluxa.cpp (currently 70 of each type and 2000 terminal nodes) * 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. > Do we have any known issues there or am I simply using stuff in the > wrong way? I'm happy to cheerfully go in with my surgical chain-saw > but this sounds like something you might have notes on. I would suggest chain-sawing the above variables and posting your results! cheers, dave
