Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Tim Hockin (thockin_AT_hockin.org)
Date: Thu Dec 05 2002 - 06:43:11 EET
> 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.
This archive was generated by hypermail 2b28 : Thu Dec 05 2002 - 07:26:51 EET