Urs, I have two questions...

[Photontic]

I want to preface this, since it is the internet, by saying that this is NOT some passive-aggressive stab at saying "omg, why does your stuff use so much CPU! Learn to program!". It is purely me asking so I can understand why it is, because I just can't wrap my head around it, as I have no knowledge of DSP programming. I have some programming knowledge and for instance, having worked with 3D graphics, I can wrap my head around why that takes a lot of CPU power.

So if you can explain, without going into too much detail, why for instance Diva is so CPU hungry, I would much appreciate it. What goes on with the code that it ends up being so taxing on the CPU?

On a tangent to this I thought of something else... A lot of us have pretty powerful GPUs in our systems these days - could they be used for DSP computing?
I realize that there's probably a whole bunch of issues regarding it, for instance I assume that you pretty much have to have two versions of the plug-in code to be able to have code running on the GPU as well, which is obviously a big undertaking for an option.
Another issue could be that you're not at all allowed to do this kind of thing from within the plug-in architecture.
There's of course also the issue with load, since it's a bit more tricky knowing when the GPU is overloaded (weak GPU, too many plug-ins set to use it), so it's not super transparent for the user what's going on, as opposed to watching the DAW's load meter.
I assume that there's not really any latency issues with doing it.

If we ignore the issues, could it technically be done? Would there be a benefit? It's just a thought I've been playing with and it would be cool to hear your take on it.

I hope you have time to indulge a curious soul.

[whyterabbyt]

On a tangent to this I thought of something else... A lot of us have pretty powerful GPUs in our systems these days - could they be used for DSP computing?

Im not Urs (obviously), but I'd suggest you search KVR, and particularly the DSP forum, for 'GPU'. Its a topic which has been discussed there many times, and the issues for audio are fairly well established. eg

http://www.kvraudio.com/forum/viewtopic ... &p=5604696

[Photontic]

On a tangent to this I thought of something else... A lot of us have pretty powerful GPUs in our systems these days - could they be used for DSP computing?

Im not Urs (obviously), but I'd suggest you search KVR, and particularly the DSP forum, for 'GPU'. Its a topic which has been discussed there many times, and the issues for audio are fairly well established. eg

http://www.kvraudio.com/forum/viewtopic ... &p=5604696

Nice, thank you for this.

[pdxindy]

You can also search this forum and in particular the original main Diva thread. There you would find technical explanations for the cpu use.

In short, it takes a lot of cpu to model the complex non-linear behaviors of classic synths. U-he plug-ins are highly optimized and at least as well coded cpu-wise any any plug-in out there.

cheers

[Photontic]

You can also search this forum and in particular the original main Diva thread. There you would find technical explanations for the cpu use.

In short, it takes a lot of cpu to model the complex non-linear behaviors of classic synths. U-he plug-ins are highly optimized and at least as well coded cpu-wise any any plug-in out there.

I'm looking for a bit more detailed information. I understand that it takes a lot of CPU power, but I want to know why. Why is this code so taxing? Yes, you're running code that models some things, but what semi-exactly is happening code-wise?

Is that mentioned in the thread? Is there that kind of detailed information? I've read some of it, as I'm interested in Diva (have yet to purchase it (need more money!)), but I haven't finely combed the thread.

[pdxindy]

You can also search this forum and in particular the original main Diva thread. There you would find technical explanations for the cpu use.

In short, it takes a lot of cpu to model the complex non-linear behaviors of classic synths. U-he plug-ins are highly optimized and at least as well coded cpu-wise any any plug-in out there.

I'm looking for a bit more detailed information. I understand that it takes a lot of CPU power, but I want to know why. Why is this code so taxing? Yes, you're running code that models some things, but what semi-exactly is happening code-wise?

Is that mentioned in the thread? Is there that kind of detailed information? I've read some of it, as I'm interested in Diva (have yet to purchase it (need more money!)), but I haven't finely combed the thread.

Your question has been asked and answered in detail a few times... and in this forum... I do not specifically remember it being in that thread, but that is a good guess. If not then another Diva thread. There is also the original Diva thread in the instruments forum. There is also a big Diva thread on Gearslutz.

I'm sure you can find what you are looking for in those threads. There has been quite a bit of discussion.

[Urs]

Why is this code so taxing?

It's simple.

There is a mathematical solution for this:

We know F, X, S1 and S2. y1 and y2 are unknown.

y1 = F * (X- y2) + S1
y2 = F * y1 + S2

We can get a single equation for y2 and solve everything in a simple manner, by substituting y1 in the second equation:

y2 = F * (F * (X - y2) + S1) + S2

By reordering this gives us

y2 = (F^2*X+S1*F+S2)/(F^2+1)

This can be computed in one go, all variables on the right hand side are known.

However, when we do non-linear stuff, it looks like this:

y1 = F * tanh(X- y2) + S1
y2 = F * tanh(y1) + S2

No matter what you do, you can't make this into a single equation that could be resolved to either y1 or y2. At best you get:

y2 = F * tanh(F * tanh(X- y2) + S1) + S2

One can't somehow get rid of the y2 that resides in the tanh term on the right hand side. The y2 on the left hand is always dependent on the y2 on the right hand side, that is, the result is dependent on the result itself. Impossible? No. Difficult? Yes.

What it means is, in order to solve it *accurately* one has to revert to numerical methods. Those methods iteratively probe values for teh y2 on the right hand side and test if the answer is correct, i.e. if the y2 on the right hand side yields the same value on the left hand side.

In pseudocode:

y2Right = y2 // start with previous sample

loop
{
y2Left = F * tanh(F * tanh(X- y2Right) + S1) + S2

if( y2Left == y2Right ) y2 = y2Left; end()

y2Right = ( y2Left + y2Right ) / 2; // meet half way and try again
}

This isn't actually correct, but you catch the drift. In order to find an y2 that makes the original equation work, we need to probe and refine our guess until the left and right hand sides of the equation converge. The actual mathematical term for this is "root finding algorithm". The one we use in Diva is faster than the fastest one found on Wikipedia (because we cheat by brutal optimisation for the synth filter case). However, it's still slower - obviously - than solving the filter in the naive way, or by cheating on numerical accuracy - which is the only chance to solve this faster.

- Urs

[Photontic]

Thank you, Urs! That was exactly what I was looking for and I now understand why it is as taxing as it is - I can wrap my head around that.

Thank you again for taking the time to satisfy my curiousity.

[Nielzie]

Can't you just simply program those models along the lines of: behave unexpectedly from time to time + add saturation with output

[Urs]

Can't you just simply program those models along the lines of: behave unexpectedly from time to time + add saturation with output

[BMoore]

The obvious follow up would be - why?

[valerian_777]

Proofs and Algorithms - An introduction for the rest of us ( by Urs Heckmann).

Thanx m8!!!

[xh3rv]

The obvious follow up would be - why?

The complete survey of the principles and mathematics is just a bit more esoteric

Googling 'zero delay filter' turns up a lot of resources, many on KVR and many from Urs.

[Urs]

The obvious follow up would be - why?

The complete survey of the principles and mathematics is just a bit more esoteric

Googling 'zero delay filter' turns up a lot of resources, many on KVR and many from Urs.

zero delay *feedback* filters - there's no such thing as a zero delay filter because the principle of filtering is always either related to frequency-dependent phase shifts (=delay by frequency), or to latency (=delay of whole signal) in the case of zero phase filters

[Urs]

The obvious follow up would be - why?

To build a pretty accurate model of an electronic circuit and say "yep, this is it!".