Plug-ins, Hosts, Apps,
Hardware, Soundware
Developers
(Brands)
Videos Groups
Whats's in?
Banks & Patches
Music Search
KVR

KVR Forum » DSP and Plug-in Development
KVRist
 Posted: Wed Jul 04, 2012 8:46 am reply with quote
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
^ Joined: 08 Feb 2012  Member: #274678  Location: South - Africa
khanyz
KVRian
 Posted: Wed Jul 04, 2012 8:55 am reply with quote
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.
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
KVRist
 Posted: Wed Jul 04, 2012 9:56 am reply with quote
khanyz wrote:
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.
^ Joined: 08 Feb 2012  Member: #274678  Location: South - Africa
KVRist
 Posted: Wed Jul 04, 2012 11:01 am reply with quote
This is how a lorenz-attractor sounds @ 96kHz (well - actually 2 of them).

^ Joined: 08 Feb 2012  Member: #274678  Location: South - Africa
khanyz
KVRian
 Posted: Wed Jul 04, 2012 11:08 am reply with quote
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.
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
KVRist
 Posted: Wed Jul 04, 2012 11:40 am reply with quote
khanyz wrote:
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

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
^ Joined: 08 Feb 2012  Member: #274678  Location: South - Africa
khanyz
KVRian
 Posted: Wed Jul 04, 2012 12:17 pm reply with quote
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
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
Robin from www.rs-met.com
KVRAF
 Posted: Wed Jul 04, 2012 1:23 pm reply with quote
khanyz wrote:
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.
Cheers.

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.
----
^ Joined: 08 Mar 2004  Member: #15959  Location: Berlin, Germany
khanyz
KVRian
 Posted: Wed Jul 04, 2012 1:29 pm reply with quote
Robin from www.rs-met.com wrote:
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.
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
Robin from www.rs-met.com
KVRAF
 Posted: Wed Jul 04, 2012 1:49 pm reply with quote
khanyz wrote:
My solution for my college work was to have an adaptive delta.

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.
----
^ Joined: 08 Mar 2004  Member: #15959  Location: Berlin, Germany
khanyz
KVRian
 Posted: Wed Jul 04, 2012 1:55 pm reply with quote
Could you then pre-render the solution and then just play it, changing for pitch etc.?
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
Robin from www.rs-met.com
KVRAF
 Posted: Wed Jul 04, 2012 1:58 pm reply with quote
khanyz wrote:
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.
----
^ Joined: 08 Mar 2004  Member: #15959  Location: Berlin, Germany
khanyz
KVRian
 Posted: Wed Jul 04, 2012 2:01 pm reply with quote
Sorry didn't see you mention render and was thinking mid-post.
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
Robin from www.rs-met.com
KVRAF
 Posted: Wed Jul 04, 2012 2:16 pm reply with quote
khanyz wrote:
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").
----
^ Joined: 08 Mar 2004  Member: #15959  Location: Berlin, Germany
khanyz
KVRian
 Posted: Wed Jul 04, 2012 2:38 pm reply with quote
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.
----
PM me for 10% off at the FabFilter shop (New Customers Only).
^ Joined: 16 Jul 2004  Member: #33410  Location: Yorkshire, UK
 KVR Forum Index » DSP and Plug-in Development All times are GMT - 8 Hours Printable version Page 1 of 2 Goto page 1, 2  Next