[gmpi] Re: Decision time: 7.2

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 22 Jul 2003 08:41:37 -0700 (PDT)

I know I've been a pain int the ass about a lot of these, but it's just
because I want to see this work.  As it is, it seems to be going the other 
way.  No one wants to argue for the best ideas.

I'm, of course, willing to go by popular majority, but I'd rather see some
form of consensus, even begrudged.

> Topic 7.2:  In-place processing
> -------------------------------
> 
> Q: Do we do in-place processing?

I think the win of doing in-place processing is obvious, no matter HOW we
do it.

>   a) Yes.  A plugin-global flag indicates a plugins ability to do this.
>      This tells the host that ANY input buffer may be re-used on ANY output
>      (perhaps withing some higher-level grouping of stuff (think MIDI
>      channel?)).  If a plug can not accept this rule, it must not use
>      in-place processing. (VST model?)

This would be fine for many plugins - and fine by me, if that is hat people
want.

>   b) Yes.  A plugin statically maps inputs to outputs.  The host may
>      re-use an input buffer for an output if they map together.

If people want this, I'll cope, but I don't think it is the best.

>   c) Yes.  A plugin is given inputs and produces it's own output buffers
>      based on internal knowledge or other variables.  The host is not
>      involved, except to furnish new buffers as requested.  The plugin must
>      re-use or release all input buffers.  Variations on this can be devised
>      to allowed shared input/outputs. (baton passing, or similar to DX model)

I think I still prefer this method, but as I said, I'll go with whatever

>   d) No.  All output buffers are unique from input buffers.

If we can't agree, this is fine, though it will be sad to step back in
functionality from existing APIs.

ANYONE ELSE?  I know you have opinions..

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