new pages

This commit is contained in:
sejo 2021-06-16 15:57:56 -05:00
parent 5f5c912020
commit ecbc0eef95
30 changed files with 1510 additions and 19 deletions

View File

@ -77,8 +77,8 @@ NR == 1{
print "</head>"
print "<body>"
print "<header>"
# print "<p><a href='./index.html'>{" sitio "}</a></p>"
print "<p><a href='./index.html' title='compudanzas'>{<img src='./img/icon_bola.gif' style='margin:0' alt='icono de compudanzas'/>}</a></p>"
print "<p><a href='./index.html'>{" sitio "}</a></p>"
# print "<p><a href='./index.html' title='" sitio "'>{<img src='./img/icon_bola.gif' style='margin:0' alt='icono de compudanzas'/>}</a></p>"
print "<h1>"titulo"</h1>"
print "</header>"

View File

@ -5,7 +5,7 @@ mkdir -p gem
mkdir -p tmp
fecha=$(date +"%s")
fecha=$(date --rfc-3339=date)
echo "empezando conversión, estamos en ${fecha}"
@ -44,7 +44,7 @@ ls -t src/*gmo | awk -f genindice.awk > src/pages.gmo
echo "generando incoming links..."
python3 links.py
echo "revisando y convirtiendo archivimos gmo a html y gmi..."
echo "revisando y convirtiendo archivos gmo a html y gmi..."
i=0
# convierte y actualiza archivos gmi a html

View File

@ -12,7 +12,15 @@ to what extent can we reappropriate these logics to inspire other ways of being
what can be the role of non-electronic, very slow, human-scale, and seemingly useless computers, in a world that seems to be in {collapse}?
are they alternative and empowering didactic materials? performances? puzzles? passtimes? magic tricks? marvelous pursuits?
are they alternative and empowering didactic materials? {performances}? puzzles? passtimes? magic tricks? marvelous pursuits?
# research
{las danzas} is our main line of exploration. for the moment the texts are in spanish only.
we have also develop {coloring computers}.
and we tend to write some {poetry} related to these interests.
# meta

18
src/apuntes.gmo Normal file
View File

@ -0,0 +1,18 @@
# apuntes
recordatorios de procesos y herramientas computacionales
# línea de comandos
=> ./ffmpeg.gmi {ffmpeg}
=> ./imagemagick.gmi {imagemagick}
=> ./ed.gmi {ed}
=> ./postfix.gmi {postfix}
# misc
=> ./guix.gmi {guix}
# web
=> ./jitsi_hacks.gmi {jitsi hacks}

319
src/avr-asm.gmo Normal file
View File

@ -0,0 +1,319 @@
# avr-asm
explorando programación de microcontroladores avr a través de asm, en attiny85. {s-camino}
# attiny85
## diagrama de pines
```diagrama de pines
┌──────┐
PB5 │1 8│ VCC
PB3 │2 7│ PB2
PB4 │3 6│ PB1
GND │4 5│ PB0
└──────┘
```
además, cada pin es:
* 1: PB5 / PCINT5 / ~RESET / ADC0 / dW
* 2: PB3 / PCINT3 / XTAL1 / CLKI / ~OC1B / ADC3
* 3: PB4 / PCINT4 / XTAL2 / CLKO / OC1B / ADC2
* 5: PB0 / MOSI / DI / SDA / AIN0 / OC0A / ~OC1A / AREF / PCINT0
* 6: PB1 / MISO / DO / AIN1 / OC0B / OC1A / PCINT1
* 7: PB2 / SCK / USCK / SCL / ADC1 / T0 / INT0 / PCINT2
para flashear nos interesan los pines desde el punto de vista de SPI:
```pines spi
┌──────┐
~RESET │1 8│ VCC
│2 7│ SCK
│3 6│ MISO
GND │4 5│ MOSI
└──────┘
```
## programador
=> https://www.fischl.de/usbasp/ USBasp - USB programmer for Atmel AVR controllers (web)
## makefile
para ensamblar y flashear
```makefile
# Makefile
# nombre del programa sin .S :
PROG = test
# config hardware
BOARD = attiny85
PROGRAMMER = usbasp
# ensambla programa a .hex
hex:
avr-gcc -Os -DF_CPU=8000000 -mmcu=$(BOARD) -c $(PROG).S
avr-ld -o $(PROG).elf $(PROG).o
avr-objcopy $(PROG).elf -O ihex $(PROG).hex
rm $(PROG).o $(PROG).elf
# flashea
flash:
avrdude -c $(PROGRAMMER) -p $(BOARD) -U flash:w:$(PROG).hex:i
# lee la memoria flash a read.hex
read:
avrdude -c $(PROGRAMMER) -p $(BOARD) -U flash:r:read.hex:i
# prueba conexión con programador y micro
test:
avrdude -c $(PROGRAMMER) -p $(BOARD)
```
# programas
software experimental, compartido como referencia y sin garantía de ningún tipo :)
## test.S
enciende un el pin PB0 — conecta un led
```
; test.S
; enciende un pin
#include <avr/io.h>
.org 0x0000
ldi r17, (1<<DDB0) ; configura al PB0 como salida
sts DDRB, r17
ldi r16, (1<<PB0) ; enciende el bit correspondiente al PB0
sts PORTB, r16 ; actualiza el puerto
sleep ; duerme por siempre (?)
```
## blink.S
parpadea el pin PB0 usando el timer/counter0 — conecta un led
```
; blink.S
; parpadea el pin PB0 (OC0A)!
; r16 y r17 se usan como registros auxiliares
; el programa usa el timer/counter 0 con:
; * waveform generation mode (WGM0): 2, que es CTC (clear timer on compare match)
; * compare match output A mode (COM0A): 1, que es toggle en compare match
; * clock select (CS0): 5, que utiliza el reloj i/o dividido entre 1024
; notas sobre el reloj:
; por default el attiny85 va a 8MHz, y el reloj i/o va a 1MHz
; 1MHz/1024 ~= 967 Hz
#include <avr/io.h>
; ***********************
; vectores de interrupts:
; ***********************
; Reset
.org 0x0000
rjmp main
; ***********************
; Main
; ***********************
.org 0x0010
main:
; pin PB0 (OC0A) como pin de salida
ldi r16, (1<<DDB0) ; pin de salida
sts DDRB, r16
; togglea OC0A en Compare match (1 en COM0A[1:0])
; y usa modo Clear Timer on Compare Match (2 en WGM0[2:0])
ldi r16, (0<<COM0A1) | (1<<COM0A0) | (1<<WGM01) | (0<<WGM00)
sts TCCR0A, r16
; completa el modo WGM (waveform generaton mode, bit 2)
; establece el tipo de reloj: 0b101 en CS0 es clk/1024
ldi r16, (0<<WGM02) | (1<<CS02) | (0<<CS01) | (1<<CS00)
sts TCCR0B, r16
; el TOP es el valor en OCR0A
ldi r16, 0x80
sts OCR0A, r16
loop:
sleep
rjmp loop
```
## buzz.S
zumba el pin PB0 — conecta un buzzer
```
; buzz.S
; haz zumbar el pin PB0 (OC0A)!
; el código es igual a blink.S, pero con diferentes frecuencias
; r16 y r17 se usan como registros auxiliares
; el programa usa el timer/counter 0 con:
; * waveform generation mode (WGM0): 2, que es CTC (clear timer on compare match)
; * compare match output A mode (COM0A): 1, que es toggle en compare match
; * clock select (CS0): 4, que utiliza el reloj i/o dividido entre 256
; notas sobre el reloj:
; por default el attiny85 va a 8MHz, y el reloj i/o va a 1MHz
; 1MHz/256 ~= 3906 Hz (/2 para el periodo completo ~=1953Hz)
#include <avr/io.h>
; ***********************
; vectores de interrupts:
; ***********************
; Reset
.org 0x0000
rjmp main
; ***********************
; Main
; ***********************
.org 0x0010
main:
; pin PB0 (OC0A) como pin de salida
ldi r16, (1<<DDB0) ; pin de salida
sts DDRB, r16
; togglea OC0A en Compare match (1 en COM0A[1:0])
; y usa modo Clear Timer on Compare Match (2 en WGM0[2:0])
ldi r16, (0<<COM0A1) | (1<<COM0A0) | (1<<WGM01) | (0<<WGM00)
sts TCCR0A, r16
; completa el modo WGM (waveform generaton mode, bit 2)
; establece el tipo de reloj: 0b100 en CS0 es clk/256
ldi r16, (0<<WGM02) | (1<<CS02) | (0<<CS01) | (0<<CS00)
sts TCCR0B, r16
; el TOP es el valor en OCR0A
ldi r16, 0x02
sts OCR0A, r16
loop:
sleep
rjmp loop
```
## alarm.S
zumbido intermitente en el pin PB0 — conecta un buzzer
```
; alarm.S
; zumbido intermitente en el pin PB0 (OC0A)!
; r16 y r17 se usan como registros auxiliares
; r20 tiene el valor de TCCR0A para apagar sonido
; r21 tiene el valor de TCCR0A para encenderlo
; el programa usa el timer/counter 0 con:
; * waveform generation mode (WGM0): 2, que es CTC (clear timer on compare match)
; * compare match output A mode (COM0A): 1, que es toggle en compare match
; * clock select (CS0): 3, que utiliza el reloj i/o dividido entre 64
; y el timer/counter 1 con:
; * clock select (CS1): 0b1010, que es clk/512
; * interrupciones de overflow y de compare match A:
; - en compare match A el zumbido se apaga
; - en overflow el zumbido inicia
; notas sobre el reloj:
; por default el attiny85 va a 8MHz, y el reloj i/o va a 1MHz
; 1MHz/256 ~= 3906 Hz (/2 para el periodo completo ~=1953Hz)
#include <avr/io.h>
; ***********************
; vectores de interrupts:
; ***********************
; Reset
.org 0x0000
rjmp main
; dirección 0x0003 * 2
.org 0x0006
rjmp timer1compareA_isr
; dirección 0x0004 * 2
.org 0x0008
rjmp timer1overflow_isr
; ***********************
; Main
; ***********************
.org 0x001E
main:
;----------------------------------
; configuración general
;----------------------------------
; habilita interrupciones
sei
; pin PB0 (OC0A) como pin de salida
ldi r16, (1<<DDB0) ; pin de salida
sts DDRB, r16
; valores de TCCR0A para encender o apagar sonido
ldi r20, (0<<COM0A1) | (0<<COM0A0) | (1<<WGM01) | (0<<WGM00)
ldi r21, (0<<COM0A1) | (1<<COM0A0) | (1<<WGM01) | (0<<WGM00)
;----------------------------------
; configuración TIMER0 para buzzer
;----------------------------------
; togglea OC0A en Compare match (1 en COM0A[1:0])
; y usa modo Clear Timer on Compare Match (2 en WGM0[2:0])
sts TCCR0A, r21
; completa el modo WGM (waveform generaton mode, bit 2)
; establece el tipo de reloj: 0b011 en CS0 es clk/64
ldi r16, (0<<WGM02) | (0<<CS02) | (1<<CS01) | (1<<CS00)
sts TCCR0B, r16
; el TOP es el valor en OCR0A
; más pequeño es más agudo
ldi r16, 0x06
sts OCR0A, r16
;----------------------------------
; configuración TIMER1 para alternar entre sonido on/off
;----------------------------------
; CS1 en 0b1010 es CK/512
ldi r16, (1<<CS13) | (0<<CS12) | (1<<CS11) | (0<<CS10)
sts TCCR1, r16
; establece el valor A al que cuenta el timer1 antes de apagar sonido
; menor valor, menor tiempo de sonido (duty cycle)
ldi r16, 0x30
sts OCR1A, r16
; set Timer overflow interrupt enable 1
; y timer output compare A interrupt enable 1
ldi r16, (1<<TOIE1) | (1<<OCIE1A)
sts TIMSK, r16
loop:
sleep
rjmp loop
timer1compareA_isr:
; apaga la salida
sts TCCR0A, r20
reti
timer1overflow_isr:
; enciende la salida
sts TCCR0A, r21
; regresa de la interrupción
reti
```

View File

@ -1,8 +1,8 @@
# danzas compuertas
antiguas historias hablaban de computar en conjunto, en comunidad. ¿{las danzas}?
antiguas historias hablaban de computar en conjunto, en comunidad.
tareas sencillas y divertidas (requeridas de atención y presencia) que combinadas dan paso a complejidad, a olas, a cambios.
tareas sencillas y divertidas que requieren atención y presencia y que combinadas dan paso a complejidad, a olas, a cambios.
# guía

50
src/darena.gmo Normal file
View File

@ -0,0 +1,50 @@
# darena
an open-ended game of rocks and sand, and/or a simulator for compudanzas
the sandy space contains a bunch of rocks in either one of two possible colors, and yourself.
push and arrange the rocks to prototype and build your own computer, cellular automata, 1-bit art, etc.
=> ./img/screenshot_darena.png screenshot of the game. it shows a square clear space inside a textured world. inside the square there are several round rocks of two possible colors. there is a small platform, and a person.
what will you do with the sand?
# about
darena was developed as an exercise to learn about {postfix} notation and uxn
=> https://wiki.xxiivv.com/site/uxn.html uxn virtual machine and assembly language
on one hand, this happened as part of the {s-camino} practice.
on the other, this was thought as a potencial simulator of computational {performances}.
you can play with it in the web, thanks to the webuxn port by aduros:
=> https://aduros.com/webuxn/?rom=roms/darena.rom darena via webuxn
=> https://github.com/aduros/webuxn webuxn repository
# features
* a character that moves in all four cardinal directions
* rocks that can be pushed around, unless they are colliding with other rocks or the borders of the "arena"
* a toggling station where rocks can be switched to the other color
* realistic animation: the character slows down when pushing rocks, recovering their original speed when walking
# controls
use the arrow keys for cartesian movement within the space
# possible "improvements"
* add an "official" pulling option (you can pull rocks right now, but in a hacky way)
* save rocks state (position and color) to file
* optimize the use of memory for rock colors, using one bit per rock instead of one byte
# the code
this iteration has 31 rocks and a single toggling station where one can switch their color/state.
you can find the code in the
=> https://git.sr.ht/~rabbits/uxn/tree/master/item/projects/examples/demos/darena.tal uxn repo

15
src/ed.gmo Normal file
View File

@ -0,0 +1,15 @@
# ed
pequeño editor de texto
# tips
para formatear un texto asignándole cierto número de columnas, primero guarda con 'w' y luego:
```
e ! fmt -w50 %
```
esto toma la salida del comando fmt aplicada al mismo archivo (%), y la toma como contenido del buffer, reemplazando todo lo que había antes.
el comando 'e' es de "edit"

View File

@ -84,6 +84,9 @@ nav{
nav li{
list-style-type:square;
}
li{
padding:0.5em;
}
table,th,td{
border-style:inset;

112
src/ffmpeg.gmo Normal file
View File

@ -0,0 +1,112 @@
# apuntes de ffmpeg
notas de usos comunes que le doy a ffmpeg
# "trim" / cortar
```
ffmpeg -i input.video -ss 5 -t 20 output.video
```
donde:
-ss es el tiempo inicial
-t es la duracion total del nuevo video
# escalar
```
ffmpeg -i input.video -vf scale=640:480 output.video
```
y para reducir el tamaño del archivo, suele ser útil recomprimir con crf (constant rate factor)
```
ffmpeg -i input.video -crf 24 output.video
```
en teoría 24 es una compresión difícil de percibir. números mayores comprimen más.
# cambio de framerate
```
ffmpeg -i input.video -r 30 output.video
```
o
```
ffmpeg -i input.video -filter:v fps=fps=30 output.video
```
# cambio de "velocidad"
obtiene un video a 2x de velocidad:
```
ffmpeg -i input.video -filter:v "setpts=0.5*PTS" output.video
```
para hacer 60x (por ejemplo, convertir minutos a segundos):
```
ffmpeg -i input.video -filter:v "setpts=0.016*PTS" output.video
```
# concatenar
hacer lista de videos con el formato:
```
file 'archivo1'
file 'archivo2'
file 'archivo3'
```
y luego:
```
ffmpeg -f concat -i lista.txt -c copy output.video
```
# generar video desde serie de img
```
ffmpeg -framerate 30 -i frame-%04d.tif -pix_fmt yuv420p -c:v libx264 <output.mp4>
```
# crop (y exportar desde recordmydesktop)
```
ffmpeg -i out.ogv -filter:v "crop=1280:720:0:0" -codec:v libx264 -codec:a libmp3lame output.mp4
```
# video a partir de una imagen
```
# video de una imagen,
# 10 segundos, 30 frames por segundo
ffmpeg -loop 1 \
-i imagen_verde.png \
-t 00:00:10 -r 30 \
video_verde.ogv
```
# video a partir de serie de imágenes
```
# cambia entre imágenes a 2fps,
# video final a 30fps
ffmpeg -framerate 2 \
-i "%02d.png" \
-pix_fmt yuv420p \
-c:v libx264 \
-r 30 salida.mp4
```
# overlay de imagen sobre video
```
ffmpeg -i input.mp4 -i imagen.png -filter_complex "overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2" output.mp4
```

46
src/gemini.gmo Normal file
View File

@ -0,0 +1,46 @@
# gemini
protocolo del "small internet" para documentos de hipertexto:
* minimalista en su especificación
* una conexión por documento
* la prioridad es el (hiper)texto
* comunicación cifrada
* presentación queda a cargo del programa cliente
se les llama "cápsulas" a lo que en la web llamaríamos "sitios".
# enlaces
## sobre gemini
=> https://gemini.circumlunar.space/ project gemini (web)
=> gemini://gemini.circumlunar.space/ project gemini (gemini)
## recomendaciones
agregador de cápsulas con contenido en castellano:
=> gemini://caracolito.mooo.com/deriva/ bot en deriva
y estas son las cápsulas que suelo leer:
=> gemini://soviet.circumlunar.space/sejo/subs/ gemini subs
más enlaces en el {linkroll}
## para navegar
en android, utilizo la app ariane:
=> https://oppen.digital/software/ariane/ ariane (web)
=> gemini://oppen.digital/software/ariane/ ariane (gemini)
desde un navegador web, se puede utilizar algún proxy:
=> https://portal.mozz.us/ gemini portal
además hay muchos clientes más:
=> https://gemini.circumlunar.space/software/ gemini software (web)
=> gemini://gemini.circumlunar.space/software/ gemini software (gemini)

96
src/guix.gmo Normal file
View File

@ -0,0 +1,96 @@
# guix
sistema operativo cuyo estado se describe en un archivo de texto
=> https://guix.gnu.org/ guix
# configuración del sistema
configura el sistema a partir del archivo config.scm:
```
sudo guix system reconfigure config.scm
```
# paquetes
instala los paquetes que están (d)escritos en el archivo paquetes.scm:
```
guix package -m paquetes.scm
```
este es mi archivo paquetes.scm:
``` paquetes.scm
; paquetes.scm
(specifications->manifest
(list
; multimedia
"evince" ; pdf viewer
"vlc"
"peek" ; screen record
"imagemagick"
"ffmpeg"
"libreoffice"
; image
"inkscape"
"mypaint"
"krita"
"gimp"
; browsers
"icecat"
"netsurf"
"lynx"
"lagrange" ; gemini
"bombadillo" ; gemini / gopher
"python-vf-1" ; gopher
; programming
"make"
"git"
"python"
"clang-toolchain"
"pandoc"
; fonts
"font-openmoji"
"font-fira-code"
"font-fira-mono"
"font-fira-sans"
"font-gnu-unifont"
"font-gnu-freefont"
"font-google-noto"
; utils
"xclip"
"wget"
"cryptsetup"
"rsync"
"bash-completion"
"adb"
"bc" ; calculator
"htop" ; system monitor
"zip" "unzip"
;misc
"vinagre" ; vnc viewer
"xscreensaver"
"keepassxc"
"syncthing-gtk"
"syncthing"
; comms
"icedove"
"telegram-desktop"
"filezilla"
"openssh"
"qtox"
; text editors
"mousepad"
"vim"
))
```

141
src/imagemagick.gmo Normal file
View File

@ -0,0 +1,141 @@
# apuntes de imagemagick
# redimensiona imagen
```
convert imagen.png -resize 100x100 imagen100.png
```
o con -scale, para no interpolar y mantener la apariencia de pixeles
```
convert imagen.png -scale 200% imagenx2.png
```
# reemplaza color por otro
reemplaza azul por blanco:
```
convert imagen.png -fill white -opaque blue salida.png
```
se puede agregar fuzz factor:
```
convert imagen.png -fuzz 45% -fill white -opaque blue salida.png
```
y para convertir a transparente:
```
convert imagen.png -fuzz 45% -transparent blue salida.png
```
# elimina metadatos exif
para imágenes jpg
```
convert foto.jpg -strip fotolimpia.jpg
```
esto re-comprime la imagen, pero puede usarse al mismo tiempo que se redimensiona
```
convert foto.jpg -strip -resize 640x480 fotolimpia_480p.jpg
```
# convierte pdf
## imagen a pdf
por default la conversión sucede en baja calidad, esto la mejora:
```
convert imagen.png -quality 100 -units PixelsPerInch -density 300x300 imagen.pdf
```
## pdf a imagen
para el caso opuesto:
```
convert -quality 100 -units PixelsPerInch -density 300x300 imagen.pdf imagen.png
```
# reduce la cantidad de colores
deja que imagemagick elija qué colores utilizar:
```
convert imagen.png -colors 8 imagen_8.png
```
o con dithering:
```
convert imagen.png -dither FloydSteinberg -colors 8 imagen_8.png
```
en -dither se puede usar None, Riemersma, o FloydSteinberg
# genera mapas de bits
con color plano:
```
convert -size 100x100 xc:'rgb(0,255,0)' imagen_verde.png
```
con ruido:
```
convert -size 100x100 xc: +noise Random imagen_ruido.png
```
# compone/encima imágenes
para componer una imagen con fondo transparente sobre otra que se convertirá en su fondo
```
composite -gravity center imagen_con_alpha.png fondo.png resultado.png
```
# mosaico de imágenes
combina varias imágenes en mosaico, con margen de 0 entre ellas:
```
montage imagen1.png imagen2.png -geometry +0+0 mosaico.png
```
el parámetro geometry indica los márgenes entre imágenes, y opcionalmente sus dimensiones:
```
montage imagen1.png imagen2.png -geometry 100x100+0+0 mosaico.png
```
para asignar fondo transparente al montaje:
```
montage imagen1.png imagen2.png -geometry +0+0 -background none mosaico.png
```
# corta
para cortar una imagen a ciertas dimensiones (wxh) y cierto offset en x,y
```
convert imagen.png -crop 300x300+100+50 +repage recorte.png
```
para quitarte el borde de color constante a una imagen
```
convert imagen.png -trim +repage sinborde.png
```
TODO: notas sobre -chop

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.7 KiB

View File

@ -3,5 +3,5 @@
human-powered explorations of emergent complexity
=> ./about.gmi {about}
=> ./coloring_computers.gmi {coloring computers}
=> ./las_danzas.gmi {las danzas}
=> ./coloring_computers.gmi {coloring computers}

47
src/jitsi_hacks.gmo Normal file
View File

@ -0,0 +1,47 @@
# hacking jitsi meet
esta es una colección de funciones de javascript para modificar localmente el diseño/layout de una videollamada de jitsi meet.
las he usado tanto para adecuar el diseño de una videollamada para que sea capturada/retransmitida, como para que todes les integrantes modifiquen el diseño y tengamos un punto de vista similar.
estas funciones se pueden ejecutar directamente en la consola web del navegador, ya sea descendiente de firefox o de chrom(ium) (ctrl+shift+k, o con F12 y eligiendo la tab de consola)
# cambia el color de fondo
esta línea cambia el color de fondo a negro:
```
document.getElementById('largeVideoContainer').style.backgroundColor='black';
```
# deja de mostrar a quienes no tienen video encendido
para cuando hay participantes presentes sin video, en la vista de mosaico:
```
for(c of document.getElementsByClassName('display-avatar-only')){
c.style.display='none'
};
```
# espejea a todos los videos y redimensiónalos
en la vista de mosaico, por defecto une misme se muestra con la toma "en espejo" y todes les demás con la toma "normal".
cuando se trabaja con espacialidades, esta situación puede volverse confusa (e.g. todes queremos señalar a "la izquierda"). con este código podemos unificarnos.
este ciclo hace que todos los videos estén "en espejo", además de que permite que crezcan un poco en el mosaico.
```
for(v of document.getElementsByTagName('video')){
v.classList.add('flipVideoX'); // "espejea"
v.style.objectFit = 'cover'; // "redimensiona"
};
```
# re-ordena
pendiente: código/tutorial para re-ordenar la cuadrícula a una configuración predeterminada.

33
src/linkroll.gmo Normal file
View File

@ -0,0 +1,33 @@
# linkroll
me alegra mucho que estos sitios existan
# en la web
=> https://melmuvz.neocities.org/ melmuvz.neocities.org
=> https://xxiivv.com/ xxiivv.com
=> https://kokorobot.ca/ kokorobot.ca
=> https://copiona.com/ copiona.com
=> https://100r.co/ 100r.co
=> https://xj-ix.luxe/ xj-ix.luxe
=> https://leetusman.com/ leetusman.com
=> https://marijn.uk/ marijn.uk
=> https://maya.land/ maya.land
=> https://simone.computer/ simone.computer
=> https://sophieleetmaa.com/ sophieleetmaa.com
=> https://sixey.es/ sixey.es
=> https://u2764.com/ u2764.com
=> https://ellugar.co/ ellugar.co
=> https://ritualdust.com/ ritualdust.com
=> https://now.lectronice.com/ now.lectronice.com
# en gemini
(¿y qué es {gemini}?)
=> gemini://soviet.circumlunar.space/sejo/deriva/ bot en deriva
=> gemini://sunshinegardens.org/~xj9/ xj-ix (dreamspace never)
=> gemini://gemini.circumlunar.space/~solderpunk/ solderpunk
=> gemini://republic.circumlunar.space/users/maleza/ maleza
=> gemini://gemini.circumlunar.space/users/hundredrabbits/ hundredrabbits
=> gemini://alexschroeder.ch/ alex schroeder

View File

@ -2,18 +2,16 @@
compendio de circuitos lógicos que pueden implementarse en las {danzas compuertas}.
material de referencia para las {las danzas}
# acerca de
los circuitos lógicos en este compendio están descritos en {verilog}, un lenguaje descriptor de hardware. esto con la idea de estandarizarlos, de facilitar simularlos e implementarlos en otros materiales, y de indicar su cualidad de red abstracta.
cada circuito indica un número de participantes que varía entre dos opciones. el número menor está calculado como el número de entradas más el número de compuertas. el otro número suma también el número de salidas del circuito completo, que de otra forma serían realizadas por alguna(s) de las compuertas.
utilizamos el lenguaje a nivel de {compuertas} lógicas solamente: cada compuerta se expresa como una función (and(), not(), or(), nor(), nand(), etc) donde el primer argumento es el nombre de la salida de la compuerta, y el o los otros argumentos son los nombres de las entradas.
este es un compendio de circuitos lógicos que pueden implementarse en las {danzas compuertas}.
están descritos en *verilog*, un lenguaje descriptor de hardware. esto con la idea de estandarizarlos, de facilitar simularlos e implementarlos en otros materiales, y de indicar su cualidad de *red abstracta*.
utilizamos el lenguaje a nivel de {compuertas} lógicas solamente: cada compuerta se expresa como una función (`and()`, `not()`, `or()`, `nor()`, `nand()`, etc) donde el primer argumento es el nombre de la *salida* de la compuerta, y el o los otros argumentos son los nombres de las *entradas*.
el número de participantes asignado por circuito está contado como el *número de entradas* más el *número de compuertas*, donde alguna(s) de ella(s) incluyen las compuertas cuyas salidas son también la(s) del circuito. si se tienen más participantes, se pueden agregar el *número de salidas*: persona(s) que copien el resultado de la compuerta correspondiente.
# multiplicador de 1 bit
circuito que multiplica a dos números de 1 bit y da el resultado en 1 bit.

12
src/low-level.gmo Normal file
View File

@ -0,0 +1,12 @@
# low-level programming
writing code closer to the machine(s)
# texts
=> ./s-camino.gmi {s-camino}
# software
=> ./darena.gmi {darena}
=> ./avr-asm.gmi {avr-asm}

19
src/performances.gmo Normal file
View File

@ -0,0 +1,19 @@
# performances
public appearances of the project on a stage.
see also {talks and workshops}
# past
## 12019
{la consagración de la computadora} was presented in two different events:
### june 21,22
=> https://www.collab-orators.com/events/itp-residents-show itp residents show 2019, collab, brooklyn, ny
### april 14
=> https://ipfs.io/ipfs/QmYYqFXowEuak9NVNMHexrwZQkEnfH4J6weSPpv3kjFP94/mub/show.html world premiere, mayday space, brooklyn, ny

View File

@ -0,0 +1,42 @@
# personal statement for ITP
an accepted application written in the beginning of 12016 for the itp-nyu masters degree, with some minor edits for formatting purposes.
shared for reference purposes: the four stages in the text are the precedents for the compudanzas project.
for the record: i don't agree now with all that is stated :)
# Personal Statement 12016
1) Everything is possible with hard work and dedication.
2) There is always more.
3) If something is not difficult, then it is not of value.
It is difficult to write this text.
I like to think of myself as a creator. I create choreographies, I create software, I create classes, and in general I create ideas that I have to make come true. In my experience, creativity and curiosity are two aspects of humanity that can enlighten, empower and free whoever is willing to see beyond the conventions. In order to foster them, changes and challenges are needed. My application into the ITP is based in the search for a different and stimulating environment, where things will not be easy, where my assumptions will be challenged, and where I will be surrounded by more people looking for more. I want to break free from my own mental barriers so that I can grow as a creator. This will allow me to have a broader impact inviting others to try living in the non conventional and authentic paths.
Computing has been present in most of my life. I have enjoyed algorithmic thinking since the moment I was introduced to a programming language in my middle school days. An exciting journey of self-directed learning about computers, programming languages and operating systems started, and I got motivated writing my own scripts for automating diverse tasks, ranging from file management to simulations web applications. During my Electrical Engineering studies I was introduced to Digital Systems, and then computing began to make sense as a whole. However, although I liked those topics a lot, I felt that something was missing. My curiosity started to show me some funny ways of creating using that knowledge.
For example, we had a course about Microcontrollers, where the main difficulty was that we also had to learn and code in the corresponding assembly language. I decided to have a humorous challenge as a final project, so I developed an “8051 Assembler: Assembler for the 8051 assembly language, written in the 8051 assembly language”. On one hand the project could be seen as completely useless because it had no social impact other than impressing people with the feat and its name, but on the other hand it helped me think about the expressive possibilities of technology beyond an utilitarian point of view.
During the same college years, I started to practice and learn about an art that would completely change the plans that I had: Dance. What started as a diversion from school, gradually became the activity which got me more interested. The first great goal that I achieved was being accepted into the schools dance company, where I could learn a lot about teamwork and collaboration.
A fortunate event was having a change in the director of the company: the new leader [redacted] showed us the advantages of hard work and encouraged us to find our own paths. I started to think about other ways of doing dance and I began exploring choreographic possibilities. I got braver and authentic, and as a choreographer I guided two different teams into contests where we had great national results. I founded Escenaconsejo, performing arts and interactive digital media company, and I decided to study Choreography. In those different contexts I enjoyed working with people that I admire and that find value in my ideas.
Since then, I have had an interesting evolution of my way of thinking and creating dance in relation to computing and digital technology. This process can be divided in four main stages.
The first one consisted in thinking that digital technology had only a decorative role in dance. I experimented with a variety of motion tracking techniques to enable the real-time generation of multimedia content.
The second stage consisted in understanding that research and educative challenges could be tackled with the creation of specific and personalized tools that I could made and that I actually constructed. Some some examples include visualizations of the meanings of dance notation symbols, or a computer vision aid for measuring joints angles in dancers.
The third stage in this evolution process consisted in realizing that I could apply the computational, mathematical and structured vision that I developed as an engineer, as a source for composition methods that greatly differed from the commonly used ones. For example, I created a choreographic palindrome, a fractalic micro-macro cosmic choreographic structure, and finally I created Desfases (Phase shifts).
Desfases was the work with which I decided to get into the entrepreneurial path of Escenaconsejo along with my partner [redacted]. It is a collection of strict structural games based on shifting time, space and/or points of view. We decided to work full-time in it, and we launched a crowdfunding campaign that was a success after several months of hard work. We set an example in our dance community, as many people have tried since then to achieve a crowdfunding goal with the magnitude of ours. We work in Escenaconsejo because we are convinced about the value of our creations, and that is why we are pursuing the dream of living from them.
Finally, the fourth and current stage in this thinking evolution has consisted in getting to know about the concept of generative art. It starts to be clear how to create organic-like works using artificial means, either in choreography or in software. After more than ten years learning about programming and computers, I think that now it is the perfect time to unlearn those topics in order to cultivate a new perspective.
For example, this year I wrote a project to create a choreography based in the Little Man Computer model. The idea is to devise the architecture and machine instruction cycle that a person should execute so that she/he could become a computer. Choreographic repetition could acquire a new meaning if each iteration were part of a program. An important question that I had kept unanswered was about which programs should I write in order to run them in a live performance. Now, after reading and coding generative art, I think that this choreographic work would be complete if the strict rules of the computer architecture and its corresponding machine instruction cycle controlling the human performer were complemented by the execution of an algorithm with a chaotic outcome.
In some way, the description of that choreography would summarize the creative processes that I want to live and the works that I want to create: Worlds that mix the human spirit with a computational context that involves great challenges, and that reveal different ways of thinking, learning and doing. I am convinced that in this graduate program I will have the needed stimuli for being under constant difficulties. These will probably transform my way of working so that I will have a broader range of action and influence. My goal is that then I will be able to help more people find their own personal ways through creativity, curiosity, and hard work. Changes and challenges will come, and new choreography and interactive digital media will arise.
jvc

View File

@ -1,3 +1,9 @@
# poetry
non-executable poetic texts around compudanzas.
=> ./después_ahora.gmi {después ahora}
=> ./s-camino.gmi {s-camino}
=> ./the_rite_of_computing.gmi {the rite of computing}
see also the {proposals} for more texts surrounding the project.

93
src/postfix.gmo Normal file
View File

@ -0,0 +1,93 @@
# notación postfix (o rpn: reverse polish notation)
los operadores van después de los operandos, y todo funciona con una pila (stack)
por ejemplo, para sumar dos números:
```
3 4 +
```
leyendo de izquierda a derecha:
* primero se hace "push" al 3
* luego se hace "push" al 4
* el operador + hace "pop" dos veces, suma los valores, y hace "push" al resultado
tres números:
```
3 4 2 + +
```
nota: el primer operador + realiza la suma entre 4 y 2, y el segundo operador + realiza la suma entre ese resultado y 3.
otra posibilidad:
```
3 4 + 2 +
```
# operadores de stack
* pop: saca (y descarta) el elemento de arriba de la pila
* swp: intercambia los dos elementos superiores en la pila
* dup: duplica el elemento superior en la pila
* ovr: copia el segundo elemento de la pila, y colócalo hasta arriba
* rot: quita el tercer elemento de la pila, y colócalo hasta arriba
# rutinas con firth
firth es una calculadora rpn con fracciones:
=> https://git.sr.ht/~rabbits/firth firth
el operador . imprime el estado de la pila
## tiempos
convierte (minutos, segundos) a una cantidad de segundos. en el ejemplo, son 8 minutos, 49 segundos:
```
8 49
swp 60 * + .
resultado: 529
```
convierte (minutos, segundos) correspondientes a un "paso" min/km, a una velocidad km/hr:
```
4 30
swp 60 * + 3600 swp / .
resultado en modo dec: 13.3333 (km/hr)
```
convierte una velocidad km/hr, a un "paso" min/km
```
14
3600 swp / 60 / .
resultado en modo dec: 4.285714 min/km
```
o para obtener minutos y segundos:
```
14
3600 swp / dup 60 / swp 60 % .
resultado en modo mix: 4&2/7 17&1/7 ( 4'17" min/km)
```
¿se nota el gusto por el {running}?
# herramientas
firth, una calculadora rpn con fracciones:
=> https://git.sr.ht/~rabbits/firth firth
uxn, una máquina virtual basada en pilas
=> https://wiki.xxiivv.com/site/uxn.html uxn

17
src/proposals.gmo Normal file
View File

@ -0,0 +1,17 @@
# proposals
an (incomplete) archive of statements, applications, proposals related to compudanzas.
for less formal texts, see {poetry}
# 12020
=> ./propuesta_poñg.gmi {propuesta poñg}
# 12016
=> ./personal_statement_itp.gmi {personal statement itp}
# 12015
=> ./propuesta_el_computador.gmi {propuesta el computador}

View File

@ -0,0 +1,134 @@
# El Computador: Coreografía estructurada como microprocesador (Propuesta)
El siguiente texto fue parte de mi aplicación a la convocatoria de jóvenes creadores (1)2015 en la disciplina de danza.
Probablemente es el primer precedente escrito del proyecto de compudanzas.
La propuesta no fue aceptada en la fase administrativa.
# Características del proyecto
## Sinopsis
El microprocesador es una máquina diseñada para repetidamente leer y ejecutar instrucciones sencillas. La complejidad de las operaciones computacionales, que van desde calcular una raíz cuadrada hasta simular el inicio del Universo, surge a partir de la combinación adecuada de pasos a seguir. El Computador es coreografía estructurada como microprocesador: las repeticiones de un cuerpo llevado a sus límites físicos lo trascienden porque está ejecutando un algoritmo que busca una respuesta.
## Introducción
En la búsqueda de diferentes propuestas estructurales en la coreografía, resulta interesante someter al cuerpo humano a planteamientos rígidos y basados en repeticiones, como podemos notar en obras de creadores minimalistas. Este proyecto parte de esas ideas, y se pregunta: ¿Qué pasaría si las repeticiones de acciones físicas, además de tener un sentido estético y estructural, fueran acumulando sus efectos en un plano abstracto para llegar a un resultado tangible?
Es posible partir de una disciplina que entre otros objetos estudia las secuencias, las repeticiones, y los resultados de sus combinaciones: las ciencias computacionales. Una computadora es una máquina basada en la repetición, y esta se usa de tal forma que sus acciones se acumulan de acuerdo al diseño dado por un algoritmo para logran llegar a soluciones.
¿Qué pasa entonces si un cuerpo humano se convierte en una computadora, en donde sus acciones repetidas en una coreografía son en realidad parte de un programa que tiene un objetivo? En primera instancia este hecho puede verse como una representación de las rutinas en la sociedad actual, y los efectos de la repetición estricta sobre una persona, pero en las realidad hay más implicaciones.
Por un lado, las ciencias computacionales, como las matemáticas, pueden ser sumamente abstractas, manejando conceptos elevados donde además se busca la elegancia y la simplicidad para expresar gran complejidad. Se llega a decir que "el código es poesía", por lo que esta coreografía sería una representación de ese punto de vista estético. Por otro lado, las computadoras en la realidad trabajan a velocidades que es difícil imaginar: cuando se dice que un microprocesador trabaja a 2 GHz, por ejemplo, significa que está realizando 2,000'000,000 operaciones durante un segundo. Un humano replicando su funcionamiento estaría alentando el tiempo en una proporción inmensa, en la que por ejemplo unos cuantos años se transformarían en el periodo correspondiente a la edad del Universo. Finalmente, actualmente vivimos rodeados de dispositivos digitales, pero es poco conocido cómo funcionan en realidad, o cómo son una maravilla del ingenio humano.
Para tener una idea más clara de las implicaciones del proyecto coreográfico, previo a describirlo con mayor profundidad se presenta a continuación un breve marco teórico sobre algoritmos y arquitectura computacional.
## Breve marco teórico sobre pensamiento algorítmico
Un algoritmo es una secuencia finita y ordenada de pasos o instrucciones que buscan resolver un problema. Por ejemplo, cualquier receta de cocina es un algoritmo, pues combina elementos en una secuencia y tiene el fin de preparar un platillo. En las ciencias computacionales y en las matemáticas, los algoritmos son estudiados por su capacidad de resolver problemas diversos, como cálculos numéricos, control de sistemas automatizados, telecomunicaciones, administración de datos, por citar algunos.
Las instrucciones de un algoritmo computacional pueden clasificarse en cuatro grandes grupos:
* Instrucciones de entrada de datos, para recibir los materiales a procesar en el algoritmo.
* Instrucciones de salida de datos, para entregar los resultados del algoritmo.
* Instrucciones aritméticas, lógicas, y de otros procesamientos, que realizan operaciones sobre los datos.
* Instrucciones de control, que permiten tomar decisiones condicionales ("Si sucede X, haz Y, si no haz Z") y construir estructuras de repetición ("Haz X 3 veces" o "Haz Y mientras Z no suceda")
Cualquier problema que se ha resuelto o se puede resolver con un algoritmo, tiene una solución construida únicamente con una combinación adecuada de esos cuatro elementos. Esto implica que cualquier máquina capaz de ejecutar este tipo de instrucciones, al seguir el algoritmo correcto teóricamente puede resolver cualquiera de esa clase de problemas.
## Breve marco teórico sobre arquitectura computacional
Alan Turing propuso en 1936 el modelo de lo que después se llamaría Máquina de Turing: un dispositivo hipotético que se desliza sobre una cinta con símbolos que son leídos y manipulados de acuerdo a una tabla de reglas, y que al hacerlo puede ejecutar un algoritmo computacional. En la misma publicación estableció lo que se llamaría Máquina Universal de Turing: un dispositivo hipotético de la misma naturaleza pero que puede simular a cualquier otra máquina de Turing de acuerdo a los símbolos escritos sobre la cinta. Estas ideas y su estudio, además de ser pilares para las ciencias computacionales, dieron paso a lo que se conoce actualmente como arquitectura de von Neumann.
La arquitectura de von Neumann consiste en la descripción funcional de un sistema electrónico digital que funge como computadora: un dispositivo con la capacidad de ejecutar algoritmos codificados en una serie de instrucciones denominadas programa. Consta de cuatro componentes básicos: Unidad de Procesamiento Central (CPU o microprocesador), Memoria, Dispositivos de Entrada, y Dispositivos de Salida. La Unidad de Procesamiento Central debe tener a su vez una Unidad de Control y una Unidad Aritmética y Lógica (ALU).
Lo más relevante de la arquitectura de von Neumann para este proyecto se enlista a continuación:
* La Unidad Central de Procesamiento está diseñada para ser capaz de ejecutar un conjunto pequeño de instrucciones sencillas. Además, su función es ejecutar una instrucción a la vez.
* La Memoria almacena de manera ordenada tanto las instrucciones del algoritmo, también llamadas programa, como los datos de apoyo.
* La Unidad de Control guía la secuencia de acciones, estableciendo cuándo y dónde leer una instrucción de la memoria, y qué hacer dependiendo de la lectura.
* El funcionamiento de la computadora, llamado Ciclo de Instrucción (Machine instruction cycle) se divide en dos grandes etapas que se repiten sin fin a una gran velocidad: etapa de lectura (fetch cycle), en el que la Unidad Central de Procesamiento busca en la Memoria la siguiente instrucción a ejecutar, y etapa de ejecución (execute cycle) en el que la decodifica, la ejecuta, y se calcula la ubicación de la siguiente instrucción.
Debido a lo complejo que puede resultar comprender y utilizar el funcionamiento de estas máquinas, se han desarrollado modelos como el de Little Man Computer (Computadora del hombre pequeño) de Stuart Madnick. En esta representación, la Unidad de Control se piensa como un hombre que se encuentra en una habitación y sigue una secuencia específica de pasos para leer y ejecutar instrucciones y datos guardados en una serie de buzones ordenados. El hombre, al igual que los microprocesadores, solo obedecen las instrucciones en el orden en el que se le dan, una a la vez. Como sea, al seguir instrucciones correspondientes a diferentes algoritmos, pueden resolver tareas de gran complejidad sin tener que ser conscientes del problema que están resolviendo.
## La coreografía de El Computador
Con base en el modelo de la Little Man Computer, la propuesta coreográfica de este proyecto consiste en construir con las acciones físicas de una persona sujetas a una serie de reglas, una computadora funcional y programable. Después de establecer de manera abstracta las características del microprocesador y sus operaciones, y de la arquitectura de la computadora completa, es posible determinar cómo las etapas del fetch cycle y del execute cycle serán implementadas con acciones del intérprete. Probablemente debe utilizarse utilería auxiliar para la representación de los números en la computadora, que son la base para codificar las instrucciones del microprocesador, las ubicaciones en la Memoria, y los datos con los que hacer operaciones. Ejemplos posibles son rocas, pizarrones, pelotas, globos, etc.
Ya con la computadora construida de esta forma, se tendrán infinitas coreografías en potencia: el algoritmo que se programe en la Memoria, determinará la secuencia de las repeticiones de lectura y ejecución (fetch y execute). Así, lo que podremos ver en escena es a una persona trasladándose repetidamente y realizando operaciones con su cuerpo y la utilería. Como sea, el acto escénico, además de ser una estructura coreográfica basada en repetición, estará realizando alguna operación preestablecida por su programa.
## Breve ejemplo de programa
Una operación relativamente sencilla a resolver para ejemplificar el proceso y un esbozo de la coreografía resultante, es la suma de dos números recibidos por la computadora, y la entrega de sus resultados. El algoritmo, numerado por instrucciones, sería algo como:
* 1) Pedir número y guardarlo en el registro temporal
* 2) Copiar el número del registro temporal a una posición X de la Memoria
* 3) Pedir número y guardarlo el registro temporal
* 4) Sumar el registro temporal con el número en la posición X de la Memoria
* 5) Entregar el resultado presente en el registro temporal
Al momento de su ejecución coreográfica, siguiendo el Ciclo de Instrucción, la secuencia de acciones quedaría algo como:
* Fetch: Intérprete se dirige a la posición #1 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como la instrucción dice: Pedir número y guardarlo en el registro temporal, el intérprete se dirige a la zona de entrada de datos a esperar un número. Ya que se recibe el número, el intérprete lo lleva al registro temporal. Como la instrucción terminó, se dirige a ver cuál es el número de la siguiente instrucción (#2).
* Fetch: Intérprete se dirige a la posición #2 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como la instrucción dice: Copiar el número del registro temporal a una posición X de la Memoria, el intérprete se dirige al registro temporal, copia el número ahí presente, y lo lleva a la posición X en la Memoria. Como la instrucción terminó, se dirige a ver cuál es el número de la siguiente instrucción (#3).
* Fetch: Intérprete se dirige a la posición #3 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como la instrucción dice: Pedir número y guardarlo en el registro temporal, el intérprete se dirige a la zona de entrada de datos a esperar un número. Ya que se recibe el número, el intérprete lo lleva al registro temporal. Como la instrucción terminó, se dirige a ver cuál es el número de la siguiente instrucción (#4).
* Fetch: Intérprete se dirige a la posición #4 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como la instrucción dice: Sumar el registro temporal con el número en la posición X de la Memoria, se dirige a la posición X de la Memoria, copia el número ahí presente y lo trae de regreso, se dirige al registro temporal y toma el número ahí presente, pasa ambos números por un proceso sumador, y el resultado lo coloca en el registro temporal. Como la instrucción terminó, se dirige a ver cuál es el número de la siguiente instrucción (#5).
* Fetch: Intérprete se dirige a la posición #5 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como la instrucción dice: Entregar el resultado presente en el registro temporal, el intérprete se dirige al registro temporal, copia el número ahí presente, y lo lleva a la zona de salida de datos. Como la instrucción terminó, se dirige a ver cuál es el número de la siguiente instrucción (#6).
* Fetch: Intérprete se dirige a la posición #6 en la Memoria y se lleva el número de la instrucción ahí guardada
* Execute: Intérprete regresa y ve qué acciones debe tomar de acuerdo al número de la instrucción. Como ya no hay instrucción, el programa se termina.
# Descripción de las actividades
Las actividades las podemos dividir en cuatro grandes etapas: El diseño abstracto de la arquitectura computacional, la realización de la computadora, la programación de la computadora, y la realización de objetos coreográficos y didácticos.
## Diseño abstracto de la arquitectura computacional
Esta etapa tiene como objetivo la creación del modelo computacional sobre el cual se realizará físicamente las operaciones. Básicamente hay tres componentes a establecer:
* El conjunto de instrucciones del microprocesador con sus códigos numéricos y descripciones.
* La microprogramación del microprocesador: cómo realizar el fetch cycle y el execute cycle para cada instrucción, paso a paso.
* La arquitectura computacional: cómo se conectarán y comunicarán los componentes, cómo se representarán los datos e instrucciones de forma numérica, incluyendo el rango de los números a utilizar, y cuál será el tamaño de la Memoria
## Realización de la computadora
En esta etapa el modelo computacional se debe aterrizar al mundo físico para que pueda funcionar. Los tres componentes básicos a establecer son:
* La implementación escenográfica de los componentes de la computadora: cómo se representarán los números en escena, tomando en cuenta su tamaño y las posibilidades de copiarlos y hacer operaciones con ellos; cómo se representarán las casillas ordenadas de la Memoria, y cómo se representarán las áreas funcionales de la computadora.
* Las acciones físicas para hacer funcionar a la computadora, interactuando con los datos numéricos y haciendo operaciones sobre ellos.
* La velocidad de operación de la computadora, procurando un entrenamiento cardiovascular completo para que el cuerpo se pueda encontrar bajo una gran demanda durante la ejecución de los programas.
## Programación
En esta etapa, con la computadora ya construida, es posible escribir y probar diversos programas, buscando:
* Que usen datos de entrada para pedirlos en escena y el algoritmo funcione a partir de ellos
* Complejidad y estética algorítmica ("la poesía del código")
* Ejecuciones físicas estéticamente interesantes
* Diferentes duraciones: 5, 10, 20, y 60 minutos.
## Objetos coreográficos y didácticos
El objetivo de esta etapa es desarrollar materiales multimedia para describir o replicar el funcionamiento de la computadora a partir del hecho coreográfico. Además, el proyecto puede tener una carga fuertemente didáctica sobre las ciencias computacionales, por lo que será necesario establecer estrategias para divulgar el conocimiento a partir del material creado.
# Objetivos que se pretenden conseguir
* Desarrollar de una obra coreográfica que funcione como una computadora programable de acuerdo a las descripciones anteriores.
* Desarrollar programas de diferentes duraciones para la computadora, que usen datos de entrada a pedir en escena y funcionen a partir de ellos.
* Construir objetos coreográficos y didácticos para utilizar a la obra como material de divulgación científica y artística.
# Referencias
=> http://www.alanturing.net/turing_archive/pages/Reference%20Articles/BriefHistofComp.html A Brief History of Computing.
=> http://www.yorku.ca/sychen/research/LMC/ Little Man Computer.
=> https://xkcd.com/505 Munroe, R. A bunch of rocks.
* Turing, A.M. (1936). "On Computable Numbers, with an Application to the Entscheidungs problem". Proceedings of the London Mathematical Society. 2 (1937) 42: 230265.
* von Neumann, John (1945), First Draft of a Report on the EDVAC

245
src/propuesta_poñg.gmo Normal file
View File

@ -0,0 +1,245 @@
# POÑG (Propuesta)
este texto fue enviado como parte de mi postulación para el programa jóvenes creadores (1)2020-(1)2021 del fonca, en la disciplina de medios audiovisuales, especialidad de nuevas tecnologías.
la propuesta no fue aceptada en la fase resolutiva.
# Descripción
POÑG es un videojuego digital a gran escala cuyo funcionamiento lógico es provisto por personas.
El juego es una simulación monocromática y con muy baja resolución (16x12) de un partido de tenis para dos personas jugadoras. Su funcionamiento se basa en un aparato de hardware digital diseñado con la intención de ser muy lento y relativamente amigable con el mundo vivo: en vez de requerir el uso de semiconductores para sus transistores, compuertas lógicas y/o circuitos integrados - componentes asumidos como necesarios en el mundo de la electrónica digital, y con un alto costo social y ambiental-, logra computar gracias a una o más personas operadoras, que son parte del equipo artístico y previamente preparadas para la labor.
POÑG se instala en un espacio amplio y abierto. Por un lado está la sala de juego, donde hay asientos para dos personas jugadoras del público, sus respectivas palancas de mando, y una gran pantalla de bombillas; aquí el demás público es invitado a turnarse para jugar y seguir el progreso del juego. Por otro lado está todo el aparato de hardware, transitado y manejado por las personas operadoras. Esta área parece laberinto, y aquí el público es invitado a recorrerlo y a observar la operación.
El aparato está conformado por materiales eléctricos sencillos y fáciles de reusar: cables, interruptores, y bombillas. Estos componentes están agrupados en múltiples bloques de interruptores rodeados por bombillas, y estos bloques están interconectados por un entramado complejo de cables.
Para funcionar, el juego depende de que las personas operadoras enciendan o apaguen cada uno de todos los interruptores que lo conforman, de acuerdo a una regla lógica simple.
Cuando estas personas terminan de evaluar las centenas de interruptores contenidos en el aparato, lo que han logrado es completar el procesamiento de un cuadro (frame) de la animación del videojuego, que un interruptor maestro les permite mostrar en la pantalla de bombillas de las personas jugadoras.
Con esta información en la pantalla, quienes juegan pueden elegir cambiar la posición de su palanca de mando, para después esperar el cómputo de la siguiente iteración que resultará en un cuadro (frame) distinto.
Así, jugando cuadro por cuadro y movida por movida, esperando el procesamiento de las personas operadoras, las jugadoras eventualmente (o no) podrán ganar el partido.
# Justificación
Las tecnologías de la información y de la comunicación, fundamentales para entender el estado actual de la civilización, se basan completamente en el uso de circuitos digitales fabricados con semiconductores. La miniaturización y la aceleración de estos circuitos, además de tener un gran costo ambiental, social y económico, los han convertido en literales cajas negras: se ha vuelto muy difícil el conocer y entender qué pasa en su interior, y cómo es que logran hacer emerger todas las capacidades que entendemos inherentes a estas tecnologías.
Por otro lado, la configuración social actual genera e incrementa una brecha de conocimientos y posibilidades entre unos cuantos que tienen el poder de desarrollar estas tecnologías digitales, y el resto de la población al que se le asigna únicamente un rol de consumo y de fuente de datos a extraer.
Este proyecto busca visibilizar fundamentos de los circuitos digitales, tomando una aplicación conocida -un juego- y transformando su hardware en un aparato miles de veces más grande y millones de veces más lento. Al exponer sus "tripas" y permitir el tránsito del público cerca de ellas, y al agregar en la ecuación al componente humano que ha de proveer la función lógica, se exhibe tanto literal como metafóricamente cómo es que paso a paso logra desarrollar su comportamiento: operaciones sencillas y repetitivas, realizadas por un "otro".
También, el proyecto busca invitar al público a observar el fenómeno de complejidad emergente: el hecho de que el juego surja únicamente a partir de la interconexión de múltiples operaciones sencillas y similares.
Por último, el proyecto también puede ser entendido como un ejercicio especulativo, que visualiza usos alternativos de lo eléctrico/electrónico, que imagina la posibilidad de recuperar y reutilizar desechos de infraestructura eléctrica, y que como juego lento agrega fricción al torrente contemporáneo de entretenimiento inmediato y sin fin.
El proyecto es viable desde el punto de vista técnico porque se apoya en la disciplina del diseño de hardware digital, un cuerpo de conocimientos que ha existido desde hace décadas pero que las abstracciones del software ha dejado relegado a un reducido grupo de personas.
Un año de trabajo es suficiente para desarrollar el proyecto: el proceso de creación se enfocará en el diseño digital del aparato, en el diseño y construcción de las interfases eléctricas (interruptores acompañados por bombillas, palancas de mando, pantalla de bombillas), en la configuración espacial del aparato y su red de cables, y en las posibilidades coreográficas de las personas operadoras, quienes manipularán los interruptores al "servicio" de las personas jugadoras.
# Objetivos del proyecto
* Diseñar y construir un videojuego monocromático y con muy baja resolución (16x12) de un partido de tenis para dos personas jugadoras, a nivel de compuertas lógicas NOR de escala humana.
* Visibilizar los mecanismos de complejidad emergente en el ámbito digital, exponiendo cómo un comportamiento de videojuego conocido puede obtenerse a partir de múltiples interruptores interconectados que siguen reglas lógicas simples.
* Plantear en la práctica una postura alternativa de creación computacional cuyos valores son la lentitud, la escala humana, la transparencia, la comunidad, y el no uso de semiconductores.
# Detalle de las obras a realizar
* Medidas: 8m x 8m x 2m
* Materiales: Bombillas LED, interruptores, cables, fuente de alimentación, personas operadoras.
* Duración: Funcionamiento continuo por turnos de 2 horas por persona operadora
# Producto cultural resultante (metas númericas)
* Una presentación pública del juego funcionando durante dos horas con dos personas operadoras.
* Un ejemplar completo del aparato del juego, que consistirá en una pantalla de 16x12 (192) bombillas LED; unas tres centenas de páneles de compuertas, con un interruptor, varios LED y terminales de conexión cada uno; dos palancas de mando; señalizaciones e indicaciones impresas; soportes estructurales; cableado etiquetado y organizado.
* Un repositorio en línea que documente el proyecto, incluyendo: descripción del diseño del hardware, en diagrama y en lenguaje verilog; texto que explique los bloques funcionales del diseño digital; diagramas de construcción del aparato; texto que instruya cómo construir el aparato; fotografías y videos del proceso de diseño de interfases físicas; fotografías y videos de las pruebas del aparato durante las distintas etapas del proceso; fotografías y video finales.
* Una maqueta en escala 1:10 del aparato completo y funcional.
* Un video de 10 minutos que documente y resuma el funcionamiento del juego en la Muestra Escénica.
* Colección de fotos del juego en funcionamiento durante la Muestra Escénica.
# Actividades por periodo (12)
## 2020-12-01 a 2020-12-31
Actividades:
* Diseño digital del juego, a nivel de compuertas NOR, y buscando estrategias de parametrización de bloques funcionales.
* Transcripción del diseño en Verilog, lenguaje descriptor de hardware.
* Simulación y verificación del diseño.
Metas:
* Archivo de texto con descripción del hardware a nivel de compuertas NOR en el lenguaje Verilog
* Conjunto de gráficas que muestren las condiciones y resultados de la simulación del diseño.
* Archivo de texto con notas que indiquen cómo la simulación verifica que el diseño funciona como esperado.
* Archivo de texto que documente las generalidades del diseño digital del juego.
## 2021-01-01 a 2021-01-31
Actividades:
* Obtención de la red de nodos eléctricos en el diseño.
* Diagramación de la distribución del cableado e interruptores en el espacio.
* Cálculo de materiales necesarios para maqueta.
Metas:
* Imagen en SVG con el diagrama completo del cableado del hardware.
* Archivo de texto con el resumen numérico de la cantidad de compuertas, nodos eléctricos e interconexiones.
* Archivo de texto que indique el procedimiento para llegar al diagrama de cableado a partir del diseño digital.
## 2021-02-01 a 2021-02-28
Actividades:
* Compra de materiales para maqueta
* Construcción de maqueta
* Verificación del funcionamiento de la maqueta
* Preparación del primer informe
Metas:
* Una maqueta del aparato completo a escala 1:10, construida y en correcto funcionamiento.
* Envío en tiempo y forma del Primer Informe
1er informe: del 24 de febrero al 2 de marzo de 2021
## 2021-03-01 a 2021-03-31
Actividades:
* Diseño y prototipado de la interfaz de las compuertas, que consisten en bloques con interruptores y bombillas
Metas:
* Una muestra en prototipo de la interfaz de las compuertas, con colocación de los componentes y terminales eléctricas funcionales.
* Colección de fotos que muestren las iteraciones de diseño y prototipado.
* Asistencia al Primer Encuentro con maqueta y muestra de interfaz de compuerta
1er encuentro: del 18 al 21 de marzo de 2021
## 2021-04-01 a 2021-04-30
Actividades:
* Diseño y prototipado de las palancas de mando de las personas jugadoras.
* Diseño y prototipado de la pantalla de bombillas
Metas:
* Una muestra en prototipo de las palancas de mando de las personas jugadoras.
* Una muestra en prototipo de una fracción de la pantalla de bombillas, con conectores eléctricos y manera modular de ser montada.
* Colección de fotos que muestren las iteraciones de diseño y prototipado.
## 2021-05-01 a 2021-05-31
Actividades:
* Cotización y compra de materiales: cable, interruptores, bombillas, conectores, soportes.
* Construcción de las interfases de compuertas
Metas:
* Al menos 75% de todas las interfases de compuertas, construidas y funcionales con conectores eléctricos y forma definida de ser montadas.
## 2021-06-01 a 2021-06-30
Actividades:
* Construcción de las interfases de compuertas
* Construcción de las palancas de mando
* Construcción de la pantalla de bombillas
* Preparación del Segundo Informe
Metas:
* Todas las interfases de compuertas, construidas y funcionales con conectores eléctricos y forma definida de ser montadas.
* Dos palancas de mando, construidas y funcionales con conectores eléctricos y forma definida de ser montadas.
* Al menos el 50% de la pantalla de 16x12 (192) bombillas, construida a partir de 12 bloques de 4x4, funcional con conectores eléctricos y forma definida de ser montada.
* Envío en tiempo y forma del Segundo Informe
2do informe: del 30 de junio al 6 de julio de 2021
## 2021-07-01 a 2021-07-31
Actividades:
* Construcción de la pantalla de bombillas
* Conexión completa del aparato para pruebas eléctricas y de funcionamiento
Metas:
* Toda la pantalla de 16x12 (192) bombillas, construida a partir de 12 bloques de 4x4, funcional con conectores eléctricos y forma definida de ser montada.
* Un video que muestre al aparato funcionando en su totalidad
* Asistencia al Segundo Encuentro con video del aparato funcionando
2do encuentro: del 22 al 25 de julio de 2021
## 2021-08-01 a 2021-08-31
Actividades:
* Construcción completa del aparato
* Exploración coreográfica para las personas operadoras
Metas:
* Un video y una colección de fotos que muestren al aparato completo funcionando
* Un manual indicando cómo armar el aparato desde el punto de vista eléctrico y mecánico
## 2021-09-01 a 2021-09-30
Actividades:
* Producción de audios con indicaciones y ambientes sonoros para la puesta en escena
* Producción de señalizaciones y gráficos a añadir al aparato
* Ensayos de las personas operadoras
Metas:
* Conjunto de archivos de audio a ser reproducidos durante la puesta en escena
* Conjunto de señalizaciones y gráficos impresos para agregar al aparato
* Un video y una colección de fotos que muestren a dos personas operadoras haciendo funcionar al aparato durante media hora.
## 2021-10-01 a 2021-10-31
Actividades:
* Construcción del aparato completo, con señalizaciones y fuentes de sonido.
* Ensayos de las personas operadoras
* Pruebas públicas en pequeña escala ("playtesting") y ajustes
* Preparación del Tercer Informe
Metas:
* Un video y una colección de fotos que muestren a dos personas operadoras haciendo funcionar al aparato por dos horas seguidas, con personas externas jugando.
* Envío en tiempo y forma del Tercer Informe
3er informe: del 13 al 19 de octubre de 2021
## 2021-11-01 a 2021-11-30
Actividades:
* Preparación y montaje de la Muestra Escénica
* Ensayos de las personas operadoras
* Finalización de la documentación
Metas:
* Muestra de POÑG durante al menos un turno de dos horas.
* Un video y colección de fotos documentando la muestra.
* Repositorio en línea con todos los materiales del proceso y archivos multimedia de documentación.
Muestra escénica • Primera muestra: del 4 al 7 de noviembre de 2021 •
Segunda muestra: del 18 al 21 de noviembre de 2021
Informes 1er informe: del 24 de febrero al 2 de marzo de 2021 2do
informe: del 30 de junio al 6 de julio de 2021 3er informe: del 13 al 19
de octubre de 2021 Encuentros 1er encuentro: del 18 al 21 de marzo de
2021 2do encuentro: del 22 al 25 de julio de 2021 Muestra escénica: •
Primera muestra: del 4 al 7 de noviembre de 2021 • Segunda muestra: del
18 al 21 de noviembre de 2021

View File

@ -4,16 +4,21 @@ the things that want to happen
# wiki
add the following pages and resources:
create and add the following pages and resources:
* page: wolfram 1d cellular automata
* link to "arte generativo en papel: reglas de wolfram" videos
* page: the beans computer, uploading the video somewhere
* page: manifestos (e.g. human powered computation machines)
* page: manifestos (e.g. human powered computation machines, proposals, abstracts)
* page: postcards computer
* page(s) : references and inspiration
* page(s) : desfases?
* page: el computador proposal
* page: poñg
* complete the mub page
complete, organize and clean de following:
* organize translations
* complete the {mub} page
* add machines to the {d-turing} page
* systematize classificatin in the {logiteca}

27
src/s-camino.gmo Normal file
View File

@ -0,0 +1,27 @@
# s-camino... el camino del ensamblador (?)
veo razones varias, múltiples, para el estudio poético y contemplativo de la computación a bajo nivel.
específicamente aquí me refiero al programar en el llamado lenguaje ensamblador (¿o idioma ensamblador?)
en otros contextos se puede hablar de que conviene hacerlo buscando eficiencia, velocidad, haciendo el sacrificio de descender por las escaleras para mover los fierros; ensuciarse las manos mientras se observa la complejidad del dispositivo... pero todo sea por la productividad y el resultado óptimo que se encontrará a final del tunel.
aquí no estamos en ese contexto, claramente. pero justo esa impracticidad, esa mugre, esa manualidad o artesanalidad, la imagen de que a fin de cuentas (solo) estamos moviendo bits de aquí para allá (conectados de tal manera que algo más sucede) es la que llama la atención.
¿qué tal si acompañamos a la máquina en un nivel cercano al que será su propósito (¿o condena?) de vida?
tomamos conciencia de cada uno de los pasos por la que la haremos pasar sin otra opción más que seguir, seguir, seguir…
y sí, al escribir y programar en ensamblador vamos con lentitud, porque las convenciones son extrañas (todo un dialecto que tal vez busca alejar a quien no tiene cierto perfil), porque es un mundo que contrasta con la costumbre de la eficiencia, de los resultados inmediatos.
además, ¿cuál es la prisa, por qué querer hacer tanto?
hacer un programa se puede convertir en un ritual; la invocación del libro de instrucciones y conexiones, la planeación y reflexión antes de escribir la primera letra; tardarse horas en algo que aquellas estructuras de facilidad, practicidad, te permiten hacer en minutos, segundos (¿pero te quitan toda la magia, todo el asombro y confrontación con lo que realmente está pasando?)
la no portabilidad del código está a nuestro favor, porque implica rehacerlo cada vez (o cuando sea necesario), re-contemplar, ir lento. de nuevo, ¿cuál es la prisa?
estoy de acuerdo, es un mundo inaccesible (¿similar a cualquier otro tipo de hechicería?), pero parte de la labor que me autoasigno es hacerle puertas (o grietas, hoyos, y adentro madrigueras) para poderlo compartir.
no cualquiera tiene el tiempo... igual aquí andaremos, con paciencia, y un paso a la vez.
(escrito el 12019-07-05)

View File

@ -2,6 +2,8 @@
public appearances of the project.
see also {performances}
# upcoming
## june 12021

3
src/verilog.gmo Normal file
View File

@ -0,0 +1,3 @@
# verilog
lenguaje de descripción de hardware digital