[ANN] Infamous Plugins

[male]

fair enough. Again, it was mostly done with the goal of not performing floating point operations, mostly because I had been unsuccessful in getting guitarix running on my atom machine with acceptable latency. I imagine other distortion plugins would work and sound better on the system, but I grew curious about how to get a mildly decent saturation function by performing bitwise operations on the float representation. So it wasn't really a big performance goal, just a pet project. Had it been so I would have done benchmarking. But I got all excited and started making unwarranted performance claims. Apologies.

Anyhow, it seems there is little interest in this plugin, so I'm removing it from the repository. I'm leaving hip2b as I feel it gives a significantly different sound from the other plugins I've heard.

I definitely encourage you to do the benchmarking. Organized experimentation can be just as fun, and far more informative than just fiddling.

[tramp]

to give you some examples:
CPU~Single core Intel Pentium 4 CPU (-UP-) clocked at 2592.121 Mhz
jack with 128 frames/period at 48000Hz

GxTubeScreamer 1.3% CPU
GxTiltTone (tube overdrive) 1.3% CPU
GxAmplifier-X 4.5% CPU
GxMuliBandDistortion 2.6% CPU

If you interested in integer based dsp's, you may have a look at tintamp
https://gitorious.org/tintamp#more
they have port the guitarix tube emulation to integer math.

[male]

to give you some examples:
CPU~Single core Intel Pentium 4 CPU (-UP-) clocked at 2592.121 Mhz
jack with 128 frames/period at 48000Hz

GxTubeScreamer 1.3% CPU
GxTiltTone (tube overdrive) 1.3% CPU
GxAmplifier-X 4.5% CPU
GxMuliBandDistortion 2.6% CPU

If you interested in integer based dsp's, you may have a look at tintamp
https://gitorious.org/tintamp#more
they have port the guitarix tube emulation to integer math.

Interesting. Never heard of tintamp before. I'll check it out.

Where are you getting those CPU figures? Are those JACK DSP load numbers or..? Guitarix is written in FAUST, AFAIK and not known to be particularly efficient. And comparing an amp sim to a distortion plugin hardly apples to apples either.

[tramp]

Where are you getting those CPU figures? Are those JACK DSP load numbers or..?

Those are LV2 plugs, CPU load could checked in htop for process.

Guitarix is written in FAUST

Guitarix is written in C++
It's a plugin host, and provide a framework which allow to easy write and load plugins written in FAUST, C, or C++.
As well it supports LADSPA plugs.

AFAIK and not known to be particularly efficient

That's new to me, "AFAIK and not known to be particularly efficient", could you explain what you mean?
How knows that, from were?? Here guitarix runs very efficient.
When I compare NON Mixer with it, I come to nearly the same CPU usage (0.6 - 1.9% CPU for a empty project). As you properly know, mostly the plugs use the CPU. Now, if you speak about the "main amp plugin", it use here 3-5% of my CPU, so what, do you mean that is in-efficient?

And comparing an amp sim to a distortion plugin hardly apples to apples either

I just present it here, because ssj71 mention that he couldn't get it to run smoothly, I wonder why.
Some of the plugs be as well just distortion plugins (GxTubeScreamer,GxMuliBandDistortion) .

[male]

Where are you getting those CPU figures? Are those JACK DSP load numbers or..?

Those are LV2 plugs, CPU load could checked in htop for process.

Guitarix is written in FAUST

Guitarix is written in C++
It's a plugin host, and provide a framework which allow to easy write and load plugins written in FAUST, C, or C++.
As well it supports LADSPA plugs.

AFAIK and not known to be particularly efficient

That's new to me, "AFAIK and not known to be particularly efficient", could you explain what you mean?
How knows that, from were?? Here guitarix runs very efficient.
When I compare NON Mixer with it, I come to nearly the same CPU usage (0.6 - 1.9% CPU for a empty project). As you properly know, mostly the plugs use the CPU. Now, if you speak about the "main amp plugin", it use here 3-5% of my CPU, so what, do you mean that is in-efficient?

And comparing an amp sim to a distortion plugin hardly apples to apples either

I just present it here, because ssj71 mention that he couldn't get it to run smoothly, I wonder why.
Some of the plugs be as well just distortion plugins (GxTubeScreamer,GxMuliBandDistortion) .

The top figures are more or less meaningless, you need to look at the DSP load figures. Non Mixer will actually give you DSP load numbers for each group (or individual ungrouped strips) which can help you gather this information for LADSPA plugins. I'm not aware of any good way to get the figures for anything else other than to patch the program to record/report them. Regarding FAUST not being efficient: it's no secret that there are some design aspects of the language which make it more or less impossible to match hand-written code. I'm not saying it's grossly inefficient, but when you compare something written in FAUST to hand crafted C or C++ code of the same function, you're likely to see a difference in the DSP load favoring the hand-written code. So to compare something hand-written to something written in FAUST is hardly fair.

[tramp]

