>On Sun, 2007-04-01 at 15:09 +0200, Julian Rohrhuber wrote:
>> In SuperCollider, both patterns and UGens are purely functional
>> higher order constructions. The whole purpose of JITLib is to allow
>> to impose changes on those structures that map in a meaningful way to
>> their extension (calculation process or sound, dependent on the
>> perspective). Depending on the underlying model, this mapping may
>> vary, but the assumption of "immediacy" is not valid when the model
>> of time is an abstract / structural one. Pattern proxies generate
>> coroutines that can be modified even if they do not return. Node
>> proxies abstract from buses and allow to refactor synthesis graphs on
>> the fly, so that parts of them can be exchanged. All proxies abstract
>> from evaluation order as far as possible, and provide meaningful
>> "empty" values. For me, the problem you describe has been the source
>> of the idea of live coding in a way.
>
>Ok, I've now reread the Algorithms today paper[1] and see that you have
>been here before with Alberto and Renate.
>
>I guess I didn't see the significance of this the first read, as
>feedback.pl has a simple approach to live coding and time. There is one
>method that is called once every beat. The method does something
>depending on the number of beats since start up. Different instances of
>feedback.pl sync together by delaying start up time under instruction of
>a central time keeping process. Code replacements to the method (and
>those its calls) are enacted by doing reinterpretation between beats.
>
>This seems a reasonable approach to me, the code decides what to do by
>looking at a clock. Smooth transitions (or otherwise) may then be
>handled by the livecoder, just by making lots of small changes towards a
>goal rather than big ones.
yes, I think this is one good live coding paradigm - which we should
give a name. Would it be reasonable to call it discrete time-mapping?
(a variant may be called time-warping if appropriate)
>
>I built in a way for messages to be passed between feedback.pl
>processes, but never used them since. It at first seemed obvious to
>assume that symbolic interactions between musical elements must happen
>in the code, in order for interesting music to be made. It seems though
>that these interactions happen in human perception, and there is no need
>to make them explicit in the code.
this is an interesting point. And an experience that may contribute
to what makes live coding different from a-life.
> (Well, there is no need, but of
>course it may still be desirable for emergent effects and so on that can
>result from interacting processes.)
>
>In pure functional programming though, it seems to make less sense to
>have functions that just take a timestamp as input, and not take
>advantage of for example lazy evaluation. I think your answer with
>jitlib is to have a pure functions that are modified by an imperative
>process.
in a way, yes. What you have in sc is stateless graphs that create
stateful streams. Proxies implement a semantics of what a change in
the stateless graph means for the streams. This change can be a
change by a code modification or by a program that creates the new
state. Such a program can be composed of proxies, too, of course.
>
>I think monadic programming could provide a different answer, but I'm
>struggling here... I think it would involve having a pure functional
>program that would take edits as input and audio samples as output. The
>edits would describe removal, insertion and replacement of pure
>functions within a synthesis graph. Somehow idempotence would be
>preserved.
currently I'm also struggling with a good way to describe textual
changes. If you know a simple good solution for a diff system, I'd be
interested.
>
>The connections between the functions within the synthesis graph is
>where the monadic stuff would lie. These connections would handle
>modification of the graph (including creating new connections when
>inserting a function), as well as holding state for that connection.
>That state would include enough historical context for a function,
>whether newly modified or not, to be able to decide what to do next.
>
>Maybe some real haskell programmers can clear up my thinking here...
I'm interested what you find out. I like Haskell (from looking at it)
and it would be good to know how such things work in static type
systems.
>
>alex
>
>[1] http://akustik.hfbk.net/publications/AlgorithmsToday.pdf
--
.
Received on Sun Apr 01 2007 - 19:57:52 BST