On Wed, 2007-05-09 at 15:41 +0200, Fons Adriaensen wrote: > > > 3. Plugins may want to delegate some of the processing to threads > > > running just below the audio thread priority, so this priority > > > is an essential initialisation parameter. > > > > Can be done as a HostFeature. > > So a plugin writer can't count on it. > > > > 4. There are 'audio rate' and 'control rate' ports, but no 'init > > > time' ports. How are plugins supposed to discover initialisation > > > parameters ? > > > > Can be done as a HostFeature. > > Again, of no use it you can't count on it being present. > > > > 5. If a plugin is instantiated multiple times to operate on > > > multi-channel data it may want to share control ports within > > > such a group, if only to optimise the (possibly complex and CPU > > > intensive) code that maps external control values to internal > > > data. I see no way to form such groups. > > > > Can be done as a HostFeature. > > Same remark as the two above
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...) If something you require is not present, the plugin simply won't work in that host. You (the plugin) can also make things optional so the functionality will only be used if supported by the host. This is a Good Thing(TM), not a bad thing. Bloating the spec requires a real reason why a thing /must/ be in the core specification, i.e. why it will not work at all as an extension. Plugins can "count on" anything they want, if it's not provided things will simply fail gracefully (a lot of thought has been put into being sure of this). The simple reason for this is that we cannot be building every single thing into the spec, because the spec would never exist. We'd be having the same old LADSPA GUI rant fest on l-a-d all day, and nothing would get finished. The line needs to be drawn somewhere, so it was drawn as "equivalent to ladspa, with whatever additions necessary to be fully extensible". That said, I like most of your ideas, particularly control ports - I hate them, lots. Hopefully someone comes up with a better solution and they disappear entirely one day. Being a modular guy, I want CVs, but others want timestamped events. It would be nice if we could have some kind of polymorphic control port that supports all these uses, though personally I think timestamped controls might as well just be more fully featured messages. > Optional support for fundament things is not a solution. None of the things you have mentioned have any /actual/ reason to go in LV2 itself, except the sample rate issue which does need to be figured out. I'm for making it a rational number or double; locking it as an int for no reason when there's any reason for something better at all is short-sighted. I do think I vaguely remember some reason why floating point sample rates aren't good though.... ? -DR- _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
