<br><br><div class="gmail_quote">On Sun, May 27, 2012 at 7:16 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So it's my *behaviour* that bothers you. So be it. I'm not going<br>
to change my opinions in function of the advancement of Free<br>
Software or whatever 'higher cause' or marketing campaign, ever.<br>
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<br>
shortcomings, not by keeping my mouth shut about the latter. If some<br>
potential user asks me what is the state of audio plugins in Linux<br>
I'll tell him/her that there are some great ones, but also that some<br>
things are missing, and that 50% of what is available is pure crap.<br>
Since I'm usually known or introduced to sich persons as 'the Linux<br>
Audio nerd', that may come as a surprise to them, But they generally<br>
appreciate the honesty.<br></blockquote><div><br>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.<br>
<br>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. <br><br>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. <br>
<br>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". <br>
<br>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. <br>
<br>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. <br>
<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im HOEnZb"><br>
Ciao,<br>
<br>
--<br>
FA<br>
<br>
A world of exhaustive, reliable metadata would be an utopia.<br>
It's also a pipe-dream, founded on self-delusion, nerd hubris<br>
and hysterically inflated market opportunities. (Cory Doctorow)<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br>