Le 2011-11-14 à 14:46:00, Jonathan Wilkes a écrit :
Ok. It's hard for me to differentiate that from breadth-first, probably because I have a hard time reading the linetraverser c code (or any c code really) and figuring out from it what the rules are for ordering the signal objects in the DSP graph.
I haven't really read that code either... well, at least not the d_ugen.c code, that contains dsp_add and such.
But just think that for the DSP, the order of some things don't matter, as long as when summing inputs in a buffer, the first one to do it does a plain assignment, and the other ones do a +=, and running the code does not happen before all the inputs have been added together.
So, in the DSP, things can't happen in a plain breadth-first manner, and they can't happen in a plain depth-first manner either, but they can happen if you modify those manners to prevent running the code until all the inputs are ready. In that model, it doesn't matter much whether you are running a modified depth-first or a modified breadth-first, as long as it's modified to run each perform() function at most once per block. And there are many other ways to traverse the patch in a way that would be correct, and would be neither like depth-first, nor like breadth-first.
The only place where this breaks, is if a given DSP order causes a 1-block delay on certain send/receive or throw/catch tasks. And also dsp loops are forbidden.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC