Turntable Midi

Es una pena que la gente no se anime, agosto es lo que tiene. Ok adelante, esperemos que poco a poco se vayan uniendo.

Lo del tema del motor, pienso que con algo que regule la tensión podriamos ajustar la velocidad de giro (a modo de pich), y al girar el encoder es cuando manda la señal no?entonces con un interuptor que encienda el motor, seria como el play.

De todas formas yo me conformo con que el plato sea estático.aunque estoy acostrumbrado a scratchear con vinilo normal, no creo que si el plato está estático sea un inconveniente.

yo ánimos tengo para construirlo, si pasais por la ultima pagina del post sobre controlador midi casero, podreis ver un diseño del controlador que quiero construir. El caso esque yo no tengo idea de elctrónica, asi que siento no poder ser de ayuda.

A ver si alguien se anima a construirlo o a ayudarme si quiere, jeje.

saludillos

Lo único que obtendrías sería un motor con velocidad de rotación regulable (con el encoder), cosa nada recomendable. Se pretende que el motor sea perfectamente constante en su giro, otra cosa son las variaciones (fuerzas) que ejerzamos sobre él, eso es lo que hay que parametrizar y lo más difícil, interpretar e implementar dichos resultados. Si sobre un plato ejercemos fuerzas, aparecen aceleraciones y para recrear dichas aceleraciones deberemos obtener continuamente pares de velocidades (v1 y v2 obteniendo a1), (v2 y v3 obteniendo a2),..., (v[n] y v[n+1] obteniendo a[n]), ahora toca interpretar estas aceleraciones (fuerzas) en midi. Si la rotación dextrógira transfiere un +1 y levógira un -1 (habitualmente los controladores suelen mandar 63-64, 0-64, 0-128, etc...) ¿cómo traducimos los valores de aceleraciones a1, a2,..., an? Parece lógico pensar que para una a=5 (dextrógira) enviaré +1, +1, +1, +1, +1 en un intervalo de tiempo t, para una a=-3 (levógira) sería -1, -1, -1 en el mismo intervalo t, así sucesivamente. El tacto/sensación de realidad será proporcional a la "estrechez" del intervalo t, en la vida real ese intervalo es un dt y ahí es donde veo el gran problema, en la capacidad/incapacidad de midi o en la mia propia, me temo lo segundo.

Mmmm, ni idea chico, puro chino para mi, ejeje.

Lo único que opino esque si es tan complicado, podemos bajar un poco el listón, porque para mi seria suficiente un controlador que me permita moverme por la pista o incluso hacer scratch; para un plato que tenga las mismas caracteristicas que un plato de vinilos, ya uso los vinilos.
Yo cre que la opción más comoda es la del plato estático, aunque animo a los más intrépidos a construirse un plato midi motorizado.

De todas formas como dije antes, lamento no poder ser útil en este campo al no saber de electrónica.

Perdon por postear dos veces.

Creo que me apresuré al opinar, supongo que aunque el plato esté estático tambien habría que parametrizar las paradas y fuerzas que se ejerzan no?

En cuanto al primero de tus dos últimos mensajes si te suena a chino lo intentaré explicar de otra manera.
Si te sujetas a la barra de un autobús y éste marcha a 60 km/h ¿a qué velocidad vas si estás quieto? ¿0 ó 60?. Tu velocidad absoluta será 60km/h pero la relativa (respecto al autobús) 0km/h. ¿Y si caminas por el pasillo a 7 km/h hacia el conductor mientras el autobús circula a 60? En ese caso tu velocidad absoluta será 67 km/h y la relativa 7km/h.
Eso es lo que pretendía explicar, me da igual a qué velocidad vaya el autobús (plato) lo que realmente me importa es lo que sucede dentro de él (fuerzas que aplica el dj sobre el plato). Las aceleraciones que nos importan son las relativas.
Al segundo post decirte que sí, ya que queremos que la sensación se ajuste lo máximo posible a un plato real pero sin motor.

creo que si os comento un poco como funciona el mio podeis aclarar alguna duda. la sincro si es midi hay de dos tipos, la clasica SPP Song Position Point ó MTC Midi Time Code. de esto leeros las especificaciones por que tiene tela pa que yo os lo cuente http://www.eumus.edu.uy/docentes/jure/midi/#2.2.1
en un plastico transparente hice divisiones iguales creo recordar que eran 128 u 256 aunque ahora mismo me parecen pocas. y le monte dos comparadores lm311 con unos receptores de infrarojos por debajo del disco y por encima los diodos led infrarojos, para que al pasar la cuadricula del plastico vaya dando los pulsos. todo esto podeis leer sobre encoders incrementales. aseguraros algun sistema para poder mover uno de los sensores y así desfasar un canal de otro, alejando u acercando los sensores
__XX__XX A
_XX__XX_ B
ahora el micro lo que hace es en cada flanco ascendente de la señal A lee el estado de B y diferencia en que sentido esta girando. utilizando SPP en el modo tipico sin hacer un traductor con pure data ni na de eso... hay que jugar con play stop y los bytes de SPP, al leeros las especificaciones os dareis cuenta que se suele quedar pillao este sistema, pero es al que se adieren muchas firmas. luego con MTC si que hay buena resolucion y es todavia mas facil de usar. En los dos tipos lo que se hace es eso, enviar una señal de sincro en cada flanco del encoder segun el cambio con respecto al anterior. por ejemplo si esta parado o hubo una señal de stop y le llega un flanco ascendente debera enviar PLAY seguido de la señal de sincro, en el siguiente pulso ya solo enviaria la señal de sincro, y si se detiene X tiempo manda STOP

