Seems like we're arriving at a fairly good, almost formal
understanding of the constraints on process-in-place. Let me try to
summarize, in hopes of arriving at something to measure design
candidates against.
-- Chris
A plug may re-use an input buffer as an output buffer only when all
of the following criteria are met:
1. The plug is written so as to allow it.
This means that a) Any logical output buffer that the plug writes to
before processing all input buffer data cannot be used as a
process-in-place buffer; b) Any logical output buffer that needs to
be larger than a given input buffer (for example, in a rate upsampler
plug) can't be used as a process-in-place pair; c) The plug must
include whatever plug-side process-in-place buffer usage negotiation
code GMPI may require. [Any other plug-side constraints?]
The plug-in is in a position to know criterion 1, and the GMPI API
could allow the host to query the plug about this.
2. The host is written so as to allow it.
This means that some hosts may depend on simpler but less efficient
connection models, such as one buffer per connection, and these hosts
will not include whatever host-side process-in-place buffer usage
negotiation code GMPI may require.
The host is in a position to know criterion 2, and the GMPI API could
allow the plug to query the host about this.
Discussion Point: To guarantee support for simpler hosts (as
described in 2. below), the GMPI spec could include a rule that all
plugs must always be capable of purely non-in-place processing; in
other words, that process-in-place can only be done if the host
requests it. (Is this rule explicitly spelled out in other plug
specs, e.g. VST?)
3. The process-in-place mapping from a given logical input buffer to
the corresponding logical output buffer is unambiguous to the host.
While this is obvious in one-in / one-out plugs, a plug with multiple
inputs or outputs (especially of different multichannel formats or
data types) presents the possibility of unpredictable in->out buffer
mappings. In particular, it may be possible that not all input
buffers can be used for process-in-place, and that the correspondence
of the ones that can is unobvious.
This unpredictability could be resolved either a) via a uniform set
of GMPI-wide rules, such as requiring any plug advertising
process-in-place capability to support it for all input buffers and
all possible in->out combinations, or b) via communication of
workable mappings from the plug to the host via the GMPI API. This
communication could take any of a number of forms, including get...()
calls or the 'baton-passing' plug-side buffer allocation technique.
4. The plug graph allows it.
This means that if a given input buffer is connected to more than one
plug input (either in the same plug or in any other plug), that
buffer cannot be used for process-in-place by any of them. (Note:
The host is in a position to automatically resolve all such problem
connections by duplicating the source buffer, creating a separate
buffer copy for each fed input.)
The host is in a position to know about problematic buffer
connections under criterion 4. Either a) the GMPI API could allow
the plug to query the host about this and avoid processing-in-place
for that input buffer, or b) GMPI could specify that all graph
construction and buffer allocation decisions are left to the host,
i.e. requiring all plugs to unquestioningly use host-furnished buffer
ptrs.
..end..
---------------------------------------------------------------------- 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
