10 Dec
2002
10 Dec
'02
12:13 p.m.
Steve Harris wrote:
On Tue, Dec 10, 2002 at 03:08:01 +0100, Tim Goetze
wrote:
> it'd still be interesting to know how the sync problems this
> method poses are solved: you cannot rely on executable code
By sync problemt do you mean loop latency? There not
solved exactly its
nope, i meant dynamic updates on a realtime (lock-free)
code path; it's an interesting problem with, afaict, no
obviously elegant solutions.
just that the loop latency is 1 sample, so it becomes
(generally)
insgnificant. To the extent that its lo longer neccesary (or desirable) to
do graph dependent ordering.
yes, this is a huge plus.
As you know the latency is one sample you can do
intersting tricks with
module placement and mixing.
yeah, i agree it's the ideal method of processing. i'm not
convinced it would run anywhere as fast as block-based
processing though. cache effects are an argument (filter
histories, delay lines, lookup & wave tables etc would all
frequently move in and out of the cache lines) and the
implementation effort, including dynamic code updates,
would probably be huge. and you'd have to drop some possible
applications of simd (vectorized) instructions.
tim