[[k.0_lab]] Hacklabs -- All Problems of Notation Will be Solved by the Masses (7mo parrafo)

[alejo duque]

On Feb 16, 2009, at 7:22 AM, Andres Burbano wrote:

> Aunque inicialmente el "livecoding" se ha desarrollado como una  
> forma de música en vivo no se limita a ello. Fluxus de David  
> Griffith y PacketForth de Tom Schouten son herramientas para la  
> creación de obras visuales, el primero basado en un motor de  
> gráficos 3D y el segundo es un sistema de procesamiento de vídeo.  
> [12] Algunos de los instrumentos existentes, tales como  
> SuperCollider, Chuck y Pure Data también se han utilizado para  
> trabajos "livecoding". [13] De hecho, cualquier lenguaje de  
> programación o herramienta que pueda ejecutar código en directo se  
> puede utilizar para "livecoding". El concepto se ha ampliado también  
> a otras formas de trabajo. Social Versioning System (SVS) permite  
> crear juegos de simulación multiusuario para ser "codificados" en  
> vivo, distribuyendo  el nuevo código  entre los jugadores es como un  
> juego evoluciona. [14]  El Life Coding de Ap es un performance a  
> gran escala que combina la escritura de software, circuit bending ?  
> y presentaciones tipo conferencia [15].


por comentar algo que me interesa del parrafo 4, el concepto de SVS,  
desafortunadamente el proyecto que lo ejemplifica es confuso y dificil  
de implementar.. es decir requiere un nivel alto de conocimiento para  
ponerlo a rodar.... ademas de un interes particular en jugar el juego.

con el proyecto un/loquer empezamos a usar un sistema de revision de  
contenidos, no como lo usaria un coder, o programador, sino como lo  
usaria una persona que toma notas de manera electronica y las quiere  
compartir con un grupo de manera que si alguien hace una edicion o  
cambio esta se refleja en los documentos locales que hacen las veces  
de clones. El sistema que usamos se llama GIT, desarrollado por Linus  
Torvalds hace unos 5 años para controlar el desarrollo del kernel de  
linux. Una de las cosas mas interesantes es que no es centralizado y  
se pueden manera ramas (branches).

el ejemplo basico de lo que hemos hecho esta aca, creo que somos ahora  
5 personas compartiendo un directorio local a traves de GIT:
http://github.com/son0p/un-loquer/tree/master

todo lo que se ve ahi se puede copiar al disco duro local, donde el  
usuario podra hacer cambios que podran crear nuevas ramas o seran  
simplemente ediciones a lo que ya existe, uno puede editar cuando esta  
offline y simplemente actualiza cuando se conecta, de esta manera se  
suben y bajan los cambios recientes. no sobra decir que se guarda un  
historial y en cualquier momento es posible regresar a una revision  
anterior.

en el terreno del arte y (los nuevos) media: me recuerda un poco el  
proyecto life-sharing, aunque este fuera de una sola via, del artista  
al "gran publico":
http://www.0100101110101101.org/home/life_sharing/index.html

acerca del termino circuit bending pues creo que lo mejor es no forzar  
(circuitos) traducciones, yo lo dejaria en circuit bending, una  
practica de "mejoramiento" de aparatos electronicos musicales  
(generalmente que de esos que usan pilas) a traves de la intervecion  
de sus circuitos añadiendo potenciometors, resistencias, etc. para  
sacar nuevos sonidos.

si en algun momento quisieramos dar el paso de traducir a hacer  
podriamos tal vez darnos a la tares del uso, por ejemplo, de Packet  
Forth, un lenguage para manipular video realizado por quien desarrollo  
los objetos [pdp] en puredata Tom Schouten. No hay mucha gente usando  
pf ahora, pero esta incluido en el pure:dyne por si a alguien le  
interesa.

/a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://music.columbia.edu/pipermail/dorkbot-kolab/attachments/20090216/f2910e67/attachment.html