Re: [LAD] Plugin buffer size restrictions

On Sat, 2012-05-26 at 22:02 +0000, Fons Adriaensen wrote:
> On Sat, May 26, 2012 at 05:08:47PM -0400, David Robillard wrote:
>
> > Here, notice a plugin not working in the host is *inherent*. This is
> > why LV2 folks generally don't consider this a "problem" - it isn't one.
> > If the host literally *can't* provide a given feature (e.g. fixed buffer
> > size) and the plugin *requires* it to function at all, well, clearly the
> > plugin can't work in that host. LV2 merely provides a mechanism to
> > express such things. The decision of whether to do them is inherent.
>
> Understood, and not for the first time. But it leads to chicken/egg
> situations. I'm not going to write an LV2 requiring N features if
> there isn't a host providing them. And probably vice versa for host
> authors. And that is why I'd prefer a more demanding core spec.
>
> Dave, if there is anything I find contradictory in your argumentation
> (and that is often why I react to it) it is that you seem to sweep
> this point under the carpet, while in other cases you can be very
> pragmatic.

Yes, it does. But what you sweep under the carpet is that this would be
true of the hypothetical monolithic spec you allude to. That would just
give you a mountain of chicken & egg all at the same time.

The only difference between LV2 and that is that LV2 actually exists.
This is not at all a coincidence.

I am using a producer mentality. You are using a consumer mentality.
You don't like that a monolithic specification that does everything you
want has not been handed to you. I sympathize, I really do. I would
much rather just be writing and using the plugins and apps I want,
believe me.

The big thing you're missing - and this is important - is that this
process, right here, right now, IS the process of making that
specification you want.

Read that again. Several times, ideally.

*Nothing* emerges instantaneously, they get worked on. This one is
being worked on in the open, and as we work on it, we're making sure the
bits actually work along the way, and making sure things are sensible in
the one and only way it is possible to do so: implementing them.

If you like, and are not interested in influencing the specification,
you can simply pretend it has not been "released" yet. Of course, this
means you voluntarily forfeit your right to have any input on its
design. It's when you criticize this *design in process* without
actually trying to help that things turn sour, and I'd say rightly so.

In fact, I actively advocate NOT adopting LV2 some times, for
people/projects/companies that need an extremely conservative very long
term stable API. For them, it is not done yet. We're working on it.

For others, for whom either everything they need is done yet, or are
agile enough to keep up, it is done yet.

It's simply an open development process. The only difference is, you
know about it, and - lucky you! - you even get to participate and
influence it if you wish.

> > It is not my job, or your job, to tell plugin and host authors what they
> > can and can not do. Ad hoc extensions are where innovation happens,
> > where solutions get sorted out *before* they become part of the main
> > spec. You can't sort them out without actually implementing them.
> > Software simply does not work that way. Ever.
>
> Mmm, I'd like to disagree. Most open source software may be developed
> in such conditions - but that is both a strength and a curse. Having
> worked some ten years developing software for space and aviation I
> can tell you things are different there. And that has some advantages.

They most certainly are, but here is simply not there. They are not in
any way similar, the culture, organization, requirements, and
methodologies are entirely different.

That does have some advantages. So does this. What you do there could
never work here, and vice-versa.

(Much like in politics) it's helpful to imagine yourself *not* in the
position of power. In LV2, for example, the fantasy monolithic scenario
is not *you* dictating everything, it's *me* dictating everything, i.e.
not giving a damn what you have to say because *I* drive this bus and to
hell with you. Doesn't sound so great now, does it? :)

I, in fact, *do* drive this bus, and (having learned a thing or two) am
slowly moving the project to *appear* as more of a monolithic effort
because it helps with adoption. It's just an illusion, though. I am
toning down the decentralized talk and moving more to a role of
benevolent dictator on purpose, but I'm only the benevolent dictator
because I did all the damned work. The API itself always has been, and
always will be, extensible by anyone.

> > It will all work out eventually. You've been around here long enough to
> > know everything ain't happening tomorrow regardless :)
>
> Yes. But that's no reason to not learn from the past. Which is what
> LV2 started out to do...

