10 Dec
2002
10 Dec
'02
1:05 p.m.
On Tue, Dec 10, 2002 at 05:06:29 +0100, Tim Goetze wrote:
No, I imagine it will be noticably slower, however I think CPU's are
getting to the kind of power where its feasable to use it for real.
The dynamic compiliation will win you some speed back.
I dont think the implementation is really that hard, the UI would be the
most complex part, as always. Its kindof a pipedream anyway, as none of us
has enough free time to tackle it at the moment.
- Steve
Steve Harris wrote:
Argh! I was thinking of dumping the code and rebuilding (hopefully keeping
the state). Doing it that way would be interesting, but much harder. Youd
have to either use a lot of function calls or do some hard code relocation
stuff I think.
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. 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