is it possible to know or influence VM's module run order?

[tristanshoutsf]

Consider the case of module A doing something with pitch and a control signal generated by module B, and module B is also connected to pitch. If module A runs before B the results might be very different than if module B runs before A.

Is there any way to either predict or influence the run order of modules?

VM might be doing graph analysis of all the connections, and barring feedback, work out a zero-delay feedforward run order. Cycles (feedback loops) complicate that, and may even complicate getting feedforward subgraphs. I've used Boost's graph analysis for this kind of run order generation, but I really don't recall what it generates when faced with one or more cycles.

Anyway, is VM actually doing anything like that to ideally generate zero-delay signal paths, simply running left to right, running based on order of instantiation, random?

[utdgrant]

We had quite a deep discussion about this in the VM Designer board.

TL;DR - Every module requires a minimum one-sample delay (1/48,000th second) between input and output. Effectively, all modules process signals in parallel every sample period. The order only matters in a few corner cases, where a signal is split down multiple chains of modules, then recombines in some way later.

If you DO want to go hard-core with re-aligning propagation delays along different module chains, you might want to consider something like the ACE Delay Line. (Full disclosure: ACE is one of my products).

[tristanshoutsf]

Thanks for the reply! That's really helpful. And as it turns out I already own the ACE modules - they conjured up distant fond memories of a particular EE course I took long ago. Thanks for reminding me about the ACE delay module.

[tristanshoutsf]

ACE Delay solved my propagation delay problem quite nicely. Thanks!