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 [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
