@neauoire I mean this is how it currently works, each thread has a pointer to the ram, but they have to have their own stack if execution is going to be multi-threaded
we *could* create a copy of the stacks when the audio vector is called, but this doesn't solve anything, it will still be subject to race conditions and unpredictable behaviour
@bd nono, I don't want to create a copy of the stack..
Like, I mean, I think we should create a new Uxn for the thread, instead of shoving the audio stacks into the main uxn instance that's evaluating the program.