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
