> don't think that the string is needed I think that's fair.
> One version number should be enough though, > and it doesn't have to match the actual version of the LADSPA spec Both those points (especially the second) sound simple and sensible. Okay, so on reflection... There's a case to be made that some version information ought to go into the struct, since it directly affects how the struct may be properly accessed. There are two case where you would need version information to correctly access the struct. 1) A future version extends the struct. (does not break backwards compatibility) version information is needed so that eg. a 2.1 host does not try to use 2.1 functionality in a 2.0 plugin. 2) A future version modifies the struct. (breaking backwards compatibility) case 2) is very unlikely to occur anytime soon, so let's just forget about that (it can be solved by using a new discovery function anyhow) case 1) could most simply be addressed like this: The struct starts with a single unsigned short. The host must check the version number at the start... If the plugin version >= host version: No problem - the host knows it's functionality is fully supported. If the plugin version < host version: The host may access the plugin normally and is aware of what functionality the plugin does not support. Why is this useful? Well, it provides a _built-in_ way of ensuring that the struct is properly accessed, even if the metadata file is corrupted or lost. Say a user meddles with the metadata file to make a 2.0 plugin look like a 2.1 plugin. The host attempts to access 2.1 functionality and core dumps. Say the metadata file has been lost - the plugin contains sufficient information to remain accessible although it no longer has any associated metadata. I realise that the LADSPA library should mostly enforce keeping things okay, but it seems like a nice idea to have a protected way of making sure that we don't accidentally attempt to access invalid memory when things go wrong. I would suggest then: A single unsigned short at the start of the struct, starting at '0' for ladspa 2.0 plugins and incrementing if and when the struct is extended. The LADSPA major and minor versions would stay in the metadata. Any milege in this?...
