On Friday 13 December 2002 20.28, Tim Hockin wrote: > > 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..
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. > > 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. 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.) > > > ...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... :) > > 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 ---