[linux-audio-dev] Plugin APIs (again)

Tim Hockin thockin at hockin.org
Wed Dec 4 23:48:01 UTC 2002


> No, there are other ways. All you really need is a unique ID for each 
> voice, for addressing per-voice.

Unless I'm missing something - all you really need is a voice-id that is
Unique within that instance of that plugin.

[... RT vs NONRT controls ...]
> that, you basically have three options:
> 
> 	1) realloc() the buffers when the certain parameters
> 	   change, or
> 
> 	2) decide on an absolute maximum buffer size, and always
> 	   allocate that during instantiation, or
> 
> 	3) realloc() the buffers when a NONRT "max_delay" or
> 	   similar parameter is changed.
>
> 3 works and is relatively clean and simple - but it requires an 
> "extra" interface for setting NONRT parameters. I would definitely 
> prefer this to be basically the same as the normal control interface, 
> as the only significant difference is in which context the control 
> changes are executed.
>
> > Or maybe it's not, and a user
> > who changes a sample in real time can expect a glitch.
> 
> So you're not supposed to be able to implement delays that can take 
> modulation of the delay parameters, and still cope with arbitrary 
> delay lengths? (Just an example; this has been discussed before, so I 
> guess some people have more, and real examples.)

So how do VST effects do it?  I can increase the delay feedback all I like and
it doesn't hiccup, stutter, or misbehave at all.  You're saying that this is
a non-rt control because it might have to realloc() buffers?

> that plugins should have "safe defaults" built-in (to prevent them 

absolutely - this is why controls have default values.



More information about the Linux-audio-dev mailing list