Plataforma MIDI V2 Ya!

Wikter
#1 por Wikter el 27/01/2009
Esto es un intento de queja masiva.
A cuantos no os parece retrógrado tener sólo 128 CC's y que para usarlos haya que estar esquivando los números 0, 1, 7, 10, 32, 64, 95, 96, 97, 98, 120, 121... porque interferirán en el funcionamiento de otros aparatos o afectaran a parámetros globales?

http://www.facebook.com/group.php?gid=60189853311

He creado un grupo en Facebook, aunque a la larga lo mismo habría que hacer algunas cartas, emails masivos y cosas por el estilo directamente a organismos internacionales.
Los que tengáis Feisbuck, apuntáos, los que no, id posteando por aquí... y Quejaros, y sugerid.

- Para empezar, podrían cambiar el Din por USB (V2.0 o V3.0) directamente...
- Tener varios modos de CC (Multi/Soundedit), y que no estuviese limitado a 128, sinó por ejemplo, a 1024.
- 64 canales midi de manera estándar, en grupos de 8 (por ejemplo, para facilitar la gestión de performances).
- Mejorar el sistema de volcado de datos.
- Usar Words, y no bytes. Por no decir 32bits directamente.
- Permitir la transmisión de sonido directamente a través del cable (8 canales estándar? 16 canales?).
- Transmisión de sincronía wordclock.

Sugerid, quejáos y recordad la sombra de mLan... el pobrecito se quedó en na... dejemos la transmisión en 2 canales para que no se lie la cosa.
Subir
OFERTASVer todas
  • -21%
    Zoom H4n Pro Black
    158 €
    Ver oferta
  • -8%
    Behringer X Air XR18
    645 €
    Ver oferta
  • -40%
    ¡Precio mínimo histórico! AKAI MPK 261
    298 €
    Ver oferta
Wikter
#2 por Wikter el 27/01/2009
Vaya... he puesto Pataforma!
:D
Subir
Mudo
#3 por Mudo el 27/01/2009
wikter escribió:
Esto es un intento de queja masiva.
A cuantos no os parece retrógrado tener sólo 128 CC's y que para usarlos haya que estar esquivando los números 0, 1, 7, 10, 32, 64, 95, 96, 97, 98, 120, 121... porque interferirán en el funcionamiento de otros aparatos o afectaran a parámetros globales?


Es la maravilla del midi.

wikter escribió:
He creado un grupo en Facebook, aunque a la larga lo mismo habría que hacer algunas cartas, emails masivos y cosas por el estilo directamente a organismos internacionales.
Los que tengáis Feisbuck, apuntáos, los que no, id posteando por aquí... y Quejaros, y sugerid.


Open Sound Control es la alternativa que buscas.

wikter escribió:
- Para empezar, podrían cambiar el Din por USB (V2.0 o V3.0) directamente...


Pues hay varias contras.
La primera que dejarias sin compatibilidad a los aparatos con midi din.
Segundo el midi es un protocolo punto a punto y no necesita un ordenador para funcionar. En esto se parecen más el firewire, el protocolo de red y el OSC (que creo esta basado en el último)
Tercero; todos ellos pueden desaparecer pero la gente seguira buscando sintes analogicos con MIDI din.

wikter escribió:
- Tener varios modos de CC (Multi/Soundedit), y que no estuviese limitado a 128, sinó por ejemplo, a 1024.


El midi tb puede tener resolucion de 10 bits con los mensajes sysex (que son particulares de cada fabricante, de ahi su baja implementación). El problema es de estandarización pues cada fabricante dice la suya.

wikter escribió:
- 64 canales midi de manera estándar, en grupos de 8 (por ejemplo, para facilitar la gestión de performances).


Comprueba que el OSC no te permita esto. No conozco tanto los pormenores del sistema.

wikter escribió:
- Mejorar el sistema de volcado de datos.


Esto se debe al protocolo midi que esta basado en el serial. Es una de sus mayores limitaciones en cuanto a velocidad.

wikter escribió:
- Usar Words, y no bytes. Por no decir 32bits directamente.


Más de lo mismo. Esto requiere un lenguaje de alto nivel cuando el midi puede usarse en chips standalone. Habria que hacer quizás un traductor pero tendria cuellos de botella. (Que me corrijan los expertos si me equivoco please)

wikter escribió:
- Permitir la transmisión de sonido directamente a través del cable (8 canales estándar? 16 canales?).


Firewire again. OSC again. Ademas que audio? si el midi son comandos de control sobre un generador de sonidos. Tendria que ser un conector con i/o de datos e i/o de sonido si quisieras conectarlo a un cacharro antiguo. Entre dos mLan sin problema para hacer eso que dices. Si no fuera porque yamaha es cara y no se si su protocolo es abierto... Ya te digo que Stanton y Numark van por ahi pero con soluciones "cerradas" lo cual no deja mucho lugar a la moduralidad.

wikter escribió:
- Transmisión de sincronía wordclock.


El midi no manda sincro wordclock?

wikter escribió:
Sugerid, quejáos y recordad la sombra de mLan... el pobrecito se quedó en na... dejemos la transmisión en 2 canales para que no se lie la cosa.


Y lo que es peor la implantación del usb frente al firewire cuando el usb (que tanto te gusta al parecer) no mantiene altas las tasas de transferencia lo cual lo hace menos indicado para el streaming de audio. No es punto a punto lo cual lo hace indicado para interfaces con ordenador (pues el HID es plugandplay) pero contraindicado para montar redes de aparatos sin ordenador y para postres también tiene sus limitaciones y cada fabricante hace lo que le da la gana.

Estoy contigo, el midi 1.0 está anticuado pero aunque busquemos una solución, esta debe cumplir dos puntos basicos.

Escalabilidad futura y compatibilidad pasada.
Protocolo estandarizado y open source.

...
Subir
Wikter
#4 por Wikter el 27/01/2009
Esto es un intento de queja masiva.
Veo que eso lo has entendido...

DIN/USB:
- No se trata de anular el uso del DIN, sino estandarizar un conector.
- Seguirá existiendo lo que ya existe. Los tambores se siguen aporreando con madera.
- Usar conectores USB no implica necesitar un ORDENADOR...

Open Sound Control:
- Se pierde entre estándares. Demasiado abierto. Protocolo UDP, Wifi, Ethernet... sí, es inmensamente potente, pero ahí se para. Lo que propongo NO es CREAR un nuevo estándard que salvará al mundo... es una revisión, compatible hacia atrás, del protocolo MIDI.
Incluso se podría seguir usando el DIN dado que en la mayoría de conexiones de datos de hoy día no se suelen usar más de 4 pines... Ethernet, USB, Firewire...

Todos ellos pueden desaparecer pero la gente seguira buscando sintes analogicos con MIDI din.
Igual que pasó con los sintes con control CV pasaría con el MIDI... no seamos ciezos.

El midi tb puede tener resolucion de 10 bits con los mensajes sysex
Si mal no recuerdo llegan a haber volcados sysex de varios megas (SDMS, no?) para transferir muestras. Aún así, las "palabras" siguen siendo de 8 bits.

Comprueba que el OSC no te permita esto. No conozco tanto los pormenores del sistema.
Permite hacer maravillas de comunicación. La apuesta es muy buena, como el JACK de Linux, pero a lo bestia en terminos de comunicación. Se basa en UDP, o sea, IP's, o sea, TCP, o sea, Ethernet, o sea....

Mejorar el sistema de volcado de datos.
No se trata solo de los 33/38kbps de velocidad del MIDI, sinó en que no usa correción de errores, no usa paquetes, no usa transmisiones síncronas, sólo entiende "inicio" y "final" y si lo que hay enmedio falla, ni se entera.

Usar Words, y no bytes. Por no decir 32bits directamente.
La ventaja de usar logitud de palabras más largas es que se pueden implementar más fácilmente correción de errores y ampliar el abanico de mensajes. En MIDI del 00000000 (00h) al 01111111 (7Fh) son parámetros y del 10000000 (80h) al 1111111(FFh) son comandos o inicios de mensaje (sean de longitud variable (Sysex) o fija). Imagínate que en vez de 127 valores tuvieses 16384, eh? Eso sería usando 16bits y reservando 2bits al estado, en vez de 1. Vendría a ser como usar el MSB y el LSB en el midi actual, cierto.

wikter escribió:
- Permitir la transmisión de sonido directamente a través del cable (8 canales estándar? 16 canales?).

Lo mejor sería transmitir 2 canales digitalmente. Sin mandangas. Firewire, OSC, HDMI (ésto si que es un estandard con cojones). La mayoría nos conformaríamos con saber que nos estamos ahorrando conexiones en el estudio. Sólo haría falta un ASIC que integrase mensajes de control y reloj de muestras, y de hecho, ya existen múltiples, como bien dices, adquiribles e integrables sin comprometer protocolos propietarios.

El midi no manda sincro wordclock?
No, sólo manda MTC. Si tienes un sincronizador te puede sincronizar el hardware al Midi Time Code, pero de ahí a que las transmisiones sean "bit a bit", hay un cacho largo, largo.

Escalabilidad futura y compatibilidad pasada.
Protocolo estandarizado y open source.

Un estándard abierto??? Sí, ok, pero con especificaciones concretas y cerradas, no?. Será por eso que elegiste tu nombre.
Subir
Wikter
#5 por Wikter el 27/01/2009
...ah, mi cámara imprime fotos en la impresora por USB... :mrgreen:
Pero claro, esas cosas... sólo HP, Canon, Epson, Minolta, Nikon, Kiocera, Toshiba, Panasonic, Sony, Philips, Pentax, Acer, Benq y marcas por el estilo lo hacen... Photobridge, era, no? Otro estándar a través de USB...

:cry:

Mejor afinaré la guitarra y me olvidaré de seguir programando VSTi's Sysex para controlar mis máquinas. Demasiado... #-o
Subir
Mudo
#6 por Mudo el 28/01/2009
wikter escribió:
Esto es un intento de queja masiva.
Veo que eso lo has entendido...

Masiva consensuada o sólo lo que te parece bien o mal a ti? Tienes razón no te entiendo.

wikter escribió:
DIN/USB:
- No se trata de anular el uso del DIN, sino estandarizar un conector.
- Seguirá existiendo lo que ya existe. Los tambores se siguen aporreando con madera.
- Usar conectores USB no implica necesitar un ORDENADOR...

Si? puedes conectar un cacharro usb a otro (quitando una impresora y una camara) y que se hablen entre ellos? Si es afirmativo (para audio) por un ejemplo y una cosa menos. Si estandarizamos el conector, dime cual? Usb, Firewire, Ethernet, din...?

wikter escribió:
Open Sound Control:
- Se pierde entre estándares. Demasiado abierto. Protocolo UDP, Wifi, Ethernet... sí, es inmensamente potente, pero ahí se para. Lo que propongo NO es CREAR un nuevo estándard que salvará al mundo... es una revisión, compatible hacia atrás, del protocolo MIDI.
Incluso se podría seguir usando el DIN dado que en la mayoría de conexiones de datos de hoy día no se suelen usar más de 4 pines... Ethernet, USB, Firewire...


Es decir hablas del lenguaje? Te vuelvo a repetir que al ser serial tiene ciertas limitaciones "físicas". Si cambias esto quizás (no lo se seguro) volvamos a tener incompatibilidades. Misma clavija pero que no se entienden entre ellos...

wikter escribió:
Todos ellos pueden desaparecer pero la gente seguira buscando sintes analogicos con MIDI din.
Igual que pasó con los sintes con control CV pasaría con el MIDI... no seamos ciezos.


Tienes razón pero es así. Yo sólo tengo un sampler que por desgracia (o por suerte ves a saber) la unica manera que tengo de atacarle a los parametros en tiempo real es o por midi din o a traves del usb conectado al ordenador. Ójala pudiera conectarle algo por el usb y reaccionara. (La peña de Ucapps está intentando desarrollar algo en esta linea pero no se como lo llevan)

wikter escribió:
El midi tb puede tener resolucion de 10 bits con los mensajes sysex
Si mal no recuerdo llegan a haber volcados sysex de varios megas (SDMS, no?) para transferir muestras. Aún así, las "palabras" siguen siendo de 8 bits.


Supongo que lo que hay no te sirve, si es por reformar el lenguaje, estoy contigo. Costará que las marcas se estandaricen cuando todas creen que su implementación es la mejor o la más comoda.

wikter escribió:
Comprueba que el OSC no te permita esto. No conozco tanto los pormenores del sistema.
Permite hacer maravillas de comunicación. La apuesta es muy buena, como el JACK de Linux, pero a lo bestia en terminos de comunicación. Se basa en UDP, o sea, IP's, o sea, TCP, o sea, Ethernet, o sea....


Mmm, no es por nada pero Artnet y CITP/MSEX són el futuro en una era de la telecomunicación. ¿Cómo integrarias el Midi 2.0 en ellos? Es pura curiosidad.

wikter escribió:
Mejorar el sistema de volcado de datos.
No se trata solo de los 33/38kbps de velocidad del MIDI, sinó en que no usa correción de errores, no usa paquetes, no usa transmisiones síncronas, sólo entiende "inicio" y "final" y si lo que hay enmedio falla, ni se entera.


Es lo maravilloso del midi, ya te dije.

wikter escribió:
Usar Words, y no bytes. Por no decir 32bits directamente.
La ventaja de usar logitud de palabras más largas es que se pueden implementar más fácilmente correción de errores y ampliar el abanico de mensajes. En MIDI del 00000000 (00h) al 01111111 (7Fh) son parámetros y del 10000000 (80h) al 1111111(FFh) son comandos o inicios de mensaje (sean de longitud variable (Sysex) o fija). Imagínate que en vez de 127 valores tuvieses 16384, eh? Eso sería usando 16bits y reservando 2bits al estado, en vez de 1. Vendría a ser como usar el MSB y el LSB en el midi actual, cierto.


Con sysex se pueden hacer cosas increibles. Precisamente en la implementación de Ms. Pinky para enviar información útil fuera de maxipatch (su aplicación principal) tuvimos esta discursión sobre la resolución en el foro y al final la resolución es personalizable en función de numero de "tics" o pasos del Knob virtual. Mayor numero de tics mayor resolución final. No recuerdo la cifra pero estaba en miles (más de 1024). No se si es lo mismo pero a mi me parece ya increible hacer esto con Midi 1.0 y sysex (o pitch bend)


wikter escribió:
- Permitir la transmisión de sonido directamente a través del cable (8 canales estándar? 16 canales?).
Lo mejor sería transmitir 2 canales digitalmente. Sin mandangas. Firewire, OSC, HDMI (ésto si que es un estandard con cojones). La mayoría nos conformaríamos con saber que nos estamos ahorrando conexiones en el estudio. Sólo haría falta un ASIC que integrase mensajes de control y reloj de muestras, y de hecho, ya existen múltiples, como bien dices, adquiribles e integrables sin comprometer protocolos propietarios.


Disculpa mi ignorancia no se que es un ASIC pero tienes razon en cuanto a lo del HDMI pero porque no aprovechar el Firewire que ya lleva más tiempo implantado (a la par que se desarrolla el HDMI que no es muy abierto que digamos.)

wikter escribió:
El midi no manda sincro wordclock?
No, sólo manda MTC. Si tienes un sincronizador te puede sincronizar el hardware al Midi Time Code, pero de ahí a que las transmisiones sean "bit a bit", hay un cacho largo, largo.


No lo sabia. Alternativa?

wikter escribió:
Escalabilidad futura y compatibilidad pasada.
Protocolo estandarizado y open source.

Un estándard abierto??? Sí, ok, pero con especificaciones concretas y cerradas, no?. Será por eso que elegiste tu nombre.


Especificaciones concretas y cerradas + estandard abierto en la misma frase es un tanto complicado. El firewire (o el mLan como lo llama yamaha) ya cumple muchas de tus necesidades pero precisamente por ser cerrado se ha quedado en nada. Si el OSC acaba imponiendose dependerá en gran medida de su caracter abierto.

En cuanto a mi nombre, es evidente que es sarcasmo pero si intentabas hacer algún tipo de comentario "jocoso" para restarme valor, has cometido dos errores.

El primero pensarte que toda mi contra era algo personal, sencillamente trataba de darte mi punto de vista porque creo que te quejas un poco por vicio (aunque todo es mejorable claro).
En segundo lugar como mi intención era (y sigue siendo) llegar a algo útil no hago caso de los comentarios jocosos y sin embargo intento aportarte soluciones que te hagan más fácil la vida. No llevarte la contraria o descalificar tu punto de vista. Aunque creo que entre ser un pasota (como dices que hay) y necesitar cambiar todo el protocolo de pe a pa... hay mucho que "negociar" entre todos antes de firmar ninguna petición.

;)

...
Subir
Wikter
#7 por Wikter el 28/01/2009
Ya veo ya.
Subir
Wikter
#8 por Wikter el 28/01/2009
Y tú qué le canviarias al MIDI, es lo que preguntaba.
La convención la harán las industrias.

Responde, macho.
Y déjate de dudas sobre ataques personales.
Subir
neomad
#9 por neomad el 28/01/2009
Me parece bien la iniciativa, pero estoy con Mudo.
Pocos estandares han durado tanto en una industria como el MIDI. Yo lo veo redondo y en el caso que no te sea suficiente, tienes NRPN que sin ser standard, puedes 'suplir' otras faltas.
Suerte de todas formas
Subir
Wikter
#10 por Wikter el 29/01/2009
Brrr....

Ale pues, hilo cerrado.
Subir
Soyuz mod
#11 por Soyuz el 30/01/2009
Sobre una posible revisión del MIDI, esto era lo que nos decía Dave Smith (su creador) en octubre de 2007:

Alguien escribió:
La implementación del MIDI en instrumentos musicales se ha mantenido sin cambios durante mucho tiempo. ¿Hay alguna esperanza de que veamos una mejora equiparable a lo que fue la presentación del MIDI? ¿Qué cambios te gustaría ver?

Sería muy difícil actualizar el MIDI. Cuando lo hicimos al principio, sólo había 5 compañías involucradas, y la mayor parte del trabajo estaba hecho por dos de ellas (Sequential y Roland). Ahora, el MIDI se usa para todo, no sólo para sintetizadores. Hay tantas compañías que instalan MIDI (sintes, teclados, PCs, móviles, teclados portátiles, efectos, grabadores, etc) que sería casi imposible. ¿Cómo sería? ¿Incluiría audio? Si es así, ¿a qué velocidad, cuantas pistas? ¿Y qué pasa con el vídeo? Como puedes ver, la cosa podría irse de las manos perfectamente.


https:/www.hispasonic.com/revista/dave- ... eta-sintes
Subir
zoolansky
#12 por zoolansky el 30/01/2009
Independientemente del tema del MIDI, veo fuera de lugar y con algo de mala leche innecesaria tu respuesta al primer mensaje (muy currado por cierto) que te ha dado Mudo. Lo sepas.
Subir
dorremifasol
#13 por dorremifasol el 30/01/2009
El único problema que le encuentro al estándar MIDI actualmente es la velocidad de transmisión, todo lo demás se puede hacer sin problemas. Hay mecanismos para ello. He programado bastantes aplicaciones e interpretes MIDI y es potente de sobra para hacer lo que te de la gana.

Mezclar Audio y MIDI como estándar no tiene sentido. Son cosas diferentes y así deben seguir siendo.

Una cosa es el "lenguaje" MIDI, por llamarlo de alguna manera, y otra muy diferente es el mecanismo físico por el cual se transmite ese "lenguaje" entre los dispositivos.

Dentro de un secuenciador los mensajes MIDI se transmiten a velocidad... inmediata, no hay velocidad. Un paquete de mensajes con el mismo tick se interpretan por orden de llegada pero en el mismo punto del tiempo. No hay cables por medio ni conectores.

Lo que hay que hacer es actualizar el medio físico que transmite esos mensajes (interfaz MIDI), para que la velocidad de transmisión sea lo más rápida posible y no esté limitada a los 31.25 kbaudios actuales. De esa manera podríamos "volver" a transmitir samples a través de un cable MIDI como ya se hizo en el pasado, cuando estos ocupaban mucho menos.
Subir
muiagudo
#14 por muiagudo el 30/01/2009
Desde un profano en la materia como yo , que solo necesita del midi , sincronía , note ON/OFF , PC y poco mas .

Unas preguntas ?

Tanto se le pide ahora al midi ?

Tantos CC a la vez se necesitan para controlar un aparato ?

No os funciona lo suficientemente bien con 127 menos los globales señalados antes ?

Es que a mi y a los de mi entorno como nos sobran CC , veo poco realista esta petición del MIDi V2 .

Puede ser que desde el prisma de un programador como puedes ser tu Wikter ,
el MIDI te venga pequeño , pero para el usuario MUSICO medio e incluso avanzado ,
creo que esta bien como esta .

Ya te digo , es mi opinión y seguramente me equivoque , pero yo lo veo así .
Subir
dorremifasol
#15 por dorremifasol el 30/01/2009
En realidad los 127 CC# no son un problema, se pueden usar los controles NRPN y los MSB y LSB para direccionar miles de parámetros y asignar miles de valores (no sólo 127). Como digo, ya está todo pensado, por eso el estándar dura tanto.

Estos funcionan de manera similar a los registros de algunos chips. Con los controladores NRPN (CC# 98 y 99) o RPN (CC# 100 y 101) se "abre" un registro de 14 bits, y con los controladores LSB y MSB (CC# 6 y 96) se le asigna un valor, también de 14 bits.

Y luego tenemos SYSEX, que te permite hacer lo que te de la real gana.

Por cierto yo uso MLAN sin problemas, va de maravilla, y es más potente que cualquier otra cosa. Poder rutear el audio y el midi como me de la gana entre todos mis aparatos y que quede grabado en el fichero de proyecto no tiene precio. No está muerto ni de lejos, lo que pasa es que no es tan estándar como debería.
Subir
Hilos similares
Nuevo post

Regístrate o para poder postear en este hilo