Re: [LAD] Plugin buffer size restrictions

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Fons Adriaensen <fons@...>
Cc: <linux-audio-dev@...>
Date: Sunday, May 27, 2012 - 2:01 pm

--0023544718dc9b0c3304c1050963
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 27, 2012 at 7:16 AM, Fons Adriaensen wrote:

>

i don't see any problem with this, and i'm guessing that david doesn't
either (though i shouldn't try to speak for him). i spend a lot of my time
trying to explain to people all the shortcomings in my own software out of
a similar need for honesty.

the problem is that this isn't "some potential user asking me what is the
state of audio plugin in linux". its the linux audio develop(ers|ment)
mailing list.

in this context, i think that criticizing a feature of a plugin API as
though it is fundamentally misconceived, and as if the people who came up
with the feature basically don't know what they are doing, when the same
feature is found in every other even moderately used plugin API just seems
... well, i don't know a good adjective for this. i concede that there is
room for a much more generalized discussion about whether plugin APIs or
DSP in general should avoid variable block sizes. that discussion should
draw on the variety of reasons why variable block sizes exist at all and
this needs to cover the large variety of different contexts in which plugin
APIs are used. it could be that the outcome of a focused discussion on this
would reach the clear conclusion that variable block size is a detrimental
feature in such an overwhelming way that it should never be part of such an
API. personally i find this highly unlikely, but i'm willing to concede
that its a possibility.

but instead, as i correctly though preemptively anticipated (can there be
such a thing as preemptive anticipation?) this discussion once again turned
into a very personally-driven spitting match in which david's personal
involvement and belief in LV2 and his committed work on it slams up against
a distaste for many aspects of LV2 that you've made clear for several
years. this type of clash isn't useful to anyone, and this is why i think
david gets so upset with them - that rather than there being discussion
that targets "how can this be done (right)?" there ends up being a tone of
"well, this is wrong, and that is wrong, and also this other thing is
wrong, and by the way the whole basic idea, conception and architecture is
wrong".

and maybe that is actually what you think of LV2, and if so you're not
alone in that assessment and its clearly OK. its just that having public
battles that superficially claim to be about a detail of the API but are
really just surrogates for "this whole thing is just misconceived" is
really pointless.

if thats not what you think of LV2 overall, then wouldn't it be more
helpful, when bringing up an issue like this, to put it in the context of
all plugin APIs? I don't trust the people in of the particular individual
tiny sub-niches of audio software (digidesign, windows, coreaudio, ALSA,
pulseaudio, linux, audiounits, vst, h/w DSP, consoles-on-linux,
audio-over-IP etc, etc,) to get things right. but i do think that if you
scan across the appropriate sub-niches (in this case, a half dozen or more
plugin APIs) and you find a consistent pattern, then it becomes much more
important to make the claim "this is the wrong thing to do" be backed up
with explanations of why the other instances of the same kind of thing also
got it wrong. perhaps the argument is "they all copied each other", and
perhaps that is the only possible argument. if so, its a weak one though i
will grant that it could be true.

>

--0023544718dc9b0c3304c1050963
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, May 27, 2012 at 7:16 AM, Fons Ad=
riaensen <fons@linuxaudio.org> wrote:

So it's my *behaviour* that bothers you. So be it. I'm not going
to change my opinions in function of the advancement of Free
Software or whatever 'higher cause' or marketing campaign, ever.
I've done my part of advocacy for Linux Audio, and I'm still doing<=
br>
that, by example and pointing out both its great features *and* its
shortcomings, not by keeping my mouth shut about the latter. If some
potential user asks me what is the state of audio plugins in Linux
I'll tell him/her that there are some great ones, but also that some
things are missing, and that 50% of what is available is pure crap.
Since I'm usually known or introduced to sich persons as 'the Linux=

Audio nerd', that may come as a surprise to them, But they generally
appreciate the honesty.i don't see any proble=
m with this, and i'm guessing that david doesn't either (though i s=
houldn't try to speak for him). i spend a lot of my time trying to expl=
ain to people all the shortcomings in my own software out of a similar need=
for honesty.
the problem is that this isn't "some potential user asking me =
what is the state of audio plugin in linux". its the linux audio devel=
op(ers|ment) mailing list. in this context, i think that criticizin=
g a feature of a plugin API as though it is fundamentally misconceived, and=
as if the people who came up with the feature basically don't know wha=
t they are doing, when the same feature is found in every other even modera=
tely used plugin API just seems ... well, i don't know a good adjective=
for this. i concede that there is room for a much more generalized discuss=
ion about whether plugin APIs or DSP in general should avoid variable block=
sizes. that discussion should draw on the variety of reasons why variable =
block sizes exist at all and this needs to cover the large variety of diffe=
rent contexts in which plugin APIs are used. it could be that the outcome o=
f a focused discussion on this would reach the clear conclusion that variab=
le block size is a detrimental feature in such an overwhelming way that it =
should never be part of such an API. personally i find this highly unlikely=
, but i'm willing to concede that its a possibility.
but instead, as i correctly though preemptively anticipated (can there =
be such a thing as preemptive anticipation?) this discussion once again tur=
ned into a very personally-driven spitting match in which david's perso=
nal involvement and belief in LV2 and his committed work on it slams up aga=
inst a distaste for many aspects of LV2 that you've made clear for seve=
ral years. this type of clash isn't useful to anyone, and this is why i=
think david gets so upset with them - that rather than there being discuss=
ion that targets "how can this be done (right)?" there ends up be=
ing a tone of "well, this is wrong, and that is wrong, and also this o=
ther thing is wrong, and by the way the whole basic idea, conception and ar=
chitecture is wrong".
and maybe that is actually what you think of LV2, and if so you're =
not alone in that assessment and its clearly OK. its just that having publi=
c battles that superficially claim to be about a detail of the API but are =
really just surrogates for "this whole thing is just misconceived&quot=
; is really pointless.
if thats not what you think of LV2 overall, then wouldn't it be mor=
e helpful, when bringing up an issue like this, to put it in the context of=
all plugin APIs? I don't trust the people in of the particular individ=
ual tiny sub-niches of audio software (digidesign, windows, coreaudio, ALSA=
, pulseaudio, linux, audiounits, vst, h/w DSP, consoles-on-linux, audio-ove=
r-IP etc, etc,) to get things right. but i do think that if you scan across=
the appropriate sub-niches (in this case, a half dozen or more plugin APIs=
) and you find a consistent pattern, then it becomes much more important to=
make the claim "this is the wrong thing to do" be backed up with=
explanations of why the other instances of the same kind of thing also got=
it wrong. perhaps the argument is "they all copied each other", =
and perhaps that is the only possible argument. if so, its a weak one thoug=
h i will grant that it could be true.
=A0

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_____________________________=
__________________
Linux-audio-dev mailing list
Linux-audio-dev@lis=
ts.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev

--0023544718dc9b0c3304c1050963--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Plugin buffer size restrictions, David Robillard, (Sat May 26, 2:43 am)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sat May 26, 10:02 am)
Re: [LAD] Plugin buffer size restrictions, Tim E. Real, (Sat May 26, 11:47 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 12:58 am)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat May 26, 6:24 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sat May 26, 8:05 pm)
Re: [LAD] Plugin buffer size restrictions, Stefano D'Angelo, (Sun May 27, 6:59 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sun May 27, 8:26 pm)
Re: [LAD] Plugin buffer size restrictions, Stefano D'Angelo, (Sun May 27, 9:00 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sun May 27, 9:33 pm)
Re: [LAD] Plugin buffer size restrictions, Stefano D'Angelo, (Sun May 27, 11:59 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Mon May 28, 12:17 pm)
Re: [LAD] Plugin buffer size restrictions, Stefano D'Angelo, (Mon May 28, 3:05 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Mon May 28, 5:01 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Mon May 28, 5:30 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Mon May 28, 7:48 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Mon May 28, 9:08 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Fri Jun 1, 10:09 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Fri Jun 1, 10:22 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Fri Jun 1, 10:42 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Fri Jun 1, 10:56 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat Jun 2, 12:22 am)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat Jun 2, 2:40 am)
Re: [LAD] Plugin buffer size restrictions, Tim Goetze, (Sat Jun 2, 9:32 am)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat Jun 2, 4:16 pm)
Re: [LAD] Plugin buffer size restrictions, Tim Goetze, (Mon Jun 4, 8:08 am)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Mon May 28, 10:41 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Tue May 29, 3:55 am)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 8:01 pm)
Re: [LAD] Plugin buffer size restrictions, Stefano D'Angelo, (Sun May 27, 8:17 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat May 26, 9:08 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sat May 26, 10:02 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 12:48 am)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sun May 27, 11:16 am)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 4:05 pm)
Re: [LAD] Plugin buffer size restrictions, Paul Davis, (Sun May 27, 2:01 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 5:19 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sun May 27, 7:56 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sun May 27, 10:33 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Mon May 28, 10:53 am)
Re: [LAD] Plugin buffer size restrictions, Thorsten Wilms, (Mon May 28, 11:54 am)
Re: [LAD] Plugin buffer size restrictions, Paul Davis, (Sat May 26, 8:23 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat May 26, 11:08 pm)
Re: [LAD] Plugin buffer size restrictions, Fons Adriaensen, (Sat May 26, 8:59 pm)
Re: [LAD] Plugin buffer size restrictions, Paul Davis, (Sat May 26, 10:34 pm)
Re: [LAD] Plugin buffer size restrictions, Adrian Knoth, (Sat May 26, 6:42 pm)
Re: [LAD] Plugin buffer size restrictions, David Robillard, (Sat May 26, 8:27 pm)