Repro-1 (out now)

[Urs]

Since Diva's release...there were the people who thought it took too much CPU, and that wasn't warranted. This thread is about latter. It's about showing that implementing the same physical/analogue model sounds different if done with CPU saving shortcuts.

Has there been a lot of "CPU too high" complaints with Diva lately? I know it was an issue on first release, but once you implemented the multi-core button, it's been 100% a non-issue here. On my newer i7 desktop, even less so. I consider Diva's CPU use as reasonable these days (not low, not high, but reasonable).

It isn't as bad as it was back then, but we still get a lot of "I have Diva and I love it, but I can't use it".

It also goes a bit further than that. There are articles and reviews about us and our stuff in magazines and blogs that start with "u-he, who are known for their CPU-taxing plug-ins...". I hear the same on trade shows, during small talk whatsoever. People - if they know about us at all - associate u-he with high CPU load. And if there's a smirking undertone I don't think it's because "but hey, it sounds great", it's because "well, I guess you gotta live with that if you like their stuff". Of course you'll hear a different view as often, but it bugs me when this happens.

So I've decided to change this. The key ingredient of this campaign is education

[ATN69]

Since Diva's release...there were the people who thought it took too much CPU, and that wasn't warranted. This thread is about latter. It's about showing that implementing the same physical/analogue model sounds different if done with CPU saving shortcuts.

Has there been a lot of "CPU too high" complaints with Diva lately? I know it was an issue on first release, but once you implemented the multi-core button, it's been 100% a non-issue here. On my newer i7 desktop, even less so. I consider Diva's CPU use as reasonable these days (not low, not high, but reasonable).

It isn't as bad as it was back then, but we still get a lot of "I have Diva and I love it, but I can't use it".

It also goes a bit further than that. There are articles and reviews about us and our stuff in magazines and blogs that start with "u-he, who are known for their CPU-taxing plug-ins...". I hear the same on trade shows, during small talk whatsoever. People - if they know about us at all - associate u-he with high CPU load. And if there's a smirking undertone I don't think it's because "but hey, it sounds great", it's because "well, I guess you gotta live with that if you like their stuff". Of course you'll hear a different view as often, but it bugs me when this happens.

So I've decided to change this. The key ingredient of this campaign is education

Well, I love your stuff and that's why I bought Zebra2, Hive and ACE and they work 100% perfect. I just need to figure out what I might be doing wrong with Diva. I Think that the education you are talking about is needed, because me for one was, until recently, not fully aware about the so called devine mode and how that works ..but I am not complainig. Besides, not only U-he stuff need CPU load. There is a whole lot of plugins that are hungry. Ozone 5 for example

[wagtunes]

Since Diva's release...there were the people who thought it took too much CPU, and that wasn't warranted. This thread is about latter. It's about showing that implementing the same physical/analogue model sounds different if done with CPU saving shortcuts.

Has there been a lot of "CPU too high" complaints with Diva lately? I know it was an issue on first release, but once you implemented the multi-core button, it's been 100% a non-issue here. On my newer i7 desktop, even less so. I consider Diva's CPU use as reasonable these days (not low, not high, but reasonable).

It isn't as bad as it was back then, but we still get a lot of "I have Diva and I love it, but I can't use it".

It also goes a bit further than that. There are articles and reviews about us and our stuff in magazines and blogs that start with "u-he, who are known for their CPU-taxing plug-ins...". I hear the same on trade shows, during small talk whatsoever. People - if they know about us at all - associate u-he with high CPU load. And if there's a smirking undertone I don't think it's because "but hey, it sounds great", it's because "well, I guess you gotta live with that if you like their stuff". Of course you'll hear a different view as often, but it bugs me when this happens.

So I've decided to change this. The key ingredient of this campaign is education

I have ACE, Bazille, Diva and Zebra 2 along with a few of your free synths. Made libraries for all of them. Had to. That's how great they are.

And I run them all fine on an I3. Yes, an I3.

So screw all the naysayers.

People just need something to complain about.

[deltaMACHINE]

still I3 iMac here no problems

