[gmpi] Re: Time Summary (was *Ping*)
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 20 May 2003 06:02:44 -0400 (EDT)
On Tue, 20 May 2003, David Olofson wrote:
> Also note that we'll probably need a feature that allows process() to
> return before the actual work is done, and a way of notifying the
> host upon completion. VST has such a feature, and AFAIK, it's
> specifically meant for plugins that wrap DSP hardware and the like.
> (No point in blocking the whole audio thread in process(). The host
> might have other things to do that doesn't depend on the output of
> this plugin.)
But DSP cards on VST are NOT actually implemented in this way, and it has
implications for downstream plugins. DSP cards on VST simply declare that
they have one buffer of latency, so each time process() is called they
return the data that was passed in in the previous process(). This isn't
ideal because if a host calls process() too often it will block waiting
for the DSP card. (that's the difference between time latency and data
latency... VST does not provide a means to differentiate, and some hosts
assume it's a data latency)
> It's just that some people think it's an important feature, and I'm
> trying to come up with a solution that does the job well for them,
> without making life misserable for the rest of us. Forcing every
> plugin to have a separate, thread safe entry point for events is just
> not an option, IMNSHO.
Agreed 100%.
Regards,
Angus.
----------------------------------------------------------------------
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:
