13 Dec
2002
13 Dec
'02
6:26 p.m.
On Friday 13 December 2002 20.28, Tim Hockin wrote:
Yes... Many plugins don't care at all about sample rate, and others
can deal with it without too expensive partial reinitialization. That
might be worth considering.
OTOH, how often do you actually change the sample rate? If you run
plugins to generate data for a synth, you'd have resampling in
between those plugins and the synth - but even then, you probably
don't want to tell those plugins what's actually going on... Let them
think they're working at a constant sample rate.
Synchronization with external machines (*) could be another reason,
but I don't think you should tell the plugins the whole truth in that
case either, since the idea is that the *whole system* should be
locked at the exact same sample rate.
(*) Layla (like many other studio machines) does it by tracking the
wordclock with it's own sample rate; can vary from 25-50 kHz
for Layla20 or 50-100kHz for Layla24.
So, this probably only matters to the API and implementations. I
agree that reinstantiating sounds like overkill, especially since
many plugins will more or less ignore the change.
Well, that's the point. Whether it's the whole plugin that is
nondeterministic, or just this single control event handler, it still
means the same thing: It means there is something you should never do
from within the RT thread. So, if you want your RT thread to keep
running at all times, you'll have to rip a plugin with
nondeterministic controls out and run it in a fake host or something
to handle a change of one of those controls, and then trow the plugin
back into the real net.
Or you can try to make the offending plugin use the host's worker
thread service to perform the actual work related to those controls.
That's the main reason why I considered something like that. (Very
easy for simple hosts to fake, BTW - although then they won't be able
to run Linuxsampler and other plugins that expect *real* worker
threads.)
I've completely ignored the pitch thread. I'll get there. I just
have a job during the day (which I already am abusing to read all
you guys' emails - 30 last night! :)
It's like the old days again! *hehe* Insane bandwidth, but still the
same extreme SNR. :-)
Lots of things to consider here...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
This should
not be allowed, if you want to run the instrument at
a different rate, reinstantiate it.
This makes the API simpler (one less function call). Are there any
drawbacks to it? Or conversely, are there any drawback to having a
set_rate() method which is only ever called from the inactive
state? It seems that if a host wants to change rate,
re-instantiating everything is overkill, if it knows it is in a
safe state.. Agreed. I
think tis less confusing to have to indicate that a
plugin /is/ deterministic though.
Don't do what ladspa did though and mix together RT safe-ness and
determinicity (is that a real word?).
Clarify? Are you suggesting I change RTFL_SLOW to RTFL_NDETERM?
Keep in mind these are per-control flags. ...and the optional "NOTE_PITCH" that no one
will ever use, of
course. ;-)
And many of us still think doesn't belong in the API... :)