Las constantes y las unidades del sonido

De dónde vienen las críticas

Se pidió a tres modelos de lenguaje que criticaran el método de equivalencia (septiembre de 2026); el registro de esas conversaciones se archiva en la carpeta del proyecto. Dos críticas se tratan aquí. Crítica 1: la regla D ignora las constantes; para los tres modelos, si las constantes difieren, los programas difieren. Crítica 2: la antigua regla C trataba un tono en hercios y un tono como número de nota como el mismo tono (desde el 19-09-2026 ya no es una regla aparte: la altura es una constante más, regla D, § 04). Esas dos codificaciones producen sonidos distintos ante la misma inclinación. Cada crítica se examina con ejemplos del corpus. Cada una termina en tareas para la pipeline y en preguntas para el panel de expertos del Objetivo 2.

Las constantes: calibración

Una constante queda fuera del algoritmo, porque si un sensor entrega valores de 0 a 100 y el otro de 0 a 500, el programa que hace lo mismo con los dos usa constantes distintas. Escalar un sensor adapta el programa a la plataforma. Es el caso del xilófono. Las dos versiones toman la lectura de un acelerómetro, la dividen por una constante, le suman 440 y tocan el resultado en hercios. Los dos sensores miden lo mismo, la gravedad a lo largo de un eje, en unidades distintas. El micro:bit entrega milésimas de g: plano, un eje lee 1023. Protobject entrega m/s² multiplicados por diez: 1 g se lee como unos 98. Por eso el divisor es distinto: el micro:bit divide por 20 y Protobject por 2, y en las dos el tono sube o baja como mucho unos 50 Hz alrededor de 440. La base fija el tono de reposo y deja la frecuencia siempre positiva; el divisor fija cuánto sube. El divisor es una constante de calibración en estado puro: compensa la unidad del sensor para que las dos versiones suenen igual.

En la detección de clones de código, dos fragmentos que difieren solo en identificadores y literales son clones de tipo 2: «el mismo código» con parámetros distintos. La noción de sketch en síntesis de programas formaliza «mismo esqueleto, constantes por determinar». La regla D pone a la pipeline en ese nivel de abstracción, de forma declarada y documentada.

Algunas constantes cambian el comportamiento cualitativo del programa:

• Un repetir 4 veces contra un repetir 40 veces es el mismo bucle y una animación distinta.
• Una pausa de 10 ms contra una de 100 ms, en la misma plataforma, es la misma instrucción y, para el ojo, un parpadeo invisible contra uno visible. Entre plataformas distintas puede ser al revés: la misma pausa nominal dura distinto en pantalla (§ 03).
• Un umbral de 50 sobre un sensor de 0 a 100 se cruza a la mitad del rango; el mismo umbral sobre un sensor de 0 a 500 casi nunca se cruza.

La distinción es calibración contra comportamiento, con una prueba operativa:

La regla D se aplica a la dimensión algorítmica, la única que la pipeline decide. Las constantes que cambian lo que el niño ve u oye pertenecen a la dimensión sensoriomotriz y se hacen visibles como residuo. La pipeline declara cuáles constantes ignoró.

Aplicada al xilófono, la prueba da «calibración»: en las dos versiones la frecuencia es una recta de la lectura del sensor, con el mismo punto de reposo y casi la misma pendiente. Lo que queda, un par de hercios en los extremos porque 1023 ÷ 20 no es exactamente 98 ÷ 2, se reporta como residuo.

Entre el 18-09-2026 y el 19-09-2026 el autor revisó una por una las 17 parejas y las alineó con un principio explícito: los mismos bloques, en el mismo orden y con los mismos operadores en las dos plataformas; las diferencias entre plataformas van solo en los números, constantes o valores de variables. Rechazó dos arreglos que cambiaban la estructura: agregar bloques de pausa de 400 ms en un solo lado (actividad 16.5) y cambiar un operador en un solo lado, 100 − x en lugar de x + 100 (actividad 16.7), porque «un cambio de signo lo haría no equivalente algorítmicamente». Así, las diferencias de plataforma que se pueden compensar quedan en las constantes, y la regla D las deja fuera del veredicto. Si cada una es de calibración o de comportamiento lo decide la prueba de normalización (T3). Las principales, vigentes al 19-09-2026 y verificadas en los programas (microbit/decoded/ y protobject/decoded/):

Dos de estas constantes cambiaron en esos días. El nivel de Protobject pasó de 7 a 5 columnas: antes la alarma saltaba a unos ±25° y el micro:bit era asimétrico. El metrónomo dejó x + 600 contra x + 60, que daba 600 contra 60 pulsos por minuto en reposo. Los umbrales los fija el autor probando, no con una fórmula, y el plan no los iguala. El signo de x no necesita constante: la Inclinación de Protobject seguía la convención del navegador y ahora entrega x con el signo del micro:bit; el eje y ya coincidía. Lo que ninguna constante compensa queda como residuo para el Objetivo 3: el timbre, la forma de detectar el ruido, los 400 ms del primer «mostrar LEDs» cuando no hay una pausa antes donde absorberlos (en 16.1 el primer pitido llega 0,4 s después de la cara), la vuelta de los bucles (20 ms en el micro:bit, 33 ms en Protobject), el muestreo de los sensores de Protobject (ruido a 10 Hz, inclinación a 30 Hz) y la latencia de red de Protobject.

El llavero de corazón: una constante que compensa la plataforma

La actividad n.º 1 del corpus tiene, en las dos plataformas, la misma estructura: un bucle infinito que hace sonar un tono, muestra el corazón grande, espera, corta el sonido y luego repite dos veces una alternancia de dos dibujos, el corazón de contorno y el corazón chico, con una pausa después de cada uno. Los tres corazones son los mismos en las dos: el de Protobject usa el 5 × 5 central de su matriz de 7 × 7. El tono es el mismo Re: la nota 74 en Protobject, 587 Hz en el micro:bit. La pipeline la declara isomorfa. Las pausas son distintas: 500 y 100 ms en el micro:bit, 900 y 500 ms en Protobject, verificado en la fuente (microbit/decoded/02.1-heart-beat.ts y protobject/decoded/02.1-heart-beat.txt). Por la regla D, la diferencia queda fuera del veredicto algorítmico.

Las pausas son distintas a propósito. La matriz de LED del micro:bit tarda en encenderse por completo, y el bloque «mostrar LEDs» lleva una pausa implícita: la documentación oficial dice que, al programar con bloques, el parámetro interval «is set at 400 milliseconds», y el código fuente lo confirma (showLeds(leds, interval = 400)). El «dibuja» de Protobject no espera: manda el dibujo y pasa a la orden siguiente, verificado en la fuente de la app (19-09-2026). Por eso cada pausa de Protobject es la del micro:bit más 400 ms: 500 + 400 = 900 y 100 + 400 = 500. En lo nominal, el corazón grande y su tono duran 900 ms, y cada dibujo del latido 500 ms, en las dos. La constante absorbe un límite de la implementación: es una constante de calibración en el tiempo, como el ÷ 20 y el ÷ 2 del xilófono lo son en el rango del sensor.

Hasta el 18-09-2026 el llavero era otro: un latido doble (tambor en Protobject, tono en el micro:bit) separado por 300 ms, y cuatro vueltas del bucle interno con pausas de 10 ms en el micro:bit y 100 ms en Protobject. Esa compensación solo acercaba las dos animaciones. El 18-09-2026 el autor rehízo la actividad con los mismos corazones y los mismos tiempos en las dos plataformas.

La prueba de normalización, aplicada al tiempo, corre sobre la duración medida en pantalla, porque el ritmo que se ve incluye el tiempo de encendido y los intervalos implícitos. El glosario del panel del Objetivo 2 dice «mostrar LEDs = dibujar + pausa implícita de 400 ms, sobre una matriz lenta», porque el ritmo visible depende de esa pausa implícita. El par es un control natural para el piloto del Objetivo 3: quitar la compensación —las mismas pausas nominales en ambas— produce dos ritmos distintos que el instrumento debe detectar.

El tono que sale del sensor, en hercios en las dos plataformas

Esta crítica se acepta y se resuelve en el diseño. Un número de nota y una frecuencia no son la misma escala. Cada unidad de número de nota multiplica la frecuencia por 2^1/12, un semitono; cada unidad de frecuencia le suma un hercio. Ante la misma inclinación, las dos codificaciones dan funciones de forma distinta, una exponencial y otra lineal en hercios, y los intervalos musicales se perciben como razones de frecuencia. Tratar las dos codificaciones como iguales, como hacía la antigua regla C, igualaría dos cosas que suenan distinto.

Por eso, en las dos versiones del xilófono, el tono se da en hercios: «tono de timbre (Hz)» en el micro:bit y «tocar frecuencia (Hz)» en Protobject. Con la misma unidad, lo único que queda distinto es la constante, y eso es la crítica 1 (§ 02).

Desde el 19-09-2026 todas las actividades suenan con tonos en las dos plataformas: «tono de timbre (Hz)» en el micro:bit y «tocar nota» o «tocar frecuencia» en Protobject. El sonido se corta con «para todos los sonidos» en el micro:bit y con «detener» en Protobject. La altura, en hercios o como nombre de nota, es una constante más (regla D): las notas fijas van como nota en Protobject y en hercios en el micro:bit (en 02.1, la nota 74 y 587 Hz, el mismo Re). La antigua regla C, «sonido por intención», se quitó: ya no quedan sonidos de naturaleza distinta que clasificar (clips grabados, golpes de batería). La regla C dice ahora solo que todo sonido es un tono: tocar y detener.

Toda normalización deja una huella

Las dos críticas llevan a un principio. Las reglas de normalización de la pipeline (A: sin análogo; B: recursos, donde el eje del sensor sí cuenta; C: sonido, que desde el 19-09-2026 es solo tonos y reemplaza a la antigua «sonido por intención»; D: aritmética, las constantes no cuentan; E: orden) deciden la dimensión algorítmica, y cada una borra una diferencia. La pipeline escribe qué borró: que una versión divide por 20 y la otra por 2, que una espera 500 ms y la otra 900. El principio:

La salida de la pipeline es un perfil: «equivalentes en la dimensión algorítmica; residuos: constantes {÷ 20 ↔ ÷ 2, ÷ 450 ↔ ÷ 30}». Hasta el 18-09-2026 el perfil del xilófono llevaba también «recursos {eje x ↔ eje y}»; el 18-09-2026 las dos versiones pasaron a leer el eje y, y desde el 19-09-2026 el eje cuenta (regla B). El panel lo usa para juzgar, y el instrumento del Objetivo 3 lo usa para saber dónde mirar.

Tareas concretas para la pipeline

1. T1 · Residuos de constantes. En la construcción del PDG, cada nodo aritmético conserva sus constantes (el AST fiel las guarda); el motor de cálculo emite en metricas.json una lista residuals con, por cada nodo emparejado, los valores de un lado y del otro. node_match conserva la regla D. Al 19-09-2026, pendiente: ningún metricas.json trae residuals.
2. T2 · Residuos de unidades. La ontología marca la unidad de cada salida que la tiene (Hz, ms). Si las dos plataformas usan unidades distintas, el motor lo reporta en residuals como unit. El tono que sale del sensor, en los xilófonos, va en Hz en las dos; las notas fijas van como nota en Protobject y en Hz en el micro:bit (§ 04). Al 19-09-2026, pendiente: la ontología no marca unidades.
3. T3 · Prueba de normalización. Para los pares donde se conocen los rangos de sensor y de salida, un script normaliza con una transformación afín y compara la forma de la función (misma familia, desviación máxima bajo un umbral escrito de antemano); reporta «calibración» o «forma distinta». Los rangos van en una tabla de plataforma que distingue rango nominal del sensor y rango alcanzable en el gesto de la actividad (medido, con fuente), y documenta el comportamiento fuera de rango de cada salida. Al 19-09-2026, pendiente: no hay script de normalización; la tabla de § 02 reúne las principales constantes vigentes.
4. T4 · Pausas implícitas. El decodificador anota los bloques con duración implícita conocida («mostrar LEDs»: 400 ms) y el PDG muestra ese nodo de espera con la marca «implícito», para que el panel vea el residuo temporal. Los tiempos reales de encendido de las dos plataformas se miden en hardware, porque el residuo temporal se calcula sobre lo que se ve. Al 19-09-2026, pendiente: los decodificadores no anotan la pausa implícita. Que el «dibuja» de Protobject no espera ya está verificado en la fuente (§ 03).
5. T5 · Dashboard. El visor muestra los residuos junto a la métrica, con la regla que los produjo. Al 19-09-2026, pendiente.
6. T6 · Runbook. prompt.md incorpora el principio de § 05 y las salidas nuevas. Al 19-09-2026, en parte: prompt.md ya dice que las diferencias de plataforma van en las constantes (unidades de los sensores, los 400 ms de «mostrar LEDs», alturas, umbrales), pero todavía no pide escribir el residuo.

Preguntas abiertas

1. ¿Suenan igual los dos xilófonos? Están calibrados para eso: la misma base, 440 Hz, y el mismo recorrido, unos ±50 Hz. Propuesta: confirmarlo con la prueba de discriminación del Objetivo 3, con participantes de la edad de destino.
2. ¿Está bien ajustada la compensación temporal del llavero de corazón? Desde el 18-09-2026 cada pausa de Protobject es la del micro:bit más 400 ms, así que en lo nominal los ritmos son iguales (§ 03). Falta verlo en pantalla: filmar cuatro vueltas del bucle en las dos plataformas y comparar los ritmos.
3. ¿Tiene «dibuja en DibujoLED» de Protobject alguna pausa implícita? Verificar en la fuente de la plataforma, o medir. Respuesta (19-09-2026): no; el bloque manda el dibujo y pasa a la orden siguiente, verificado en la fuente de la app. Queda por medir la latencia de red.
4. ¿La regla D se le presenta al panel tal cual, con la marca de disenso? Ver P4 del Objetivo 2.
5. ¿Qué constantes pasan la prueba de normalización en las 17? T3 produce esa tabla antes de que el panel juzgue.
6. ¿Dónde se documentan los rangos de sensores de cada plataforma? Propuesta: una tabla nueva junto a la ontología, con fuente para cada rango. Mientras tanto, la tabla de § 02 reúne las principales constantes vigentes al 19-09-2026.

Fuentes verificadas

Sobre las constantes

• Chanchal Kumar Roy; James R. Cordy (2007). A Survey on Software Clone Detection Research. Technical Report No. 2007-541, School of Computing, Queen's University at Kingston, Ontario, Canada, 115 pp. (dated September 26, 2007). research.cs.queensu.ca/TechReports/Reports/2007-541.pdfClones de tipo 2: idénticos salvo identificadores y literales. La regla D es una decisión de este tipo.verificado en línea · 11-09-2026
• Armando Solar-Lezama (2008). Program Synthesis By Sketching. PhD thesis, EECS Department, University of California, Berkeley; Technical Report No. UCB/EECS-2008-176, Tech. Rep. UCB/EECS-2008-176, diciembre 2008. www2.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-176.html«Mismo esqueleto, constantes por determinar», formalizado como sketch.verificado en línea · 11-09-2026

Sobre MakeCode

• Microsoft MakeCode team (repositorio microsoft/pxt-microbit) (s.f.). show leds — basic.showLeds(leds, interval). MakeCode for micro:bit, referencia y código fuente (pxt-microbit). makecode.microbit.org/reference/basic/show-ledsDocumentación y código fuente: «mostrar LEDs» pausa 400 ms por defecto tras dibujar cuando se programa con bloques.verificado en línea · 11-09-2026
• Microsoft MakeCode team (repositorio microsoft/pxt-microbit) (s.f.). ring tone / note frequency — music.ringTone, music.noteFrequency. MakeCode for micro:bit, referencia y código fuente (pxt-microbit). makecode.microbit.org/reference/music/ring-tone«tono de timbre» recibe Hz; «frecuencia de nota» devuelve los Hz de una nota elegida en un menú; no hay bloque número de nota → Hz en la caja estándar.verificado en línea · 11-09-2026
• Microsoft MakeCode team (s.f.). acceleration — input.acceleration. MakeCode for micro:bit, referencia. makecode.microbit.org/reference/input/accelerationLa aceleración se mide en milésimas de g; con la placa plana y la pantalla hacia arriba, z lee −1023.verificado en línea · 18-09-2026

Sobre Protobject

• Protobject (código fuente de la aplicación). Inclinación (SmartphoneOrientation) y Teclado Musical (PlayKeyboard). src/device/components/accorientation/index.ts, src/device/components/_shared/orientation.ts, src/device/components/playkeyboard/index.ts.La inclinación entrega la aceleración con gravedad en m/s² × 10, truncada: 1 g se lee como unos 98. «tocar frecuencia (Hz)» toca cualquier frecuencia positiva; con 0 o menos, silencio.verificado en la fuente · 18-09-2026
• Protobject (código fuente de la aplicación). Bloques de dispositivo y Dibujo LED (drawled). src/editor/blocks/device-blocks.ts, src/runtime/worker/api.ts, src/device/components/drawled/index.ts.El bloque «dibuja» se traduce en protobject.setProperty, que manda la orden y vuelve sin esperar. El bucle principal, «repetir para siempre», hace una pausa de 33 ms al comienzo de cada vuelta.verificado en la fuente · 19-09-2026
• Protobject (repositorio de la aplicación). Tilt the phone right for a positive x, as on the micro:bit. Commit 827ef50, 18-09-2026; src/device/components/accorientation/index.ts.Desde este cambio la Inclinación entrega x positiva al inclinar a la derecha, como el micro:bit; el eje y ya coincidía.verificado en el repositorio · 19-09-2026

Sobre MIDI y la percepción de intervalos

• MIDI Manufacturers Association (1996). The Complete MIDI 1.0 Detailed Specification. MIDI Manufacturers Association, secciones Note Number y MIDI Tuning. midi.org/midi-1-0-detailed-specificationDo central = 60; nota 69 = 440 Hz; pasos de semitono en temperamento igual. La fórmula f = 440·2^((n−69)/12) se deriva de ahí (y aparece literal en Wolfe, UNSW, y en Wikipedia).verificado en línea · 11-09-2026
• Brian C. J. Moore (2012). An Introduction to the Psychology of Hearing (6.ª ed.). Emerald / Brill, cap. 6, Pitch Perception. brill.com/display/title/24210Los intervalos musicales se perciben como razones de frecuencia (la octava es 2:1) por debajo de unos 5 kHz: por eso una escala lineal en Hz no suena como una escala.verificado en línea · 11-09-2026