[BR393]

As far as I'm concerned U-He is and has been the premier soft synth developer in the market for some time now. The only other soft synths I've encountered that match the sound quality of U-He's products are NI's Monark and the latest Blocks modules with Reaktor 6. These products have kept me from spending a fortune on analog hardware. I don't think it's necessary to spend the extra money for hardware synths anymore when software is finally starting to sound every bit as good. It's seems crazy to me that people complain about these products being too CPU taxing when they sound so close to the original hardware being emulated. Even if you have to go out and by a computer with the most high end CPU available to run them (which you don't) it would still be a far cheaper option than trying to acquire all of the original hardware.

[Vesius]

I'm not sure we have heard a linear "best to worst" in terms of CPU in this test. I have a feeling that different filters have been testing different things, like some filters have different ways of modelling the resonance loop, or some filters try different ways of oversampling, or *insert different technique here*.

I wouldn't be surprised to find that things might not be as clear cut as expected, and that the best filter involve aspects of more than one of the filter models. But, whatever, I am very curious indeed as to what what is what, and it's been very enjoyable, so thanks Urs and team.

[louderr]

I have never watched a thread so closely in my life. Not a big forum watcher except when I'm trying to troubleshoot or gather people's opinions about this or that product. But something about this has made me jump into the community in a big way. I'm pretty new to soft synths but I've experimented with hundreds of plug-ins since last September. I've got a lot of electronics and record production experience so I've been getting up to speed rapidly and have started programming synths comfortably lately. But I'm far from being an expert. What I'm not getting is that filters 3 & 4, which are everyones faves here, didn't work very well on my computer. I got a lot of stairstepping, dropouts, and other artifacts in much of the filter/resonance ranges. So I sort of "dismissed" those filters and went with #1 (dirty & fun) or #2 (thin but sexy). My computer wasn't overly taxed, I had the Mac activity monitor and Ableton CPU readout available. I do remember the sound of the Prophet and others although but never got to own any of the original synths. So I voted for what I liked, since I had no other comparison point. Now I'm intrigued by these (messy but interesting) results. What am I missing, exactly? I want to train my ears a little better. Is it possible that these filters gave wildly different results on various computers and speakers? Or is the variance more subjective, as it may very well be in my case? And what about the dropouts and artifacts across parts of the filter range in #3 and #4. Personally, I thought #5 worked okay and had good fidelity but it struck me as sort of "bland". Just reporting, interested in feedback on this

[moscom_electronics]

I have never watched a thread so closely in my life. Not a big forum watcher except when I'm trying to troubleshoot or gather people's opinions about this or that product. But something about this has made me jump into the community in a big way. I'm pretty new to soft synths but I've experimented with hundreds of plug-ins since last September. I've got a lot of electronics and record production experience so I've been getting up to speed rapidly and have started programming synths comfortably lately. But I'm far from being an expert. What I'm not getting is that filters 3 & 4, which are everyones faves here, didn't work very well on my computer. I got a lot of stairstepping, dropouts, and other artifacts in much of the filter/resonance ranges. So I sort of "dismissed" those filters and went with #1 (dirty & fun) or #2 (thin but sexy). My computer wasn't overly taxed, I had the Mac activity monitor and Ableton CPU readout available. I do remember the sound of the Prophet and others although but never got to own any of the original synths. So I voted for what I liked, since I had no other comparison point. Now I'm intrigued by these (messy but interesting) results. What am I missing, exactly? I want to train my ears a little better. Is it possible that these filters gave wildly different results on various computers and speakers? Or is the variance more subjective, as it may very well be in my case? And what about the dropouts and artifacts across parts of the filter range in #3 and #4. Personally, I thought #5 worked okay and had good fidelity but it struck me as sort of "bland". Just reporting, interested in feedback on this

Personally I did not notice dropouts and artefacts on 3. 4 produced some artifacts when modulated like crazy, but behaved very nicely otherwise and very close to 3. 2 and 5 did not produce anything interesting to my ears, they just remained gentle and bland. 1 sounds good, but certainly not analogue. I would love this filter as a digital-sounding option though!

