Hey all,
Really interesting discussion! We're in the land of rigged demos, but
I think we can have a lot of actual fun with this stuff in music/video
DSLs, as ixilang shows.
Lets not forget spreadsheets, where you see the data 'in front of' the
code, and can press a button to recalculate the values.
feedback.pl was called that because the process could change its own
sourcecode. I did use this to change variable definitions, although
found it easier to store and read data in code comments, which worked
as visualisation. The code did really feel live then, and the code
containing its process state was just useful. It was good fun for
making semi-autonomous generative music, but it was not a practical
approach for the from-scratch live coding performances I wanted to do.
Otherwise this ad-hoc approach could be worth exploring, it gets
around the problem with generalising.. I should try and find all that
code again and make some videos of it.
Another approach I've tried is visualising data flows between
functions, inspired by the reactable:
http://yaxu.org/colourful-texture/
Again not super practical so far, but I think there's something there.
(It's not really dataflow, but pure functions of events over time
which are rendered).
Cheeers
alex
--
Read the whole topic here: livecode:
http://lurk.org/r/topic/5rUCQaaTwspEQZ5zDFiNKp
To leave livecode, email livecode_at_group.lurk.org with the following email subject: unsubscribe
Received on Sun Feb 01 2015 - 08:53:05 GMT