towards an artistic OS >

how unix like os not entirely suitable as artistic OS
example of lisp machines.

environmental code -> video/audio as environment for the machine

+ code within the environment - an insertion

1) INTRO:

***brief issues addressed:

- data rather than sound/video - examination of differing
representations of process/information for the machine and the
programmer (DCT, FFT etc)

endodata/ cross/merge of data streams

even q of control data

- not interested in discrete processing/ I/O

- what such representations of data for the machine could be - how
mould/work these representations intrinsic in how represented

vector/chunking/leakage - how we approach the machinic thru that
percieved representation

- towards OS - even if just vm layer on top of any Unix 
(why approach of vm - flexibility, openness and lack of brittleness ?)

reflexive os -> below reflects above without kludges...

- interoperability in terms of artists and coders

***ap / ap projects > development ap01/02 towards 03 (fm01/gdapp/om01)

what is AP?

central notion of environmental code expanded/contracted (example of
such operators) into idea of code-based environment (an OS)

what is an OS?

((nodal methodology))

also how notion of an os as environmental virtual machine layer allows
for addressing of questions of interoperability - hardware issues are
abstracted 

fm01: semi-automated, environment


**[first demo breaks down data/software division in context of a
programmatic presentation [algorithms applied to areas such as walking
- psychogeographic]


***what was ap01? - balletic, modular, contingent networked effects
(examples of hardware modules) but restricted conceptual basis

2) AP02 software:

ap02 is a virtual computer, an organism which runs on top of a host
computer. it mirrors the host machine almost exactly. it possesses a
CPU (Central Processing Unit), memory and can detect all manner of
input and provide a wide range of outputs. however, rather than
running instructions designed for speed and efficiency in
accomplishing a specific task, the ap02 virtual CPU runs a reduced and
abstracted set of instructions. and the programs this CPU runs are not
determined by a user or programmer. ap02 runs software which has been
determined entirely by its environment. in other words, the
environment has written the code which ap02 runs. this environment, a
mirror of the host computer, can consist of audio data from a
microphone or CD, video from a webcam or other input device, all the
information in the files held on the machine and all network data
recieved by the machine and on the local network. each ap02 virtual
machine also communicates with others running across the global
internet. all data is converted from disparate file formats into a
generic format for use by the ap02 system. 

this data is used to construct an initial cell space whose individual
cells will run on the virtual CPU. this cell space is constantly
examined by the software to determine new cell boundaries which
establish the identity of cells as they split and reproduce.

the set of instructions used by these cellular programs running on the
virtual CPU has been carefully chosen to match the needs of the cell
space. it allows for complex computations, reproduction and
communication. the instruction set also allows for great
flexibility. there is no incorrect series of instructions and the
virtual machine cannot crash. communication is conceived here
primarily as primitive self-display. this act is priveleged and cells
which are un-responsive within the environment are swiftly
replaced. the two key instructions used by the cells are say and
listen. listen looks for activity within the machine environment and
inserts this data into the cell body. say operates in reverse,
inserting a portion of the cell body into the environment. this
implies some form of display or a communication with cells running on
remote networked hosts. each ap02 application maintains a list of
internet hosts which are running ap02. as cells communicate remotely,
the application exchanges lists with others and adds new hosts to the
list as they arise. the network grows as applications communicate and
exchange lists. the cell environment expands.

ap02 was conceived in late 2001 and coded with the assistance of artm
baguinski at v2_lab rotterdam and subsequently by myself in
london. ap02 is expressed within three interwoven projects; as
physical self display devices, as a freely available, distributed
networked application, and as a performance-based application
interfacing to a range of hardware modules such as EEG equipment.


3) AP02 DEVELOPMENT AND FUTURE AP03

**[DEMO: ap02: command line channels/viewer/instruction set/mapfile]

1) goes some way towards decentralized model (no central list of IP
addresses) despite client-server model deeply ingrained in code
2) highly flexible -- replace over-determined instruction set with
non-brittle abstraction layer .. to bypass known givens of coding in
pre-determined languages
3) avoids closed data formats -- generic data format .. translators
data/software on level of equivalance

problems in development: 
1) arriving at de-centralized model difficult
2) non-illustrative nature of software (is not software which uses
metaphor to say something --> many question meaning to work)
3) finding ways of doing things that no functional software would need
to do (except perhaps viruses etc) so working very much from scratch
security issues ... determined towards discrete functional, secure
blackboxes

conceptual problems: 
1) still seperation cpu from environment
2) ... input/process/output model rather than a total environment (is
after all an application) ... tho
physical devices maybe resolve this

more about these:

**show IMAGES

