VM Execution Order

Post Reply
UrbanCyborg
Posts: 585
Joined: Mon Nov 15, 2021 9:23 pm

VM Execution Order

Post by UrbanCyborg »

One of those little questions that niggles at you in the dead of night...what is the module execution order in a VM patch? Does it hold second copies of every module's state, so as to do an atomic commit? Or is there some specific order in which modules process their inputs and create their outputs? The first possibility is deterministic, the second much less so (in a sense, since anything running on a computer is deterministic outside of random quantum tunnelling effects). But which is it? Or perhaps another possibility I haven't considered? My brain hurts. :?
Cyberwerks Heavy Industries -- viewforum.php?f=76
ColinP
Posts: 935
Joined: Mon Aug 03, 2020 7:46 pm

Re: VM Execution Order

Post by ColinP »

I made a brief attempt to determine how this works during the early stages of developing LSSP but didn't come to a final conclusion, although if I recall correctly it doesn't seem to be atomic.

I gave up because I soon realised that even if an atomic commit was used one still has the problem of propagation delays through an arbitrary network of modules.

This isn't a problem for most modules as a signal being delayed by a few samples isn't going to have much impact, but it is critical in certain applications that are trigger sensitive and require synchronous delivery of independent signals. In such critical applications one has to take care to allow signals to in effect "settle" before interpreting a trigger.
UrbanCyborg
Posts: 585
Joined: Mon Nov 15, 2021 9:23 pm

Re: VM Execution Order

Post by UrbanCyborg »

Yeah, it strikes me that there could be critical order dependencies.
Cyberwerks Heavy Industries -- viewforum.php?f=76
User avatar
utdgrant
Posts: 530
Joined: Wed Apr 07, 2021 8:58 am
Location: Scotland
Contact:

Re: VM Execution Order

Post by utdgrant »

From what I could tell, based on my own experiments, the order of execution seems to be:

1. Loop round all cables in an arbitrary order.
2. For each cable, pass the output value from the out jack on the source module through to the in jack on the destination module.
3. At this point, all modules will have the [t-1] output value of the 'nearest upstream' modules at their inputs. Similarly, each module's [t-1] output values will have been propagated to the 'nearest downstream' modules.

4. Loop round all input jacks in an arbitrary order.
5. Perform a summing operation of all cables attached to that input jack.

6. Loop around all modules in an arbitrary order.
7. For each module, execute ProcessSample().
8. It's entirely under the module designer's control what happens within ProcessSample(). However, it makes sense to read all input jacks, perform the DSP, then write to all output jacks. Obviously, modules which create delays, etc will hold input values in a buffer until it is time to perform output writes.

And that seems to be it. Based on my experiments when developing the ACE bundle, I saw this behaviour play out consistently.

From an intuitive point of view, you might think that the order of looping round cables (in Step 1), and modules (in Step 6) might make a difference to how signals propagate, especially with multiple branches and uneven module counts. Consider this diagram:

VM Sources Jack (1L) -> Module1 -> Module2 -> Module3 -> Module4 -> VM Main Output Jack (1L)

Get yourself some pieces of paper with input voltages at T=1, T=2, T=3, T=4, T=5, T=6, T=7.
Now, feed these voltages through the cables and modules according to the instructions provided above.
Do the cable value transfers in any order you want. Do the module ProcessSample() calls in any order you want.
You will find that the same value ends up at the Audio Output Jack after the same delay every time you 'run' it.

The takeaway is:

1. If the cable transfers are all carried out as one atomic 'batch' AND
2. All input jack summing is carried out in one atomic 'batch' AND
3. All the module ProcessSample() calls are carried out as one atomic 'batch' THEN

<DRUMROLL>

You don't have to worry about the order of execution of the individual cables, summing or modules.
______________________
Dome Music Technologies
User avatar
utdgrant
Posts: 530
Joined: Wed Apr 07, 2021 8:58 am
Location: Scotland
Contact:

Re: VM Execution Order

Post by utdgrant »

I introduced the ACE Delay module so that you could accurately recombine signals from the same source time slice, if they had propagated down multiple module chains with different lengths.
CubeRootOfTen.png
CubeRootOfTen.png (13.19 KiB) Viewed 1787 times
It can also be a useful module for ensuring you don't get race conditions with logic edges and propagation delays through latches, boolean modules, etc. And in situations where you want to set values, start various processes in a specific order.
______________________
Dome Music Technologies
ColinP
Posts: 935
Joined: Mon Aug 03, 2020 7:46 pm

Re: VM Execution Order

Post by ColinP »

It took me a few minutes of head scratching to figure out why the output from the S&H would be approximately 2.15443 volts.

Not the example I would have chosen, but an ingenious demonstration.

Although unavoidable, propagation delay can be a real pain. Yes it's possible to compensate with a module such as yours but your average user is unlikely to tally propagation delays by counting the number of modules that various signals pass through. It's not the headspace people exploring complex patches want to side step into when they are focused on the music and/or the sound design.

I ended up using a fixed 10 sample delay built in to various modules where race conditions were an obvious risk.

This doesn't fix all issues of course but has the benefit of being transparent so that most of the time most users will never even realise that any problem existed.
User avatar
utdgrant
Posts: 530
Joined: Wed Apr 07, 2021 8:58 am
Location: Scotland
Contact:

Re: VM Execution Order

Post by utdgrant »

ColinP wrote: Fri May 13, 2022 1:20 pm Yes it's possible to compensate with a module such as yours but your average user is unlikely to tally propagation delays by counting the number of modules that various signals pass through. It's not the headspace people exploring complex patches want to side step into when they are focused on the music and/or the sound design.
That was always going to be a big risk with making ACE available for sale.
It was definitely a case of developing to 'scratch an itch' for me, and me alone. I got quite obsessed about getting results as accurate as possible, hence the inclusion of a module for propagation delay compensation. These are the things that keep me awake at night! :geek:

It was always a bit 'out there', which is why the 'ACE Sucks' video was only partially 'tongue-in-cheek', and more of a genuine warning. :lol:
______________________
Dome Music Technologies
Post Reply

Return to “Module Designer”