Robin Schmidt

this is why i have the BreakpointEnvelopeData class. all BreakpointEnvelope objects for the same mod-target (amp, cutoff, ..) but different voices refer to the same "data" object. in this case,...

all this data is shared among voices ```cpp template class rsBreakpointModulatorData { public: T scaleFactor; T offset; T bpm; T sampleRate; T minimumAllowedLevel; T maximumAllowedLevel; T endLevel; T minBreakpointDistance; T...

but as said - i consider that as rather heavy handed. i think, the design i proposed above is more convenient and for new polyphonic synths, i'd rather implement that...

the problem is that with that data class etc. even a monophonic breakpoint envelope will need to have all that code - then lying dormant - that is very undesirable

i'll try to come up with something in the coming days. i actually want to be able to chain polyphonic modules in ToolChain, too - like chain a polyphonic osc...

hmmm - i'm not so sure anymore about my design idea. maybe the "every voice is a new instance" idea makes more sense...i'm currently looking into how juce does it...

i'm not sure what you mean with *interpreting* in this context. do you mean, if the noise is modeled in some way? at the moment, most the noise is modeled...

for modeling noise, this algorithm here could be useful: https://pdfs.semanticscholar.org/e777/f38fbb4817e41c9fb2b87d24d51cddc1ed6a.pdf?_ga=2.31492158.1209010308.1561792114-1197917107.1561792114 ...i once implemented it in matlab long ago. i guess, i could dig out the code and port it to...

you may use class `ModulatorCurveEditor` directly.

why not subclassing BreakpointModulatorEditor?