[pdxindy]

And what about the dropouts and artifacts across parts of the filter range in #3 and #4. Personally, I thought #5 worked okay and had good fidelity but it struck me as sort of "bland". Just reporting, interested in feedback on this

Dropouts sounds like a cpu issue... 3 and 4 seem to use just a slight bit more cpu. When I tried RePro at 96khz both 3 and 4 got some cpu crackles, though the cpu meter hardly changed.

[louderr]

I know the topic of this thread isn't CPU usage, directly. But since Urs brought up the 'educational' motive as part of this experiment I have a comment that I hope is helpful: Yes, one of the first things I heard about U-He was how CPU-"hungry" the synths are. Its practically at the start of every review. But they always pointed out how GOOD these products sound. So for me that wasn't a deterrent, in fact it was a motivator. I went directly to the website and started to download the demos and to read everything I could find about Urs and the company. I figured, "...well, if these synths are using so much CPU they must be doing some heavy, hi-res math. What's the design philosophy behind that?"

With the advent of Hive, U-He began to tout the low CPU usage, almost apologetically. I felt sort of bad about that because the synths like Diva, Ace, Zebra are simply awesome and deserve mad respect. I'm planning to buy a couple of them soon. Hive sounds fabulous too but the point is that one can expect a heavy overhead for super "analog" resolution. Now, I think it's great that Urs is working on a virtual CV-style approach to polyphony, among other things. Improvement is always welcome. But I think that to some people, like myself, the CPU question was actually a PLUS because it made me curious enough to learn more about U-He in a world of competing products. Its a madhouse out there with so many new synths coming out every day. U-He stuff comes sort of "pre-approved" as warm, rubbery, fat, analogue-esque. Partly because it takes real processing power? Just a thought.

I appreciate Urs including us in his research. It's a lot of fun, enlightening, and i'm sure it attracts dedicated fans. I'm certainly one of the new U-He loyals. It's fascinating to be in on the development of something like this!

[Urs]

A quick reply to recent posts:

Artifacts in 3 & 4 are most likely CPU spikes, resulting from intentionally bad optimization.

About the "gradually less accurate" modeling... all 5 filters approximate a set of 4 "unsolvable" mathematical equations. They are unsolvable because they are of the form of y = tanh( y ), so that the resulting y is needed to be known to compute itself. That is, one can not isolate y on the left hand side of the equation and so it isn't possible to solve these equations directly, like one would with a pocket calculator. Other means need to be deployed and these equations have to be solved for each sample.

Now, two filter algorithms overcome this by calculating the current y with the result for y of the previous sample. So the what's inserted on the right hand side is a y that is delayed by one sample. Mathematically what's solved is y = tanh( y_delayed ). This is called a unit delay and it is the opposite of what's called zero delay feedback. The difference between these two algorithms is that one does this twice per sample to improve the result.

Two other filter algorithms overcome this by replacing the tanh() function with something else, so that the equations take the form y = a * y, which can be rearranged so that y is isolated on the left hand side. In this case however the replacement of tanh() by a factor "a" is again based on a unit delay, but the overall equation is not. Again, one of the two algorithms adds a corrective step to improve the accuracy.

Lastly, one algorithm computes the actual equations of the form y = tanh( y ) as they are, but it involves computing the whole filter not once or twice, it involves computing it several times, usually between 2x and 6x until the correct solution is found. This algorithm provides for a mathematically accurate method without any form of unit delay.

(some people will argue that a unit delay is required for "history", and that's undeniable, but it's needed for the integration in the capacitor model, not for the computation of the currents and voltages at a point of time)

As such, all 5 filters are based on the same set of equations, hence the same "model" of a filter. All they do is deploy different strategies to solve those equations.

But mind you, even the worst method using bland unit delays is beyond average quality here because we're calculating at an internal sample rate beyond 300kHz. In arguments about DSP, people often argue that if one oversampled enough, the differences between the methods would disappear, and usually 8x is enough. But clearly, the differences do not disappear - which I think we're proving here, and which this is really about.

