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.