[patchShare] Duffing oscillator in gen~
Uses accumulation to integrate the differential equations found here: http://www.cfm.brown.edu/people/dobrush/am34/Mathematica/ch3/duffing.html
Nice! This is a really responsive system, has some lovely stable & unstable points, and nice transitions, thanks for sharing!
I took the liberty of hacking on it a bit:
I de-codeboxified it, since it doesn't really use any features that require codebox, and I wanted to see what would happen by inserting things here & there.
Found that toning down the amp before waveshaping helped retain a bit more of the curvature.
Added a 2nd output for the velocity, which has a rawer/brighter waveform but still useful.
Also I pulled out the cosine driver itself -- mainly because I wanted to see how it behaves when driven by non-cosine functions. (Kind of interesting, almost turns into a kind of env-following filter; esp. when friction is low).
Also turned the simulation rate (=> step size) into a signal input, to see what modulation would do. It's good :-)
And added a 2D scope~ to view the actual flows, which are pretty fascinating.
I think this might be a nice one to add to the chaotic oscillators in the gen~ examples.
Nice expansions Graham!
This is astounding work. Thank you, Both! đ
Wow!!!!
Great patch thanks !
Another good source for adaption of Chaotic Systems in gen~ is from one of Hans Mikelson's article in the Csound Book :
Hi everyone, thank you Jazer and Graham for this amazing object. We're having a lot of fun exploring it this week. Just one question though. It really crashes a lot. We've been exploring all the parameters to try to avoid it. What are you best pieces of advise to avoid such crashes? Best!
My first guess with these kinds of simulation is positive feedback; the Duffing is a 2nd order integrator (integration of integration) so that positive feedback can be extremely rapid.
The absolute simplest way to prevent this would be to insert some kind of limiting in the feedback loop.
Unfortunately, from what I can see, the cases where blow ups happen are not necessarily the largest ranges of x and v, so, applying limiting would break "normal behaviour". I also looked at maybe limiting at dx/dt and dv/dt, but the same thing holds: the ranges at "blowup" are not necessarily higher than the ranges of "normal behaviour".
But, after playing around with a few things, I found that simply sticking a [clip -200 200] in the feedback path for "x" seems to stop the blow ups. That's a pretty minimal change -- at that scale, the tanh shaping downstream will be already pretty much flat, so I think you won't really hear any difference.
Also maybe add a [clip -20000 20000] in the dv/dt loop, which should also be "mostly harmless".
Thank you so much Graham, and thank you for replying so quickly! Since we are in a bit of an extreme situation (we use audiodescriptors that send very hectic numbers), we had to push you tricks a bit further: [clip -100 100] in the feedback path for "x"; a [clip -100 100] in the dv/dt loop; a [clip -100 100] after the drive. Now we're crash free even when the index, depth and intrinsic frequency are at the max followed by brutal changes.
Hej everybody.
I found this thread while searching for implementations of oscillators like this or others like van der pool etc. in gen.
I am currently trying to understand how you you implemented the formula in gen. Could somebody explain me how to approach this?
I know that the first derivative means velocity, the second acceleration. I know we working in a discrete system and therefore need to integrate that way.
But I don't understand the technique of named History Loops and couldn't find any information on it. (what does + x mean in a History X loop?)
I also don't fully understand how we approach the dv/dt with the "simulation rate" (why isn't that just 1 sample?)
Quite messy - but thats how it is in my head atm. Thanks for your help!
Martin
//ah ok. + "X" in a History X Loop is the same as += (is there a reason to name the History Loops?)