Re: [LAD] [ANN] LV2 beta3

On Wed, 2007-05-09 at 21:51 +0200, Fons Adriaensen wrote:
> On Wed, May 09, 2007 at 12:19:39PM -0400, Dave Robillard wrote:
>
> > This is intentional. LV2 is not intended to include every single
> > feature that everyone might want. It is intended for it to
> > be /possible/ to implement any feature someone might want (this is why
> > LV2 actually exists in a useful state and, say, GMPI does not...)
>
> I don't buy this. This is not about complicated or esoteric 'features'
> but _basic infrastructure_.

Basic infrastucture is exactly what is there. If there is a problem you
see with the basic infrastructure, that is what we need to solve right
now.

Complaining that /your/ specifically needed features /must/ be in what
we call "the core LV2 specification" is pointless.

> I didn't have to torture my mind to dream
> up the simple things I mentioned - they were plain obvious after
> reading the LV2 specs for about 15 minutes. That is several orders of
> magnitude less than the GMPI discussion.
>
> Do you really think that run(nframes, framecount) is so horribly
> complicated compared to run(nframes) that the average plugin writer
> would run (pun intended) away screaming ?

Do you really think that run (nframes, framecount) is the single
parameter list for run that anyone might ever, at any point in the
indefinite future, for any purpose, wish to pass to run? Of course not.
framecount isn't even a good way of expressing a fixed block size
anyway, you can just pass a different thing every time.

If you want to discuss fixed block sizes, etc, discuss the existing work
done in that area by tapas (who has longed for that feature for ages
now, and I assume from the lack of objections from him that things are
fine on that front). There is already a solution to this, if you have a
problem with the solution, let it be known.

Perhaps we /do/ need to have a facility for additional parameters passed
to run. I'm open to this possibility with justification. What is
definitely not going to happen is tacking on a few arbitrary fixed
parameters with no foresight into future compatibility issues, such as
this framecount suggestion.

This is an extensible spec, and problems with it must be addresssed in
an extensible way.

Additional run parameters in a HostFeatures kind of way isn't
appropriate because of performance issues though. I think the current
way is probably fine, since plugins can provide additional run methods.

In other words, nothing at all is stopping you from providing your
run(nframes, framecount) method, and therefore it's absense from lv2.h
is not a problem.

> Do you really think that init(samplerate, periodsize, priority, groupid)
> instead of init(samplerate) would complicate a host to the extent that
> nobody would dare write one ?

?

We already have a mechanism for passing whatever parameters you want to
initialize a plugin. Unlike your (completely arbitrary and
non-extensible) idea here, it doesn't break binary compatibility with
every host/plugin implementation in existence every time someone comes
up with a need for another parameter.

LV2 as a specification requires significantly more foresight than the
examples you are providing here.... we can't be breaking everything
every time someone needs a new parameter for this or that.

> Any objection you may have to 'periodsize' or any of the other arguments
> in that list would apply equally to 'samplerate' - many plugins don't
> need it. And it can be provided by an extension. Everything can be
> provided by an extension. We need nothing at all.

Sample rate is required by basically any plugin, is included in LADSPA,
and is included in LV2. Therefore sample rate is important to get
right, because it's there.

You are right it doesn't strictly /need/ to be there. It's there
because it's there in LADSPA - this rule exists solely to draw a line in
the sand to prevent everybody and his brother fighting over what baroque
junk to cram in the spec, like you are attempting at the moment. ;)

> None of these parameters are 'features' in the sense that they add
> user-level functionality. They are just basic low-level technical
> infrastructure required to make some things work, and cost almost
> nothing. This is not the sort of thing that should be negociated
> between a host and a plugin via a high-level protocol. A host that
> does not provide such basic information is IMHO just broken.

No, what they are is Fons Adriaensen's pet features. Other people have
different pet features. We can't ram everyone's pet features into the
spec - not mine, not Steve's, and not yours. What we can do is make
sure that everyone's pet features as possible, which is what this beta
is for.

Things will not be added to lv2.h that are not /required/. Period. The
rationale for this is obvious, but I can elaborate if it's really
necessary.

What's important right now is any possible example you can think of why
something is _not possible_ with the current specification. Help in
this area is very much appreciated, arguing for unnecessary inclusions
is a waste of time.

-DR-

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Thu May 10 04:15:02 2007