> firstly i propose to make a processing classification. > > A - the strict inplace plug-in. > ---------------------------- > these processing take "n" samples and return "n" samples. whatever "n" = 0 > to infinite. This kind of plug-in can manage several input and several > output in real time, and are easy to port on DSP system where the latency > time is often fixed (e.g. 32 samples , 64 samples). i think the plugin should handle any number of samples per processing as long as the number of frames is the same for all inputs/outputs. > B - the non real time plug-in. > ---------------------------- > These kind of plug-ins are needing a minimum of sample number before > processing. They cannot be implemented on a real time system without > modifying some part of it. For example processing needing FFT 1024 sample, > needs 1024 samples to start to process something. But on a low latency > stream, you may be called every 32 samples , so if you process 1024 sample > on a single call, you kill the stream. In this case , or the programmer is > able to diffuse the processing in small part (e.g. 32 samples) or the system > is able to provide an other kind of delayed call to avoid DSP overload.... > (that we call in the hardware domain the double interrupt call, a first > interrupt push/pull samples, the second on is called when the required > number of sample is riched). large block based algorithms such as the 1024 sample FFT you mention can be handled in real time by having the plugin introduce an extra delay of 1024 samples (this requires 2 buffers of 1024 samples) and process asynchronously. > C - Conversion Plug-in. > ---------------------------- > These kind of product can process "n" samples and return "m" samples. "n" != > "m". This is the case for time stretching , or variospeed processing, or > simply an audiot format conversion processing. i doubt this should be introduced for the kind of plugin gmpi aims to be. --ms ---------------------------------------------------------------------- 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