On Sat, Feb 08, 2003 at 11:55:00PM +0100, David Olofson wrote:
> On Saturday 08 February 2003 13.17, Steve Harris wrote:
> [...brachless clamp...]
> > Its not an instruction its just a bit of maths using fabs().
>
> Yes, of course! I keep forgetting that fabs() is an FPU operation. :-)
> (Life's
On Sun, Feb 09, 2003 at 12:16:02AM +, Steve Harris wrote:
> On Sat, Feb 08, 2003 at 12:03:01 -0800, Tim Hockin wrote:
> > > Branching to fill your delay line with explit 0.0's intead of reading them
> > > from a buffer of zeros doesn't help. We allready know that reverbs cant
> > > support it a
On Sat, Feb 08, 2003 at 12:03:01PM -0800, Tim Hockin wrote:
hi... first i want to apologize for not taking part in this
discussion so far. But i had a huge workload at university
and did not even have the time to read the XAP threads...
But now the semester is over and i hope to be useful to
the
On Sunday 09 February 2003 14.29, Steve Harris wrote:
[...]
> There is also the instruction cache to think of. Practical
> experience suggests that suddenly waking up a chain of plugins
> causes a spike of CPU load which settles down. It may be possible
> to moderate this with carefull coding howev
On Sun, Feb 09, 2003 at 11:13:53 +0100, David Olofson wrote:
> On Sunday 09 February 2003 01.18, Steve Harris wrote:
> [...silence and RT...]
> > I suspect (but have no intention of finding out) that suddenly
> > waking up a large subnet will have large chace effects too, so it
> > wont be a case o
On Sunday 09 February 2003 01.18, Steve Harris wrote:
[...silence and RT...]
> I suspect (but have no intention of finding out) that suddenly
> waking up a large subnet will have large chace effects too, so it
> wont be a case of just the CPU load varying.
I suspect that unless most of the memory
On Sat, Feb 08, 2003 at 11:55:00 +0100, David Olofson wrote:
> On Saturday 08 February 2003 13.17, Steve Harris wrote:
> [...brachless clamp...]
> > Its not an instruction its just a bit of maths using fabs().
>
> Yes, of course! I keep forgetting that fabs() is an FPU operation. :-)
> (Life's no
On Sat, Feb 08, 2003 at 12:03:01 -0800, Tim Hockin wrote:
> > Branching to fill your delay line with explit 0.0's intead of reading them
> > from a buffer of zeros doesn't help. We allready know that reverbs cant
> > support it at all. Efficieny reasons would also rule out flangers, delays,
> > mos
On Sat, Feb 08, 2003 at 11:54:28 -0800, Tim Hockin wrote:
> > [silence detection]
> >
> > You still have unpredicatable CPU load, which makes it pretty useless.
>
> ...for you
For anyone working in realtime, who doesn't want dropouts.
The seems to be the common case.
- Steve
On Saturday 08 February 2003 21.03, Tim Hockin wrote:
> > Branching to fill your delay line with explit 0.0's intead of
> > reading them from a buffer of zeros doesn't help. We allready
> > know that reverbs cant support it at all. Efficieny reasons would
> > also rule out flangers, delays, most fi
On Saturday 08 February 2003 13.17, Steve Harris wrote:
[...brachless clamp...]
> Its not an instruction its just a bit of maths using fabs().
Yes, of course! I keep forgetting that fabs() is an FPU operation. :-)
(Life's not that nice with ints on most CPUs...)
[...]
> > Besides, if you have s
> Branching to fill your delay line with explit 0.0's intead of reading them
> from a buffer of zeros doesn't help. We allready know that reverbs cant
> support it at all. Efficieny reasons would also rule out flangers, delays,
> most filters and choruses.
Maybe I'm missing something, but how can
> [silence detection]
>
> You still have unpredicatable CPU load, which makes it pretty useless.
...for you
On Fri, Feb 07, 2003 at 07:25:25 -0800, Tim Hockin wrote:
> > Now, there is a problem here: If you have a chain of plugins, and some
> > of them don't support silence, these will screw things up for the
> > silence aware plugins. However, if we apply silence detectors on the
> > outputs of plugi
On Sat, Feb 08, 2003 at 03:06:40 +0100, David Olofson wrote:
> On Saturday 08 February 2003 02.17, Tim Hockin wrote:
> [...]
> > Assuming we really want to allow soft-limits (which I just don't
> > get), we can just say that if you want a hardlimit, constrain it
> > internally.
>
> Yeah.
>
> As t
On Sat, Feb 08, 2003 at 12:09:59 +0100, David Olofson wrote:
> On Friday 07 February 2003 23.07, Steve Harris wrote:
> [...]
> > > You might ove the conditionals around a bit depending on which
> > > case you want to be the fastest, but I don't think it gets much
> > > more fun than that.
> >
> > T
> > Let's just say that all ranges are suggestions, and if it matters,
> > it is the plugin's problem. If we later find this to be a big
> > problem, we'll deal with it. Fair?
>
> Yeah. Works for LADSPA, so it can't be *that* bad.
Unless anyone objects with good arguments, I'm putting it in my
On Saturday 08 February 2003 02.17, Tim Hockin wrote:
[...]
> Assuming we really want to allow soft-limits (which I just don't
> get), we can just say that if you want a hardlimit, constrain it
> internally.
Yeah.
As to soft limits, I think the main point is to relieve the plugin
author of the t
> > > something out... It just seems to me that plugins have a better
> > > idea how to clamp - and they can quite often use constant limits
> > > as well, I guess.
> >
> > I'm fine with this. If the plugin can constrian the inputs itseelf,
> > it seems reasonable not to have explict host support.
On Friday 07 February 2003 23.07, Steve Harris wrote:
[...]
> > You might ove the conditionals around a bit depending on which
> > case you want to be the fastest, but I don't think it gets much
> > more fun than that.
>
> The are branchless clamps, which save a few cycles.
Cool. Would your averag
On Fri, Feb 07, 2003 at 10:04:54 +0100, David Olofson wrote:
> Yeah, that's nasty as well - but not nearly as nasty as forcing
> *outputs* to clamp to the range of whatever inputs you connect them
> to.
Sure.
> > Maybe the host could signal that a control might go out of range
> > and the SDK
On Friday 07 February 2003 21.14, Steve Harris wrote:
> On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> > On Friday 07 February 2003 11.07, Steve Harris wrote:
> > > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > > It sounds like the wrong thing, the general cas
On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> On Friday 07 February 2003 11.07, Steve Harris wrote:
> > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > It sounds like the wrong thing, the general case is that the
> > > > host generates values its knows to be in
On Friday 07 February 2003 11.07, Steve Harris wrote:
> On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > It sounds like the wrong thing, the general case is that the
> > > host generates values its knows to be in range, then the plugin
> > > checks it again to check its in range..
On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > It sounds like the wrong thing, the general case is that the host
> > generates values its knows to be in range, then the plugin checks
> > it again to check its in range...
>
> Not the host; the *sender*. That is the sequencer (whic
On Thursday 06 February 2003 22.56, Tim Hockin wrote:
[...]
> Now, based on recent arguments, I am rethinking my otiginal idea.
> I had originally put this at the plugin granularity, then moved it
> to per-channel. This may be Good Enough, but not The Best.
I actually suspect that it might be *ea
> On Thursday 06 February 2003 07.50, Tim Hockin wrote:
> [...Paul's k5000...]
> > The top-of-chain plugin (synth) will tell you when it is silent, of
> > course!
> >
> > I think it can be a massive, coarse-grain optimization, if we can
> > make it work.
>
> I think it'll be rather useless if done
On Thursday 06 February 2003 07.50, Tim Hockin wrote:
[...Paul's k5000...]
> The top-of-chain plugin (synth) will tell you when it is silent, of
> course!
>
> I think it can be a massive, coarse-grain optimization, if we can
> make it work.
I think it'll be rather useless if done on the plugin lev
28 matches
Mail list logo
