1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
Execution in `alv` is split into two phases - *evaltime* and *runtime*.
At *evaltime*, that is whenever there is change to the source code, `alv`
behaves similar to a Lisp. But once one such *eval cycle* has executed,
*runtime* starts, and `alv` behaves like a dataflow system like
[PureData][pd], [Max/MSP][max] or [vvvv][vvvv].
Every alive expression returns a *stream* of values. Whenever an input to an
operator changes, the operator (may) update and respond with a change to its
output as well. To see this in action, we need to start with a changing value.
Number literals like `1` and `2`, are *evaltime constant*, which means simply
that they will never update. Since all inputs to our [math/+][] operator are
*evaltime constant*, the result is constant as well. To get some *runtime*
activity, we have to introduce a side-effect input from somewhere outside the
system.
The [time/][] module contains a number of operators whose outputs update
over time. Lets take a look at [time/tick][]:
(import* time)
(trace (tick 1))
This will print a series of numbers, incrementing by 1 every second. The
parameter to [time/tick][] controls how quickly it counts - try changing it to
`0.5` or `2`. As you can see, we can change [time/tick][] *while it is
running*, but it doesn't lose track of where it was!
All of the other things we learned above apply to streams of values as well -
we can use [def][] to store them in the scope, transform them using the ops
from the [math/][] module and so on:
(import* time math)
(def tik (tick 0.25))
(trace (/ tik 4))
Note that if you leave the [time/tick][]'s *tag* in place when you move it into
the [def][] expression, it will keep on running steadily even then.
[pd]: http://puredata.info/
[max]: https://cycling74.com/products/max
[vvvv]: https://vvvv.org/
|
