Firstly - by strange attractors - I mean something like a Lorenz Oscillator:

http://en.wikipedia.org/wiki/Lorenz_system

In code it's something like this:

float h,a,b,c;
h = 0.01f;
a = 10.0f;
b = 27.0f;
c = 8.0f / 3.0f;

for( int s = sampleFrames; s > 0; --s )


      x1 = x0 + h * a * (y0 - x0);
      y1 = y0 + h * (x0 * (b - z0) - y0);
      z1 = z0 + h * (x0 * y0 - c * z0);
      x0 = x1;
      y0 = y1;
      z0 = z1;

It does obviously require scaling and an HP filter - but it's fun noise to play with. Now the question is: how do I get it to sound the same @ different samplerates? It has unit delays - so it's basically a type of filter.

Anybody here with some practical advice, played around with something similiar?

Andrew

Off the top of my head, can't you just use a Runge-Kutta method with the delta at the sample rate (probably a multiple)? It's been a while since I did this, so I could be way off.

http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods

I did some work on chaos theory and numerical analysis in college. I can try to dig up my old code if you want. It's pascal and uses Runge-Kutta methods to solve different sets of equations with chaotic solutions, including lorenz.

Hope it helps.

I've seen some RK4 solver for the lorenz system - seems very CPU heavy - just for a noise-generator!

My code posted above does work though - if you vary the c parameter from 2.666 -> 7.666 in real-time - it sounds like your trying to "stangle the wind" - would be lovely for eerie-pad sounds!

The only problem is - if you look at my code above - is that the 'for' loop updates at samplerate - and if the samplerate changes - so does the divergence of chaos. If that makes any sense.

This is how a lorenz-attractor sounds @ 96kHz (well - actually 2 of them).

http://soundcloud.com/ichad-c/lorenz-demo

From your code you have a fixed dt and are extending the range t (t>0) with samplerate. This will indeed change the solution range.

Have you tried replacing h with dt where

      h = 0.1f * bestsamplerate
      dt = h / samplerate
so
      x1 = x0 + dt * a * (y0 - x0);
      y1 = y0 + dt * (x0 * (b - z0) - y0);
      z1 = z0 + dt * (x0 * y0 - c * z0);
bestsamplerate is basically the rate at which it sounds best with your current code. It will then fix the t range and you will just be getting it in finer detail with higher samplerate.

WARNING: Take care as this is all head code. I reserve the right to completely change it once I've tried it.

Cheers.

Seems like a good idea, thanks! I though of maybe updating it faster/slower but was/is worried about the ODE solver falling apart due to gaps, and the recursive nature of the whole thing in general. Too late @ night to test it here though, as I have a disliking to headphones. Will test it - first thing in the morning! Hopefully - if it works - I could find a "dt" value for Rossler, Van der Pol, Duffing, Chua, and the Brusselator(love that name).

Later

Andrew

Hi Andrew,

I'll try to dig out my code. It's in storage though, so no promises. It has Rosslers et al, including some nice coefficient and initial values.

Cheers,
Nigel

with this approach, one could get it sound higher and lower and qualitatively the same at different samplerates. but i would assume that, when you compare a signal created with oversampling to a signal created without oversampling (using the same parameters and start values), at the same physical time instant (in seconds), you could end up at a completely different sample-value for both signals, as the numerical time-discretization may create a chaotic divergence between the oversampled and non-oversampled signal on its own. if this is to be used as a modulation signal in the time domain (as a chaotic LFO), this is probably undesirable. so, i would probably go with a fixed internal sample-rate and then resample to get different pitches/speeds.

Robin, you are right, it will. That is why I initially said that a multiple of the sample rate would be better. The multiple would depend on the sample rate range, so say 4x for < 50Hz, 2x for 50Hz to 100 Hz and just 1x for > 100Hz. Is is not oversampling exactly because you are not just getting intermediate values, you are also changing the end result.

My solution for my college work was to have an adaptive delta. So if the new set of values were too far away from the last ones, I did the iteration again with a smaller dt. This "riding the error margin" worked quite well for my work. It meant the code ran faster than just using a fixed, smallest common delta. The end result of my code was mostly animation, though.

oh yes, adaptive stepsize control is often a good idea as well. but this internal stepsize (whether adaptive or fixed) should in any case be independent of the external sample-rate and pitch/speed, if a match between time-domain signals at different speeds/pitches/sample-rates is desired.

edit: adaptive stepsize control, of course, creates another problem: you have to resample a source signal that is sampled at irregular time instants to the (fixed) target sample-rate, so a lot of our usual resampling filters will not be applicable. linear interpolation is easy to generalize to irregularly spaced samples, though.

Could you then pre-render the solution and then just play it, changing for pitch etc.?

well, yes. that's basically what i mean when saying: render it at an internal sample-rate and then resample.

Sorry didn't see you mention render and was thinking mid-post.

i didn't use the term "render" in the post further above, (i actually said: "go with a fixed internal sample-rate and then resample" - but the "go with" was meant to mean "render").

As I read that I was actually thinking about calculating at the lowest acceptable resolution (high delta) and then interpolating/up sampling. Whereas the render would be at the highest resolution and then go down. This would allow the real-time to be CPU friendly and the offline to be accurate.

I really should actually get this into a computer.