Steve Harris wrote:
I couldn't resist it so I hacked up a quick script to try the blockless, dynamicly compiled processing we were discussing the other day.http://plugin.org.uk/blockless/
Nice! I've only had a very quick look so far, but just knowing it exists has improved my day by quite a bit.
I went as far as defining a biquad filter in the graph format (http://plugin.org.uk/blockless/blockless/modules/biquad.g), but it dosen't quite work because the execution order is more or less random.
I haven't looked closely yet but do you mean that the atoms are being executed in some compiler-determined order that doesn't reflect the flow of data through the graph? Someone suggested here that single sample latencies, eg in feedback loops, shouldn't cause noticeable problems. (There's got to be one somewhere in a feedback loop anyway). The combined effect of whole load of atoms executing in the wrong order might be a different matter though. Anyway I know this sort of thing can cause problems occasionally because I've suffered them: If you try to do anything too tricky with the logic modules in the Nord Modular you can end up "latching" a logic value that hasn't been evaluated yet. (OTOH the Modular is a synth not an FPGA and I was well across the line which divides use from abuse before I even noticed that I wasn't in control of the evaluation order).
The optimisations I'm really hoping to see are for the compiler to strip outI used the biquad in a simple toplevel graph (http://plugin.org.uk/blockless/blockless/graphs/test4.g), it takes about 50 cycles per sample on PIII (interestingly its compiles to slightly worse code in gcc3.2), the source my script produces is very tangled and funtion-y, but gcc manages to untagle it and inline it all, eg. http://plugin.org.uk/blockless/blockless/intem/test4.c
dead code when an output isn't connected, and to propogate a constant 0
through the graph when an input isn't connected.
This would need a recompile every time a connection is made (which is
already the case in your implementation anyway) rather than just when an
atom is added or removed though.
Thinking again about what the Nord Modular does: You can make and break
connections between existing modules as much as you like with neither a
glitch nor a change in (what it claims to be its) CPU usage. As soon as you
add a new module, though, all the existing modules reset themselves and
everything "starts again" with the new module, suggesting that the existing
modules have all lost their contexts. This is *really* annoying if you're trying
to develop a patch or sequence that evolves very slowly.
Simon Jenkins
(Bristol, UK)