The top figures are more or less meaningless, you need to look at the DSP load figures. Non Mixer will actually give you DSP load numbers for each group (or individual ungrouped strips) which can help you gather this information for LADSPA plugins. I'm not aware of any good way to get the figures for anything else other than to patch the program to record/report them. Regarding FAUST not being efficient: it's no secret that there are some design aspects of the language which make it more or less impossible to match hand-written code. I'm not saying it's grossly inefficient, but when you compare something written in FAUST to hand crafted C or C++ code of the same function, you're likely to see a difference in the DSP load favoring the hand-written code. So to compare something hand-written to something written in FAUST is hardly fair.

So, if I get the CPU usage in htop for a process with , say prio -80, it is meaningless for you? Okay. . .
Regarding FAUST, there are some benchmarks out, were Julius Smith and Fons Adriaensen competing about the zita-rev source, well, FAUST language didn't loose. However, Faust language is block bounded, that is the only drawback, but you can extend FAUST with foreign functions, which you can wrote in C/C++.
I've no Idea were you have your knowledge of "no secret" from.

[male]

The top figures are more or less meaningless, you need to look at the DSP load figures. Non Mixer will actually give you DSP load numbers for each group (or individual ungrouped strips) which can help you gather this information for LADSPA plugins. I'm not aware of any good way to get the figures for anything else other than to patch the program to record/report them. Regarding FAUST not being efficient: it's no secret that there are some design aspects of the language which make it more or less impossible to match hand-written code. I'm not saying it's grossly inefficient, but when you compare something written in FAUST to hand crafted C or C++ code of the same function, you're likely to see a difference in the DSP load favoring the hand-written code. So to compare something hand-written to something written in FAUST is hardly fair.

So, if I get the CPU usage in htop for a process with , say prio -80, it is meaningless for you? Okay. . .
Regarding FAUST, there are some benchmarks out, were Julius Smith and Fons Adriaensen competing about the zita-rev source, well, FAUST language didn't loose. However, Faust language is block bounded, that is the only drawback, but you can extend FAUST with foreign functions, which you can wrote in C/C++.
I've no Idea were you have your knowledge of "no secret" from.

Yes. Meaningless. A plugin could usleep() in its run() method and that would count against your DSP load, but not your CPU load. Perhaps not the most realistic example, but it should be sufficient to get the point across, no? The DSP load is what matters, the CPU load includes to many other factors to be a very meaningful measurement.One can surely craft an example where C and FAUST performance is closely matched, but one would be extremely hard-pressed to craft an example where FAUST can beat hand written C. For one thing (and this is not insignificant) there is no such thing as branching or optional processing in FAUST, they advertise that as 'constant DSP load'. Well if you consider using more processing than necessary to be a feature, then sure, that's great. But in C or C++ you can avoid calculating smoothing, coefficients etc when doing so would be unnecessary, and therefore achieve lower average DSP load. But all of the details are entirely beside the point. The point is that if you compare a C distortion to a FAUST amp sim, the C distortion is going to win regardless. For ssj71 to conclude that his distortion is any kind of win in terms of efficiency, he must compare it to another distortion of similar capabilities written in C, not a FAUST amp sim. If you still have trouble understanding this, then I'm sorry, but I can't make it any clearer.

[tramp]

Well if you consider using more processing than necessary to be a feature, then sure, that's great. But in C or C++ you can avoid calculating smoothing, coefficients etc when doing so would be unnecessary, and therefore achieve lower average DSP load. But all of the details are entirely beside the point.

Did you ever used FAUST? It seems to me that you don't.
To give you a hint, in FAUST, when you want smooth parameters, you need to explicit do it. If you do it on the wrong place, you archive a bad performance, the very same is true when you "hand crafted it in C". The same is true about the constant DSP load, if you know how it works, you can avoid any unwanted calculation. Your entry argumentation still fail, and all your argumentation shows me only, that you never have used FAUST, that you never have used guitarix, and that you never have had a look at the guitarix source, but you feel yourself able to comment on it.

Guitarix is written in FAUST, AFAIK and not known to be particularly efficient.

However, you are right and I loose my interest in further discussions about that with you.

The point is that if you compare a C distortion to a FAUST amp sim, the C distortion is going to win regardless.

You still fail to get the point that I've post this because ssj71 wrote he cant run the amp sim smooth, and there are plain distortion plugs attached as well. Also, I still believe that ssj71knows about the fact, that a amp sim, which emulate 3 tube stages, a 3band distortion, a tonestack and use additional 2 convolution processes, surly will use more CPU power, then a plain distortion unit.

Yes. Meaningless. A plugin could usleep() in its run() method and that would count against your DSP load, but not your CPU load. Perhaps not the most realistic example, but it should be sufficient to get the point across, no? The DSP load is what matters, the CPU load includes to many other factors to be a very meaningful measurement.

Really not realistic, and if your DSP load differ that much from the CPU load of the rt process, you may check your system setup.

[male]

