2008/6/3, Nedko Arnaudov <[EMAIL PROTECTED]>: > "Stefano D'Angelo" <[EMAIL PROTECTED]> writes: > >>>> #3. Some serious connection logic thing (all the "equal channels" thing >>>> etc.). >>>> This needs a thousand flame wars and *deep* thinking. >>> >>> No idea what you mean by this. >> >> If someone is going to write that helper library (or adjust SLV2 or >> whatever), I guess we should find some reasonable conventions to >> organize and use plugins in a chain-like thing. This is damn hard, as >> Paul Davis outlined already on this mailing list, and I actually don't >> know to which degree it should be done. > > Looks like good cadidate for separate helper library. But as Paul said, > proably each player will end with its own helper "library".
I'm waiting for an answer from Steve Harris on this :-) >> Example: some LV2 extension tells the host that which parameter is a >> "quality vs. speed" parameter in a plugin. The host can, then, show a >> global "quality vs. speed" parameter to the user. > > In dynparam extension there are "hints" for this. They could be used as > generic UI generation hints, as MIDI mapping hints or as "quality > vs. speed" hint. I think this could be done for normal LV2 ports too, > i.e. assigning hint URIs with a port. That could do the trick. >>>> #7. Global explicit initialization/finalization functions for more >>>> exotic platforms (they wouldn't harm, so why not having them). >>> >>> I still dont get what is the use case for this. >> >> Both on the host side and on the plugin side, no need for #ifdefs to >> define initialization/finalization functions and maybe support for >> exotic platforms not having them. > > I dont see what you will do within those global > initialization/finalization functions. That thing needs to be something > not platform specific. Well, I for example would use them with NASPRO to fill the plugin with all effect descriptors (don't know yet how to do with RDF/Turtle, but I'll find a way). > This can be made as separate thing that can be > reused for other things too. The same way libtool is asbtraction to > shared libraries. ? >>>> #8. Rules to find plugins possibly platform-specific and outside of >>>> the specification; possibly one compile-time valid path. >>> >>> AFAIK, this conficts with "LV2 spirit". Why one needs this? If the goal >>> is to avoid RDF Turtle, this shouldnt be issue with proper helper >>> library for hosts. Still such feature could be implemented in such a >>> helper library. >> >> Nope. I mean there should be platform-specific rules to get the list >> of directories containing shared object files and possibly there >> should be a fixed path to check on each platform, known at compile >> time. > > Interface to SLV2 (-like) library should definitively allow modification > of directory list. Which kind of modification? Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
