Since voice units are always processed in the order they're listed in the struct definition, units with control outputs should (but don't strictly have to) be placed before the units they are to control. Wiring up the graph (against the unit processing order) will introduce latencies that depend on the fragment size - which will of course vary when script timing or external events trigger fragment splitting.
Though this shouldn't make the engine crash or anything, it's usually undesired behavior, and the compiler should probably detect it, and warn about it - or maybe even fail. (As it is, the only way to implement feedback in the graph is to have 'env' units modulating each other, which doesn't strike me as particularly useful - although I could be missing something!)
If/when proper feedback support is implemented, explicit syntax or directives to eliminate the warnings can be added.
Since voice units are always processed in the order they're listed in the struct definition, units with control outputs should (but don't strictly have to) be placed before the units they are to control. Wiring up the graph (against the unit processing order) will introduce latencies that depend on the fragment size - which will of course vary when script timing or external events trigger fragment splitting.
Though this shouldn't make the engine crash or anything, it's usually undesired behavior, and the compiler should probably detect it, and warn about it - or maybe even fail. (As it is, the only way to implement feedback in the graph is to have 'env' units modulating each other, which doesn't strike me as particularly useful - although I could be missing something!)
If/when proper feedback support is implemented, explicit syntax or directives to eliminate the warnings can be added.