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

> The answer is: Mark input buffers read-only. Downstream plugins then have to
> create a new output buffer each.
> 
> 2 problems with that:
> 1) It's not the optimal solution (the 'last' plugin to use the input buffer
> could have safely recycled it).

This is exactly the case that I called 'pretty ugly'.  The idea that the
host has to actually enforce the order is pretty ugly to me.  It's a good
chunk of host logic that isn't needed.

> >>"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)."
> 
> Yeah.......I'm trying to avoid "pretty ugly".

Again, to be clear - this is EXACTLY what everyone is saying happens with
the traditional approach with one caveat:  unless plugins identify
themselves as doing in-place-processing, the last plugin might or might not
reuse the buffer.  This is the only difference, and would be the only reason
to need the plugin to express it's capabilities.

> 2) These 2 new buffers, are they read-only?........
> 
> Answer: It depends on the graph layout.  If an output feeds a 'Y junction'
> it's read-only.

If you allow a plugin to split the same buffer out of two outputs, then you
have to mark one as read-only.  If you disallow that, the ONLY time you get
into this case is if the host splits a signal, and it can do the rigth
thing.

> The more I think about it, the more I realise baton-passing dosn't save any
> memcopys, it dosn't save any buffers, it just allows the plugin defer the
> problem to someone else (either the host or the next plugin downstream).
> 
> There is zero performance gain from batton-passing. zero.

Except for plugins with non-trivial input->output mappings.  So not zero.
Non-trivial plugs will NOT be able to do in-place processing without
something more advanced.

But it seems that no one cares, and maybe that's fine.

> "Worse performance than VST", catchy advertising phrase?
>
> Batton-passing is an optimisation for 'corner cases', (plugins that do
> nothing but pass an input signal un-modified to an output).  Yet penalises
> all other plugins.

Straw men catch flames pretty easily.  The penalities are negligible.

That said, I have expressed the model.  The flaws have been shown.  It's
time to weigh in.

All you silent observers - now's the time!

a) Simple: a per-plug global flag. Plugins are either in-place safe (any
input can be reused for any output - at the host's whim) or they are not (no
input will be reused for any output <see footnote 1>).  Not flexible, but 
simple.

b) Mapped: static plugin-defined mapping of ins to eligible outs.  Plugins
that can do in-place processing identify the output(s) on which a buffer for
each input can be reused.  More complex, marginally more flexible.

c) Batons: dynamic, internal mapping done by plugin.  Plugins output buffers
where they want, resuing whatever they can.  Fairly complex, most flexible.

d) Other - did I miss one?
Tim

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