Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
sutchwon_notes [2007-07-04 08:42] – external edit 127.0.0.1sutchwon_notes [2015-11-05 12:43] (current) – maja
Line 1: Line 1:
  
- +=====sutchwon notes=====
-====sutchwon notes====+
  
 network crab fishing workshop network crab fishing workshop
Line 8: Line 7:
  
  
- +==== introduction ====
- +
- +
-introduction+
  
 these notes are a brief overview from a series of discussions, tangents and diversions which was informally based around the issues involved in using computer networks as an integral part of collaborative projects. Most of the discussion focused around the mechanisms + implementation issues on a quite general level. mostly questions involving 'how' rather than 'what', 'why', 'when' or 'where' were covered. these notes are a brief overview from a series of discussions, tangents and diversions which was informally based around the issues involved in using computer networks as an integral part of collaborative projects. Most of the discussion focused around the mechanisms + implementation issues on a quite general level. mostly questions involving 'how' rather than 'what', 'why', 'when' or 'where' were covered.
  
  
 +==== issues of multiplicit control of media output ====
  
-issues of multiplicit control of media output 
  
 looking at various ways in which multiple users could affect the output, or contribute to the output of a single data stream. whether in fact it makes sense to think of this as a stream, or as a larger whole, in which users/collaborators are affecting a part of, which may feedback into the rest of the system in various ways. having the possibility for many ppl to affect a system in such a way raises a range of issues in presenting an interface to the system, collecting data + resolving the effects of the data. looking at various ways in which multiple users could affect the output, or contribute to the output of a single data stream. whether in fact it makes sense to think of this as a stream, or as a larger whole, in which users/collaborators are affecting a part of, which may feedback into the rest of the system in various ways. having the possibility for many ppl to affect a system in such a way raises a range of issues in presenting an interface to the system, collecting data + resolving the effects of the data.
Line 23: Line 19:
  
  
-physics of consistent worlds separated in causal time+==== physics of consistent worlds separated in causal time ==== 
  
 if parts of a causally related system require data about what is happening in other parts of the system in order to develop transitions, intermediate states (in which the information is assumed, but not available) can be calculated to give the impression of continuity. however, if there are sufficiently large gaps between events, this intermediate state can take on a life of its own. the longer the gap, the more divergent the intermediate state becomes. this is applicable with high speed networked games, where the simulated world should be consistent for all players, in which critical action can take place in the same timeframe as 'lag time'. the problem of creating a seemingly continuous experience with discontinuous flow of information. pseudo divergent realities, collapsing wave functions. if parts of a causally related system require data about what is happening in other parts of the system in order to develop transitions, intermediate states (in which the information is assumed, but not available) can be calculated to give the impression of continuity. however, if there are sufficiently large gaps between events, this intermediate state can take on a life of its own. the longer the gap, the more divergent the intermediate state becomes. this is applicable with high speed networked games, where the simulated world should be consistent for all players, in which critical action can take place in the same timeframe as 'lag time'. the problem of creating a seemingly continuous experience with discontinuous flow of information. pseudo divergent realities, collapsing wave functions.
Line 29: Line 26:
  
  
-timeflow/causality/2d-time+==== timeflow/causality/2d-time ==== 
  
 this lead to a brief, yet convoluted discussion on the nature of time, causality and how to represent discontinuous (and/or inconsistent) time embedded in a single time dimension. most of these questions are open ended and not particulary intuitive, but could lead to some novel representations of dataflow, interaction + influence which would extend current network visualisation + sonification techniques. this lead to a brief, yet convoluted discussion on the nature of time, causality and how to represent discontinuous (and/or inconsistent) time embedded in a single time dimension. most of these questions are open ended and not particulary intuitive, but could lead to some novel representations of dataflow, interaction + influence which would extend current network visualisation + sonification techniques.
Line 35: Line 33:
  
  
-osmic/hypertime/version control+==== osmic/hypertime/version control ==== 
  
 the version control + extended 'undo' features as presented in osmic (part of the xanadu system) provide an example of multilinear structure for tracking changes over linear time. the version control + extended 'undo' features as presented in osmic (part of the xanadu system) provide an example of multilinear structure for tracking changes over linear time.
Line 41: Line 40:
  
  
-audio/video control/influence dataflow confluence+==== audio/video control/influence dataflow confluence ==== 
  
 treating all data as indistinguishable, using audio data as video, audio to control graphics, control rates as audio, etc. the main problem is one of scale, data-density or frequency. the creative decisions on how to translate or arrange influences is left to the author(s). treating all data as indistinguishable, using audio data as video, audio to control graphics, control rates as audio, etc. the main problem is one of scale, data-density or frequency. the creative decisions on how to translate or arrange influences is left to the author(s).
