¿Por qué los controladores para DJs ahora sólo funcionan con un único software?

Mucha gente manifiesta su descontento en redes sociales y foros con la actual situación que se da en equipamiento para DJs: de manera ya casi habitual la mayoría de controladores están diseñados para funcionar con un único software. ¿Por qué sucede esto? Te explico los motivos, que no son pocos.

Una conocida marca lanza un excelente controlador, con funciones nunca antes vistas y estás deseando comprarlo para incorporarlo a tu setup, pero… resulta que está diseñado para usarse con un software que no es el que habitualmente usas. Te planteas mapear el controlador para usarlo con tu software favorito a pesar de todo pero… algunas de las funciones más atractivas del controlador sólo son accesibles con el software para el que han sido diseñados. Te indignas y maldices a las empresa que ha diseñado el controlador. La primera idea que te viene a la cabeza es “me quieren obligar a cambiar de software” y maldices toda la industria mentalmente. Pero, ¿sabes realmente todos los motivos por los que esto sucede en la actualidad más frecuentemente?

Lo evidente

El primer factor es evidente y seguramente no te has equivocado al pensarlo, una empresa como por ejemplo Native Instruments que comercializa tanto el software para pinchar como el hardware, es la primera interesada en que la gente compre un controlador de su marca y se quede usándolo en su software. Si quien ha comprado un controlador de Native Instruments queda contento con cómo funciona con Traktor, es probable que cuando Native Instruments lance un nuevo controlador actualizado todos los anteriores clientes se interesarán por el nuevo producto. Así pues Native Instruments hará todo lo posible –y doy por hecho que será dentro de lo ético y legal– por mantener a los clientes dentro de su ecosistema de hardware y software.
Por otra parte y siguiendo el ejemplo de Native Instruments, aunque su software sea “abierto” y permita mapear muy detalladamente empleando el protocolo MIDI los controladores de otras marcas, hace tiempo que dejaron de colaborar con otras empresas que comercializan hardware y ya no ofrecen aquella antigua certificación de “Traktor Ready”, y tampoco incluyen en la instalación del software más mapeos de controladores de otras empresas, tan sólo mantienen los de aquellos controladores que hace años obtuvieron esa certificación. Concretamente empezaron a hacer esto no mucho después de empezar a comercializar su propio hardware. Nuevamente esta práctica entra dentro de lo lógico, ya que no tiene ningún sentido vender tu propio hardware y al mismo tiempo seguir diciendo que el hardware de la competencia funciona igual de bien que el tuyo.

En una línea similar trabaja Pioneer, incluso de forma un poco más evidente. Pioneer vende actualmente su propio hardware y software, pero en el software son relativamente “novatos”, así que han optado por una práctica curiosa para que quienes quieran usar su software deban necesariamente usar su hardware: ciertas funciones básicas del programa sólo funcionan con su hardware. El principal ejemplo de esto está en que los únicos jogwheels que pueden funcionar con su software son los de sus controladores o reproductores –aunque yo ya os enseñé como saltaros esta limitación–.

Lo no tan evidente

Lo que he descrito un poco más arriba es la política de empresas que desarrollan software y hardware, pero, ¿qué ocurre cuando tu empresa sólo se dedica al desarrollo de una de las dos cosas?
En el caso del software existen dos posibilidades, una es que la empresa decida que su software sea compatible con la mayor cantidad de hardware posible, y si toman esta opción es probable que sean ellos directamente los que trabajen por ir añadiendo compatibilidad al software con todo el hardware nuevo que llegue al mercado; es el caso de Virtual DJ y Cross. La otra posibilidad es que la empresa decida que su software sea cerrado y sólo funcione con quienes ellos decidan, ¿y cómo se decide esto? El mejor factor decisivo siempre es el dinero, así que si una empresa quiere que su controlador sea compatible con un software cerrado, tendrá que pagar a la empresa de software; es el caso de Serato, cuya licencia viene incluida con muchos controladores, pero que recibe una cantidad de dinero por cada uno de esos controladores que se vende.

Hay una excepción a esto que se da con Pioneer y sus reproductores, y es que dado su papel dominante en ese tipo de productos, es la única compañía que fabrica hardware que puede sentarse a negociar si los programas de otras empresas son o no compatibles con su hardware. Esto puede parecer absurdo porque a fin de cuentas ya que estos controladores envían mensajes MIDI debería ser posible mapear sus reproductores para usarlos como controlador en cualquier software, pero no todas las funciones del hardware son accesibles por MIDI, y para ello es necesario el uso del protocolo HID. Este protocolo no es exclusivo de aparatos musicales, por ejemplo un ratón es un dispositivo que usa también HID. Si fuéramos desarrolladores de sofrware y quisiéramos acceder a las pantallas táctiles a todo color de los reproductores Pioneer y a algunas funciones de iluminación del aparato se debe usar HID, pero para que el reproductor escuche nuestros comandos HID previamente Pioneer nos debe haber autorizado para ello. Y para esa autorización ya te pedirán lo que quieran.

Lo técnico

Hasta ahora hemos visto factores económicos más o menos evidentes, pero también los hay técnicos. Hace unos cuantos años los controladores eran bastante más básicos, disponían de controles similares a los de una mesa de mezcla junto con unos jogwheels y controles de tempo y transporte; todo era fácilmente integrable mediante mensajes MIDI corrientes. Sin embargo la cosa se empezó a complicar cuando algunos controladores empezaron a implementar MIDI de alta resolución para dar mayor precisión a jogwheels y controles de tempo, lo cual implicó que aquellos programas que quisieran sacar provecho de estos controladores tuvieran que actualizarse para soportar mensajes de este tipo. La cosa tardó un poco normalizarse pero finalmente todo el software soportaba este tipo de mensajes.

