Just a thought...
If plugins are supporting different types that makes them universally
usable in different hosts!
The plugin knows what it needs inside - the host doesnt.
So if the decision about how to convert the data remains within the plugin
this might be the more efficient solution from a neutral viewpoint.
Things change if the weight of the sensible applications change...
Scenario: FLOAT host >>>> INT interface <<<<<< FLOAT plugin FLOAT host >>>> INT interface <<<<<< INT plugin INT host >>>> INT interface <<<<<< INT plugin INT host >>>> INT interface <<<<<< FLOAT plugin FLOAT host >>>> FLOAT interface <<<<<< FLOAT plugin FLOAT host >>>> FLOAT interface <<<<<< INT plugin INT host >>>>> FLOAT interface <<<<< INT plugin INT host >>>>> FLOAT interface <<<<< FLOAT plugin
The more I think on it, the less I think that multiple type support will actually impact anything much. I think it is a relatively simple extension, and will actually buy us something in terms of marketing and future-proofing. ... Let's build it as we see for 'normal' processors, and then derive a GMPI-Embedded or GMPI-Mobile spec. <<<
So what are you saying, that you want per-binary sample types should be part of the 1.0 spec, or not? I think we should avoid GMPI-x specs. The whole point of all this is to wind up with one spec, ONE.
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
