Sometimes when I run the subleq hello world example it finishes without printing hello world...

Currently we are unfortunately limited by the browser throttling of setTimeout to 4ms delays upon repeated chained calls to it (which we have all strung together with awaits and promises.)

Could we eliminate the need for setTimeout by making it entirely callback based somehow? i.e. when a data packet is received (outputs of the graph are ready to be used), we call a function that computes the new input values. Not sure if this would allow us to fix this or not; look into it.

My other idea is to simply move all the logic into the AudioWorklet itself and just like, feed the worklet with a clock signal (a buffer source w/ looping enabled) and then let the worklet provide both the inputs and outputs to the graph via its output and input. Then it would run as fast as the audio graph could be processed in theory? No need for setTimeout?
And then we'd only use the message port for like, UI updating and user input, etc.
Seems plausible...?

For some reason audio contexts need to be started by code triggered by a user event? (i.e. a click) -- ???
My technique of programmatically creating an invisible button and calling .click() on it works inconsistently?

How do we do this?

I wrote out the code to generate a PLA from the .names BLIF command; haven't tested it yet, and it doesn't explicitly handle the special cases of buffers or constants.

But then I got smart and turned them off (I think?) via yosys. As far as I can tell it won't generate them at all now so, should we just remove all code relating to the .names command and be done with it?