Failing to learn from the past would be trying to have this mailing list
come to a universal agreement on everything, and actually expecting a
project to work out that can't be released until that happens.

This increasingly ironic thread is a perfect example of why.

*That* lesson is the core thing LV2 was designed to work around, and it
worked beautifully.

LV2 was designed to be feature compatible with LADSPA with the
additional requirement that improvements be able to be added on as they
get figured out, and people actually interested in solving them (i.e.
not just bitching on l-a-d) have the ability to do so. Many have. This
particular issue is no different.

That it can and will be solved now, years after all sorts of fancy new
plugins have been in production, is all the proof you need that the
requisite lesson has been learned, and applied.

> > This is a bit difficult to decipher. You are saying you think
> > block-accurate controls at a given fixed minimum size are good enough?
>
> For anything except synthesis, yes. Not only good enough, but actually
> much easier to implement correctly.
>
> > However, making "synthesis modules" an exception is kind of pointless
> > over-classification. Either a sample accurate control mechanism is
> > required, or it isn't. There is no hard distinction between "synthesis
> > modules" and other things anyway, it is not a useful (false) dichotomy.
>
> If 'sample accurate' control would be the only difference between
> 'general purpose' and 'synthesis' modules I'd agree with you.
>
> But it isn't. 'Polyphonic' is not the same as 'multichannel' for one.
> And synthesis modules may require real-time instantiation - no need
> for that in case of an effect in a DAW. My conclusion is that the
> two are fundamentally different. Which doesn't mean that a plugin
> standard couldn't provide both. But probably not by ignoring the
> differences.

The problem here is conflating all kinds of orthogonal issues. Being
unimportant to the problem at hand, and categorization ("synthesis" vs
not) not being useful anyway, I will ignore them.

> > It's odd to speak of this like there has been some active decision to
> > "allow" arbitrary nframes values. It's more accurate to say that
> > basically nothing has been said about this thus far. It is simply an
> > absence of well-defined restriction because nobody has defined them yet.
>
> AFAIK, the 'core spec' requires plugins to accept a non-constant nframes:
>
> "Thus the "control rate" is determined by the block size, which is
> controlled by the host (and not necessarily constant)."
>
> > It'd have been solved and implemented long long ago if it was brought up
> > in useful channels and not weird cloak and dagger reports...
>
> Nothing cloak and dagger about it. If someone is prepared to pay me for
> writing a report on something I do have strong opinions about (and very
> probably because of that), should I refuse that ? It's a consultancy
> job just like any other. And at least one other well-known developer
> got the same.

No, you clearly wouldn't refuse it, but you could at least attempt to do
a competent job. Since you didn't, I in turn clearly am not going to
pull any punches:

Did they pay for FUD? Because it sounds to me like what is a relatively
straightforward problem they could have easily overcome if they needed
to was hyped up as a fundamental flaw, and quite possibly someone didn't
invest in open technology because of it. Because of some stupid trivial
bit of missing API that could be added in a day.

Anyone with an even basic grasp of how LV2 works would have included how
trivial of an addition this is, which would be actually useful.

Whatever they paid you, they could have paid for a solution. Hell, if
it was mentioned on lv2-dev they could have had that for free.

You got your money, so hey, you win. Free Software didn't, however, and
that's the part that saddens me.

Can I really be expected to not personally be thoroughly pissed off
here? I - and several others - spend so much time working on this
effort to provide a powerful free audio API, and not only do you have
nothing but endless public ignorant criticism, you get privately *paid*
to do so?

You make more money in a day in your fancy aerospace job than I do in an
entire month, and on the side you're taking contracts to write essays on
how shit the entire effort is? Not any actual solution, not even a peep
on any of the available channels to mention this issue which would have
surely been addressed, nothing helpful whatsoever, just project libel
for profit. Not only being literally paid to hurt, but the arguments
used don't stand up to even the a hint of public scrutiny.

Gee, thanks, Fons. Thanks a lot.

Enjoy your money.

-dr

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