13 Dec
2002
13 Dec
'02
4:09 p.m.
On Fri, Dec 13, 2002 at 11:28:59 -0800, Tim Hockin wrote:
The problem with a set_rate function is that a lot of plugin authors wont
want to implement it (its a pain and its not obvious what you should do),
so it wont be usable very often.
The hosts needs instantiation code anyway, and its not like chaging the
sample rate is an RT operation, so I dont see the point.
No, change it to RTFL_DETERM, autohors ahould have to explicity state that
it is determinstic, not the other way round.
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. 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! :)
Hey, you too ;)
- Steve