Yes, I'm exploring 'what if non-interleaved is always required,' so I
guess it seems different enough to warrant its own letter. (Though
I'm thinking the interleave-vs-mono aspect might be better addressed
via how the binary is packaged... so the interleave version might be
a separate code resource from the mono version... so maybe really on
the inside they'd be separate 'inner plugs' and therefore the
mono/interleave distinction completely vanishes at the plug source
code level... but that's getting into another topic entirely, which
we're trying hard to avoid.)
-- Chris G.
Mike said:
I read (d) as "The plugin must accept both types, but can express a preference for one or the other. The host is free to ignore that preference." Your wrinkle is that the plugin must accept mono and can accept interleaved. Maybe that's (e)?
Chris Grigg wrote:Mike said:
Chris Grigg wrote:
>> So, unless I'm forgetting something, it seems like I'm (back) on the
a) side of the fence... Mono buffers only.
So you support (c), too.<g> Simply write all your plugins using mono buffers only. I understand (c) as a way to let someone who wants to do interleave, even if 99% of the world chooses not to.
not quite. it forces all host apps to support interleave even if they don't want to, because some plugins may demand it. thats a case of the tail wagging the dog if ever i saw one ... host buffer management is generally an order of magnitude more complex than what happens in a plugin.
Doesn't it work to say the plug -must- always support mono buffers, and -may- at its own option support interleave? Then a host that only does mono has no problem.
I would be OK with this. My concern was the one stated above, that host would have to do a lot of interleaving to support some plugins. But your suggest is just basically option (d).
Uh, no, d) says...
d) Both, as requested by the plugin. Plugin can specify preference, but accept either (global or per-stream).
...which has some ambiguity about whether mono would be required. I'm saying, what
if mono is always required and interleave is always optional.
-- Chris G.
---------------------------------------------------------------------- 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
-- Mike Berry Adobe Systems
---------------------------------------------------------------------- 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
---------------------------------------------------------------------- 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