I'll start writing my conclusion today and I hope to publish it next week

[hansiwalker]

Filter #3 is the only one i really like. The only one which sounds good for my ears ("analogue" is not a quality by itself).

[nortle]

Since Diva's release...there were the people who thought it took too much CPU, and that wasn't warranted. This thread is about latter. It's about showing that implementing the same physical/analogue model sounds different if done with CPU saving shortcuts.

Has there been a lot of "CPU too high" complaints with Diva lately? I know it was an issue on first release, but once you implemented the multi-core button, it's been 100% a non-issue here. On my newer i7 desktop, even less so. I consider Diva's CPU use as reasonable these days (not low, not high, but reasonable).

It isn't as bad as it was back then, but we still get a lot of "I have Diva and I love it, but I can't use it".

It also goes a bit further than that. There are articles and reviews about us and our stuff in magazines and blogs that start with "u-he, who are known for their CPU-taxing plug-ins...". I hear the same on trade shows, during small talk whatsoever. People - if they know about us at all - associate u-he with high CPU load. And if there's a smirking undertone I don't think it's because "but hey, it sounds great", it's because "well, I guess you gotta live with that if you like their stuff". Of course you'll hear a different view as often, but it bugs me when this happens.

So I've decided to change this. The key ingredient of this campaign is education

Limitation in music software is not that bad today... I hate endless possibilities..

[ImNotDedYet]

A quick reply to recent posts:

Artifacts in 3 & 4 are most likely CPU spikes, resulting from intentionally bad optimization.

About the "gradually less accurate" modeling... all 5 filters approximate a set of 4 "unsolvable" mathematical equations. They are unsolvable because they are of the form of y = tanh( y ), so that the resulting y is needed to be known to compute itself. That is, one can not isolate y on the left hand side of the equation and so it isn't possible to solve these equations directly, like one would with a pocket calculator. Other means need to be deployed and these equations have to be solved for each sample.

Now, two filter algorithms overcome this by calculating the current y with the result for y of the previous sample. So the what's inserted on the right hand side is a y that is delayed by one sample. Mathematically what's solved is y = tanh( y_delayed ). This is called a unit delay and it is the opposite of what's called zero delay feedback. The difference between these two algorithms is that one does this twice per sample to improve the result.

Two other filter algorithms overcome this by replacing the tanh() function with something else, so that the equations take the form y = a * y, which can be rearranged so that y is isolated on the left hand side. In this case however the replacement of tanh() by a factor "a" is again based on a unit delay, but the overall equation is not. Again, one of the two algorithms adds a corrective step to improve the accuracy.

Lastly, one algorithm computes the actual equations of the form y = tanh( y ) as they are, but it involves computing the whole filter not once or twice, it involves computing it several times, usually between 2x and 6x until the correct solution is found. This algorithm provides for a mathematically accurate method without any form of unit delay.

(some people will argue that a unit delay is required for "history", and that's undeniable, but it's needed for the integration in the capacitor model, not for the computation of the currents and voltages at a point of time)

As such, all 5 filters are based on the same set of equations, hence the same "model" of a filter. All they do is deploy different strategies to solve those equations.

But mind you, even the worst method using bland unit delays is beyond average quality here because we're calculating at an internal sample rate beyond 300kHz. In arguments about DSP, people often argue that if one oversampled enough, the differences between the methods would disappear, and usually 8x is enough. But clearly, the differences do not disappear - which I think we're proving here, and which this is really about.

I'll start writing my conclusion today and I hope to publish it next week

Great explanation Urs! There's nothing like geeking out on math first thing in the morning. But interesting seeing how you've chosen to solve the problem in the different filters.

As for CPU usage...I'll admit I held off on Diva for a long time due to the CPU load reputation it had. Once I finally gave in, I realized number one, that it wasn't as bad as people said, and that two if I just froze a track if I needed the CPU cycles, it was fine. That is after all, how I record hardware synths, so from a workflow perspective it's not a big deal.

[overhishead]

need to hear some actual analog filters in order to tell which one sounds more analog. i can't vote until i have compared the two myself.