[gmpi] Re: Topic 7: Audio packaging

> >Equally if it has
> >inputs A and B and outputs C and D it shouldn't assume that A will become C
> >and B will become D, the host may have perfectly good reasons for crossing
> >them.
> 
> Hm, is this part really always true?  Consider inputs A', B', C'  and 
> outputs D' and E', where A' and B' are control signals affecting the 
> processing of audio input C', with time-smoothing constants, D' is 
> the audio out, and E' is a control signal out based on an analysis of 
> A' and B'.  So because of the time constants you want to do a full 
> pass on A' and B' before doing the audio processing pass on C'.  In 
> this case the host couldn't use  the C' buffer for D' as that would 
> erase the audio input before the plug got around to processing it.

This is what I meant when I said 'sufficiently complex'.  This plugin would
almost certainly have to flag itself as NOT in-place safe, when in reality
it could be.  This plug could define a mapping of inputs to outputs (via
some context stuff like David said) statically.

But now make it more complex - the input->output mapping can change based on
some other variable.  Now solve that.

> So I still think what I said before, that the plug is the only entity 
> in a position to know which logical output buffer(s), if any, can 
> safely be used as the physical 'process-in-place' buffer for each 
> logical input buffer.  We could decide to furnish a mechanism for the 

If the PLUGIN decides what input ends up at each output, it's all flexible
and all transparent to the host.  Baton-passing.

I have a summary email coming up - watch for it.


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