miércoles, 6 de febrero de 2008
martes, 5 de febrero de 2008
MIDI Formato de fichero. Eventos en tracks
Lo que he leido de los ficheros midis, me deja una duda que quiero solventar, por eso voy a traducir este documento.
Es una especie de borrador que espero ir arreglando.
Traducido de: aquí
Eventos en tracks.
Un MTrk(track) puede contener eventos MIDI y no eventos MIDI (es decir, los eventos que contienen datos como la configuración de tempo, los titulos, etc.)
Los primeros (1 a 4) byte (s) en un MTrk serán los delta-tiempos del el primer evento almacenados como una cantidad de longitud variable. El siguiente byte de datos es, en realidad, el primer byte de ese evento en sí. Voy a referirme a este byte como el Estado del Evento. Para eventos MIDI, ése será el byte de Estado MIDI (midi o el primer byte de datos en caso de running status). Por ejemplo, si el byte hexadecimal es 90, entonces este es un caso de Nota On en el canal midi 0. Si, por ejemplo, el byte hexadecimal es 23, lo que tenemos que recordar es el estado anterior (es decir, running status midi). Obviamente, el primer evento MIDI en la MTrk debe tener un byte de estado. Después de un byte de estado midi llegan sus bytes de datos 1 o 2 bytes de datos (dependiendo del Status - algunos mensajes MIDI sólo tienen despues 1 byte de datos ). Luego nos encontramso el delta-tiempo del siguiente evento (como una cantidad variable), etc
Eventos SYSEX
Eventos SYSEX (sistema exclusivo) (status = F0) son un caso especial porque un mensaje SYSEX puede ser cualquier longitud. Después del byte de Estado F0 (que siempre existe - no hay running-status aquí), encontrará una serie de bytes de longitud variable. De la misma forma que el delta-time pueden ser hasta 32 bits(8 bytes) que indica cuántos bytes más siguen al F0 y conforman el evento SYSEX. Esta longitud no incluye el Estado F0.
Por ejemplo, considere el siguiente mensaje SYSEX MIDI:
F0 7F 7F 04 01 7F 7F F7
Esto sería almacenado en un archivo MIDI con la siguiente serie de bytes (sin contar con los bytes de delta-tiempo que preceden al F0):
F0 07 7F 7F 04 01 7F 7F F7
La 07 es la cantidad de longitud variable (que pasa a caber en un solo byte para este ejemplo). Se indica que hay siete bytes despues del F0 para componer el mensaje SYSEX.
Los dispositivos midi del fabricante Really oddball envian un mensaje exclusivo del sistema(SYSEX) como una serie de "pequeños paquetes" (con un tiempo de retraso entre transmisión de cada paquete). La primera comienza con un paquete de F0, pero no termina con un F7. Los siguientes paquetes no empiezan con una F0 ,empiezan con F7 pero no finalizan con con F7. El último paquete no se inicia con una F0, se inicia con F7, pero sí termina con la F7. Así, entre el primer paquete de apertura de F0 y el último paquete de clausura del F7, hay un SYSEX mensaje. (Nota: sólo extremadamente pobres diseños, como el 'crap' comercializado por Casio exhiben tal horrible conducta). Por supuesto, como necesita una demora entre cada paquete, necesita almacenar cada paquete como un evento separado con su propio tiempo en el MTkr. Tambien, debe de alguna manera saber que eventos no deben comenzar con una F0 (es decir, todos ellos, excepto el primer paquete). Así, el archivo MIDI midi redefine una situación de F7 (que normalmente se utiliza como un fin para la marca SYSEX paquetes) como una forma de indicar que un evento no comienza con F0.
Si un evento sigue a un F0 evento, entonces se asume que el evento F7 es el segundo "paquete" de una serie. En este contexto, es mencionado como un caso SYSEX CONTINUACIÓN.
Al igual que el tipo de evento F0 , ls F7 tienen una cantidad de longitud variable seguida de bytes de datos.
Por otra parte, el evento F7 puede utilizarse para almacenar mensajes MIDI TIEMPO REAL o MIDI COMÚN(PERO NO MENSAJES DE CANAL). En este caso, después de los bytes de longitud variable, usted puede esperar encontrar un byte de Estado MIDI de F1, F2, F3, F6, F8, FA, FB, FC, o FE. (Tenga en cuenta que NO va a encontrar cualquiera de esos bytes dentro de un evento SYSEX CONTINUACIÓN). Cuando se usa de esta manera, el F7 evento es denominado ESCAPED evento.
Por lo que he entendio, un mensaje de SYSEX en formato continuación , son varios mensajes del formato.
F0datos
F7datos
.......
F7datos
F7F7
Otra cosa es el evento ESCAPE.
F7
En el evento ESCAPE caben los Estados comunes y Tiempo real.
Eventos no MIDI.
El estado de FF se reserva para indicar un evento especial no-MIDI.(Notar que FF es usado en MIDI con el significado de "reset", por lo que no es util almacenarlo en un fichero de datos. Sin embargo, el fichero MIDI redefine arbitrariamente el uso de este status). Despues del byte de estado FF, hay otro byte que nos indica el tipo del no-MIDI evento. Despues de este byte, tenemos otros bytes de cantidad de longitud variable que ya conocemos (ver delta-time). que nos indica la longitud del mensaje sin inccluir el FF el byte de tipo y la longitud misma. Estos no-MIDI eventos especiales se llaman Meta-Eventos, y la mayoría son opcionales mientras no se indique lo contrario. La seción de este libro online titulado "Meta-Eventos", lista los Meta-Eventos corrientemente definidos. Notar que aunque no ha sido mencionado, estos eventos se menten en un MTrk, puede haber mas de uno y llevan su delta-time correspondiente.(Como los eventos midi. Los Meta-Eventos tienen un delta-time que los separa del anterior evento. Tambien, puede libremente mezclar MIDI y Meta eventos).
Es una especie de borrador que espero ir arreglando.
Traducido de: aquí
Eventos en tracks.
Un MTrk(track) puede contener eventos MIDI y no eventos MIDI (es decir, los eventos que contienen datos como la configuración de tempo, los titulos, etc.)
Los primeros (1 a 4) byte (s) en un MTrk serán los delta-tiempos del el primer evento almacenados como una cantidad de longitud variable. El siguiente byte de datos es, en realidad, el primer byte de ese evento en sí. Voy a referirme a este byte como el Estado del Evento. Para eventos MIDI, ése será el byte de Estado MIDI (midi o el primer byte de datos en caso de running status). Por ejemplo, si el byte hexadecimal es 90, entonces este es un caso de Nota On en el canal midi 0. Si, por ejemplo, el byte hexadecimal es 23, lo que tenemos que recordar es el estado anterior (es decir, running status midi). Obviamente, el primer evento MIDI en la MTrk debe tener un byte de estado. Después de un byte de estado midi llegan sus bytes de datos 1 o 2 bytes de datos (dependiendo del Status - algunos mensajes MIDI sólo tienen despues 1 byte de datos ). Luego nos encontramso el delta-tiempo del siguiente evento (como una cantidad variable), etc
Eventos SYSEX
Eventos SYSEX (sistema exclusivo) (status = F0) son un caso especial porque un mensaje SYSEX puede ser cualquier longitud. Después del byte de Estado F0 (que siempre existe - no hay running-status aquí), encontrará una serie de bytes de longitud variable. De la misma forma que el delta-time pueden ser hasta 32 bits(8 bytes) que indica cuántos bytes más siguen al F0 y conforman el evento SYSEX. Esta longitud no incluye el Estado F0.
Por ejemplo, considere el siguiente mensaje SYSEX MIDI:
F0 7F 7F 04 01 7F 7F F7
Esto sería almacenado en un archivo MIDI con la siguiente serie de bytes (sin contar con los bytes de delta-tiempo que preceden al F0):
F0 07 7F 7F 04 01 7F 7F F7
La 07 es la cantidad de longitud variable (que pasa a caber en un solo byte para este ejemplo). Se indica que hay siete bytes despues del F0 para componer el mensaje SYSEX.
Los dispositivos midi del fabricante Really oddball envian un mensaje exclusivo del sistema(SYSEX) como una serie de "pequeños paquetes" (con un tiempo de retraso entre transmisión de cada paquete). La primera comienza con un paquete de F0, pero no termina con un F7. Los siguientes paquetes no empiezan con una F0 ,empiezan con F7 pero no finalizan con con F7. El último paquete no se inicia con una F0, se inicia con F7, pero sí termina con la F7. Así, entre el primer paquete de apertura de F0 y el último paquete de clausura del F7, hay un SYSEX mensaje. (Nota: sólo extremadamente pobres diseños, como el 'crap' comercializado por Casio exhiben tal horrible conducta). Por supuesto, como necesita una demora entre cada paquete, necesita almacenar cada paquete como un evento separado con su propio tiempo en el MTkr. Tambien, debe de alguna manera saber que eventos no deben comenzar con una F0 (es decir, todos ellos, excepto el primer paquete). Así, el archivo MIDI midi redefine una situación de F7 (que normalmente se utiliza como un fin para la marca SYSEX paquetes) como una forma de indicar que un evento no comienza con F0.
Si un evento sigue a un F0 evento, entonces se asume que el evento F7 es el segundo "paquete" de una serie. En este contexto, es mencionado como un caso SYSEX CONTINUACIÓN.
Al igual que el tipo de evento F0 , ls F7 tienen una cantidad de longitud variable seguida de bytes de datos.
Por otra parte, el evento F7 puede utilizarse para almacenar mensajes MIDI TIEMPO REAL o MIDI COMÚN(PERO NO MENSAJES DE CANAL). En este caso, después de los bytes de longitud variable, usted puede esperar encontrar un byte de Estado MIDI de F1, F2, F3, F6, F8, FA, FB, FC, o FE. (Tenga en cuenta que NO va a encontrar cualquiera de esos bytes dentro de un evento SYSEX CONTINUACIÓN). Cuando se usa de esta manera, el F7 evento es denominado ESCAPED evento.
Por lo que he entendio, un mensaje de SYSEX en formato continuación , son varios mensajes del formato.
.......
Otra cosa es el evento ESCAPE.
En el evento ESCAPE caben los Estados comunes y Tiempo real.
Eventos no MIDI.
El estado de FF se reserva para indicar un evento especial no-MIDI.(Notar que FF es usado en MIDI con el significado de "reset", por lo que no es util almacenarlo en un fichero de datos. Sin embargo, el fichero MIDI redefine arbitrariamente el uso de este status). Despues del byte de estado FF, hay otro byte que nos indica el tipo del no-MIDI evento. Despues de este byte, tenemos otros bytes de cantidad de longitud variable que ya conocemos (ver delta-time). que nos indica la longitud del mensaje sin inccluir el FF el byte de tipo y la longitud misma. Estos no-MIDI eventos especiales se llaman Meta-Eventos, y la mayoría son opcionales mientras no se indique lo contrario. La seción de este libro online titulado "Meta-Eventos", lista los Meta-Eventos corrientemente definidos. Notar que aunque no ha sido mencionado, estos eventos se menten en un MTrk, puede haber mas de uno y llevan su delta-time correspondiente.(Como los eventos midi. Los Meta-Eventos tienen un delta-time que los separa del anterior evento. Tambien, puede libremente mezclar MIDI y Meta eventos).
MIDI Especificación. Mensajes excusivos.
Después de haber traducido la especificación de los mensajes midi, voy a traducir los que menos entiendo. los famosos mensajes exclusivos.
Traducido de aqúi
Mensajes Exclusivos del sistema (es decir, SysEx)
Propósito :
Se utilizan para enviar una gran cantidad de datos a un dispositivo MIDI, como un volcado de memoria de su patch(conjunto de instrumentos o datos del secuenciador o los datos de forma de onda(datos de audio). Asimismo, SysEx pueden ser utilizados para transmitir la información que es particular de un modelo de dispositivo. Por ejemplo, un mensaje SysEx podría ser usado para enviar la información del operador en un Sintetizador Roland de Modelado Físico. Esta información sería probablemente inútil para un sampler AKAI que reproduce muestras de sonido. (Por el contrario, prácticamente todos los dispositivos responden a un control de rueda de modulación, por ejemplo, así que tiene sentido tener definido un mensaje de controlador de modulación que todos los fabricantes puedan apoyar con ese fin).
Status:
Comienza con el byte de estado 0xF0. y termina con un byte de estado 0xF7 (es decir, después de los bytes de datos).
Datos:
Puede ser cualquier número de bytes de datos entre el 0xF0 inicial y el 0xF7 final. El más importante es el primer byte de datos (después del 0xF0), que debe ser una identificación del fabricante.
Errata ?????
Prácticamente todos los dispositivos MIDI definen el formato de su propio conjunto de mensajes SysEx (es decir, que sólo ellos lo entienden). El único punto en común de los mensajes SysEx de diversos modelos de dispositivos MIDI es que todos los mensajes SysEx debe comenzar con un estado 0xF0 y terminar con un estado 0xF7. En otras palabras, este es el único mensaje MIDI que tiene 2 bytes de estado, uno al inicio y otro al final.
Entre estos dos bytes de estado, cualquier número de bytes de datos (todos a cero el bit # 7, es decir, el valor de 0 a 127) puede ser enviado. Por eso necesita un SysEx 0xF7 estado byte al final, de modo que un dispositivo MIDI sabrá cuando el final del mensaje aparece, incluso si los datos del mensaje no es entendido por el dispositivo (es decir, el dispositivo no sabe Exactamente el número de bytes de datos a esperar antes del 0xF7).
Por lo general, el primer byte de datos (después del 0xF0) será un ID definido por el fabricante. La organización MMA ha asignado valores del byte ID a varios fabricantes, de manera que un dispositivo puede determinar si un mensaje SysEx se destina para el. Por ejemplo, un dispositivo de Roland espera un byte ID de 0x41. Si un dispositivo de Roland recibe un mensaje SysEx cuyo byte ID no es 0x41, el aparato hace caso omiso de todos los del resto de los bytes hasta que llega el byte final 0xF7 que indica que el mensaje SysEx ha terminado.
El objetivo de los restantes bytes de datos, que pueden ser muchos, son determinados por el fabricante . Normalmente, los fabricantes al ID del fabricante le sigue un byte de Número de identificación asi, un dispositivo no sólo puede determinar que hay un mensaje SysEx correcto del fabricante, sino también que es un mensaje SysEx específicamente para este modelo. Luego, después de la ID del modelo puede seguir otro byte que el dispositivo utiliza para determinar el tipo de mensaje SysEx , y, por lo tanto, el número de bytes de datos más que seguirán. Algunos fabricantes tienen un byte de checksum, (por lo general, justo antes de la 0xF7) que se utiliza para verificar la integridad de la transmisión del mensaje.
El byte de estado 0xF7 se utiliza para marcar el final de un mensaje SysEx. Nunca debe ocurrir sin precederle un Estado 0xF0. En el caso de que un dispositivo experimente tal condición (es decir, tal vez el cable MIDI se conectó a mitad de la transmisión de un mensaje SysEx), el dispositivo debe ignorar el Estado 0xF7.
Además, aunque el 0xF7 supone que marca el final de un mensaje SysEx, de hecho, cualquier byte de estado (a excepción de la categoría de mensajes en tiempo real), debe causar el mensaje SysEx como "terminado" (es decir, "abortado". Ya que tal situación indica una situación anormal del MIDI). Por ejemplo, si un 0x90 se envió después de un 0xF0 (pero antes de la 0xF7), entonces el mensaje SysEx se considera abortado en ese momento. Cabe señalar que, como todos los Mensajes Comunes del Sistema, SysEx anula cualquier 'runing status' actual. En otras palabras, el siguiente mensaje de Categoria de Voz (tras el mensaje SysEx) debe comenzar con un Estado.
Vaaaaya, creo que lo he entendio casi todo.
La unica duda que tengo es ese : (a excepción de la categoría de mensajes en tiempo real)
Traducido de aqúi
Mensajes Exclusivos del sistema (es decir, SysEx)
Propósito :
Se utilizan para enviar una gran cantidad de datos a un dispositivo MIDI, como un volcado de memoria de su patch(conjunto de instrumentos o datos del secuenciador o los datos de forma de onda(datos de audio). Asimismo, SysEx pueden ser utilizados para transmitir la información que es particular de un modelo de dispositivo. Por ejemplo, un mensaje SysEx podría ser usado para enviar la información del operador en un Sintetizador Roland de Modelado Físico. Esta información sería probablemente inútil para un sampler AKAI que reproduce muestras de sonido. (Por el contrario, prácticamente todos los dispositivos responden a un control de rueda de modulación, por ejemplo, así que tiene sentido tener definido un mensaje de controlador de modulación que todos los fabricantes puedan apoyar con ese fin).
Status:
Comienza con el byte de estado 0xF0. y termina con un byte de estado 0xF7 (es decir, después de los bytes de datos).
Datos:
Puede ser cualquier número de bytes de datos entre el 0xF0 inicial y el 0xF7 final. El más importante es el primer byte de datos (después del 0xF0), que debe ser una identificación del fabricante.
Errata ?????
Prácticamente todos los dispositivos MIDI definen el formato de su propio conjunto de mensajes SysEx (es decir, que sólo ellos lo entienden). El único punto en común de los mensajes SysEx de diversos modelos de dispositivos MIDI es que todos los mensajes SysEx debe comenzar con un estado 0xF0 y terminar con un estado 0xF7. En otras palabras, este es el único mensaje MIDI que tiene 2 bytes de estado, uno al inicio y otro al final.
Entre estos dos bytes de estado, cualquier número de bytes de datos (todos a cero el bit # 7, es decir, el valor de 0 a 127) puede ser enviado. Por eso necesita un SysEx 0xF7 estado byte al final, de modo que un dispositivo MIDI sabrá cuando el final del mensaje aparece, incluso si los datos del mensaje no es entendido por el dispositivo (es decir, el dispositivo no sabe Exactamente el número de bytes de datos a esperar antes del 0xF7).
Por lo general, el primer byte de datos (después del 0xF0) será un ID definido por el fabricante. La organización MMA ha asignado valores del byte ID a varios fabricantes, de manera que un dispositivo puede determinar si un mensaje SysEx se destina para el. Por ejemplo, un dispositivo de Roland espera un byte ID de 0x41. Si un dispositivo de Roland recibe un mensaje SysEx cuyo byte ID no es 0x41, el aparato hace caso omiso de todos los del resto de los bytes hasta que llega el byte final 0xF7 que indica que el mensaje SysEx ha terminado.
El objetivo de los restantes bytes de datos, que pueden ser muchos, son determinados por el fabricante . Normalmente, los fabricantes al ID del fabricante le sigue un byte de Número de identificación asi, un dispositivo no sólo puede determinar que hay un mensaje SysEx correcto del fabricante, sino también que es un mensaje SysEx específicamente para este modelo. Luego, después de la ID del modelo puede seguir otro byte que el dispositivo utiliza para determinar el tipo de mensaje SysEx , y, por lo tanto, el número de bytes de datos más que seguirán. Algunos fabricantes tienen un byte de checksum, (por lo general, justo antes de la 0xF7) que se utiliza para verificar la integridad de la transmisión del mensaje.
El byte de estado 0xF7 se utiliza para marcar el final de un mensaje SysEx. Nunca debe ocurrir sin precederle un Estado 0xF0. En el caso de que un dispositivo experimente tal condición (es decir, tal vez el cable MIDI se conectó a mitad de la transmisión de un mensaje SysEx), el dispositivo debe ignorar el Estado 0xF7.
Además, aunque el 0xF7 supone que marca el final de un mensaje SysEx, de hecho, cualquier byte de estado (a excepción de la categoría de mensajes en tiempo real), debe causar el mensaje SysEx como "terminado" (es decir, "abortado". Ya que tal situación indica una situación anormal del MIDI). Por ejemplo, si un 0x90 se envió después de un 0xF0 (pero antes de la 0xF7), entonces el mensaje SysEx se considera abortado en ese momento. Cabe señalar que, como todos los Mensajes Comunes del Sistema, SysEx anula cualquier 'runing status' actual. En otras palabras, el siguiente mensaje de Categoria de Voz (tras el mensaje SysEx) debe comenzar con un Estado.
Vaaaaya, creo que lo he entendio casi todo.
La unica duda que tengo es ese : (a excepción de la categoría de mensajes en tiempo real)
MIDI Especificación. Mensajes.
Primer post sobre el protocolo midi.
Esto es una tradución de aquí
Es una especie de borrador que dios 'menguante' trataré de formalizar.
Voy a tratar de ahondar todo lo posible desde mi experiencia.(¡ejem!.Que puede ser muy poca).
MENSAJES MIDI.
El protocolo MIDI está compuesto de mensajes. Un mensaje consiste en una cadena (es decir, serie) de bytes (de 8 bits). MIDI ha definido muchos de esos mensajes. Algunos mensajes constan de sólo 1 byte. Otros mensajes tienen 2 bytes. Otros tienen 3 bytes. Un tipo de mensaje MIDI puede tener un número ilimitado de bytes. Una cosa que todos los mensajes tienen en común es que el primer byte del mensaje es el byte de estado. Se trata de un byte especial porque es el único byte que tiene a 1 el bit #7. Cualquier otro byte del mensaje tiene el bit #7 a 0. Por lo tanto, siempre se puede detectar el comienzo un mensaje MIDI, ya que es cuando se recibe un byte con el bit # 7 a 1. El byte de estado estará entonces en el rango de 0x80 a 0xFF. El resto de bytes del mensaje (es decir, los bytes de datos, si existen) estarán en el rango 0x00 a 0x7F. (Tenga en cuenta que estoy usando el método que tiene el lenguaje de programación C para indicar un valor hexadecimal con el prefijo 0x.).
Los bytes de estado de 0x80 a 0xEF son para los mensajes que pueden ser difundidos en cualquiera de los 16 canales MIDI(en estos mensajes, hay que indicar a cual de los 16 canales afecta). Debido a esto, estos son llamados mensajes de voz. (Mi preferencia es decir, que estos mensajes pertenecen a la categoría de voz, algunos les llaman mensajes de canal.). Estos bytes de estado, hay que romperlos en dos nibbles de 4bits.Por ejemplo, un byte de estado 0x92 puede ser dividido en 2 nibbles con valores de 9 (nibble alto) y 2 (nibble bajo). El nible alto le indica qué tipo de mensaje MIDI es. Estos son los posibles valores del nibble alto, y qué tipo de mensaje de categoría voz(canal) representa cada uno:
NOTA: Aunque el byte de estado MIDI cuenta con los 16 canales MIDI, como los números de 0 a F (es decir, de 0 a 15), todos los aparatos MIDI (incluyendo los programas informáticos) muestra un número de canal para el músico como del 1 al 16. Así, un byte de Estado enviado al canal MIDI 0 se considera el "canal 1" en la medida de lo es el músico en cuestión. Esta discrepancia entre el número de canal del byte de estado , y el canal MIDI al que el músico "cree" mandar el mensaje, se acepta porque la mayoría de los seres humanos empieza a contar las cosas a partir del 1 , en lugar de 0.
Los bytes de estado de 0xF0 a 0xFF, son para los mensajes que no están asociados a ningún canal (y por lo tanto todos dispositivos MIDI(en el sentido de dispositivos que respondena sólo un determinado canal) siempre pueden "escuchar" y optar por actuar con respecto a estos mensajes. Esto contrasta con la categoría de mensajes de voz, que solo actuan en un dispositivo MIDI configurado para responder a los mensajes de un determinado canal cuando coincide el número de canal del mensaje y el del dispositivo.). Estos bytes estado(0xF0 a 0xFF) se utilizan para los mensajes que llevan la información de interés para todos los dispositivos MIDI, como por ejemplo el sincronizado de todos los dispositivos de reproducción a un momento determinado. (Por el contrario, los mensajes de categoría de voz se refieren a las partes de musica individual que podrían desempeñar cada uno de los instrumentos, por lo que el esquema del nibble de canal permite a los dispositvos responder a su propio canal MIDI haciendo caso omiso de los mensajes de categoría voz destinados a otro dispositivo en otro canal).
Estos bytes estado(0xF0 a 0xFF) se dividen en dos categorías. Los Mensajes con bytes de estado de 0xF0 a 0xF7 son llamados mensajes comunes del sistema. Los mensajes con bytes de estado de 0xF8 a 0xFF son llamados mensajes en tiempo real del sistema. Las implicaciones de estos tipos se discutirám más adelante.
En realidad, algunos bytes de estado dentro de este rango(0xF0 a 0xF7) no están definidos por la especificación MIDI a la fecha, y se reservan para uso futuro. Por ejemplo, los bytes de estado 0xF4, 0xF5, 0xF9, y 0xFD no se utilizan. Si un dispositivo MIDI recibe dichos bytes de estado, debería ignorar el mensaje. Véase la sección: Ignorando mensajes MIDI.
Lo siguiente sería una descripción de cada tipo de mensaje. La descripción de lo que el mensaje significa, lo que significa su byte de estado, y si tiene algún posteriores bytes de datos y el tipo de información que llevan. En general, estas descripciones dependen de lo que haga dispositivo de recibir dichos mensajes (es decir, lo que esperamos que el dispositivo haga al recibir el mensajes). En su caso, tambien puede haber comentarios acerca de los dispositivos que transmiten estos mensajes.
------------------------
La especificación general de los mensajes esta super bien explicada. Otra cosa es verlo en la práctica.
Esto es una tradución de aquí
Es una especie de borrador que dios 'menguante' trataré de formalizar.
Voy a tratar de ahondar todo lo posible desde mi experiencia.(¡ejem!.Que puede ser muy poca).
MENSAJES MIDI.
El protocolo MIDI está compuesto de mensajes. Un mensaje consiste en una cadena (es decir, serie) de bytes (de 8 bits). MIDI ha definido muchos de esos mensajes. Algunos mensajes constan de sólo 1 byte. Otros mensajes tienen 2 bytes. Otros tienen 3 bytes. Un tipo de mensaje MIDI puede tener un número ilimitado de bytes. Una cosa que todos los mensajes tienen en común es que el primer byte del mensaje es el byte de estado. Se trata de un byte especial porque es el único byte que tiene a 1 el bit #7. Cualquier otro byte del mensaje tiene el bit #7 a 0. Por lo tanto, siempre se puede detectar el comienzo un mensaje MIDI, ya que es cuando se recibe un byte con el bit # 7 a 1. El byte de estado estará entonces en el rango de 0x80 a 0xFF. El resto de bytes del mensaje (es decir, los bytes de datos, si existen) estarán en el rango 0x00 a 0x7F. (Tenga en cuenta que estoy usando el método que tiene el lenguaje de programación C para indicar un valor hexadecimal con el prefijo 0x.).
Los bytes de estado de 0x80 a 0xEF son para los mensajes que pueden ser difundidos en cualquiera de los 16 canales MIDI(en estos mensajes, hay que indicar a cual de los 16 canales afecta). Debido a esto, estos son llamados mensajes de voz. (Mi preferencia es decir, que estos mensajes pertenecen a la categoría de voz, algunos les llaman mensajes de canal.). Estos bytes de estado, hay que romperlos en dos nibbles de 4bits.Por ejemplo, un byte de estado 0x92 puede ser dividido en 2 nibbles con valores de 9 (nibble alto) y 2 (nibble bajo). El nible alto le indica qué tipo de mensaje MIDI es. Estos son los posibles valores del nibble alto, y qué tipo de mensaje de categoría voz(canal) representa cada uno:
- 8 = Note Off
- 9 = Note On
- A = AfterTouch (ie, key pressure)
- B = Control Change
- C = Program (patch) change
- D = Channel Pressure
- E = Pitch Wheel
NOTA: Aunque el byte de estado MIDI cuenta con los 16 canales MIDI, como los números de 0 a F (es decir, de 0 a 15), todos los aparatos MIDI (incluyendo los programas informáticos) muestra un número de canal para el músico como del 1 al 16. Así, un byte de Estado enviado al canal MIDI 0 se considera el "canal 1" en la medida de lo es el músico en cuestión. Esta discrepancia entre el número de canal del byte de estado , y el canal MIDI al que el músico "cree" mandar el mensaje, se acepta porque la mayoría de los seres humanos empieza a contar las cosas a partir del 1 , en lugar de 0.
Los bytes de estado de 0xF0 a 0xFF, son para los mensajes que no están asociados a ningún canal (y por lo tanto todos dispositivos MIDI(en el sentido de dispositivos que respondena sólo un determinado canal) siempre pueden "escuchar" y optar por actuar con respecto a estos mensajes. Esto contrasta con la categoría de mensajes de voz, que solo actuan en un dispositivo MIDI configurado para responder a los mensajes de un determinado canal cuando coincide el número de canal del mensaje y el del dispositivo.). Estos bytes estado(0xF0 a 0xFF) se utilizan para los mensajes que llevan la información de interés para todos los dispositivos MIDI, como por ejemplo el sincronizado de todos los dispositivos de reproducción a un momento determinado. (Por el contrario, los mensajes de categoría de voz se refieren a las partes de musica individual que podrían desempeñar cada uno de los instrumentos, por lo que el esquema del nibble de canal permite a los dispositvos responder a su propio canal MIDI haciendo caso omiso de los mensajes de categoría voz destinados a otro dispositivo en otro canal).
Estos bytes estado(0xF0 a 0xFF) se dividen en dos categorías. Los Mensajes con bytes de estado de 0xF0 a 0xF7 son llamados mensajes comunes del sistema. Los mensajes con bytes de estado de 0xF8 a 0xFF son llamados mensajes en tiempo real del sistema. Las implicaciones de estos tipos se discutirám más adelante.
En realidad, algunos bytes de estado dentro de este rango(0xF0 a 0xF7) no están definidos por la especificación MIDI a la fecha, y se reservan para uso futuro. Por ejemplo, los bytes de estado 0xF4, 0xF5, 0xF9, y 0xFD no se utilizan. Si un dispositivo MIDI recibe dichos bytes de estado, debería ignorar el mensaje. Véase la sección: Ignorando mensajes MIDI.
Lo siguiente sería una descripción de cada tipo de mensaje. La descripción de lo que el mensaje significa, lo que significa su byte de estado, y si tiene algún posteriores bytes de datos y el tipo de información que llevan. En general, estas descripciones dependen de lo que haga dispositivo de recibir dichos mensajes (es decir, lo que esperamos que el dispositivo haga al recibir el mensajes). En su caso, tambien puede haber comentarios acerca de los dispositivos que transmiten estos mensajes.
------------------------
La especificación general de los mensajes esta super bien explicada. Otra cosa es verlo en la práctica.
lunes, 28 de enero de 2008
firmas gpg
Breve comentario de la necesidad de firmas y como hacerlo con gpg
Pregunta:
Para que sirve firmar un documento:
Respuesta:
1.- Para que el que lo lea sepa quien lo ha escrito.
2.- Para que sepamos que el documento es original.
Pregunta ¿Como firmamos con gpg?
Respuesta:
Una vez creada nuestra clave, podemos firmar el fichero con este comando:
gpg --output ficherofirmado.sig --sign fichero
Pregunta:¿Como verifico que es correcto el fichero firmado y quien lo ha firmado?
Respuesta:
gpg --verify ficherofirmado.sig
Pregunta: ¿Como recuperamos el fichero firmado con gpg?
Respuesta:
gpg --output fichero --decrypt ficherofirmado.sig
No nos pedirá ningun password ni 'nada' y nos dirá quien lo ha firmado.
Pregunta:¿Pero yo tengo un fichero de texto y quiero que se conserve el texto y se vea la firma?
Respuesta:
gpg --outpt ficherofirmado.asc --clearsig fichero
Pregunta:¿Y como verifico el fichero firmado en texto?
Respuesta:
Pues igual : gpg --verify ficherofirmado.asc
Pregunta:¿Y si quiero conservar el fichero original y la firma que esté en un fichero separado?
Respuesta:
También se puede de esta forma:
$ gpg --output firmadefichero.sig --detach-sig fichero
el fichero se queda como esta y se genenera uno nuevo firmadefichero.sig
Pregunta: ¿En este caso como verifico la firma?
Respuesta:
gpg --verify firmadefichero.sig fichero
Pregunta:
Para que sirve firmar un documento:
Respuesta:
1.- Para que el que lo lea sepa quien lo ha escrito.
2.- Para que sepamos que el documento es original.
Pregunta ¿Como firmamos con gpg?
Respuesta:
Una vez creada nuestra clave, podemos firmar el fichero con este comando:
gpg --output ficherofirmado.sig --sign fichero
Pregunta:¿Como verifico que es correcto el fichero firmado y quien lo ha firmado?
Respuesta:
gpg --verify ficherofirmado.sig
Pregunta: ¿Como recuperamos el fichero firmado con gpg?
Respuesta:
gpg --output fichero --decrypt ficherofirmado.sig
No nos pedirá ningun password ni 'nada' y nos dirá quien lo ha firmado.
Pregunta:¿Pero yo tengo un fichero de texto y quiero que se conserve el texto y se vea la firma?
Respuesta:
gpg --outpt ficherofirmado.asc --clearsig fichero
Pregunta:¿Y como verifico el fichero firmado en texto?
Respuesta:
Pues igual : gpg --verify ficherofirmado.asc
Pregunta:¿Y si quiero conservar el fichero original y la firma que esté en un fichero separado?
Respuesta:
También se puede de esta forma:
$ gpg --output firmadefichero.sig --detach-sig fichero
el fichero se queda como esta y se genenera uno nuevo firmadefichero.sig
Pregunta: ¿En este caso como verifico la firma?
Respuesta:
gpg --verify firmadefichero.sig fichero
sábado, 26 de enero de 2008
gnupg-Cifrado asimétrico
gnupg. un sistema criptografico libre.
¿Que podemos hacer con gnupg?.
.- Claves asimétricas.
Un problema de la encriptación de mensajes o archivos, es el ponerse de acuerdo con los passwords o claves para desencriptar un contenido. La solución asimétrica, consiste en que cada uno elije su password y lo que le mandan encriptado lo desencripta con su password. ¿Que no lo entiendes?, yo tampoco lo entendia y por eso pongo un ejemplo.
Tenemos dos amigos Juan y Pedro. Ambos quieren encriptarse cosas de modo que lo que le mande Juan a Pedro solamente lo puede desencriptar Pedro y lo que le mande Pedro a Juan, solo lo puede desencriptar Juan. ¿Como lo hacen?.
¿Se ha entendido?.
Vamos a verlo un poco mas practico, pero sin mucho detalle todavía para que se entienda.
Juan crea la clave
Pedro tiene que enviar un fichero a Juan
Juan recibe el fichero encriptado.
!alto! !alto!, la operativa parece facil, pero es un lio enorme.
Pregunta:
Respuesta:
¿Que podemos hacer con gnupg?.
.- Claves asimétricas.
Un problema de la encriptación de mensajes o archivos, es el ponerse de acuerdo con los passwords o claves para desencriptar un contenido. La solución asimétrica, consiste en que cada uno elije su password y lo que le mandan encriptado lo desencripta con su password. ¿Que no lo entiendes?, yo tampoco lo entendia y por eso pongo un ejemplo.
Tenemos dos amigos Juan y Pedro. Ambos quieren encriptarse cosas de modo que lo que le mande Juan a Pedro solamente lo puede desencriptar Pedro y lo que le mande Pedro a Juan, solo lo puede desencriptar Juan. ¿Como lo hacen?.
Pedro con el gnupg elije su password y crea un fichero que se llama clave publica que se lo envia a Juan, Juan cuando cifra (o encripta que es lo mismo) un fichero lo hace utilizando la clave pública de Pedro, el unico que puede desencriptar este fichero es Pedro que tiene el password.
De la misma forma Juan con el gnupg elije su password y crea un fichero que se llama clave publica que se lo envia a Pedro,Pedro cuando cifra (o encripta que es lo mismo) un fichero lo hace utilizando la clave pública de Juan, el unico que puede desencriptar este fichero es Juan que tiene el password.
¿Se ha entendido?.
Vamos a verlo un poco mas practico, pero sin mucho detalle todavía para que se entienda.
Juan crea la clave
Juan escribe en su terminal:Juan exporta su clave pública
$gpg --gen-key,
Le pregunta unos datos, entre otros nos pide un password, esto genera algunos ficheros en algún sitio con información sobre estos datos.
Juan crea un ficherete con su clave pública de esta forma:Pedro recibe la clave pública de Juan.
$gpg --export > juan.gpg
y este fichero se lo envia a Pedro.
Cuando Pedro recibe la clave pública de Juan, la integra en su sistema.
$gpg --import juan.gpg
Pedro tiene que enviar un fichero a Juan
Pedro tiene un fichero para Juan que se llama "ficheroparaenviar".
Pedro quiere enviarselo a Juan encriptado, y lo hace así.
$gpg --encrypt ficheroparaenviar > ficheroparajuan.gpg
(gpg le preguntará para quien quiere enviarlo).
Sólamente Juan podrá leer este fichero y se lo envía.
Juan recibe el fichero encriptado.
entonces Juan lo desencripta así:
$gpg --decrypt ficheroparajuan.gpg > ficherodepedro
le pedirá a Juan password que introdujo cuando creó la clave y ya esta.
!alto! !alto!, la operativa parece facil, pero es un lio enorme.
Pregunta:
-Es mucho mas facil el sistema de siempre, cifro con un password y envío el fichero a quien me de la gana.
¿Si quiero enviar el fichero a 5 personas tengo que encriptarlo cinco veces?.
Y aun con todo, esto es muy complicado.
Respuesta:
- De acuerdo, de acuerdo, pero este sistema de cifrado tiene sus ventajas, no hay el lio de passwords del sistema tradicional.
-No hace falta cifrar el fichero 5 veces si tienes que enviarlo a cinco personas, porque se puede cifrar con las cinco a la vez.
- En realidad esto está pensado para integrarse en programas que envian/reciben mensajes o ficheros como por ejemplo el correo. Si el cliente de correo te permite asignar una clave publica gpg a un destinatario, le enviaras los correos cifrados y si recibes un correo cifrado te preguntará el password.
martes, 1 de enero de 2008
Blender. Modelando algo parecido a un señor(1). Extruir.
Nota. Para entender este post, tienes que saber algo de blender. Los post anteriores mios te pueden servir.
Extruir:
Una utilidad muy frecuente en blender es Extruir o Extrudir (estrude en english).
1. tr. Tecnol. Dar forma a una masa metálica, plástica, etc., haciéndola salir por una abertura especialmente dispuesta.
Para comprenderlo, nada mejor que la practica:
Crea un nuevo proyecto con blender, y en modo edición seleciona una cara del cubo, pulsa tecla-E y veras como aparece un eje, mueve el ratón y veras como se 'extrude' la cara que has seleccionado. Has convertido un cuadrado en un cubo. Igualmente pudes convertir un circulo en un cilindro, un punto en una recta, un segmento en un rectangulo.......
Recuerda la operativa. Seleccionar algo, tecla-E mover el raton y cuando te parezca bien pulsa boton izquierdo del raton.
Si pulsas el boton derecho del raton, la cosa se queda como antes de pulsar tecla-E.
Recuerda control-Z para desacer.
Tienes tambien en el menu de malla(mesh) el comando extrude por si se te olvida la tecla que es.
Truco si mientras estas moviendo el raton extruyendo, pulsas la tecla control veras como se ajusta la extrusión a 'algo'. Por ejemplo si estas extruyendo la cara de un cubo, al pulsar la tecla control, se extruye como para duplicar el cubo original. ¡Pruebalo demonios, que no me se explicar y es muy facil!.
Pues ya me he cansado de extruir todo lo que he podido y vamos a empezar a hacer ese señor que digo en el título.
Empezando a modelar un señor.
Abrimos un proyecto nuevo y sobre el cubo que nos regala blender, seleccionamos una cara y extruimos pulsando tecla control para duplicar el cubo.
Y seguimos estruyendo hasta conseguir esta figura:
Para conseguirla tendras que aplicar muchas de las reglas que hemos aprendido como edit-mode ,tecla-A para seleccionar/Deseleccionar, shif-boton central del raton y mover el raton para girar la imagen, Quizá control-Z para hacer algun undo, boton derecho del raton para seleccionar caras......
Si nunca has trabajado con 3d, conseguir esto es un gran reto y gratificante.
Añadir la cabeza:
Traduzco del original en ingles.
Nota importante: asegurarse de que está todavía en el modo Editar (en la foto) al añadir la cabeza. Si no, la cabeza y el cuerpo no será parte del mismo objeto y los cambios en el cuerpo que se requieren en la siguiente sección, no afectarán a la cabeza.
Seleccionar un punto justo encima de la parte superior del cuello utilizando el boton izquierdo del raton: el círculo rojo y blanco es el cursor. Para ajustar la posición del cursor, cambiar entre la vista superior, frontal y lateral (utilizando el NUM7, NUM1, y NUM3 respectivamente). También puede utilizar la herramienta de snap (ajuste rapido): pulse SHIFT + S para mostrar el menú snap y seleccionar Cursor → Grid(o mesh->snap->Cursor->Grid) Esto nos colocara el cursor 3d justo en medio del plano superior del 'cuello'.
Una vez que estés satisfecho con la posición del cursor 3d, presione la tecla ESPACIO para que aparezca el menú. Seleccione Añadir → Icosphere. En algunas versiones de Blender es posible que tenga que elegir la subdivisión número. Basta con hacer clic en Aceptar. ¡Ahora aparecerá una pequeña esfera en la parte superior del cuerpo. Para que sea más proporcional al cuerpo, cambie el tamaño con la herramienta escalar:
* Seleccionar Mesh → Transform→Escala de la viewport menú,
* Mientras mantiene boton izq. raton, dibujar un triángulo(o una v) en la pantalla,
* O simplemente pulse el SKEY.
Si deselecciona la cabeza y luego decide que la quiere mover o cambiar el tamaño de nuevo, seleccione un vértice de la cabeza, después, haga clic en Select → Linked Vertices (o use CTRL + L). La cabeza será seleccionada, y el cuerpo se deselecciona. A continuación, transforme la cabeza como quiera. Mantenga presionado CTRL mientras mueve alrededor de si deseas ajuste(snapping) con la malla.
No olvidemos que estamos en 3D; utilizaremos del boton medio del raton para mover la vista para asegurarnos de que la cabeza realmente la colocamos en el cuello.
Nota: para hacer su carácter más realista, añadir el mono(monkey) de cabeza en lugar de la icosphere. El camino es: ESPACIO → Agregar → Monkey (no se olvide de hacerlo en Edit Mode).
Aqui pongo las fotos de como me ha quedado a mi con cabezahuevo y cabezamono.
Extruir:
Una utilidad muy frecuente en blender es Extruir o Extrudir (estrude en english).
1. tr. Tecnol. Dar forma a una masa metálica, plástica, etc., haciéndola salir por una abertura especialmente dispuesta.
Para comprenderlo, nada mejor que la practica:
Crea un nuevo proyecto con blender, y en modo edición seleciona una cara del cubo, pulsa tecla-E y veras como aparece un eje, mueve el ratón y veras como se 'extrude' la cara que has seleccionado. Has convertido un cuadrado en un cubo. Igualmente pudes convertir un circulo en un cilindro, un punto en una recta, un segmento en un rectangulo.......
Recuerda la operativa. Seleccionar algo, tecla-E mover el raton y cuando te parezca bien pulsa boton izquierdo del raton.
Si pulsas el boton derecho del raton, la cosa se queda como antes de pulsar tecla-E.
Recuerda control-Z para desacer.
Tienes tambien en el menu de malla(mesh) el comando extrude por si se te olvida la tecla que es.
Truco si mientras estas moviendo el raton extruyendo, pulsas la tecla control veras como se ajusta la extrusión a 'algo'. Por ejemplo si estas extruyendo la cara de un cubo, al pulsar la tecla control, se extruye como para duplicar el cubo original. ¡Pruebalo demonios, que no me se explicar y es muy facil!.
Pues ya me he cansado de extruir todo lo que he podido y vamos a empezar a hacer ese señor que digo en el título.
Empezando a modelar un señor.
Abrimos un proyecto nuevo y sobre el cubo que nos regala blender, seleccionamos una cara y extruimos pulsando tecla control para duplicar el cubo.
Y seguimos estruyendo hasta conseguir esta figura:
Para conseguirla tendras que aplicar muchas de las reglas que hemos aprendido como edit-mode ,tecla-A para seleccionar/Deseleccionar, shif-boton central del raton y mover el raton para girar la imagen, Quizá control-Z para hacer algun undo, boton derecho del raton para seleccionar caras......Si nunca has trabajado con 3d, conseguir esto es un gran reto y gratificante.
Añadir la cabeza:
Traduzco del original en ingles.
Nota importante: asegurarse de que está todavía en el modo Editar (en la foto) al añadir la cabeza. Si no, la cabeza y el cuerpo no será parte del mismo objeto y los cambios en el cuerpo que se requieren en la siguiente sección, no afectarán a la cabeza.
Seleccionar un punto justo encima de la parte superior del cuello utilizando el boton izquierdo del raton: el círculo rojo y blanco es el cursor. Para ajustar la posición del cursor, cambiar entre la vista superior, frontal y lateral (utilizando el NUM7, NUM1, y NUM3 respectivamente). También puede utilizar la herramienta de snap (ajuste rapido): pulse SHIFT + S para mostrar el menú snap y seleccionar Cursor → Grid(o mesh->snap->Cursor->Grid) Esto nos colocara el cursor 3d justo en medio del plano superior del 'cuello'.
Una vez que estés satisfecho con la posición del cursor 3d, presione la tecla ESPACIO para que aparezca el menú. Seleccione Añadir → Icosphere. En algunas versiones de Blender es posible que tenga que elegir la subdivisión número. Basta con hacer clic en Aceptar. ¡Ahora aparecerá una pequeña esfera en la parte superior del cuerpo. Para que sea más proporcional al cuerpo, cambie el tamaño con la herramienta escalar:
* Seleccionar Mesh → Transform→Escala de la viewport menú,
* Mientras mantiene boton izq. raton, dibujar un triángulo(o una v) en la pantalla,
* O simplemente pulse el SKEY.
Si deselecciona la cabeza y luego decide que la quiere mover o cambiar el tamaño de nuevo, seleccione un vértice de la cabeza, después, haga clic en Select → Linked Vertices (o use CTRL + L). La cabeza será seleccionada, y el cuerpo se deselecciona. A continuación, transforme la cabeza como quiera. Mantenga presionado CTRL mientras mueve alrededor de si deseas ajuste(snapping) con la malla.
No olvidemos que estamos en 3D; utilizaremos del boton medio del raton para mover la vista para asegurarnos de que la cabeza realmente la colocamos en el cuello.
Nota: para hacer su carácter más realista, añadir el mono(monkey) de cabeza en lugar de la icosphere. El camino es: ESPACIO → Agregar → Monkey (no se olvide de hacerlo en Edit Mode).
Aqui pongo las fotos de como me ha quedado a mi con cabezahuevo y cabezamono.
Suscribirse a:
Entradas (Atom)
