[gmpi] Re: Topic 7: Audio packaging, Process-In-Place

> of a Y, running a non-in-place plug first, then the in-place plug. If both 
> are in-place a copy has to be made before running either. If both are 
> not-in-place then it's moot.

The point I keep seeing is that a global I process in-place applies only to
simple plugins.  That is probably the vast majority of plugins.  If
process-in-place is decided by the host, it needs to enforce ordering such
that only the last effect run is in-place.  If it is not optional to the
host (that is, if a plugin ALWAYS processes in place) then marking inputs as 
read-only is actually a win.

If you have to make one buffer copy you use up extra memory bandwidth.  If
you have to ask for a new buffer for your output because your input is RO,
you use up more memory, more cache, but NOT memory bandwidth (cache effects
aside).

> Still better is to have the host decide whether the plugs will run in-place 
> or not. This is the point that Steve and I have been making.

The only support for this statement is shared inputs.  Baton-passing has a
reasonable answer to that (ro buffers).

There are other arguments aginst baton-passing.  Steve thinks the complexity
is too high.  I disagree, more or less.  I just want to make sure the
arguments FOR it and AGAINST it are distilled to their actual value, before
I let people discard it as an overly-complex new-fangled idea.  People are
scared of change, I just don't want THAT to be a factor in the decision.

At this point we're close to pure merit arguments ;)

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: