state_table in progmem vs. trigger cycling 8 times #90
Description
I can only think of two ways to introduce some non-determinism (eg. branching on random number) without also introducing a large number of extra event types. The first way is to push events to a randomly selected connector or connector slot (decipherable by reading source code). The second way, which I'll discuss further, is to mutate the state_table at runtime.
However, the state_table must be stored in progmem, and as such my understanding is that it's read-only. To make it writable by not storing it in progme4m, that would require redefining the read_state( addr ) macro globally. Sadly, it cannot be redefined to call a method on the Machine itself (which could have instance- or class-specific logic), without breaking Atm_step.cpp, which also calls read_state( from outside Machine. So, unfortunately it doesn't seem possible to have some Machine's state_table in progmem, and some on the heap, you have to pick one or the other globally.
I also see that trigger(int) will call cycle() eight times regardless of whether there is a valid transition for that event or not. It seems like the only reason to do that would be in the case of a mutable state_table which event()/loop() code can mutate at runtime? In that case, it seems like that should not be the default behavior since read_state will always return the same output no matter how many times cycle is called?