Wed Apr 3 08:52:54 EDT 2013
So, maybe the trouble that comes from allowing this criss-crossing
between setup and update just isn't worth it. Doing it implicitly
like that also makes things quite hard to test..
Let's kick it out, and provide a more highlevel sample-rate joining
Basically, parameters should be converted to streams only at the top
level, and in an explicit way.
Parameters should be converted to time-parameterized state machine
A low-rate parameter results in:
- Extra state for the update routine
- Extra constants for the update routine
What I want:
- To keep the siso state machine as the basic abstraction
- Combine 2 siso state machines for interpolation
So instead of solving this at the language level, it should be solved
at a level above that.
Problem: state resets don't fit this.
This is a recurring issue in thinking about this ...
I just can't wrap my head around it.
The simplest thing to do really is to make the whole thing explict.
Anything that runs inside a `setup' routine is exectued at t=0. The
default behavior is the identity function for state fetches.
This allows simple unrolling to be used.
Let's give it a try.
- Allow for if() statements
- Optimize these in case they express time-dependence
- Unify all conditional jumps?
- Piecewize operation doesn't work well for other interpretations.