On Sat, Mar 01, 2003 at 04:47:55PM +0000, Simon Jenkins wrote:
torbenh(a)gmx.de wrote:
[...]
Another problem i have with moving to the graph ordering side
is the opengl stuff in galan which requires the pull model for
the data.
It would get somewhat inconsistent if gl data was pulled and
audio data not... but this is also cosmetic...
They're not that far apart:
The point of graph-ordering is achieve pull semantics from a
push implementation. The graph orderer works out what order
the data would be pulled through the graph, and the data gets
pushed through in reverse order to achieve the same effect.
having looked at what amble does i see the point for the
push thing :)
i was thinking about this when i started experimenting with
the DSP of my EMU10K1... before university started...
But i had too much problems figuring out how one would allocate the
temp variables for n:m connections.
You seem to be more firm in this. perhaps you could give me some
clues.
the goal is the same as ambles but
source are some galan components and target is emu10k1 assembler.
alsa has some nice macros for generating the code...
problems are:
only 256 registers (no mem)
only some delay lines...
delay line allocation is not the problem because they are global
for all sample cycles.
A push implementation with push semantics probably wouldn't
bother to sort the graph: it could rapidly calculate the execution
order at runtime, executing each node as its data became available.
OTOH I agree that there's an inconsistency at the implementation
level, if thats what you're concerned about.
yeah but for obvious reasons the push model is necessary..
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language