colegas y seguimos siguiendo como dicen por ahi ... bien me di a la tarea de traducir 3 parrafos, los faltantes para completar el primer capitilo... es decir los dos que faltaban en medio y el ultimo:
Los aspectos claves del código en vivo que encarnan los principios del FLOSS son la manera como la re escritura continua del código en sí se vuelve un modo primario de producción artística y la presentación de la "obra" en sí misma como un trabajo de código abierto y mutable mas que un artefacto definido y estático. Esto no solo distingue el código en vivo de muchas formas de de arte y música no digital en las cuales un trabajo existe como un artefacto o partitura que es fijo e inalterable sino que además se aleja de los paradigmas dominantes de los trabajos con nuevos medios. La definición de Manovich de "nuevos medios" se enfoca en el modelo de una interface que visualiza cambios de datos (como estadísticas del mercado de acciones, sistemas de agua o análisis de redes) o da forma predefinida de acceso al usuario e interacción con una fuente dada (como una base de datos un video, etc.). A diferencia de la mayoría del arte no digital así como del arte con nuevos medios que está presente exclusivamente como un bien para ser consumido, el código en vivo hace accesible a otros sus materiales y prácticas de producción. El código en vivo enfatiza el principio del FLOSS de la producción de un código base como una forma de producción que es en sí misma "viva" y en vivo, que posibilita la producción de otros para sus propios propósitos. Dicha "posibilidad la producción de los otros" es frecuentemente continuada por fuera del performance no sólo en el modo de la distribución FLOSS sino también en el uso consiente para talleres como modo de presentar proyectos, enseñando las habilidades utilizadas en la creación. Este aspecto pedagógico se extiende dentro de la importancia dada a los encuentros técnicos y a los talleres de desarrollo en festivales gestionados por artistas como Piksel y MAKEART, o grupos como Dorkbot y OpenLab y dentro de la creación de plataformas de diseminación, proyectos como pure:dyne y los manuales FLOSS. Estas actividades no son marginales a la práctica de producción de su arte sino mas bien son vistos por varios artistas como un elemento central en su práctica. El código en vivo no es la única o exclusiva práctica realizada por quienes están involucrados con este tipo de proyectos. Lo que todos quienes lo practican tienen en común es el compromiso a la noción más amplia de código en vivo como un modo de producción en el sentido descrito anteriormente. Esto también cuenta dentro de las prácticas más "pedagógicas" como en las prácticas artísticas que dentro del FLOSS se encuentra con otros aspectos del mundo del FLOSS, específicamente en las prácticas de compromiso social y política como los hacklabs y los hackmeets. *** El código en vivo es una de las manifestaciones artísticas emblemáticas del FLOSS y los hacklabs se han convertido en su mas emblemática forma social. Aunque los dos pueden no tener trayectorias idénticas ambos se complementan de alguna manera y de pisan uno al otro en muchas formas significativas, el asunto central que ellos comparten es que "posibilitan la producción de los otros". Este es un asunto de distribución, no solo al nivel de la distribución de un producto, sino en la manera como un fragmento de código puede ser distribuido por ejemplo, pero a nivel práctico. La práctica en sí es intrínsecamente distributiva, ya que integra la distribución del conocimiento de cómo producir en lo que se produce. Mientras esto permite posibilidades de producción colaborativa, esto puede ser visto como algo distinto a la colaboración en si. Una práctica de colaboración que canaliza la producción de muchos en un objetivo único, con lo que la dirección de la disposición de su trabajo, es una práctica que permite la disposición de distribución de la mano de obra de los otros bajo su propia dirección. Esto es facilitado en la salida de la producción como notación, como código que no sólo crea un producto, sino que entra en una vida activa más allá de su aplicación inicial. Ya los reviso con mas calma y los subo a el g.docs y al wiki. Pero creo que el asunto empieza a tomar forma. Un abrazo grande conpadres! Andres Burbano 2009/2/19 Andres Burbano <[email protected]> > que bien, buen movimiento, > > alejo, gracias por los comentarios, lo de los circuitos lo corregiré de > entrada en la próxima sentada. seria bien interesante darle una visita al > Packet Forth, de pronto hacemos algo de video compartido, tienes algo mas de > info? > > juan, buena idea lo del documento abierto, seguro va a ser util para ir re > trabajando. > > un abrazo y en breve aparezco con mas trabajo. > > suerte > > andres burbano > > > > 2009/2/16 juan <[email protected]> > > He puesto en un documento on-line con lo que va. Me es más fácil ir >> revisando todo en conjunto y así ver por donde va la cosa y que falta. >> >> Lo he colgado en Google Docs (por rapidez).... Esta abierto y cualquiera >> lo puede modificar. De pronto es útil de algún modo para alguno. >> >> http://docs.google.com/Doc?id=dgxdh6qj_5dw6qhxcn&invite=fqg8ctr >> >> -.,-.,-----------.-.-,- >> >> Un amigo de Colonia (Julian Rohrhuber) ha creado una libreria para >> SuperCollider con la que han tratado de "unir la semantica de los canales de >> chat con la creación de código live en vivo", digamos que en la misma linea >> del "Social Versioning System (SVS). A quien le interese aquí un PDF >> (Letras robas y personas distribuidas) en ingles. >> >> http://wertlos.org/articles/Purloined_letters.pdf >> >> -.,-.,,,,,,,,,,,,,,,,,, >> >> -juan- >> >> P.D. Lo de Stockhausen es pensando otras variaciones de "Notación".... >> >> 2009/2/16 alejo duque <[email protected]> >> >>> 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 >>> >>> >>> ......dorkbot: gente haciendo cosas extrañas con o sin >>> electricidad.......http://dorkbot.org............... >>> >> >> >> >> ......dorkbot: gente haciendo cosas extrañas con o sin electricidad....... >> http://dorkbot.org............... >> > > > > -- > andres burbano > -- andres burbano
......dorkbot: gente haciendo cosas extrañas con o sin electricidad.......http://dorkbot.org...............
