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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 29 May 2003 19:34:02 -0700 (PDT)

> My host has one-to-many audio connections.
> 
> i.e. [synth]--->[effect1]
>                \-----[effect2]
> 
> to be clear: one plugin produces one output buffer, which is fed to two
> downstream plugins.

> If effect1 chooses to process-in-place, that implies it's input buffer is
> overwritten.

Right.  So only one of them can process it in place, correct?  The other
effect has to NOT do in-place processing.

> And if your reply is "the host can just duplicate the input buffer".
> 
> Think long and hard before you say that, bearing in mind your original
> reason for batton-passing (to avoid buffer copying).

No matter what, only one plugin can process in-place.  The other has to have
a new buffer.  No matter what.  So the cost is a memcpy().  If avoiding that
scenario hurts too much, you can flag them as read-only and force the plugs
to use a new buffer for output.  Or you can flag one as read-only and
enforce (in your host) that the in-place plug (non-read-only) run last (but
that is pretty ugly).


----------------------------------------------------------------------
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

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 05-2003