Line 49: Line 49:
  
  
-appropriateness of mappings/translations+==== appropriateness of mappings/translations ==== 
  
 discussing various ways of representing data in a domain other than the one it was 'intended' for. algorithmic transmogrification, human perception and "see what happens if..." seem to be the common threads/mechanisms. even though a seemingly obvious point of distinction, we did return to it several times, and it does mark definite differences in approach, not only for us, but in a wider context also. discussions about network topology + representations of network activity covered existing systems + possible future developments. discussing various ways of representing data in a domain other than the one it was 'intended' for. algorithmic transmogrification, human perception and "see what happens if..." seem to be the common threads/mechanisms. even though a seemingly obvious point of distinction, we did return to it several times, and it does mark definite differences in approach, not only for us, but in a wider context also. discussions about network topology + representations of network activity covered existing systems + possible future developments.
Line 55: Line 56:
  
  
-evolutionary models + learning+==== evolutionary models + learning ==== 
  
 the role of algorithms which develop their behaviours over time and in relation to particular thruput was suggested, but not developed extensively. it seems there is a range of applications which could benefit from such an approach. one specific application was the modelling of the complexity of an arbitrary data set, with minimum required dimensionality. an instrument would then be generated with the same control dimensionality) to play the data. the role of algorithms which develop their behaviours over time and in relation to particular thruput was suggested, but not developed extensively. it seems there is a range of applications which could benefit from such an approach. one specific application was the modelling of the complexity of an arbitrary data set, with minimum required dimensionality. an instrument would then be generated with the same control dimensionality) to play the data.
Line 61: Line 63:
  
  
-phenotype selection of sound (interchangability)+==== phenotype selection of sound (interchangability) ==== 
  
 the problems of describing + selecting sounds in an evolutionary system were discussed briefly, along with extending existing systems (tierra + mutagen) to produce sound output in parallel or instead of their present output. the problems of describing + selecting sounds in an evolutionary system were discussed briefly, along with extending existing systems (tierra + mutagen) to produce sound output in parallel or instead of their present output.
  
  
-separating interface + rendering using OSC+==== separating interface + rendering using OSC ==== 
  
 the most successful method for developing distributed instruments (which can be used for performance, or to automatically generate output) so far seems to be using the [[Open Sound Control]] protocol to pass data between separate machines running max/msp and/or pd patches (programmes). this also enable the control interface to be separated from the computationaly intensive rendering of sound + image data. naturally, anything which works over a local tcp network, can just as easily be used over a wide area network such as the internet. the most successful method for developing distributed instruments (which can be used for performance, or to automatically generate output) so far seems to be using the [[Open Sound Control]] protocol to pass data between separate machines running max/msp and/or pd patches (programmes). this also enable the control interface to be separated from the computationaly intensive rendering of sound + image data. naturally, anything which works over a local tcp network, can just as easily be used over a wide area network such as the internet.
Line 72: Line 76:
  
  
-streaming over local networks to utilize distributed peripherals+==== streaming over local networks to utilize distributed peripherals ==== 
  
 this technique of separating the 'interface' from the 'rendering' opens a range of possibilities on local networks for utilising peripherals attached to another machine on the network (eg. video cards, multichannel audio outputs, printers etc). this technique of separating the 'interface' from the 'rendering' opens a range of possibilities on local networks for utilising peripherals attached to another machine on the network (eg. video cards, multichannel audio outputs, printers etc).
Line 78: Line 83:
  
  
-midi is obsolete for network communication.+==== MIDI is obsolete for network communication. ==== 
  
 the resolution and unreliability of midi devices lead to a consensus that it is a protocol best left to musical instruments (as intended). the problems tend to increase proportionally with the number of machines connected using midi. (no exact relationship has been formulated) the resolution and unreliability of midi devices lead to a consensus that it is a protocol best left to musical instruments (as intended). the problems tend to increase proportionally with the number of machines connected using midi. (no exact relationship has been formulated)
Line 84: Line 90:
  
  
-noise diversion/thread+==== noise diversion/thread ==== 
  
 in discussion of using feedback + noise to determine the nature of an unknown system, the subject of process physics came up. in brief, process physics aims to understand the nature of reality by modelling processes. one of the central concepts in this modelling is the use of self referential noise to model a pregeometric universe. while essentially a diversion, this discussion hilighted some of the differences between designed system, and growing systems. in discussion of using feedback + noise to determine the nature of an unknown system, the subject of process physics came up. in brief, process physics aims to understand the nature of reality by modelling processes. one of the central concepts in this modelling is the use of self referential noise to model a pregeometric universe. while essentially a diversion, this discussion hilighted some of the differences between designed system, and growing systems.
Line 90: Line 97:
  
  
-performance/presentation systems+==== performance/presentation systems ==== 
  
 we briefly discussed several systems for distributed performances, or networked based collaboration. our focus was on realtime, audiovisual systems, which are aimed at performance, however there are a range of tools used for asynchronous collaboration which were not mentioned, and are beyond the scope of most of the systems discussed. we briefly discussed several systems for distributed performances, or networked based collaboration. our focus was on realtime, audiovisual systems, which are aimed at performance, however there are a range of tools used for asynchronous collaboration which were not mentioned, and are beyond the scope of most of the systems discussed.
Line 96: Line 104:
 open sound control; developed at cnmat which facilities the exchange of data over a udp network. optionally timecoded messages, can be sent within a heirarchic address space, to multiple recipients. open sound control; developed at cnmat which facilities the exchange of data over a udp network. optionally timecoded messages, can be sent within a heirarchic address space, to multiple recipients.
  
-pd; graphical programming language. +  * pd; graphical programming language. 
- +  * max/msp; graphical programming language based on pd. 
-max/msp; graphical programming language based on pd. +  * kromozone performance system; built within max for specific types of performances. 
- +  * keystroke "cross media synthesizer"; a system to enable media elements (or range of data formats) to influence each other, or be influenced over a tcp network. still in development, runs on macintosh only, but in principle extendible. 
-kromozone performance system; built within max for specific types of performances. +  * the matrix; hardware solution for connecting a range of machines using different protocols, developed by future lab (aec). in development?
- +
-keystroke "cross media synthesizer"; a system to enable media elements (or range of data formats) to influence each other, or be influenced over a tcp network. still in development, runs on macintosh only, but in principle extendible. +
- +
-the matrix; hardware solution for connecting a range of machines using different protocols, developed by future lab (aec). in development?+
  
 general discussion on the lack of adaptable systems, the range of solutions to specific problems, the ability or difficulty to generalize these systems. general discussion on the lack of adaptable systems, the range of solutions to specific problems, the ability or difficulty to generalize these systems.
Line 110: Line 114:
  
  
-sutChwon discussion+==== sutChwon discussion ==== 
  
 a proposal for a system of interconnection + interoperability with a range of networked subsystems was discussed. some specific developments were proposed, one was the idea of using protocol dependency trees which would facilitate graceful degradation. another was to extend the ideas of class inheritance (from the object oriented programming paradigm) into a content description or property inheritance structure. a proposal for a system of interconnection + interoperability with a range of networked subsystems was discussed. some specific developments were proposed, one was the idea of using protocol dependency trees which would facilitate graceful degradation. another was to extend the ideas of class inheritance (from the object oriented programming paradigm) into a content description or property inheritance structure.
Line 118: Line 123:
  
  
-overview/summary+==== overview/summary ==== 
  
  
Line 151: Line 157:
  
 links links
 +  * [[process physics]]
 +  * preprint archive papers
  
-process physics 
  
-preprint archive papers 
  
 +[[sutChwon]] Article from TimesUp Newsletter >> http://phl.cx/sutChwon/ctl_article.txt 
  
  
-sutChwon 
  
-Article from TimesUp Newsletter http://phl.cx/sutChwon/ctl_article.txt +==== performance/presentation systems ====
  
- 
- 
-performance/presentation systems 
  
 max/msp http://www.cycling74.com  max/msp http://www.cycling74.com 
Line 180: Line 183:
  
  
-network topology+==== network topology ==== 
  
 http://www.cs.cornell.edu/boom/1999/projects/Network%20Topology/topology.html  http://www.cs.cornell.edu/boom/1999/projects/Network%20Topology/topology.html 
Line 190: Line 194:
  
  
-rfcs+==== rfcs ==== 
  
 http://www.rfc-editor.org/repositories.html  http://www.rfc-editor.org/repositories.html 
Line 204: Line 209:
  
  
-Content Negotiation+==== Content Negotiation ==== 
  
 conneg Working Group http://www.imc.org/ietf-medfree/  conneg Working Group http://www.imc.org/ietf-medfree/ 
Line 214: Line 220:
 ---- ----
  
-comments to include from XDV weblog+==== comments to include from XDV weblog ==== 
  
 http://xdv.org/weblog/975069610/index_html http://xdv.org/weblog/975069610/index_html
Line 299: Line 306:
 [[SukcSpit]] [[SukcSpit]]
  
 +[[lagging behind skipping ahead]]
  
 -- needs serious refactoring -- needs serious refactoring
 +
 +
 +----
 +
 +
 +
 +====areas of interest====
 +
 +===content negotiation===
 +
 +
 +===protocol negotiation===
 +
 +protocol sketching >> http://etiquette.sourceforge.net/)
 +
 +
 +===service discovery===
 +
 +MediaSock http://mediasock.org/
 +
 +Service Location Protocol http://www.openslp.org/ 
 +
 +RFC:2608 - Service Location Protocol, Version 2 
 +
 +RFC:2609 - Service Templates and Service Schemes
 +
 +RFC:2610 - DHCP Options for Service Location Protocol
 +
 +RFC:2614 - An API for Service Location Protocol
 +
 +===ad-hoc networking===
 +
 +  * [[ZeroConf]] (aka rendezvous) will shake hands with the unconfigured
 +  * AODV (Adhoc On Demand Distance Vector routing) http://moment.cs.ucsb.edu/AODV/aodv.html
 +
 +===ad-hoc data exchange===
 +
 +ubf (a and b) is a language for transporting and describing complex data structures across a network. http://www.sics.se/~joe/ubf/site/home.html
 +
 +===media sharing===
 +
 +  * [[sukcSpit]] / / [[gulliBloon]]
 +  * RFC:3080 - The Blocks Extensible Exchange Protocol (BEEP)
 +
 +
  
  
  • sutchwon_notes.txt
  • Last modified: 2015-11-05 12:43
  • by maja