Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to maalis 02 2000 - 11:33:36 EST
>> This is what VST does. It also allows plugins to define two versions
>> of the plugin callback; one that adds to the outputs and one that
>> overwrites; the latter meant to be used instead of clearing "new"
>> output buffers before using them. I'm beginning to doubt that this
>> really makes sense with today's memory bandwidth (a memset()
>> operation is very fast), but hey, you don't *have* to provide both
>> versions.
>
>I think it's not a big amount of work to provide both output
>method versions (add and replace) since only the innermost instructions
>change, but providing both methods may save us some CPU cycles.
>Therefore a plugin developer should by default supply both methods.
>(the host will be able to query if the add method is available)
>
>Any objections ?
I don't think we have to believe that Steinberg are god, but we can
pay attention to their discussion of these questions:
This is what charlie steinberg said on the same question:
------- cut ----------------------------
Someone writes:
>So even if the host is so stupid to call process() instead of
>processReplace() where is the harm? Please, don't write something like:
>"Always use process() and processReplace() is optional." We're no kids here,
>explain (briefly) why we shouldn't leave the process() method empty and
>provide only a processReplace()? All my tests show that it works flawlessly.
if it works now that's not a proof that it will do so in the future,
or with other host applications.
in cubase, the current architecture is that a synth output streams into its
own channel, which has a single port by definition. thus, the replacing()
method is called.
however please consider a different scenario, where several plug-ins
(synths or whatever) stream to the *same* port (bus), as for instance
the send fx in cubase do...if there were only replacing methods, the hosting
application would need to make all those plugs stream to a buffer, and
then merge (add, mix) all these buffers together into the destination
buffer which is a very significant performance 'penalty' because of
memory caching issues. if however the plug reads a value from a buffer,
modifies it, and writes it back, this can be handled way more efficiently
by the cache.
you can make no assumption about what the host does with your plug. the idea
is that any application hosting vst plugs should be absolutely free to
use these black boxes as desired, and the (only) one compromise for
the plug to be made because of performance issues is the process ()
method.
either your algorithm is simple, then it will do no harm to copy/paste
the code; or it is more elaborated in which case you will probably
have a subroutine doing the actual stuff such that again copying/pasting
the process method is not a big deal.
also note that you should really always provide both methods, as when
you only provide process(), and your plug should be used streaming to
a single port, host has to first clear the buffer and then call
process() which in turn does one more unnecessary buffer memory access.
hope that helps,
charlie
-------------------------------------------------------
on the in/out port question, he wrote:
-------- cut -------------------
>On a somewhat related note, I'd very much like to see a flag or canDo
>which indicates that a plugin can handle identical input & output
>buffers, ie.
>
> inputs[0] == outputs[0]
> inputs[1] == outputs[1]
> etc
>
>I've heard that some plugins have problems with that, but it'd be a
>nice way to sqeaze more efficiency out of some hosts, preventing
>unnecessary buffer allocation/copying.
plugins simply must not have problems with that in the first place.
i find it contradictionary to say 'you need a flag for signalling
that you can do something you're supposed to be able to do anyways', just
because some implementations fail to do what they're supposed to do?
charlie
------------------------------
>Time to open a CVS ? :-)
Not till there is actual code, IMHO.
I hope everyone sees why they should be reading vst-plugins.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST