(Esta entrada es la quinta parte de una serie que cubre un proyecto personal que realicé en el verano de 2014; pueden ver todas las partes aquí).

La parte crucial de mi proyecto, sin la cual nada más podía llevarse a cabo, fue comprar un Teensy++ 2.0.

Teensy++ 2.0

Esto sí no tengo ni la más remota idea de cómo conseguirlo en México. Debe ser posible, pero maldito si acaso sé dónde preguntar al menos.

El Teensy++ 2.0 es un sistema de desarrollo microcontrolador… definición que probablemente les sirva tanto a ustedes como inicialmente me sirvió a mí. Para la gente que sabe de desarrollo en hardware, lo más sencillo tal vez sea decirles que el Teensy++ 2.0 es básicamente un Arduino; puede utilizar las bibliotecas de Arduino, e incluso el ambiente de desarrollo, y es (hasta donde tengo entendido) casi 100% compatible con Arduino.

Para la gente (como yo) con antecedentes de programación, la mejor descripción del Teensy++ 2.0 es que es hardware “programable”. La chingaderita (mide como 5×2 centímetros) tiene un montón de compuertas lógicas; yo como programador escribo un programa en C, y una versión especial de gcc (el compilador normal de C de Linux) genera un ejecutable que puedo convertir a un binario, el cual puedo quemar (flash, le dicen) en el Teensy++ 2.0 como firmware.

En otras palabras, aunque Turing completo (la tarjeta es capaz de ejecutar cualquier programa, si tiene suficiente memoria), el Teensy++ 2.0 no es un CPU dado que no tiene realmente un conjunto de instrucciones… pero podría programarle un CPU con el conjunto de instrucciones que se me diera la gana, como hicimos en mi proyecto final de Arquitectura en la maestría. Aunque probablemente necesitaría más memoria.

Programar el Teensy++ 2.0 es deliciosamente restrictivo; olvídense de asignar memoria, mejor ni intentar utilizar recursión, y casi todas las variables más vale que sean globales y estáticas. También hace cosas raras para un programador como yo que casi nunca piensa en el hardware; por ejemplo, transmitir un bit por uno del montón de pines que tiene, se consigue asignándole 0 o 1 a una variable especial (por ejemplo, UEDATX).

Hay una comunidad bastante grande de gente que utiliza el Teensy++ 2.0 para cualquier cantidad de proyectos; échenles un ojo si quieren.

El hardware es realmente restrictivo; desde el punto de vista de software, no puede hacer mucho… y si somos justos, de hecho casi no puede hacer nada. ¿Para qué podría interesarme entonces a mí, que soy programador antes que nada? Pues obviamente me interesaba por lo que puede hacer desde el punto de vista de hardware.

¿Ven el conector mini USB que tiene el Teensy++ 2.0 en la imagen de arriba? Ahí se le conecta el cable USB con el cual quemo mis “programas” en la tarjeta. Pero no es para lo único que sirve.

El Teensy++ 2.0 tiene la capacidad de emular un dispositivo USB.

Y en particular, puede emular un dispositivo HID-USB.

Estrellita en la frente a mis lectores que puedan adivinar a dónde voy con todo esto.

(Esta entrada es la cuarta parte de una serie que cubre un proyecto personal que realicé en el verano de 2014; pueden ver todas las partes aquí).

El control DualShock 3 es el control que, a partir de 2008, viene por omisión con el PlayStation 3, reemplazando (o mejor sería decirlo, extendiendo) al control SixAxis. Casi universalmente reconocido como uno de los mejores controles para videojuegos en existencia, ahora está siendo reemplazado por el DualShock 4, que es el que viene incluido con el PlayStation 4.

El DualShock 3 tiene muchas características que lo hacen interesante incluso fuera del ámbito de videojuegos; es un dispositivo Bluetooth y USB-HID casi estándar, lo que nos permite usarlo de forma casi inmediata en cualquier computadora moderna. El “casi” es porque la conectividad Bluetooth tiene un paso no estándar para autenticar al control con un PlayStation 3; y en el caso de USB-HID, existe al menos una función del dispositivo que yo no he logrado entender, pero que no es muy importante.

Lo de Bluetooth no me importa demasiado; que el dispositivo sea USB-HID en cambio lo hizo una de las piezas más en el rompecabezas de mi proyecto veraniego.

Continuando la introducción que dí de USB-HID, como el DualShock 3 es un dispositivo ídem, podemos analizar su reporte descriptivo en Linux utilizando lsusb. En esa entrada comentaba que para lograrlo hay que utilizar un truquito; la cosa es que si el dispositivo ya está controlado por el módulo usbhid del kernel (que ocurre de forma automática), el reporte descriptivo queda invisible, entonces hay que “liberar” al dispositivo del módulo. La explicación técnica se puede leer en este artículo de LWN.net, pero la manera rápida y sucia de hacerlo es haciendo

echo -n '3-1:1.0' > /sys/bus/usb/drivers/usbhid/unbind

en una terminal como superusuario; por supuesto, 3-1:1.0 es la dirección física donde conecté el DualShock 3 en mi computadora, tienen que usar la correcta en la suya.

Como sea, hecho el truco, el reporte descriptivo del DualShock 3 es este:

Report Descriptor: (length is 148)
  Item(Global): Usage Page, data= [ 0x01 ] 1
                  Generic Desktop Controls
  Item(Local ): Usage, data= [ 0x04 ] 4
                  Joystick
  Item(Main  ): Collection, data= [ 0x01 ] 1
                  Application
  Item(Main  ): Collection, data= [ 0x02 ] 2
                  Logical
  Item(Global): Report ID, data= [ 0x01 ] 1
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x01 ] 1
  Item(Global): Logical Minimum, data= [ 0x00 ] 0
  Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
  Item(Main  ): Input, data= [ 0x03 ] 3
                  Constant Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Global): Report Size, data= [ 0x01 ] 1
  Item(Global): Report Count, data= [ 0x13 ] 19
  Item(Global): Logical Minimum, data= [ 0x00 ] 0
  Item(Global): Logical Maximum, data= [ 0x01 ] 1
  Item(Global): Physical Minimum, data= [ 0x00 ] 0
  Item(Global): Physical Maximum, data= [ 0x01 ] 1
  Item(Global): Usage Page, data= [ 0x09 ] 9
                  Buttons
  Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                  Button 1 (Primary)
  Item(Local ): Usage Maximum, data= [ 0x13 ] 19
                  (null)
  Item(Main  ): Input, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Global): Report Size, data= [ 0x01 ] 1
  Item(Global): Report Count, data= [ 0x0d ] 13
  Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
                  (null)
  Item(Main  ): Input, data= [ 0x03 ] 3
                  Constant Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Global): Logical Minimum, data= [ 0x00 ] 0
  Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
  Item(Global): Usage Page, data= [ 0x01 ] 1
                  Generic Desktop Controls
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Collection, data= [ 0x00 ] 0
                  Physical
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x04 ] 4
  Item(Global): Physical Minimum, data= [ 0x00 ] 0
  Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
  Item(Local ): Usage, data= [ 0x30 ] 48
                  Direction-X
  Item(Local ): Usage, data= [ 0x31 ] 49
                  Direction-Y
  Item(Local ): Usage, data= [ 0x32 ] 50
                  Direction-Z
  Item(Local ): Usage, data= [ 0x35 ] 53
                  Rotate-Z
  Item(Main  ): Input, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Main  ): End Collection, data=none
  Item(Global): Usage Page, data= [ 0x01 ] 1
                  Generic Desktop Controls
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x27 ] 39
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Input, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x30 ] 48
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Output, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x30 ] 48
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Feature, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Main  ): End Collection, data=none
  Item(Main  ): Collection, data= [ 0x02 ] 2
                  Logical
  Item(Global): Report ID, data= [ 0x02 ] 2
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x30 ] 48
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Feature, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Main  ): End Collection, data=none
  Item(Main  ): Collection, data= [ 0x02 ] 2
                  Logical
  Item(Global): Report ID, data= [ 0xee ] 238
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x30 ] 48
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Feature, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Main  ): End Collection, data=none
  Item(Main  ): Collection, data= [ 0x02 ] 2
                  Logical
  Item(Global): Report ID, data= [ 0xef ] 239
  Item(Global): Report Size, data= [ 0x08 ] 8
  Item(Global): Report Count, data= [ 0x30 ] 48
  Item(Local ): Usage, data= [ 0x01 ] 1
                  Pointer
  Item(Main  ): Feature, data= [ 0x02 ] 2
                  Data Variable Absolute No_Wrap Linear
                  Preferred_State No_Null_Position Non_Volatile Bitfield
  Item(Main  ): End Collection, data=none
  Item(Main  ): End Collection, data=none

Eso se ve medianamente intimidante; pero después de perder el tiempo con el estándar USB-HID, de hecho se vuelve legible. Voy a comentar algunas partes del reporte descriptivo, pero siguiendo su notación en bytes con comentarios en C:

0x05, 0x01,        /* Usage Page (Generic Desktop Ctrls) */
0x09, 0x04,        /*/ Usage (Joystick) */
0xA1, 0x01,        /* Collection (Physical) */

Este es sencillamente el encabezado donde especifica que lo que sigue es la descripción del un joystick.

0xA1, 0x02,        /*   Collection (Application) */
0x85, 0x01,        /*     Report ID (1) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x01,        /*     Report Count (1) */
0x15, 0x00,        /*     Logical Minimum (0) */
0x26, 0xFF, 0x00,  /*     Logical Maximum (255) */
0x81, 0x03,        /*     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) */

El DualSock 3 reserva el primer byte; no tengo idea para qué, pero al menos en mis controles nunca envía nada distinto a 0x00.

0x75, 0x01,        /*     Report Size (1) */
0x95, 0x13,        /*     Report Count (19) */
0x15, 0x00,        /*     Logical Minimum (0) */
0x25, 0x01,        /*     Logical Maximum (1) */
0x35, 0x00,        /*     Physical Minimum (0) */
0x45, 0x01,        /*     Physical Maximum (1) */
0x05, 0x09,        /*     Usage Page (Button) */
0x19, 0x01,        /*     Usage Minimum (0x01) */
0x29, 0x13,        /*     Usage Maximum (0x13) */
0x81, 0x02,        /*     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) */
0x75, 0x01,        /*     Report Size (1) */
0x95, 0x0D,        /*     Report Count (13) */
0x06, 0x00, 0xFF,  /*     Usage Page (Vendor Defined 0xFF00) */
0x81, 0x03,        /*     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) */

4 bytes, o un entero de 32 bits (es exactamente lo mismo), para representar potencialmente 32 botones; actualmente sólo 19 de hecho son considerados (bits 0-18), y 13 reservados para uso futuro (bits 19-31).

0x15, 0x00,        /*     Logical Minimum (0) */
0x26, 0xFF, 0x00,  /*     Logical Maximum (255) */
0x05, 0x01,        /*     Usage Page (Generic Desktop Ctrls) */
0x09, 0x01,        /*     Usage (Pointer) */
0xA1, 0x00,        /*     Collection (Undefined) */
0x75, 0x08,        /*       Report Size (8) */
0x95, 0x04,        /*       Report Count (4) */
0x35, 0x00,        /*       Physical Minimum (0) */
0x46, 0xFF, 0x00,  /*       Physical Maximum (255) */
0x09, 0x30,        /*       Usage (X) */
0x09, 0x31,        /*       Usage (Y) */
0x09, 0x32,        /*       Usage (Z) */
0x09, 0x35,        /*       Usage (Rz) */
0x81, 0x02,        /*       Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) */
0xC0,              /*     End Collection */

Cuatro ejes: X, Y, Z, y rotación de Z. Cada eje es un byte (“Report Size (8)”), y se toma el valor del byte menos 127 como el valor del eje; en otras palabras, 0 – 127 = -127 es el eje en su posición más baja (o a la izquierda), 127 – 127 = 0 es el eje en “reposo” (centrado), y 255 – 127 = 128 es el eje en su posición más alta (o a la derecha). El DualShock 3 utiliza el estándar HID para definir eje Z y rotación de Z, pero esos dos realmente son los ejes del joystick derecho, y los dos primeros ejes son los del joystick izquierdo.

0x05, 0x01,        /*     Usage Page (Generic Desktop Ctrls) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x27,        /*     Report Count (39) */
0x09, 0x01,        /*     Usage (Pointer) */
0x81, 0x02,        /*     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x30,        /*     Report Count (48) */
0x09, 0x01,        /*     Usage (Pointer) */
0x91, 0x02,        /*     Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x30,        /*     Report Count (48) */
0x09, 0x01,        /*     Usage (Pointer) */
0xB1, 0x02,        /*     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) */
0xC0,              /*   End Collection */
0xA1, 0x02,        /*   Collection (Application) */
0x85, 0x02,        /*     Report ID (2) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x30,        /*     Report Count (48) */
0x09, 0x01,        /*     Usage (Pointer) */
0xB1, 0x02,        /*     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) */
0xC0,              /*   End Collection */
0xA1, 0x02,        /*   Collection (Application) */
0x85, 0xEE,        /*     Report ID (238) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x30,        /*     Report Count (48) */
0x09, 0x01,        /*     Usage (Pointer) */
0xB1, 0x02,        /*     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) */
0xC0,              /*   End Collection */
0xA1, 0x02,        /*   Collection (Application) */
0x85, 0xEF,        /*     Report ID (239) */
0x75, 0x08,        /*     Report Size (8) */
0x95, 0x30,        /*     Report Count (48) */
0x09, 0x01,        /*     Usage (Pointer) */
0xB1, 0x02,        /*     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) */
0xC0,              /*   End Collection */
0xC0,              /* End Collection */

Esta última parte explica cómo el reporte entero del dispositivo utiliza 48 bytes (más uno de identificador): 3 colecciones de 8 bytes de “controles de escritorio genérico” (“Generic Desktop Ctrls”), y tres colecciones de 8 bytes de aplicación.

El byte 0 sirve de identificador y (hasta donde he visto) es siempre 1.

El byte 1 (como dije arriba) está reservado; los siguientes 4 bytes (bytes 2-5) tienen información de los botones: bit prendido siginifica que el botón está presionado; apagado implica no presionado. Aunque son 32 bits en total (4 bytes), realmente sólo se usan 19, con 13 reservados.

Los bytes 6, 7, 8 y 9 son los ejes de los joysticks, y a partir del 10 (realmente 13; 10, 11 y 12 sólo me reportan ceros) hasta el 24 son las presiones de cada botón: 0 es el botón casi no está presionado, 255 es el botón está completamente presionado. Esas son las 3 colecciones de escritorio genérico (24 bytes). Los otros 24 bytes contienen las colecciones de aplicación, pero hasta donde entiendo sólo se usan los bytes 41-48; 2 bytes para el acelerómetro X, 2 bytes para el acelerómetro Y, 2 bytes para el acelerómetro Z, y dos bytes para el giroscopio. No tengo idea qué carajo hagan los bytes 25-40, pero en uno de mis controles siempre reporta:

00 00 00 00 03 ef 16 00 00 00 00 33 ae 77 00 40

A lo mejor ahí estarán las presiones de los 13 botones reservados. Por cierto, todo esto es como yo lo he entendido; si estoy entendiendo algo mal, por favor díganme.

¿Para qué sirve todo esto? Para mi proyecto de verano, no me sirvió de mucho; pero sí será de utilidad (de hecho ya lo fue) para otro miniproyecto relacionado. Con la información de arriba puedo leer bit a bit la información que un DualShock 3 envía; pero esto, además de que hay formas mucho más sencillas de hacerlo (por no decir de mucho más alto nivel), cualquier güey lo hace. Yo quería hacer algo más interesante (y lo hice).

En la siguiente parte de esta serie explicaré la pieza principal del rompecabezas. No sé si con ello ya quede claro mi proyecto; pero si no, la entrada que le seguirá debería dejarlo claro.

(Esta entrada es la tercera parte de una serie que cubre un proyecto personal que realicé en el verano de 2014; pueden ver todas las partes aquí).

La familia de adaptadores USB ↔ serial cp210x es bastante común para la gente que quiere comunicarse con hardware de forma serial. Hace unos años (tal vez habría que decir décadas) no era necesario utilizar este tipo de adaptadores: todas las computadoras tenían al menos un conector de este estilo incluido, llamado (imaginativamente) el puerto serial (serial port); en el mundo de DOS se le conocía como COM1 (y si había más eran COM2, etc.), y yo todavía llegué a conectar algún módem de esta manera a una computadora.

Como decía en la entrada anterior de esta serie, el estándar USB ha reemplazado a casi todos los conectores de la antigüedad; los conectores PS1, paralelo, y serial incluidos. Por lo tanto, si alguien quiere (como yo quería) comunicarse de forma serial usando una computadora moderna, uno necesita un adaptador USB ↔ serial.

Leyendo en Internet, rápidamente me decidí por un CP2102 UART Bridge, que encontré a precio de ganga en Amazon; el que ligo cuesta casi 7 dólares, pero el que de hecho compré me salió en menos de 3, con envío incluido. Lamentablemente, no sé dónde conseguir este tipo de cosas en México, así que lo pedí por Amazon y lo envié a la dirección de Omar en Boston (Amazon generalmente no envía electrónicos fuera del gabacho), donde lo recogí cuando pasé a verlo a finales de mayo.

CP2102

(Siendo 100% honesto, sí lo encontré en MercadoLibre; pero el precio era más del doble).

Me decidí por el CP2102 básicamente porque es muy barato, y porque está muy bien soportado en Linux (niguna de esas razones me sorprende; no hace nada terriblemente interesante). En Gentoo, sencillamente tuve que habilitar el módulo del kernel cp210x (funciona para el CP2101 y el CP2103 también), con la opción USB_SERIAL_CP210X, y después sencillamente lo conecté a mi computadora. Inmediatamente el adaptador queda registrado con el dispositivo /dev/ttyUSB0, y uno puede comenzar a usarlo sin problemas.

Bueno, casi; el dispositivo por omisión tiene permisos de escritura únicamente para root, así que usando la siguiente regla de udev:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE:="0666"
KERNEL=="ttyUSB*", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE:="0666"

puedo darle permisos a todo mundo de forma automática, lo que me permite que mis aplicaciones corran para cualquier usuario.

Como sea; el CP2102 es bastante sencillo de usar (si es que acaso el hardware está bien conectado), uno únicamente abre el dispositivo, y puede empezar a escribir y leer información de él sin muchos problemas:

#include <termios.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#define TTY_BAUDRATE   B38400

int
main(int argc, char* argv[])
{
        struct termios options;
        int fd;

        if ((fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK)) < 0) {
                return -1;
        } else {
                tcgetattr(fd, &options);
                cfsetispeed(&options, TTY_BAUDRATE);
                cfsetospeed(&options, TTY_BAUDRATE);
                cfmakeraw(&options);
                if (tcsetattr(fd, TCSANOW, &options) < 0) {
                        close(fd);
                        return -1;
                }
                tcflush(fd, TCIFLUSH);
        }

        uint8_t byte = 0xff;

        /* Envía byte. */
        int r = write(fd, &byte, 1);
        tcflush(fd, TCIFLUSH);

        /* Recibe byte. */
        fd_set readfds;

        struct timeval timeout = {
                .tv_sec = 1,
                .tv_usec = 0
        };

        FD_ZERO(&readfds);
        FD_SET(fd, &readfds);

        int status = select(fd+1, &readfds, NULL, NULL, &timeout);
        if (!status)
                return -1;
        
        if (FD_ISSET(fd, &readfds)) {
                r = read(fd, &byte, 1);
        } else if(status == EINTR) {
                return -1;
        }

        return (int)byte;
}

Obviamente se pueden transmitir secuencias de bytes más largas que 1, pero para lo que quería hacer 1 bastaba… o al menos no he necesitado más.

Por supuesto, el chiste de todo esto es, ¿a dónde van esos bytes que estoy enviando? El adaptador CP2120 únicamente me permite comunicarme de forma serial vía USB; es sólo una pieza más del rompecabezas que estuve armando para mi proyecto. Y, en retrospectiva, de hecho fue la pieza más sencilla; casi no tuve que hacer nada para que funcionara.

Del resto de las piezas escribiré más adelante.

(Esta entrada es la segunda parte de una serie que cubre un proyecto personal que realicé en el verano de 2014; pueden ver todas las partes aquí).

USB ha tenido a bien reemplazar casi todos los conectores de una computadora; en el caso de los teléfonos celulares inteligentes modernos (que son realmente computadoras), de hecho reemplaza todos los conectores, excepto el conector para audífonos. Bueno; hablo de teléfonos celulares civilizados: obviamente el iPhone tiene que tener su conector propietario, porque si no cómo le van a cobrar millones de dólares a sus usuarios cuando quieran reemplazarlo.

El bus serial universal (que es lo que USB significa) ha tenido este éxito por muchos motivos, de los cuales no voy a mencionar ni uno solo. Yo de lo que quiero escribir hoy aquí es de la clase USB para dispositivos con interfaz humana, o USB human interface device class en inglés.

Un dispositivo de clase USB-HID tiene la capacidad de decirle a la computadora a la cual se conecta ciertos datos; si es un teclado, por ejemplo, cuántas teclas tiene; si es un ratón, que resolución tiene el sistema de coordenadas que puede manejar; si es un joystick o gamepad, cuántos ejes y botones tiene, etc. Como USB-HID es un estándar abierto, en general esto permite que no haya necesidad de escribir controladores (drivers) para estos dispositivos: todos los sistemas operativos en existencia los soportan de manera nativa. Uno sólo conecta el dispositivo USB-HID a la computadora, y el mismo dispositivo le dice qué es, y qué características tiene. La computadora puede entonces comenzar a usar el dispositivo de inmediato, porque éste ya le dijo qué le puede pedir.

Voy a hacer la historia corta: le pide bytes. Lo único que debe hacer el dispositivo es explicarle a la computadora qué significa el bit número X del byte Y en el reporte que cada determinado número de milisegundos la computadora le pide. Es a la vez primitivo y elegante el asunto.

Cuando el dispositivo USB-HID se conecta a la computadora, ésta le pide un descriptor de dispositivo (device descriptor), el cual tiene información como qué protocolo utiliza, cuántas configuraciones maneja, y lo más visible para todo mundo, dos llaves de diccionario para el identificador de fabricante y el identificador de producto. Estas dos llaves son en Linux muy fáciles de revisar (me imagino que en otros sistemas operativos también; pero como no los uso, no tengo idea); usando el comando lsusb en mi laptop produce el siguiente resultado:

canek@acero ~ $ lsusb
Bus 004 Device 004: ID 8086:0189 Intel Corp. 
Bus 004 Device 003: ID 1bcf:288e Sunplus Innovation Technology Inc. 
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 031: ID 18d1:4ee1 Google Inc. Nexus 4 / 10
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 008: ID 0461:0010 Primax Electronics, Ltd HP Keyboard
Bus 001 Device 009: ID 0461:4d0f Primax Electronics, Ltd HP Optical Mouse
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Las primeras columnas vienen de Linux; especifican el puerto USB físico donde están conectados los dispositivos. La últimas columnas, que son humanamente legibles ("Primax Electronics, Ltd HP Keyboard") son entradas de un diccionario que Linux y todos los sistemas operativos modernos mantienen; es una base de datos que especifica qué información corresponde a las llaves que se muestran en la columna central ("0461:0010"), y que de hecho es la única información que viene del dispositivo USB. El primer número hexadecimal (0x0461) es el identificador de fabricante (VendorId), y el segundo (0x0010) es el identificador de producto (ProductId).

Además del identificador de dispositivo, un dispositivo USB-HID le envía a la computadora un reporte descriptivo (report descriptor) que es donde se (valga la rebuznancia) describe lo que el dispositivo puede o no puede hacer. Usando algunas opciones extras de lsusb, podemos ver esta información:

canek@acero ~ $ lsusb -vvv -d 0461:0010
...
          Report Descriptor: (length is 65)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x06 ] 6
                            Keyboard
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Global): Usage Page, data= [ 0x07 ] 7
                            Keyboard
            Item(Local ): Usage Minimum, data= [ 0xe0 ] 224
                            Control Left
            Item(Local ): Usage Maximum, data= [ 0xe7 ] 231
                            GUI Right
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x08 ] 8
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Main  ): Input, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Global): Usage Page, data= [ 0x08 ] 8
                            LEDs
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            NumLock
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Scroll Lock
            Item(Main  ): Output, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x05 ] 5
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Output, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x06 ] 6
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
            Item(Global): Usage Page, data= [ 0x07 ] 7
                            Keyboard
            Item(Local ): Usage Minimum, data= [ 0x00 ] 0
                            No Event
            Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255
                            (null)
            Item(Main  ): Input, data= [ 0x00 ] 0
                            Data Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
...

(Estoy aquí usando un truco en el que no quiero entrar en detalle; pero básicamente así podemos obtener el reporte descriptivo).

Esa información que está allá arriba es bastante legible para un humano; de nuevo, Linux es el que está haciendo esa chamba por nosotros. El dispositivo lo que envía son una serie de bytes codificados para expresar lo de arriba; por ejemplo, el primer elemento especifica un “Usage Page: Generic Desktop”: esto está codificado por los bytes 0x05 (Usage Page), y 0x01 (Generic Desktop). El segundo elemento es un “Usage: Keyboard”, que está codificado por los bytes 0x09 (Usage) y 0x06 (Keyboard). En todos los tutoriales en línea esto se suele representar así (usando C, pero cualquier lenguaje funciona):

0x05, 0x01, /* Usage Page (Generic Desktop) */
0x09, 0x06, /* Usage (Keyboard) */
...

Pero obviamente lo que la computadora recibe es 0x05 0x01 0x09 0x06 ...

Con esta información, la computadora sabe cuántos bytes pedirle a un dispositivo USB-HID, y qué codifica cada uno de estos bytes; el estándar es (paradójicamente) muy flexible e increíblemente rígido al respecto. Muy flexible porque uno puede enviar vía USB básicamente lo que a uno se le dé la regalada gana; pero los reportes descriptivos sólo codifican información para un puñado de cosas: ejes, botones/teclas apretados o no apretados, y cosas de este estilo. Sin embargo, como todo esto son únicamente bytes, uno puede darle la vuelta sencillamente describiéndolo como un “eje”, cuando en realidad está enviando un número que representa la temperatura en grados centígrados. O lo que sea; la verdad no leí el estándar completo (lo pueden bajar aquí), sólo lo hojeé hasta que me salí con la mía.

Y con la mía me salí; aunque no al 100%: aún hay un detalle que necesito resolver, pero es secundario a mis principales objetivos, y lo que quería hacer ya lo hice casi absolutamente todo. Pero si quisiera resolver absolutamente todo, debería leer con cuidado el estándar y ver si le puedo dar la vuelta al último obstáculo que me he encontrado.

De eso escribiré más adelante.

(Esta entrada es la primera parte de una serie que cubre un proyecto personal que realicé en el verano de 2014; pueden ver todas las partes aquí).

Clásico: digo que no debería dejar de escribir, y prontamente decido dejar de escribir durante tres semanas. El motivo por el cual no he escrito estas semanas, es porque durante estas vacaciones (además de meditar y tomar decisiones Muy Importantes™) me he estado divirtiendo como pocas veces en mi vida, trabajando en un proyecto personal que está básicamente terminado, ya que sólo falta una pequeña pieza del rompecabezas.

Esta entrada es acerca de otra de las piezas: el formato MIDI.

Durante mis dos últimos años en el CCH Sur, llevé a la escuela una guitarra todos los días. El resultado de esto fue que puedo tocar (mal) un puñado de canciones, y algunas de ellas hasta las puedo cantar (peor todavía). Tomé un cursito de guitarra bastante malo, que además no terminé, y el resto de mi educación musical fue juntarme con los chavos que tocaban la guitarra y tratar de robarles los acordes y/o requintos.

Además de eso, y al igual que (me imagino) casi todos los estudiantes de secundaria pública en el país, tuve una flauta dulce donde alguna vez (recuerdo vagamente) llegué a tocar la Oda a la Alegría de Beethoven.

Y ya: esa es toda la “educación” musical que he tenido; no sé nada de teoría musical, soy incapaz de leer una partitura, y mientras que creo que soy capaz de dibujar o esculpir algo que al menos se parezca un poco a lo que tuviera en mi mente antes de empezar, me sentiría completamente inhabilitado para poder reproducir en ningún instrumento una tonadita que yo me inventara… y de hecho no estoy seguro de poder inventarme una tonadita.

Todo lo anterior es para explicar por qué yo, asiduo como soy a casi todo relacionado con la computadora, jamás utilicé ni me interesó mucho el formato MIDI.

Para finales de los setentas del siglo pasado la música electrónica había evolucionado de ser un curioso experimento a ser parte fundamental del acto de varios artistas, y los instrumentos electrónicos tenían la enorme ventaja de poder guardar y reproducir las actuaciones de los artistas que los utilizaban, usando una fracción minúscula del ancho de banda que usan los instrumentos analógicos.

Me explico: si yo con mi guitarra de Paracho, Michoacán, quiero grabar Wendolyne, no tengo de otra sino poner un micrófono enfrente de la misma y grabar las vibraciones del aire en formato WAVE, que es del orden (más o menos) de diez megabytes por cada minuto de audio. Claro, ahora en el siglo XXI podemos utilizar MP3, que mejora en un orden de magnitud las cosas a (más o menos) un megabyte por minuto; pero las computadoras personales de finales de los setentas no tenían suficiente procesador para poder reproducir MP3 (básicamente no existían, además), a nadie en su sano juicio se le había ocurrido inventar MP3, e incluso si hubiera habido suficiente procesador, un megabyte por minuto era una fortuna en ese entonces.

Los instrumentos electrónicos pueden superar esto por mucho, porque en lugar de guardar vibraciones del aire, sencillamente pueden guardar la información musical: en el segundo 0, se tocó la nota Do a tal volumen y velocidad; en el segundo 0.024 se tocó la nota Mi a tal volumen y velocidad; en el segundo 0.57 se tocó la nota Ra a tal volumen y velocidad (si no entienden el chiste yo no se los voy a explicar). En casi todos los instrumentos electrónicos, las notas son sencillamente cerrar un circuito, así que guardando el tiempo en que el circuito se cierra y cuando se abre de nuevo, uno puede guardar casi perfectamente la información interesante de un acto.

A finales de los setentas casi todos los fabricantes de instrumentos electrónicos tenían formatos propietarios, que hacía que los músicos se jalaran las greñas porque era muy común que les gustara usar el teclado electrónico de un fabricante, y la batería electrónica de otro; lo que ocasionaba que combinar las distintas grabaciones fuera un infierno porque utilizaban formatos distintos.

Para inicios de los ochentas los fabricantes decidieron ponerse de acuerdo, y se creó el formato MIDI, que especifica en doloroso detalle no sólo el formato digital (unos y ceros) de MIDI, sino también cosas como conectores, voltajes, y otras cosas que únicamente a músicos podrían interesarles.

A mí no me importa nada fuera de los unos y los ceros; conectores, voltajes, y cosas de músicos me tienen sin cuidado. El formato de los archivos MIDI (generalmente con extensión .mid) es lo que tuve que estudiar y programar.

Un archivo MIDI tiene un simple encabezado de 12 bytes donde se especifica el número de pistas que tendrá; es común (pero no obligatorio) que cada pista represente las notas de un instrumento distinto. Cada una de las pistas consiste en “eventos”, donde se especifica el tiempo del evento, el evento mismo, y uno o dos parámetros del mismo. En el caso de las notas, los eventos son generalmente “nota prendida” y “nota apagada”, un canal (cada pista puede tener hasta 16 canales), el número de la nota, y la duración (o velocidad) de la misma. Estos son los eventos que a mí me interesaban; y más aún, me interesaban los eventos de un único instrumento.

Todo el formato MIDI está pensado para poder utilizar el mínimo número de bits posible; y lo consigue de forma magistral: todo el Carmina Burana debe utilizar menos de un megabyte de memoria, incluyendo todos los instrumentos de la orquesta. El precio que se paga es que esta información es inútil si uno no tiene lo necesario para reproducirlo; para reproducir un archivo MIDI propiamente, uno necesita “fuentes de sonido” (sound fonts), que es básicamente los sonidos de las notas de todos los posibles instrumentos que el archivo MIDI necesita. Sin una buena fuente de sonido, cualquier archivo MIDI suena básicamente como la musiquita de Super Mario Bros.

Cuando comencé a usar la computadora a inicios de los noventas, y cuando compré mi primea SoundBlaster, todavía llegué a toparme con archivos MIDI; pero justamente como nunca me molesté en buscar fuentes de sonido, nunca le vi mucho sentido, porque todo sonaba como la musiquita de Super Mario Bros. Con una buena fuente de sonido, hacer música con MIDI debe ser bastante chido, y de hecho casi todos los músicos profesionales en la actualidad lo utilizan de alguna u otra forma.

Como sea, y volviendo al formato de los archivos MIDI, cuando digo que los eventos tienen un “tiempo”, este tiempo no está representado en segundos, ni milisegundos, ni microsegundos. De hecho, olvídense de segundos; el tiempo está representado en… ¿saben qué? Aún ahora no sé en qué chingados está representado el tiempo; tiene que ver con pulsaciones por segundo, pulsos por cuartos de nota, submarcos, pulsos por minutos, y no sé qué madres más. No me interesa en lo más mínimo; pero lo necesitaba porque necesitaba el tiempo preciso en que cada nota se prendía y se apagaba. Y para acabarla de amolar, el tiempo no es absoluto; es relativo a la nota anterior: es un formato acumulativo, donde el tiempo de cada nota es una delta que se le suma al tiempo de la nota anterior.

Después de muchos quebraderos de cabeza, conseguí la fórmula que me permitía convertir el tiempo de cada nota (después de obtenerlo a partir del tiempo de la nota anterior y de la delta) a milisegundos, y me puse a sacar los tiempos de las notas del instrumento (o sea la pista) que me interesaba. Y por supuesto todo se desincronizaba; pero esto ocurría únicamente de vez en cuando, y únicamente en algunas canciones.

Estuve días golpeándome la cabeza contra un muro hasta que por fin encontré el problema: estaba calculando el tiempo utilizando las notas de la pista que me interesaba; y hay que usar todas las pistas. En otras palabras, si hay una pausa en las notas de la guitarra, pero en esa pausa la batería sí reproduce notas, la siguiente delta de la guitarra no se aplica a la última nota de la guitarra, sino a la última nota de cualquier instrumento (en este ejemplo, la batería). Lo cual tiene sentido cuando uno ve lo ridículamente pequeño que es un archivo MIDI; no hay problema en preprocesarlo todo de antemano para poder tener la información de todas las pistas disponible.

Y aún así, todavía tengo unas cuantas canciones donde de cualquier forma se me desincronizan las cosas. No tengo idea de qué pueda estar pasando; como el formato MIDI acepta cualquier cantidad de madres (por ejemplo, las letras de las canciones pueden incluirse en el archivo, para hacer cosas como karaokes), no sé si a algunas de ellas les esté tomando en cuenta el tiempo cuando no debería, o qué carajo: pero como sólo ocurre con dos o tres canciones, decidí esas arreglarlas a pie, y olvidarme del asunto para siempre. Con lo que tenía era más que suficiente para hacer lo que quería hacer, y de hecho ya lo hice; supongo que sí descubriera cuál era el problema estaría chido, pero a estas alturas ya es un extra. Lo que quería conseguir ya lo conseguí.

Para conseguirlo, escribí un programa que convertía la información de un archivo MIDI a un formato que me inventé donde dice en que nanosegundo ocurre que se prende o apaga una nota; primero lo hice en Python, pero he estado convirtiendo todo a Vala, porque es 10 veces más rapido, aunque como los archivos son todos chiquititos realemente no sería tan grave dejarlo en Python. También utilicé un programa que convertía el MIDI a un formato CSV (tipo hoja de cálculo), pero como no me salían las cosas terminé escribiendo yo uno igual, porque no me quedaba claro si había un error en el programa o cómo interpretaba yo las cosas (el error era mío, pero pues ya tengo mi programa que lee MIDIs directamente).

El medio entender el formato MIDI fue sólo una de las partes del proyecto en el que estuve trabajando; tengo todavía la duda de porqué un par de canciones se me desincronizan, pero fuera de eso creo que tengo dominada esta parte. Y de hecho, medio entender el formato MIDI me resultó de utilidad en otra de las partes del proyecto que encontré más adelante; pero de eso escribiré luego.

Mi teléfono celular tiene el mismo problema que tienen muchos dispositivos modernos: la batería le dura alrededor de 24 horas en circunstancias normales.

Ahorita no estoy en circunstancias normales; estoy utilizando la aplicación que guarda mis coordenadas para después poder ponerle información GPS a las fotos que estoy tomando.

Mi batería entonces dura como la mitad de lo normal; ayer pude conectarlo en el restaurante donde comimos, si no hubiera muerto. Mi teléfono tiene un modo de ahorro de energía, pero entonces detiene casi todas las aplicaciones para ahorrar energía cuando la pantalla se apaga, lo que incluye mi rastreador GPS.

Sólo hasta hoy descubrí que uno puede seleccionar aplicaciones que el modo de ahorro de energía no detendrá. Mi teléfono dice ahora que le va a durar dos días la batería; no le creo nada, pero si aguanta el día me daré por bien servido.

Voy a estar una semana en el gabacho en total; como ya me he acostumbrado a tener datos en mi teléfono celular todo el tiempo, decidí que no quería pasar esta semana como ciego dando tumbos en la oscuridad electrónica.

Eso me parece que fue razonable de mi parte; lo que fue increíblemente estúpido, fue creer que podía confiar en Telcel para solucionar mi problema.

Me metí a la página de Telcel, y contraté 250 megabytes para usar en el gabacho. Fue relativamente sencillo, y el cobro de hecho se realizará hasta quién sabe cuándo, en mi estado de cuenta mensual. El problema fue que llegué a gabacholandia, y por supuesto no funcionó.

Les llamé para reclamarles, y después de probar varias cosas, los muy inútiles me dijeron que no podían hacer nada. Estoy usando un teléfono que no es de Telcel, porque cuando me robaron mi celular en diciembre, compré uno independientemente, justamente porque me desesperó la inutilidad de la gente de Telcel para poder sencillamente venderme un teléfono al que le pudiera poner mi chip.

Por supuesto ellos se agarraron de esto para decir que no podían hacer nada. Me dio mucho coraje, porque cuando me hartaron en diciembre con su incapacidad para simplemente venderme un teléfono, me aseguraron que no había problema conque yo comprara un teléfono por afuera y le pusiera mi chip. Y significa que lo que gasté por mis 250 megabytes básicamente se tira a la basura.

Perdí unas dos horas de mi vida ya aquí en Chicago viendo qué podía hacer al respecto, hasta que al final me resigné a haber perdido mi dinero, y salí a al menos a conocer la ciudad, aunque fuera como ciego dando tumbos en la oscuridad electrónica.

Y entonces vi un local de T Mobile.

Me metí y pregunté si podía tener 7 días de datos. “Claro”, me dijeron (sólo que en inglés). Quince minutos después, salí del local con datos en mi celular, un número básicamente ilimitado de megabytes al día (tendría que pasármela todo el tiempo viendo videos en YouTube para acabármelos), y a la mitad del precio de Telcel.

Lo que es mejor; mi teléfono (que también compré independientemente de Telcel) tiene dos ranuras para tarjetas SIM, así que puedo recibir llamadas y mandar mensajes por mi número de México, mientras recibo datos con mi número T Mobile (que sólo usaré para ello), todo al mismo tiempo.

Así que sí perdí dinero con Telcel; pero es la última vez en la vida que lo haré. Si vienen al gabacho, ni se molesten en tratar de comprar los planes de Telcel; es probable que no funcione, y es demasiado caro para una cantidad de megabytes tan pequeña. Compren una tarjeta SIM; si tienen un teléfono con dos ranuras, tienen lo mejor de los dos mundos; si tienen sólo una, usen el SIM gringo para correo, Google Maps, redes sociales, etc., y sólo pongan el SIM de Telcel cuando quieran revisar sus mensajes o correo de voz, o hacer llamadas.

Estoy considerando seriamente dejar a Telcel por otra compañía celular; se han portado de manera criminalmente incompetente las últimas veces que he tenido que lidiar con ellos.

Pero al menos tengo datos aquí, y funciona muy bien, aunque tuve que perder dinero para aprender mi lección de que no debo utilizar los servicios que provee Telcel, porque de verdad son unos inútiles.

En la academia, al parecer, hay que llenar catorce millones de formas cada quince minutos, más o menos. Formas para plazas, formas para becas, formas para estímulos, formas para calificaciones, formas para viajes, formas para viáticos, formas para que nos paguen viáticos ya gastados, formas para votos, formas para pedir otras formas que entonces hay que llenar para poder hacernos acreedores a nuevas formas…

La única vez que he trabajado (fuera de la academia) en el sector público, cuando estuve en el IFE (que ya ni siquiera existe), no tuve que llenar tantas formas; pero estaba por obra determinada, así que no sé cómo sea si uno tiene un puesto “fijo”. En la industria privada jamás tuve que hacer nada por el estilo, pero tampoco creo que se pueda considerar “fijo” lo que hacía en ese entonces.

Como sea, hasta hace no mucho uno tenía que ir por sus formas a algún lado, pedirlas por favor, y llenarlas con pluma o máquina de escribir. Siempre odié eso, porque involucraba escribir a mano, lo cual nunca se me ha dado mucho (mi caligrafía de caquitas de mosca embarradas en el papel no ha tenido el éxito que yo hubiera esperado), así que fue con alegría cuando descubrí que por fin todo mundo empezó a poner formas en línea.

Al inicio muchas veces la forma era el escaneo de la forma original, si bien le iba a uno como un PDF, si no como un vil JPG. A veces daban las formas en el formato .doc de Microsoft Office, pero creo que ya casi nadie hace eso. Desde hace algunos años esto se ha ido estandarizando en utilizar PDFs editables, o formas PDF. Esto para mí es la gloria, porque entonces ya no tengo que hacer ningún truco sucio; sólo lleno la forma, salvo el documento PDF, y soy feliz.

Cuando no es editable el PDF, soy bastante menos feliz. Lo que he hecho desde hace algunos años, es recrear la forma en SVG con Inkscape, y entonces llenarla con la herramienta de texto que tiene. En general funciona bastante bien, y tengo ya una biblioteca considerablemente amplia de formitas en SVG que sólo abro para editar de vez en cuando. Dado que SVG es XML, en algunos casos simplemente pongo texto como un marcador de posición (por ejemplo, NOMBRE), y hago un script que reemplaza esa cadena por la que realmente quiera usar. Jala muy bien; el único problema es que a veces es un desmadre recrear la forma completa en SVG, pero incluso esto es evitable si la forma no es una imagen, sino que la información vectorial de la misma viene en el PDF: para esos casos sencillamente utilizo pdf2svg, o abro el PDF directamente con Inkscape.

El otro problema es cuando la forma son múltiples páginas. SVG no tiene realmente una manera de modelar documentos con múltiples páginas, entonces tengo que crear una serie de documentos (forma1.svg, forma2.svg, etc.), y hacer un Makefile o algo así para compilarlos a un único PDF. Que es la situación en la que me encuentro ahorita.

Por supuesto, clavado como soy, ya ando pensando en cómo mejorar mi flujo de trabajo. Lo obvio por supuesto sería escribir un programa que recibiera las entradas de la forma (o las leyera de una base de datos), y generara los SVG, o incluso el PDF ya directamente. Lo único que me detiene para hacer esto (además del hecho de que tengo que terminar de llenar mis estúpidas formas), es que no sé cómo obtener la dimensión que ocupa un texto determinado en SVG, y que aún teniendo esto tendría que implementar un algoritmo para partir líneas muy largas en párrafos, de preferencia tratando de que las distintas líneas todas tengan más o menos el mismo ancho. Este algoritmo ya existe, por supuesto; es el que Knuth y un estudiante suyo de doctorado diseñaron e implementaron para , pero tengo entendido que es suficientemente complejo como para que lo implemente yo durante un fin de semana.

Así que por mientras sigo peleándome con mis SVG separados.

Ayer mi mamá me pidió que la acompañara a comprar una tele en Best Buy, porque así es la vida.

De pura chiripa encontramos una tele Samsung LED FullHD de 39″ en 5,999.99 pesos, porque estaba de promoción, así que le dije que se llevara esa, porque sí estaba muy barata. Ya pagando, vi que podía pagarse a 12 meses sin intereses con tarjetas de crédito Banamex; yo acabo de sacar la mía porque llevaban meses jode y jode los de Banamex con que sacara una, y porque con ella compré mi nuevo celular, así que le dije a mi mamá que me dejara pagarla con mi tarjeta de crédito y que luego ella me pagara las mensualidades.

Por supuesto mi tarjeta no pasó, porque con ella pagué el hotel de Oaxaca durante el congreso de la semana pasada y tengo como tres pesos de crédito; pero entonces se me ocurrió una idea: saqué mi celular, abrí mi aplicación de Banamex, y pagué mi tarjeta de crédito ahí mismo en la tienda, todavía enfrente de la caja donde la acababan de rebotar. Acto seguido, compré la tele de mi mamá con mi tarjeta de crédito, que ahora sí pasó.

Es chistoso, pero fue a la vez sorprendente y natural que pudiera hacer eso. Sorprendente porque nunca lo había hecho, y si hace algunos años me hubieran dicho que podría hacer algo así lo hubiera puesto altamente en duda… comenzando por el hecho de que yo tendría una tarjeta de crédito. Natural porque, vamos, es el mundo en el que ahora vivimos.

Ahora si tan solo pudiera comprar procesadores en Amazon México…

Xochitl está a veces bajo ataque. En general son ataques idiotas que tratan de entrar por SSH usando combinaciones de usuario/clave del tipo “root/root” o “user1/user1”; evidentemente eso casi nunca funciona, y además esos ataques son automáticamente detenidos después de tres intentos fallidos con denyhosts.

Esos ataques no me dan problemas; me dan problemas los ataques dirigidos específicamente contra mi blog y/o galería en línea. No porque alguna vez hayan logrado nada (los mantengo actualizados); el problema es que a veces generan una cantidad tal de solicitudes que Apache comienza a sobrecargar MySQL, la base de datos queda trabada, y Apache entonces se queda atorado sirviendo páginas. Si los atacantes solicitan muchísimas solicitudes a la vez, esto causa que MySQL quede atorado con cientos de consultas en su cola, y por lo tanto que Apache quede atorado con cientos (o miles) de páginas que quieren ser servidas.

Como Apache trata de no tirar conexiones, y cada una de ellas utiliza procesador, esto hace que el CPU de Xochitl de repente se encuentre utilizado al 117%. Aquí es donde debo mencionar que Xochitl es una pobre Pentium 4 a 2.40 Ghz; es posible (y de hecho probable) que la mayoría de los teléfonos celulares inteligentes que han salido este año sean más rápidos (y tengan más memoria) que Xochitl.

De todo lo anterior no es esta entrada.

Esta entrada es acerca de una situación que encontré mientras buscaba qué poder hacer para aliviar a la pobre de Xochitl. La más sencilla es ver qué IPs están solicitando más conexiones HTTP, y agregarlas a /etc/hosts.deny (teniendo cuidado de no negarme acceso a mí y mis máquinas, o a los robots rastreros de Google). Suele funcionar; sobre todo considerando que estos “ataques” (la verdad ya no sé si son ataques o sólo lectores ligeramente stalkeadores de mi blog/álbum) no ocurren muy seguido.

Así que hice un programita que leyera los logs (o bitácora, si quisiera usar español correcto) de acceso de Apache, sacara las IPs, y contara cuántas veces aparece cada una. Como lo primero que aparece en cada línea es la IP solicitante seguida de un espacio, con el siguiente comando obtengo todas las IPs que solicitan páginas a Apache:

cat /var/log/apache2/access_log | cut -d " " -f 1

Hasta ahí vamos bien; ahora, ¿cómo saco de ahí cuántas veces se repite una IP?, porque sabiendo eso ya puedo saber cuáles IP solicitan un número ridículo de conexiones. Siendo, como soy, programador, escribí un programita que hiciera esto por mí. Lo escribí en Python, porque lo quería rápido, y esto me salió:

#!/usr/bin/env python

import sys

if __name__ == '__main__':
    ips = {}
    for line in sys.stdin.readlines():
        line = line.strip()
        if line in ips.keys():
            ips[line] = ips[line] + 1
        else:
            ips[line] = 1
    for ip in ips.keys():
        print('%d: %s' % (ips[ip], ip))

Esas son 14 líneas de Python, incluyendo el shebang y dos líneas en blanco. El programa lee línea a línea la entrada estándar, y usa un hash table para ir contando cada aparición de una IP.

Muy contento con mi programa lo corrí… y el maldito programa corrió, y corrió, y corrió, y siguió corriendo. Al minuto lo detuve, incrédulo de que pudiera ser tan endiabladamente lento. Lo revisé, lo puse a imprimir resultados intermedios, y el resultado era el mismo: es lentísimo.

Estúpido Python.

Me subí las mangas y lo reescribí en C, usando glib porque no me iba a a poner a escribir mi propio hash table (been there, done that). Esto me salió:

#include <stdio.h>
#include <string.h>
#include <glib.h>

typedef struct _integer integer;

struct _integer {
        int n;
};

static integer*
integer_new(int n) 
{
        integer* i = g_new(integer, 1);
        i->n = n;
        return i;
}

static char*
read_line(FILE* file)
{
        char line[4096];
        int i = 0;
        line[i] = (char)0;
        int c;
        while (TRUE) {
                c = fgetc(file);
                if (c == EOF || c == NEW_LINE)
                        return strdup(line);
                line[i++] = c;
                line[i] = char(0);
        }
        return strdup(line);
}

void
print_key_value(char* key, integer* value, gpointer user_data)
{
        printf("%d: %s\n", value->n, key);
}

int
main(int argc, char* argv[])
{
        GHashTable* h;
        h = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
        do {
                char* line = read_line(stdin);
                if (!strcmp(line, "")) {
                        free(line);
                        continue;
                }
                char* key;
                integer* value;
                if (g_hash_table_lookup_extended(h, line, &key, &value)) {
                        value->n++;
                } else {
                        value = integer_new(1);
                        g_hash_table_insert(h, line, value);
                }
        } while (!feof(stdin));
        g_hash_table_foreach(h, print_key_value, NULL);
        g_hash_table_destroy(h);
        return 0;
}

Esas son 65 líneas en C, incluyendo la definición medio redundante de una estructura integer porque no quise usar las macros GINT_TO_POINTER y GPOINTER_TO_INT. No es elegante.

Ya que tuve mis dos versiones, según yo, equivalentes, las corrí ambas. La salida que producen es idéntica, así que me parece que sí son equivalentes. La versión en Python tarda más o menos 1 minuto 58 segundos (más/menos dos segundos, en todas las ocasiones en que lo corrí). La versión en C tarda 0.285 segundos, consistentemente debajo de 0.290. Esto para una bitácora de 95,080 líneas, de 12 Megabytes de tamaño.

La versión en C es unas 5 veces más larga en líneas que la de Python (de hecho 4.333, pero no importa), además de que las líneas tienen más caracteres; y sin embargo tarda (en tiempo de ejecución) del orden de 400 veces menos.

Ahí está el código si alguien quiere tratar de mejorar el resultado en Python. Yo estoy sumamente decepcionado; creí que las hash tables de Python estaban decentemente optimizadas: estoy usando cadenas como llaves al fin y al cabo. Y lo peor es que la versión en C ni siquiera me tomó mucho más tiempo en escribir.

Actualización: Gracias a Omar, ya vi que estaba cometiendo un errosote al buscar la llave en la hash table de Python; no tenía porqué buscarla en .keys() cuando puedo hacerlo directamente en la tabla. Con la sugerencia de Omar, el código Python es solamente el doble de lento que el código C. Lo que de hecho tiene sentido.

En mi departamento tengo más computadoras de las que cualquier adulto viviendo solo debería tener. Más aún si cuento cosas como mi PlayStation 3 o mi teléfono celular, o incluso mi N800, por más que no lo haya usado en los últimos dos o tres años.

Como sea, casi todas las computadoras se conectan a mi red local vía inalámbrica, y todas lo hacen a través de DHCP. Todas por lo tanto suelen tener direcciones de IP dinámicas (excepto Atom, mi servidorcito con procesador Atom; como redirijo a él las conexiones SSH de mi módem DSL, necesito que tenga una dirección estática), y después de un rato es un desmadre estar viendo cuál computadora tiene qué dirección IP.

Para solucionar esto utilizo Avahi, una implementación de zeroconf para Linux, lo que causa que cada computadora con Linux que tengo anuncie su presencia en la red local. No importa qué dirección IP tenga Centurion, mi máquina de escritorio, dentro de mi LAN puedo accederla con la dirección centurion.local (desde una máquina que use Linux y Avahi). Como hay un navegador de zeroconf para Android, incluso lo puedo usar desde mi teléfono, aunque tengo que abrir el navegador, ver qué dirección tiene centurion.local y ya usarla.

Como sea; ayer salí un rato de mi departamento y al regresar vi que se había ido la luz, ya que Atom estaba apagado. Prendí de nuevo el servidorcito y mi máquina de escritorio (la había dejado suspendida), y traté de conectarme de nuevo a atom.local. No pude, así que supuse que Atom no había iniciado correctamente. Agarré mi teclado USB y lo llevé al servidorcito, usando mi televisión de 46″ como monitor (como Atom está en el mismo mueble que la tele, lo tengo conectado a ella todo el tiempo por VGA). Cuando entré al servidorcito, vi que, aparentemente, todo estaba bien. Traté de conectarme de Atom a Centurion, y tampoco lo encontró.

El protocolo de zeroconf funciona de tal forma que, bueno, necesita cero configuración. Lo dice ahí, en su nombre. Que algo falle con Avahi es bastante raro; de hecho no ha habido nuevas versiones en años; sencillamente funciona.

Regresé a Centurion, y me puse a investigar qué podía pasar. Ambas computadoras podían accesar Internet, sólo no la una a la otra. Dado que Avahi es un protocolo distribuido (no necesita un servidor), no pensé que fuera mi módem DSL, pero ya sin muchas otras opciones me metí al mismo para ver si todo jalaba bien con él; a lo mejor algo extraño había pasado con el servidor DHCP, o quién sabe.

Y entonces en el navegador apareció la página de autenticación del módem DSL. Y resultó que no era mi módem.

Cuando volvía a prender Centurion después de que regresó la luz, en lugar de conectarse a mi módem DSL, se conectó al módem DSL de un vecino, que todavía en esta época no ha aprendido que hay que ponerle clave. Conecté Centurion a mi módem DSL, y por supuesto se pudieron encontrar él y Atom. También borré el módem DSL de mi vecino de la lista de Access Points a los cuales Centurion trata de conectarse (no tengo idea de cómo llegó ahí en primer lugar), así que espero este particular problema no vuelva a repetirse.

Para mi viaje a Guadalajara instalé GPS Logger en mi teléfono Android. Antes de tener teléfono mamón, tenía mi Nokia N800, al cual le compré un GPS bluetooth, y con el cual podía ir grabando mi posición GPS cada segundo, para después transportar esa información a mis fotos.

Nunca funcionó muy bien que digamos; para empezar, el N800 no podía estar recabando mi posición GPS todo el tiempo vía bluetooth, por la sencilla razón de que la batería se moría a las doce horas, si uno tenía suerte. Además, mi GPS bluetooth sólo era eso, GPS; no soportaba AGPS (Assisted GPS), que se ayuda de las torres de celular para aproximar la posición de uno cuando no consigue engancharse a los satélites GPS (que pasa más comúnmente de lo que uno pensaría). Pero además se volvía todo una cosa muy incómoda, cargando el N800, el GPS, la cámara, y además con la angustia de que la batería se iba a morir en cualquier momento.

La única vez que intenté usarlo así fue cuando fui a ver a mi cuate Eddie en San Francisco en el 2009, y además de que pasó todo lo que acabo de describir (se murió la batería, el GPS no se conectaba a los satélites, fue un desmadre estar cargando tantos electrónicos), cuando regresé a México y traté de sincronizar la información que el N800 había estado guardando en mis fotos, resultó que no podía porque F-Spot había cambiado las horas de las mismas. Para que esto funcione bien, el reloj del GPS y el de la cámara debe estar casi perfectamente sincronizado, obviamente.

Creo que por ahí tengo la información GPS de ese viaje a San Francisco, pero la verdad ya ni intenté ver si podía ponérsela a mis fotos. Mi N800 ahora está arrumbado por ahí, y hace años que ni siquiera lo prendo.

Con mi teléfono Android todo ya es mucho más sencillo: tiene el GPS integrado, utiliza AGPS, y además la batería es bastante mejor que el del N800, así que como dije instalé GPS Logger y estuve guardando mi ubicación todo el tiempo que tomé fotos durante mi estadía en la capital jalisciense. Hoy que ya acabé la chamba que se me había acumulado por estar tres días casi sin ni siquera consultar mi correo electrónico, investigué cómo podía sincronizar dicha información en el par de centenas de fotos que tomé durante mi viaje.

Fue bastante sencillo: hay un programita llamado GPS Correlate que lo hace automágicamente, incluso con ventanitas y así. Igual y reescribo el programa, porque la verdad sí se siente medio abandonado; pero funcionó sin ningún problema. Ya que mis fotos tenían la información de ubicación dentro de ellas, vi qué podía hacer para que mi galería en línea la utilizase. También fue sencillo; sólo instalé el módulo EXIF GPS de Gallery3, y con esto aparece un mapita de Google Maps en cada uno de mis álbumes donde haya información de localización:

Mapa de álbum

Y por supuesto, cada foto con información de localización tiene un mapita de Google Maps individual:

Mapa de foto

Está bastante chido; vaya a ser que se me olvide dónde tomé una foto. Me da coraje no haberlo hecho antes; tengo mi teléfono mamón desde junio del 2011, y en mi megaviaje de seis meses me hubiera sido bastante útil. Pero bueno, así se aprende en esta vida. Mi Android soporta un día entero de estar usando GPS Logger, pero apenas; termina con la batería debajo del 5%. Pero ya dentro de poco me tocará renovarlo, y espero que mi próximo teléfono tenga mucho mejor batería que el de ahora (y que jale más rápido, porque ya lo siento muy lento… y que tenga un buen de memoria interna, porque la que tengo es una grosería).

Así que a partir de ahora mis fotos tendrán la información de dónde las tomé, a menos que algo le pase a mi celular.

Después de que me hicieron notar, de la manera más directa posible, que me veía horrible en la imagen que puse hace unos días de mi vieja Creative Webcam NX, decidí poner screenshot de cómo aparezco en los hangouts de Google con la cámara de mi nueva laptop:

Con la cámara de mi nueva laptop

