> a) if you're an app (a ladspa host) > > they must all be at least long enough to handle the SampleCount argument > you pass to the plugin's run() method.
Agreed. So: Please, can someone state this explicitly in the LADSPA specification for clarity purpose??? > noone will spank you if your buffers are too big, but your app might go > "kaboom" if you pass a longer SampleCount than what you've allocated. Yes, totally what I thought of... > you choose the SampleCount to run() for, and you choose the lengths of > the buffers ... in practice, if an app is coded to always call run with a > SampleCount of 256 (say), then there's not much point allocating either > input or output buffers any longer than that, which is why the code you've > looked at allocates buffers all of the same length. Never mind. I just want the specification to include the above statement that input and output buffers must have a reasonable amount of space allocated by the host. > b) if you're a plugin > > well, the lengths of the buffers isn't up to you, but you should hope the > app author didn't screw up, and in your run() method you have to assume all > the input and output buffers are at least as long as the SampleCount the > app asked to run for. Yes. You have to rely on the host to provide enough space. That's all I wanted to know. > > 2. Is there any range constraint applied to the audio content > > communicated by the audio input/audio output ports? > > VST e.g. does restrict the range from -1.0 to +1.0. > by convention, -1.0 to 1.0 (in most plugins and hosts) Why only "by convention". Put it into the specification, then it's "by specification". Wouldn't a common range for all plugins be the better idea? So long, J�rgen
