Re: [LAD] Plugin buffer size restrictions

On Sun, May 27, 2012 at 7:16 AM, Fons Adriaensen <fons@email-addr-hiddenwrote:

>
> 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
> 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 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.

>
> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun May 27 20:15:02 2012