[<<][meta][>>][..]
Wed Apr 3 08:52:54 EDT 2013

Trouble

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
mechanism.

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
generators.

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.

Rationale:
- Allow for if() statements
- Optimize these in case they express time-dependence
- Unify all conditional jumps?

Arguments against:
- Piecewize operation doesn't work well for other interpretations.



[Reply][About]
[<<][meta][>>][..]