physical self-display devices are devices which communicate ever changing
operational codes based on external environmental data. these self-powering
tiny devices are scattered throughout any environment and do not transmit or
relay in any manner useful sensory data to any observer. they can only be
experienced within the (often remote) situation in which they are placed.
the self-reliant operational characteristics of these devices engender
open-ness and expansion in any situation.

the devices are solar powered and have been designed to operate for a
minimum of three years within harsh environments. over this time period the
devices modify their own instruction code, the program they are running, in
response to environmental changes. fragments of code are audibly
communicated between devices which can incorporate and make use of this new
code. each device displays on LCD a segment of its operational code. through
self display and communication these devices are integrated into the
environment.

3) instruction set to large extent based on prior computing models
(turing, van neuman) -- bit instructions, registers, logic.

4) flat cell/memory model

5) inflexible in terms of assignment of environmental channels and
flows of these channels .. how to deal with large amounts of data .. a
language to work with vast data flows (event-based)


**video - mention front ends manipulate underlying ap and other data sources
- earlier gdapp - tying together data sources - kind of matrix operation

+ hardware contollers

4) AP03/fm01 FUTURE AND POSSIBLE APPROACHS TO THESE ISSUES

building on ap02 but multiplying this model .. dissecting it also into
nodal/strata model ... globular/dynamic changing node structure of
connections, of flow and instructions -- total environment, an
operating system which dynamically re-codes itself, is recoded in
operation.

**new**

requirements of such an OS:

modular approach (eg. unix shell)

modular is not opposed to environment (but critique of objects
approach)

environment integrates modular - no seperations/ poor encapsulation
and notion of leakage/strata

layers of abstraction as environment - base layer which mobile, almost
viral code nodes sit upon - open exchange as opposed to
protective/security-based OS model - promiscuity and open discovery
rather than static upload/download or I/O structuring - not dealing
with task in hand -> parallel or distributed model also

introspection and self-display

addressing: question of programming language givens
use of system models against themselves

functional/imperative languages

what we use as basis for architecture and instruction set.

fictional/poetic logic for this new artistic operating system
operating system as it is not a discrete application, rather an
environment

event/data based model

node =  instruction/data/memory [re-defined in no seperation - in flow
what an instruction would be]
        set of codes (macro)/interpretation/meta-language
        full node space contained // self-reference                                               
        linkage/strength of path = pathway or route // event-flow                             
        migrating network nodes [node as instruction point / node as
machine]                                                 
	neural excitation and barrier models ->                                      
- barrier methods of communication (of an intensity rather than of data?)       
- flow/inhibit/excite/attract/repel. internode comms=model abstracted for       
all network comms                                                               

how far could go with these ideas ... main idea OS is expansion of
layers of abstraction -- define new languages on each layer at same
time aware of geology and physicality of these layers

users become programmers without knowing envisage viral nodes (defined
and as yet to be re-defined) attaching to the user/programmer's operations.

on a very basic level overcoming the heterogenity in terms of
formats, modes of operation and interfaces in favour of a body without
organs of extreme heterogenity 

**GDAPP

how gdapp works 

trying conceptually offload as much work as possible onto nodes - for
example runnernode which executes other nodes - expanded ap-style /
also spawn and reap nodes whiuch deal with other nodes 

mobile code


- what types of node have been implemented and what is
to come ....


5) FM01:

fm01 proposed as first manifestation of ap03 OS approach ->

merged ap03 and fm01 film machine projects as feed into each other

fm01 -> 

semi-automated film scripting and editing environment for the
production of endless cinema (dru, huddersfield)

scripting both senses - user works with environment blah

in research phase, coded DV/firewire + display stuff and embedded
interpreter + collab environment (**cliki) in place 

language oriented:

notion (bootstrapping) of using core language to describe new
functionalities/potentials (rather not a case of functionality but a
steering/moving towards)

(so bulk of fmo1 written in extendible scripting language - extends
itself (both writing itself and by user)

question of language/interpretation stream in relation to
compression/geometry stream

functional aspect to project but also exemplary/impossibility

tight fit of tech + philosophical or conceptual
fit of user-defined languages with machinic imaging

current issues: 

design of core bootstrap language - choice of coding language - total
control (C, assembly) and higher level languages such as Lisp

how interface between two languages/styles of programming is effected

speculative programming -> even notion of coding a language to further
code this core bootstrap language.

data exposure

stream vs. distributed/parallel chunks -> 

question of a parallel model given linearity / stream -> smaller
parallel? cell? chunks?

promiscuous chunks as opposed to streams - chunks search out (notion
of ) scene?s - language at all levels