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

Hi Tim,

>> I keep saying 'baton-passing' and no one says no.

NO.   <grin>

But seriously.  My understanding of baton-passing...tell me if i'm wrong,
(couldn't find the original description)..

Baton passing.
*allows plugin to pointer-swap an input direct to an output.  Saves CPU.
*buffer management is plugin's responsibility.

I understand the main justification is saving CPU via pointer-swapping.

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

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

The examples i recall are:
- a mono->stereo converter
- a left/right stero swapper.
- a multichannel format converter.

The first two I have never used.  And in my modular host are 'free'
anyhow....

The multichannel format converter.  Yes, maybe, I've never written one.
Athough I suspect mutichannel processors use time delays, level adjustment
and head-related-transfer-functions to perform their magic, not just buffer
copies.

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

My guess is many plugins don't benefit from pointer-swapping.  In which case
we are decreasing overall performance by placing extra work on them.

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

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

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

http://www.joelonsoftware.com/printerFriendly/articles/fog0000000006.html


Appologies if i've missed any major advantage of batton-passing... let me
know.  I realise there is not always a 'wrong' and a 'right' way of
implementing something, just different trade offs.  (I suspect my main
objection is an irrational fear of complicted APIs).

Best Regards,

Jeff

----- Original Message ----- 
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, May 29, 2003 5:42 AM
Subject: [gmpi] Re: Topic 7: Audio packaging, Process-In-Place


> > I don't think multichannel plugins (mixers, synths with audio inputs,
> > multichannel effects, ...) are all that much of a corner case, but I
> > could be wrong... Anyway, with only a single flag for "in-place
> > capable", practically all of these will have to say "in-place
> > broken", forcing hosts to set up extra buffers for every output, even
> > if each one of them could reuse an input buffer.
>
> I keep saying 'baton-passing' and no one says no, but no one seems to give
> it any heed, either.  It's a DIFFERENT idea, but I think it is a GOOD
idea.
> It leaves optimizations to the plugin.
>
> It gives you channel bundling unbundling at near-zero cost.
>
> It lets the plugin decide when and how to reuse buffers or not, even
> dynamically.
>
> It avoids an overly-simple single flag.
>
> It avoids any overly complex mapping scheme.
>


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