No, la calidad tampoco es espectacular, pero hago notar que era de noche, y además es un screenshot de la página del navegador donde estaba el hangout. Ya animado se ve bastante decente.

Y ciertamente me gusta más que usar Skype. Que al parecer en menos de un mes todos los usuarios de messenger serán migrados (de forma obligatoria) a Skype; durante años utilicé el messenger, pero tiene ya meses que ni siquiera me he conectado (solía causar que trabajara aún menos al escribir la tesis). No me queda claro que lo vaya a extrañar mucho.

He estado usando casi diario los Google+ Hangouts para videoconferencia (¿cómo se traduce eso?, ¿”pasadores de tiempo”?). Las razones son varias, pero la más importante, para mí, es que me evitan la molestia de instalar Skype, que cada vez me resultaba más desesperante.

Como he comentado no pocas veces en mi blog, detesto KDE, e incluido en eso va Qt. Compilarlo además en Gentoo es lentísimo, y prefiero usar mi procesador para cosas más interesantes. El cliente de Skype para Linux utiliza Qt, y al menos en Gentoo tienen la decencia de incluir una versión binaria de Qt junto con el paquete; pero de todas formas significa usar Qt, y si puedo siempre lo evito.

Además de Qt, Skype nunca mereció mucha confianza de mi parte; menos aún cuando fue comprado por Microsoft (que además casi garantiza que un buen cliente para Linux nunca existirá). Los Hangouts de Google+ me evitan todos estos problemas, y además Google me cae mejor que casi cualquier otra compañía, así que les doy el beneficio de la duda.

Técnicamente además los famosos hangouts están bastante padres; puede uno tener videoconferencia con N personas a la vez; corre todo dentro del navegador por lo que no es otra aplicación que hay que iniciar y configurar; y corre básicamente de forma perfecta en Linux, con un plugin para Chromium (que no dudo funcione también en Firefox) que mide en total como 21 Megabytes.

Comencé usando los hangouts en mi laptop, y la experiencia ahí ha sido básicamente perfecta excepto por dos problemas (ninguno relacionado con los hangouts): el primero es que mi laptop tiene unas bocinas que yo creo que son una broma, literalmente; y el segundo es que, por esas cosas que suelen ocurrir con Linux, el chipset que utiliza el bluetooth de mi laptop ahorita no está funcionando para que jalen mis audífonos bluetooth. Y hago énfasis en ahorita: hace unos meses funcionaba, y con casi toda seguridad en unos meses volverá a funcionar, sólo que como bluez pasó de la versión 4.101 a la 5, y no son compatibles, el proceso para que las aplicaciones que usan bluez se porten a la nueva versión puede tardar mucho. De hecho, es posible que con bluez 5 mis audífonos ya sirvan, sólo no he actualizado porque todo el resto del software sigue dependiendo de bluez 4.101.

Y para hacerlo más agraviante, al parecer todo lo relacionado con bluetooth funciona con bluez 4.101; incluso mis audífonos son reconocidos y ligados a la laptop. Sólo luego no aparecen como tarjeta de sonido externa. Como sea, no es grave; me pongo mis infalibles audífonos Genius, que además cuentan con micrófono incluido, y todo está chido.

De cualquier forma me dieron ganas de ver cómo funcionarían los hangouts en mi máquina de escritorio, en gran medida porque mi silla ahí es más cómoda, y el monitor es mucho más grande. Así que lo primero fue ver si servían bien los audífonos ahí; perdí unos quince minutos buscando dónde estaba el control de volumen para el micrófono, hasta que caí en cuenta de que PulseAudio es lo suficientemente inteligente como para no mostrarlo a menos que esté conectado.

Ni siquiera sabía que las computadoras ahora podían detectar cuándo estaba conectado un micrófono.

Luego fue la cámara de video, que es una antiquísima Creative Webcam NX que se conecta por USB a la computadora. Para que tengan una idea, la compré cuando pensé que me iría a hacer el posgrado a Canadá, así que sí tiene casi diez años conmigo; hablé de ella hace mucho. Bastante ha cambiado desde esa entrada; en particular, el controlador de la camarita está en el kernel desde hace años, y por lo que tengo entendido funciona perfecto… mientras en Windows a 64 bits de hecho nunca funcionó.

De nuevo tardé como veinte minutos tratando de encontrar mi camarita (el software; la camarita lleva años viviendo físicamente encima de mi monitor), hasta que por fin caí en cuenta de que por alguna razón el controlador no estaba compilado en mi kernel. En alguna actualización la opción de tener camaritas de video USB requirió alguna otra opción que no activé, y desde entonces no se había compilado el módulo. Así que recompilé el kernel, reinicié, y por fin tuve camarita de nuevo.

Y fue casi dolorosamente decepcionante:

Camarita

Por supuesto las condiciones de luz en mi departamento apestan (más aún a las ocho de la noche), pero la calidad de la camarita es abismal. Tiene una resolución máxima de 352×288; en comparación, mi latop (que no es último modelo) tiene una resolución de 1280×1024. En mi monitor FullHD (1920×1080), la ventana de Cheese (el programa para tomar fotos de GNOME) tiene que escalar hacia arriba la imagen para que quepan los botones de su barra de herramientas. Y con tantito que se escale, a esa resolución, todo se ve súper pixeleado.

Así que descarté mi escritorio para usar los hangouts, a menos que mis interlocutores quieran ver sombras nada más. Lo que me impresionó, y que es el punto de esta entrada, es que hace diez años una camarita USB con resolución 352×288 no sólo no era rara, sino que tendía a estar en el grado alto del espectro. E independientemente de la resolución, la calidad del video (y fotos) que toman las camaritas actuales es muchísimo mejor que las de hace diez años.

En una década ocurrió que el hablar con alguien a cientos de kilómetros de distancia, y además verlos al mismo tiempo en tiempo real, se puede hacer de forma ridículamente sencilla, y con una calidad del video tal que uno puede ver los insectos caminando en las paredes detrás de los interlocutores (true story). A veces se me olvida que ya vivimos en el futuro.

Y por cierto, los hangouts funcionan sorprendentemente bien en teléfonos celulares inteligentes, si bien sólo los probé una vez, y ambos participantes usando red inalámbrica. Supongo que habrá que ver si funciona bien sobre 3G, aunque la verdad lo dudo. Mi teléfono no es 4G LT, pero me imagino que el próximo sí lo será.

Y entonces sí voy a sentir de verdad que vivimos en el universo de Star Trek.

Limpié y subí también mi aplicacioncita para editar etiquetas en fotos; la pueden encontrar en Github.

Quick Photo Editor

Llevo años escribiendo pequeñas aplicaciones que me quedo nada más para mí. No creo necesariamente que le vayan a servir a absolutamente nadie más, pero el hacerlas públicas me obliga a tener el código en buen estado, legible, y a escribir el mínimo de documentación e infraestructura necesarias para que no sea nada más un archivo en Vala, Python, C o Perl aventado en algún directorio de mi $HOME, que años después no tengo ni idea de qué hacía o por qué lo había escrito.

Esta aplicación está escrita en Vala, que me parece ahí reside en gran medida el futuro de GNOME; es muy divertido de programar, y los programas son razonablemente rápidos y con poco uso de memoria (contrario a C#). Además, el código es muy legible y compacto; no al grado de Python, pero me parece que sí más que C#. El programita, aunque su funcionalidad a lo mejor le es inútil a nadie que no sea yo, sirve también para estudiar un ejemplo pequeño, pero funcional, de cómo escribir una aplicación con autotools, usando gettext para internacionalización, cómo instalarle iconos, y otras cosas de ese estilo.

Total que limpié mi programita para subir fotos a Gallery3; es básicamente para mi uso privado, pero consideré que a lo mejor a alguien le podría resultar útil al menos el módulo que se comunica con el API REST de Gallery3.

Como lo iba a hacer público, lo limpié, le puse una interfaz gráfica, lo hice que hablara varios idiomas (inglés y español, porque no sé otros), y le puse toda la parafernalia para que se pueda compilar haciendo la santísima trinidad de ./configure && make && make install. El resultado no sólo es más agradable a la vista; ahora puedo seleccionar fotos en Nautilus, hacerles click derecho, y abrirlas con esta aplicacionciota, lo cual las manda a mi galería en línea.

Gallery 3 Uploader

Le faltan muchas cosas: por ejemplo, tronará sin decir nada si alguna de las etiquetas que espero encontrar en las fotos falta, pero ya es útil para mí, y espero lo sea también para alguien más. El programita está en Github: https://github.com/canek-pelaez/g3uploader.

Ahora sólo tengo que limpiar la aplicación que edita las etiquetas.