El auténtico problema llegó cuando se empezaron a implementar funciones más “exóticas” en los controladores, como por ejemplo pads con iluminación multicolor o pequeñas pantallas con caracteres alfanuméricos para mostrar información básica como tamaños de loops o la activación de alguna otra función. Aunque estas funciones pueden ser controladas por MIDI, no todos los fabricantes empleaban el mismo tipo de mensajes para manejar estas funciones, y en ocasiones ni daban detalles técnicos sobre los mensajes necesarios. Algunos fabricantes como Native Instruments optaron por empezar a emplear protocolos propios como el NHL para manejar de manera más precisa y rápida sus propios controladores, y dejando el MIDI como protocolo “auxiliar” por si el usuario decide hacer un mapeo alternativo (de hecho desde hace tiempo los controladores de N.I. realmente no envían y reciben MIDI de forma nativa, lo hacen a través de su driver); Serato por su parte realizó un protocolo propio para Serato ITCH que combinaba MIDI de alta resolución con funciones propias.
La complicación final llegó hace unos pocos años cuando los fabricantes de controladores comenzaron a integrar funciones avanzadas y exclusivas como pantallas a todo color con información gráfica de todo tipo o pequeños secuenciadores dentro del software que se manejaban desde el controlador. Estas funciones definitivamente no podían depender de mesajes MIDI estándar, y comenzó a hacer necesario para muchos fabricantes utilizar dentro del MIDI los comandos sysex, el MIDI de alta resolución y sistemas propietarios de comunicación con sus pantallas. La programación de estos dispositivos se complica y mucho, y lejos de ponerse de acuerdo en crear un sistema estandarizado, los diversos fabricantes se han centrado de manera independiente en desarrollar sus propios métodos para que el software se comunique con sus dispositivos.
Al llegar a tal punto de sofisticación, las inversiones que deben hacer los departamentos de desarrollo comienzan a ser elevadas. Por un lado los fabricantes de hardware tienen que desarrollar su método de comunicación, pero a la vez deben ponerse de acuerdo con las empresas de software para que el software esté preparado para entenderse con el hardware. Si ya es un desafío tecnológico que dos empresas distintas y que fabrican productos diferentes se pongan de acuerdo para que el software de una funcione con el hardware de la otra, imaginad por un momento la extrema complejidad y los costes para que una empresa de hardware se ponga de acuerdo con las tres o cuatro principales de software y que su hardware con funciones especiales funcione exactamente igual con todos los programas. Es prácticamente imposible sin asumir unos costes de desarrollo por las nubes, costes que para empezar las empresas de software son las que lo tienen más difícil para rentabilizar: ellos siempre tienen el riesgo de la piratería.

Sí, la piratería también influye aquí

¿No lo habías pensado? La piratería es otro de los factores influyentes en todo esto, y mucho más de lo que la gente se piensa. Por ejemplo, ¿de qué le sirve a Native Instruments que Traktor sea compatible con el último reproductor con pantalla táctil de Pioneer si luego les piratean el programa? De nada. De ahí que suceda lo que ocurre actualmente, y es que a toda costa se está tratando de ligar el software al hardware como un conjunto que funciona como un único producto. De esta forma si quieres usar un Numark NS6II y quieres que las pantallas de los jogs muestren esa información tan chula, usarás Serato que es la empresa de software con la que se alió Numark para hacer una comunicación apropiada entre software y hardware. Si quieres que los jogwheels de tu reproductor Pioneer muestren a la perfección como la iluminación central gira en consonancia con lo que ocurre en el software cuando lo usas como controlador, usarás Rekordbox porque es el software que ellos mismos hacen y por tanto con el que mejor funciona, y si quieres que tu controlador Kontrol S8 muestre en sus pantallitas las formas de onda de tu canción, usarás Traktor porque es el único software que tiene comunicación con ese aparato. Y al menos todos así tienen justificada su inversión en desarrollo, vendiendo conjuntos hardware/software que funcionan como un único elemento.

En realidad las cosas son mejor así

Tras muchos años de pelearme con MIDI, MIDI de alta resolución, protocolos propietarios, hacer mapeos de mil tipos hasta para controladores que no son para pinchar, desbloquear funciones en programas engañándolos, etc. os puedo asegurar que la mejor forma de usar un controlador es con el software para el que oficialmente está diseñado. Es una tremenda pérdida de tiempo tratar de coger un controlador de tipo integral y remapearlo al 100% para funcionar en otro software (otra cosa es hacerlo con un controlador auxiliar), nunca va a funcionar exactamente igual de bien ni va a tener el 100% de las funciones disponibles, o al menos disponibles de la forma que diseñó el fabricante, que probablemente sería la mejor forma de usarlas. Lo mejor actualmente para un usuario que simplemente quiere pinchar, es comprar su conjunto hardware/software y usarlo tal cual se lo ha preparado el fabricante o los fabricantes que se han puesto de acuerdo para hacerlo.

Y para las empresas desarrolladoras también es mejor. No sólo es más económico invertir en hacer bien las cosas en un único software, también concentrando sus esfuerzos en un único software logran mejores resultados de integración, además de que no tienen que estar ofreciendo soporte a todo tipo de gente que les pregunta “esto no me va con este otro programa”. Muchas empresas ya lo dicen bien claro: Te damos soporte si lo usas con el software que te entregamos, de las marcianadas no nos hacemos responsables. Y hacen bien.
Y ojo, si todo esto no te parece bien tienes otra opción: no compres. A fin de cuentas no es obligatorio.

Anuncio publicitario