> 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.
