Subject: Re: [linux-audio-dev] XAP status : incomplete draft
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Fri Dec 13 2002 - 22:04:07 EET
On Fri, Dec 13, 2002 at 11:28:59 -0800, 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..
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.
> > 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.
No, change it to RTFL_DETERM, autohors ahould have to explicity state that
it is determinstic, not the other way round.
> 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
This archive was generated by hypermail 2b28 : Fri Dec 13 2002 - 22:11:00 EET