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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 28 May 2003 15:18:51 -0700 (PDT)

>  You've also related baton-passing to process-in-place, but i feel
> process-in-place dosn't require baton-passing.

It doesn't REQUIRE it, but it makes in-place processing a non-issue.

> Why I don't like it.
> *few plugins benefit from pointer-swapping.

yes, but any plugin can now process in-place even in very weird situations.

> 2nd reason I don't like it.
> *extra overhead for plugins that don't care.

Irrelevant amount extra overhead.  Where do you see the extra?  The plugins
have to call new_buffer() and release_buffer() or some such thing at the 
worst case.

> *extra complication.
> I distrust radical changes to the way buffers are managed. kind of the 'if
> it aint broke don't fix it' mentality.

This is legit.  It is a different model.  Different is not necessarily bad,
though, if it comes with enough wins.

> 3rd reason
> *Ownership
> I prefer ownership of buffers to be clear.  I prefer the host to 'own' them.
> I can't prove this is a good idea.  It just comes from my 'gut feeling' of
> what robust software 'looks like'.

I buy that.  But ownership is still very clear in this model (I'll detail it
shortly).  When you pass a buffer you no longer own it.  Period.

> "The largest group of people can't program at all. There's another, smaller
> group of people who can program, but not with pointers. And there's a tiny
> group of people who can program, even with pointers"

Joel has some good thoughts, and some not.  This one is pretty accurate.

> implementing something, just different trade offs.  (I suspect my main
> objection is an irrational fear of complicted APIs).

if it is too complicated, I'll abandon it, I just want to make sure it sees
the light of day before being shitcanned.

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