Content-Type: text/plain; charset="UTF-8"
On Sun, 2012-10-21 at 11:38 +0000, Fons Adriaensen wrote:
> As shown above, in real life it will be much *less* reliable.
As *speculated* above. Things like this are shown by experiment, and
experiment only. If either of us wants to show that threads or
synchronous is better, the only way to do so is to actually load a
system with many such plugins and plot the results. There is a reason
parallel computing literature is full of such plots, and nobody cares
about performance arguments that lack them whatsoever. It's simple to
convincingly argue just about anything "would" be faster - and be wrong.
This is true even sequentially on modern architectures, and it's
*really* true when threads get involved.
More to the point though, your argument is convincing - and a straw man
(see below). More importantly, I don't care, and it was a mistake to
ever indulge it.
The point of this was to invent and implement a bunch of LV2 things,
including block length restrictions in general (something you are about
the only advocate of around here, ironically).
Perhaps convolving in this way is completely idiotic. Great, fine,
fantastic, DON'T CARE, because that is not the point. I never claimed
this plugin was the best way to do convolution (I explicitly did the
exact opposite), so stop arguing against nothing.
It's not the best convolver.
It's not the best way to convolve.
It's not the best way to use libzita-convolver.
It's not an IR.lv2 replacement.
It's not recommended for use, by anyone, at all, for anything.
It is a tech experiment. Get it?
> Both (1) and (2) are simply untrue, there is *no* relation at all between
As it happens you are using the exact same confusion of concepts to make
a straw man of my argument so you can subsequently burn it. You asked
what's wrong with threads, and I made some points about why *threads* in
plugins are undesirable, in general. I didn't even say anything about
I also don't care, and didn't write that part. Yell at Robin instead.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----