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

  • From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Wed, 28 May 2003 16:15:38 +1200

re: process-in-place discussion....

> ...seems like it wouldn't
> necessarily be an unreasonable burden on the host to make it take
> into account the existence of Y's in its graph/buffer planning...

Hi Chris,

Yeah, the more I think about it...the more i agree with you about
process-in-place.
* It's a significant performance gain.
* It's applicable to a large number of plugins.

The performance gain comes though reducing our use of memory bandwith, and
we hit the cache less.
  A large number of effects are mono-in/mono-out, and can potentially take
advantage of process-in-place(gain, EQ, compression, overdrive etc).
stereo-in.stereo-out etc qualify too of course...

I imagine it working like so...

1) Plugin advertises: "I can process-in-place"
2) If host 'agrees': Host creates 1 audio buffer.  Passes plugin 2 pointers
to the same buffer (in/out).
or,
3) Host dosn't support process-in-place: Host creates 2 audio buffers,
passes pointers to both buffers to plugin.

The plugin is doing something like....

*output_ptr++ = *input_ptr++ * gain;

..code which works either way.
  That way, no one needs to write special-case code for process-in-place vs
not-process-in-place.

Summary:
*Plugin can advertize it's ability to process-in-place. It's optional for
the plugin.
*Host can choose to honor the request or not. It's optional for the host
too.

I really like that process-in-place support can be optional for both host
and plugin, without compatibility probs.

Other questions:
Does process-in-place apply to:
A) all a plugin's pins?.....or
B) specify buffer sharing at granularity of individual pin pairs?

B is more powerfull, but I guess option-A would be fine for most plugins.
(gotta ignore those seductive 'corner cases'.....sirens luring us toward the
rocks!......)

Best Regards,
Jeff M

----- Original Message ----- 
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, May 27, 2003 3:42 PM
Subject: [gmpi] Re: Topic 7: Audio packaging


> >Hi all,
> >Lots of good ideas circulating on this topic. My vote, for the record.
> >
> >*Buffers owned/managed by host. Plugin may not mess with the raw pointers
> >(no pointer swaps).
> >*No processing in-place. Seperate in/out buffers.
> >
> >  Reasons:
> >
> >example 1)
> >
> >[Synth]--->[Effect1]----->
> >           \------->[Effect2]------>
> >
> >  My host passes same input buffer to two plugins. If one plugin
> >processes-in-place, it will over-write the other's input buffer.
> >    (To protect againt this, my host would duplicate the input buffer).
> >
> >example 2)
> >
> >---->[Mono to Stereo]-------->[Effect1]----->
> >                                   \---------[Effect2]------>
> >
> >  A mono-stereo plugin pointer-swaps one input to it's two outputs,
feeding
> >two downstream plugins.  Again, my host would need to duplicate the
output
> >buffers to protect against over-write.
> >
> >So,  both techniques, designed to save memory copying, don't. (In my
case).
> >
> >I'm uneasy about plugins passing around raw pointers to buffers. I'm sure
> >none of you gentlemen ever cause memory leaks, but... you know......
newbies
> >;-)
> >
> >I would prefer a simple approach. Host-managed, seperate in/out buffers.
> >
> >Please take this as simply stating my own preferences, not a put-down of
> >other approaches.
> >
> >Best Regards,
> >Jeff McClintock
> >
> >www.synthedit.com
>
>
> I see what you're saying, but it also seems like it wouldn't
> necessarily be an unreasonable burden on the host to make it take
> into account the existence of Y's in its graph/buffer planning.
> Would it?
>
> In other words, in your example process-in-place is only impossible
> because you assume that the one buffer is literally shared by the two
> plugs on the legs of the 'Y'. If, instead, the host buffer-duplicates
> the buffer (or else the user manually  inserts a Y plug that
> duplicates the input buffer) to avoid that problem, then each one of
> the downstream plugs receives a separate buffer and process-in-place
> is no longer impossible.
>
> -- Chris


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