Buenas,
a ver a quién se le ocurre cuál puede ser la causa. Resulta que la afinación de 1 voz hace cosas raras. El fallo ya debía estar antes pero no se ha empezado a notar hasta que le he puesto el kit GliGli.
Ocurre en uno de los osciladores "B", y es raro de narices. Ocurre cuando se dan los siguientes pasos:
-Bajo el volumen de los osciladores "A" y subo sólo el de los "B" que es donde está el fallo.
-Pulso nota 1 (se asigna a oscilador B1)
-Sin soltarla, pulso nota 2 (se asigna a oscilador B2)
-Sin soltar ninguna, pulso nota 3 (se asigna a oscilador B3)
-Hasta aquí todo suena perfecto.
-Sin soltar ninguna nota, pulso nota 4 (se asigna a oscilador B4).
En este momento, la nota 2 que ya estaba sonando (osc B2) SE DESAFINA MEDIO TONO HACIA ABAJO.
Pensé que sería un CEM3340 cascado, pero no tiene lógica, ya que ese mismo oscilador funciona bien hasta que se pulsa la 4ª nota de polifonía. Más bien parece alguna historia con algún comparador u otro elemento intermedio.
Otro síntoma: si pongo el modo UNISON (sonando sólo osciladores "B") se oye que uno de los osciladores está, en efecto, fuera de tono (el B2). Le ajusto el pote interno de calibración, el UNISON entonces suena perfecto, pero al poner de nuevo el modo POLY, una de las notas suena casi medio tono alta (equivalente a la corrección hecha por mí con el destornillador).
¿Alguna idea de dónde puede estar el problema?
Adjunto manual de servicio del chisme.
Archivos adjuntos (
loguéate para descargar)
PROPHET-600_SERVICE_MANUAL.pdf
mod
Yo creo que lo primero es confirmar (retirando la modificación) si te pasa ya en el original o no.
Lo digo porque si el salto es exactamente de un semitono parece poco probable que sea un fallo de la parte analógica y más bien pensaría en un fallo de programación, lo que nos llevaría a sospechar de la modificación.
El control del CV de los osciladores (y el de todas las señales de control analógico) viene de un único DAC que se demultiplexa hacia varios circuitos tipo S&H muy simples. Así que es el micro el que decide qué valor, el DA el que genera la tensión que corresponde a ese valor, y cada S&H el que retiene el valor (el micro va 'rotando' para ir actualizando todas las señales de control).
El único punto que veo en esa cadena que puede estar detrás de un fallo como el que dices es en el micro, internamente, en el código. En otro lugar no lo veo lógico.
En el original, esa misma voz siempre estaba ligeramente desafinada. Pero era algo muy sutil, tanto que hasta me gustaba porque sonaba "más analógico". Nunca le di importancia.
El salto que hace es casi de 1 semitono (no llega), pero además no es exacto. Hay veces que es un poco más y otras un poco menos (tiende a ser más grande cuanto más graves son las notas pulsadas).
Apunto, por si fuese importante el dato, que este sinte tiene un sistema de auto-afinado. Se pulsa el botón "Tune" y tras 20 segundos el chisme intenta calibrar los 12 osciladores y los 6 filtros (siempre que el sinte esté caliente, en frío no sirve de mucho).
mod
El autocalibrado no debería afectar. Es una rutina que sólo se lanza cuando se lo dices, no está permanentemente escuchando y corrigiendo.
Por lo que veo en el esquema no tiene influencia sobre tu problema.
A tenor de lo que dices, no sé si hay mucha relación entre el fallo anterior y el actual. Antes de la modificación una ligerísima casi imperceptible desafinación que ahora es de un semitono...
Te sugeriría (aunque te parezca una tontería) que hagas la prueba poniendo tu mano en contacto con el bus de datos y el de direcciones. Eso cambia la impedancia de las líneas. Muchas veces una tontería como esa parece que arregla mágicamente un problema de ruido o de velocidad de transiciones en un circuito digital.
Lo digo porque es impensable que cuentes con un analizador de buses, para ver exactamente qué pasa a la vez en todas las líneas (bus datos, bus direcciones).
Si parece que se arregla, se podría pensar en suplementar los buses con alguna resistencia de pull-up o pull-down, o con un juego de mini condensadores para limpiar algo de ruido...
Ya te digo que no es una vía segura. Pero si así se arregla, ya da una pista de por dónde seguir.
Es todo aventurar, pero me da que al pedirle más voces, el micro hace la ronda de actualización de valores más velozmente (o con cualquier otro cambio) y es posible que alguna parte de los valores que llegan al ADC, para alguna de las voces, esté siendo mal escrito y te de el error. Puede que todo esté tan ajustado a los tiempos y transiciones que usaba el micro antiguo, que este nuevo no se porte como cabía esperar. Lo habrán desarrollado ajustándose a un o dos p600 que tendrían a mano. Y como hayan querido forzar la velocidad para tener mejor refresco, etc. a lo mejor la han cagado un poco.
Pero, vaya, que esto es ejercicio de adivinación pura
"Lo habrán desarrollado ajustándose a un o dos p600 que tendrían a mano. Y como hayan querido forzar la velocidad para tener mejor refresco, etc. a lo mejor la han cagado un poco."
Sí, es una de las cosas que pensé. Aunque el kit lo han instalado ya cientos de personas en todo el mundo y no se ha reportado este problema previamente.
Otra prueba que haré al llegar a casa es intercambiar dos CEM3340 de sitio (el de la voz afectada y otro cualquiera) para ver si el problema se "traslada" de una voz a otra (por suerte todos los CEM están en zócalo). De esa manera podemos al menos descartar con toda seguridad que un CEM no se ha cascado.
Añado más datos (por si acaso, aunque no creo que sea útil):
En el pasado el sinte ya tuvo una reparación, tenía cascado un LM311 que afectaba a la afinación. Pero era otra cosa totalmente distinta porque afectaba a todas las voces simultáneamente.
mod
Te lo comento porque he leído que a modificación da lugar a envolventes más veloces, con más resolución en los ajustes de tiempo, etc. Eso implicaría que la actualización de las tensiones de control sucede más velozmente. Y esa nueva velocidad puede quizá no ser tolerada bien por todos los P600. Habrán subido la velocidad sin pasarse a lo bestia, pero eso no excluye que le toque la china a algún P600 concreto.
Si alguna parte del bus está ya funcionando demasiado al límite, puede haber condiciones peculiares (como lo que dices de lanzar 4 voces) que ya lo revienten. Pero eso, si se llega a detectar, a menudo puede intentar compensarse. Si le cuesta subir se refuerza con resistencias de pullup, si le cuesta bajar resistencias de pulldown. Si tiene exceso de ruido, un condensadorcito pequeño (para no cargarse las transiciones deseadas, y solo limpiar guarrería)...
Pues lo que haré (una vez descartada la avería del VCO) es grabar un video mostrando el problema y se lo enviaré al desarrollador del firmware, a ver qué opina él.
mod
Lo de 'meter la mano' es una forma de tantear. A veces el sólo hecho de tocar (con dedos, o con los instrumentos de medición como las sondas de osciloscopios y analizadores de buses) ya es suficiente para hacer que todo funcione, sencillamente porque introduce un cambio pequeño que desplaza la causa del error.
mod
Confirmado que va a toda tralla: el propio gligli hablando del firmware en la versión que había allá por jul'2013
About env clicks:
Ok I see, it's probably a side effect of driving the synth 10 times faster, not much I can do about it I think...
Legato clicks are because beta1 changed voice each time you triggered a new legato note (while keeping the same envelope ofc), this led to glide problems too. The new assigner doesn't do that anymore tho.
Claro que va a toda tralla. Incluso tuvo que meter loops de espera en algunas rutinas para que los buses y los componentes antiguos pudieran responder a la velocidad del nuevo MCU.
No obstante, el problema de los "clicks" durante las envolventes ya se solucionó en esta nueva versión.
Otra cosa que probaré: he puesto la 2.00 stable de hace unos meses, pero el tipo no ha dejado de sacar updates, el último de hace solo unos días.
Flashearé con la última versión para ver si hay algún cambio.
Gracias por la sugerencia.
Vamos a mirarlo a ver...
