I suggested this a while ago and the more i thought about it the more i thought it was a good idea, hopefully others can set me straight:)
/* Hint LADSPA_HINT_DATA_PRESENT indicates that the data item should be used to signal that the audio stream has stopped. It must be used in conjunction with LADSPA_HINT_TOGGLED. The host signals the plugin that the audio input stream has stopped. The plugin subsequently signals the host that the audio output stream has stopped. The first step requires an input port while the second requires an output port. The plugin should only look for changes in the input port state while the host may use the value of the output port state. A plugin should expect to be deactivated immediately after signalling the host that output has stopped. */ Motivation: there are 3 cases where this hint is useful, 2 of which I think fit the LADSPA criterion of falling into the intersection of all audio applications. First, discontinuing polyphonous voices. Under LADSPA, polyphony is implemented by allocating 1 instance of a plugin per note/voice. When the voice is stopped there is a decay period of time which is more inherent to the plugin then it is the host. To allow a host to deallocate a voice safely and efficiently, the DATA_PRESENT mechanism has the host signal the plugin that the activitity is over and the pluging subsequently signals the host that it has concluded its audio activity. At this point the host can deallocate the plugin instance without risking losing any worthwile information. #1 In Intersection? Hosts use a variety of methods to manage multi-voice activity. While the host can keep track of all the input passed to a plugin, it is more properly the domain of a plugin to know when it is finished with a job. The privileged position of the plugin with regard to knowing state information at wrapup carries across host/plugin arrangements. Even if the plugin has no decay, that is still a piece of information that it knows which the host does not. #2 Finite Impulse Response Filters. many plugins used as effects on an audio signal will generate output for some finite period after input has stopped. Examples include echoes and reverbs. once again the plugin has knowledge about when it has completed producing output whereas the host can only conjecture or defer the decision to the user. Third, non-realtime effects which change file length. This does not warrant being put in LADSPA but is a freebie fro mthe adoption of DATA_PRESENT. plugins which are applied to entire soundfiles can result in an output soundfile of a different length. as an example; a granular filter which changes tempo without effecting pitch. the host could conveniently know the range of the output file. the plugin could defer producing output until it has run enough data to fill some internal needs. Compatibility: If both the host & plugin are either aware or unaware of the DATA_PRESENT mechanism their is no compatibility issue. If the host is aware but the plugin doesn't use it there's no compatibility issue, the host will see there is no DATA_PRESENT port and run the plugin longer. If the plugin has the feature but the host does not there is a consideration: the host will not know how to set the data input port signalling data present. Therefore the plugin must only pay attention to changes in the state of the DATA_PRESENT input port and not the actual state. Practically this should not present a problem because most hosts expose all plugin parameters to the user who can toggle the control on and leave it there. The plugin can defer the beggining of ouput until later than it first recieves input and tell the host it is doing so with the mechanism. It could do the same without the mecchanism so this causes no compatibility issues as long as the plugin fills the pre-output buffers with zeroes. Also the plugin must not abuse the mechanism to break up its output into discontinuous patches, This would cause large compatibility problems. The output image must be continuous in time. This is ensured by the statement "plugin should expect deactivation on sending the false signal". Generally, if you think of LADSPA plugins as two dimensional fxns from a domain limited in height to -1 to 1 and with width being time, then they map to some output range with the same vertical limitation but the only time limitation being that the start of output >= the start of input. The DATA_PRESENT mechanism allows the host to discover the limitations of the output time range, which are different for each continuous run of the plugin . My argument is that the range of the output in time is useful information to the host in every audio application and that it is something the plugin has to communicate to the host because the host can not be expected to determine it on its own. please reply. --------------jacob robbins--------------------------------------- ::::::::::::::::::::::::::::: [EMAIL PROTECTED]::::::::::: >>>>>don't go to http://technoanimal.tripod.com, really. :::::::::::::::::::::::::::::::: -------------------------------- _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
