9 May
2007
9 May
'07
7:17 p.m.
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:
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.
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_. 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-