Re: [livecode] is live coding aiming to audience with particular programming knowledge

From: David Barbour <dmbarbour_at_gmail.com>
Date: Sun, 20 Jan 2013 16:44:10 -0800

On Sun, Jan 20, 2013 at 4:08 PM, Ross Bencina <rossb-lists_at_audiomulch.com>wrote:

>
> the non-left inputs are stateful. They act as memories/storage, something
> I'd forgotten from working with synchronous dataflow for so long.
>
> Perhaps some other distinctions are also helpful:
>
> - feed-forward networks
> - feedback networks
> - networks with access to input history
> - networks with input and output history (state)
> - networks passing discrete messages (or numbers)
> - networks of (or modelling) continuous signals
>
>
An interesting point in the design-space for dataflow systems is to allow
nodes access to *future* inputs, potentially without access to history.
Effectively, one is accessing the buffer of unprocessed future updates,
potentially leveraging speculative evaluation. This avoids formal state
(you can't accumulate information), but is sufficient to handle several use
cases traditionally addressed by state (such as change detection, or
gesture detection). (The tradeoff is latency, allowing the input buffer to
build a little. If you use actual state, you don't need to increase
latency.)

A history of input has nice, robust properties for live programming. In
traditional code, we maintain only state that we need. In live programming,
the state that we need can change as we modify code. That becomes
problematic when we need state that we were not maintaining. A language
that makes it convenient to model most state in terms of cached
computations on history may better serve live programmers.
Received on Mon Jan 21 2013 - 00:44:46 GMT

This archive was generated by hypermail 2.4.0 : Sun Aug 20 2023 - 16:02:23 BST