Ok, some thoughts about the headerfile: - i would find it helpful if the header also contained a definition of a valid LADSPA URI, along with some examples.
- passing the HostFeatures in instantiate is a bit too late. i wouldnt want to instantiate a plugin first to find out if they match i.e. when i enumerate plugins to display them in a menu. furthermore i'm not sure if it is an audio plugins duty to check the validity of a host. rather the host should analyze a static string pointed member containing required host features. this way the host programmer can choose the quickest method to do a match check. at least i think so. - why does the plugin require its own bundle path for instantiation? this can usually be deduced from the dl's own runtime image information, no? otherwise, an explanation of this choice in the comment would be nice. - comments still contain references to set_run_adding_gain - LADSPA is an ugly name ;) after reading this i do not see why a new ladspa header is required. there are barely any changes in 2. i think this is going to become more confusing than helpful, especially since it will not be possible to load ladspa 1+2 plugins in the same host with ease (yes, people do not like to fix orphaned code and recompile binaries, imagine!). furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2. again, looking at the slight changes that ladspa underwent, i dont see what the big fuzz is about. grumpily yours, -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org