Gracias por explicarlo asi de sencillo. yo tb tenia esa duda de como seria el funcionamiento al estar parado el plato, etc. pero hablando de xy es = a V mas la variable x...pues no lo entendí. gracias por la aclaración.

creo que vamos por muy buen camino, y mas cuando tenemos compañeros que ya han resuelto todos los problemas.

Ánimo y seguid posteando

Gracias por la información Alogic, utilizas dos sensores para cuantificar y determinar el sentido del giro pero ¿cómo relativizas los movimientos puntuales que ejercemos al mezclar sobre el plato con su movimiento de rotación natural?. Sólo se me ocurre que en tu sistema el disco de acetato no sea solidario al motor de plato para evitar lecturas en los sensores. (Podrías hacer un dibujillo modo esquemático en el paint para hacernos una idea).
Lo que llevo en mente es obtener por separado A) el movimento plato + interacción dj (rotación normal del plato + fuerzas que le aplicamos mientras mezclamos) y B) el normal del plato (rotación sin fuerzas externas). El primero A) como muy bien has explicado se puede obtener con un disco y sus correspondientes subdivisiones, que por cierto a mi también me parecen pocas 128 o 256 (7 y 8 bits). Hago un inciso para comentar esto último creo que es muy importante, un plato de 12'' su longitud lineal es 12*PI (pulgadas) si hay 128 divisiones tenemos que mover 0,75cm el plato para que el sensor reciba actividad, si hay 256 divisiones entonces 0,37cm. Personalmente lo veo una barbaridad, pensemos que en un plato real sería 0 y por poner el mejor ejemplo Numark V7 (14bits y jog de 7") quedaría en 0,00134 este se acerca al 0 que es nuestro objetivo. Continuo, el segundo B) intento obtenerlo leyendo la tensión de corriente antes de "entrar" al motor, su diferencia será el movimiento relativo que es lo único que quiero, ahora hay que hacerlo.

pa mi que te estas complicando demasiao, sobre un motor estable el cual gira a X rpm pones un disco con el codigo, este puede ser de la resolucion que quieras, y cada tantos ticks que envie la sincro. asin de "facil" pero vamos que no digo que este mal, solo que es mucho mas simple de lo que parece
las divisiones no son 128 o 256 por ser ocho bits, es por que el smpte y el mtc dan X clics por revolucion del disco si pones mas clicks ira el doble de rapido, sementendió?? se pueden obviar con el micro y que cuente cada dos o tres, pero eso son truquillos del programador. la norma dice que son (creo recordar) 4cuadros por frame. 128frames = 1segundo etc etc... y se envia cada dos cuadros segun la norma, pero por ejemplo ableton aguanta de uno en uno 4x128x60cx60x60=puf, el mensaje con la posicion es una tirada de muchos bits, un segundo 4x128=512subdivisiones que no es que me lo haya inventado yo ni na de eso, es la norma tal cual la utilizan los fabricantes. ahora si quereis hacer calculos de esos que os gustan tanto, coged las rpm que da un plato y mirad a ver cuanto se mueve en un segundo y ahí teneis que meterle 512 divisiones

...

http://midibox.org/dokuwiki/doku.php?id ... controller


...

tambien esta el traktorizer echo por MTE http://www.midibox.org/dokuwiki/doku.ph ... zer_by_mte

...

Alogic escribió:

tambien esta el traktorizer echo por MTE http://www.midibox.org/dokuwiki/doku.ph ... zer_by_mte

Si pero yo te pongo los que sirven para scratch que también funcionan para mezclar, no siendo habitual al revés.

el mtc sirve para controlar el transporte pero no es muy util para hacer scratch.

La gente de stanton defienden que su sistema basado en sysex es útil pero el hid en modo mouse es muchisimo más preciso y rápido en la transmisión de posición relativa (velocidad y dirección) que la codificación en mensajes midi (u OSC).

Es un poco mierda porque no es tan compatible ni abierto pero creo que es el motivo por el cual ITCH usa HID.




...

ahí mas pillao, yo os hablo de lo que conozco, midi. y con mas o menos resolucion no se yo,MTC MidiTimeCode funciona mu bien, ahora que si te ves capaz de sacarle mas Ole, yo soy el primero que se va a quitar el sombrero. pero vamos que es un encoder y un micro para hacer pruebas, no se necesita nada mas. y asi me enseñais alguno de esos protocolos tan chulos y aprendo un poquito, en el ultimo controlador directamente le he puesto entrada para el plato y puede servirme todo eso que dices
http://a.imageshack.us/img28/9458/img5545v.jpg
http://a.imageshack.us/img535/9683/plato.jpg

...

Te voy a pegar codigo de lo que te digo del propio rastieri para que veas parte. Rastieri usa midi pero creo que del encoder saca posición relativa (es decir sólo dispara tics cuando un flanco del fotodiodo cambia de estado)... vamos a revisarlo juntos a ver si sacamos más cosas en claro.

Lo del HID es tan sencillo como un ratón de toda la vida.



Ahi va el codigo.


...