Fons Adriaensen wrote: > On Sun, Oct 19, 2014 at 11:50:05AM +0200, Frank Heckenbach wrote: > > > LADSPA_PROPERTY_REALTIME indicates that the plugin itself *has* a > > realtime dependency. That would be the case only for few plugins, > > not really audio processing plugins, more plugins for I/O. > > We clearly disagree on the interpretation of PROPERY_REALTIME.
Indeed. Maybe we should ask Richard Furse, the author of the LADSPA specification for clarification. Then again, you might consider that his own example plugins which can be found in http://www.ladspa.org/download/ladspa_sdk.tgz all set LADSPA_PROPERTY_HARD_RT_CAPABLE, but not LADSPA_PROPERTY_REALTIME, and they're all pure audio processing (and in one case (sine), an audio generating) plugins. > For all of my plugins the following is true: if their output > is cached, or subject to significant latency, they will not > produce the expected result. Hence this must not be done, > and setting the property is required to restrict the host. Here's an example (not hypothetical, that's almost exactly what my software will do in some cases): Read an audio file, apply various effects and write the result to another audio file. For various reasons, in some cases I don't want to write the output as I go, but collect the data in memory and write the file at the end. So the output is cached and subject to possibly significant (if the files are large) latency. By this logic, it couldn't use any of your plugins, although looking at what they actually do, there's no reason they wouldn't work. > If a user expects to hear a note played on a MIDI keyboard > without delay, then this requires the entire processing > chain to do the right thing, not just the part that is > talking directly to the MIDI device. All plugins in such > a chain have the same real-time dependency. I disagree. The chain as a whole has a realtime dependency, but this doesn't mean each of its members has the dependency. As the saying goes, a chain is as strong as its weakest link, and in this case the weakest link (WRT realtime dependencies) is the MIDI interface (whether that's in another plugin or done by the host itself), not the processing plugins. Note that the comment says (emphasis mine): "Property LADSPA_PROPERTY_REALTIME indicates that *the plugin* has a real-time dependency (e.g. *listens* to a MIDI device) ...". That's not the case in your example: The plugin doesn't listen to the MIDI keyboard, it's the host (or another plugin) that does. > This is most > obvious for plugins that implement a synthesiser module, > e.g. a VCF, but in fact valid for almost all. In fact in another application I use VCFs which are controlled by data computed from a function. No realtime dependency here: If I repeatedly want to apply the same function values, I can just as well cache the VCF output. > Exception > would be plugin that implements e.g. a VU-meter or spectrum > analyser - it doesn't matter much if the result is displayed > with some delay (as long as that remains reasonable). As you say yourself, "as long as that remains reasonable". But the comment specifically talks about *significant* (i.e. non-reasonable in your terms) latency. So under your interpretation even these plugins would need to set the property. And if basically every plugin needs to set it, the property becomes meaningless. > Another interpretation, closer to yours, would be that if > the plugin has REALTIME_PROPERTY set it can not be used in > any form of batch (non-real-time) processing. But that is > not what the text in ladspa.h says. It doesn't mention batch processing explicitly, but "significant latency", and batch processing generally involves significant latency. Frank -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