Well if you consider using more processing than necessary to be a feature, then sure, that's great. But in C or C++ you can avoid calculating smoothing, coefficients etc when doing so would be unnecessary, and therefore achieve lower average DSP load. But all of the details are entirely beside the point.

Did you ever used FAUST? It seems to me that you don't.
To give you a hint, in FAUST, when you want smooth parameters, you need to explicit do it. If you do it on the wrong place, you archive a bad performance, the very same is true when you "hand crafted it in C". The same is true about the constant DSP load, if you know how it works, you can avoid any unwanted calculation. Your entry argumentation still fail, and all your argumentation shows me only, that you never have used FAUST, that you never have used guitarix, and that you never have had a look at the guitarix source, but you feel yourself able to comment on it.

Guitarix is written in FAUST, AFAIK and not known to be particularly efficient.

However, you are right and I loose my interest in further discussions about that with you.

The point is that if you compare a C distortion to a FAUST amp sim, the C distortion is going to win regardless.

You still fail to get the point that I've post this because ssj71 wrote he cant run the amp sim smooth, and there are plain distortion plugs attached as well. Also, I still believe that ssj71knows about the fact, that a amp sim, which emulate 3 tube stages, a 3band distortion, a tonestack and use additional 2 convolution processes, surly will use more CPU power, then a plain distortion unit.

If it's so obvious that there's no comparison, then why did you post those figures in the first place? Of course I assume that you don't understand that they're incomparable--if you did, then there's no logical reason you would have even posted them. I suppose there's some confusion on that point. I don't wish to argue it any further with you either. My comments are for the benefit of others who may be reading this thread. To them I say, apples to oranges comparisons tell us nothing meaningful.

Yes. Meaningless. A plugin could usleep() in its run() method and that would count against your DSP load, but not your CPU load. Perhaps not the most realistic example, but it should be sufficient to get the point across, no? The DSP load is what matters, the CPU load includes to many other factors to be a very meaningful measurement.

Really not realistic, and if your DSP load differ that much from the CPU load of the rt process, you may check your system setup.

More realistic than you'd think when you consider plugins/applications that attempt to do their own parallel processing where lock waits end up contributing to the DSP load. Don't blame me for your limited imagination. The point is, why would you use a metric so far removed from the source of the load? (unless you *want* misleading results). If you want to measure plugin performance, measure the DSP load of the plugin, not the host, the libs, the OS, etc. I'd think this was common sense.

[tramp]

First of all, I've to said sorry to ssj71, that this becomes a highjack of his announcement thread.
Sorry ssj71.
But, now that male mention the benefit of further readers, I guess there are some points which need clarification.

Guitarix is written in FAUST, AFAIK and not known to be particularly efficient

That is completely wrong. First, guitarix is written in C++, as I allready pionted out, second, FAUST is known as a high level dsp language, which be very efficient.

I'm not saying it's grossly inefficient, but when you compare something written in FAUST to hand crafted C or C++ code of the same function, you're likely to see a difference in the DSP load favoring the hand-written code. So to compare something hand-written to something written in FAUST is hardly fair.

It is nearly not possible to beet FAUST, performance wise, with hand written code. As I already pointed out,even Fons Adriansen cant beet the performance. There is a a simple reason for this, the faust compiler is written by a couple of high intelligence dsp designers, most of them are teachers for digital research. The FAUST compiler get steady developed.
The FAUST developers are highly interested in such comparison, if you can beet a unit, which you have hand written, against a FAUST build, you can be sure that the FAUST compiler will receive a improvement as a a result.

If it's so obvious that there's no comparison, then why did you post those figures in the first place?

I wouldn't repeat the answer to this question any more, as I have answer it already 2 times.

My comments are for the benefit of others who may be reading this thread. To them I say, apples to oranges comparisons tell us nothing meaningful.

Indeed, when you are not able to read the result in context to the test, they are meaningless. So, you are simple fail to get the context, and my impression is, you just didn't want to see the context. That have nothing to do with "Hey, I only do it for the others how read it".
I wouldn't comment on your stance about process wise CPU usage, I guess you know yourself how far away you have stance yourself here from the reality.

However, ssj71, I'm relay interested which CPU load your distortion plug produce, as I'm on a i686 machine, it didn't seems to be for me.

[j_e_f_f_g]

this becomes a highjack of his announcement thread.

male turns every thread where he posts into an off-topic flamefest. I've already had to restart threads because of that. Now steve needs to do likewise.

Plus, he always quotes the entire post to which he's replying, even if his response is a single sentence not germane to most of what he quoted. He has no consideration that some server has to store/retrieve that superfluous text, and readers have to slog through it. I've mentioned to him twice about trimming quotes, and his response was that he doesn't give a crap, which pretty much sums up his attitude toward the world.

[male]

(verbal diarrhea)

Thank you for your relevant and helpful contribution, Jeff G. You're a star in my book!

[ssj71]

some rudimentary benchmarking:
http://linuxmusicians.com/viewtopic.php?f=48&t=11533