Lo comento por aquí por si alguien se atreve a enzarzarse con la pelea y le apetece mejorar mi esquema, o simplemente por el hecho de que otros se puedan aprovechar de mi trabajo, dado que no ha sido poco hasta ahora. También comentaré un poco la tarea de asignar TouchOSC a las funciones del mezclador, puesto que tras mi nueva tablet de 10" (30€ usada, muy lenta para internet, totalmente operativa para control)
Para empezar, mi manera de trabajar en Studio One es casi siempre usando VSTi's (sea para controlar plugins o hardware MIDI mediante Ctrlr http://www.Ctrlr.org) y pistas de audio con inserciones de plug-ins. Creo que lo estándard.
También suele ser recurrente que use instrumentos VA, y me hace especial ilusión poder controlar esos instrumentos desde la BCR.
Así que por un lado tengo ya todo un esquema de control de síntesis en la BCR (lo cambié últimamente) de manera que todos los plugins y todo el hardware lo controlo con el mismo interfaz.
A partir de ahí, que es la parte fácil, me encuentro con el problema de que no puedo asignar fácilmente macros o tener una asignación fija de los faders del mezclador con la misma comodidad con que asigno parámetros de un plug-in una vez y me olvido... Studio One no "preasigna" los faders a nuestro controlador MIDI, hay que hacerlo manualmente y hay que hacerlo en cada tema. Se pueden crear plantillas, pero existe la posibilidad de que éstos ya esten preasignados... como?
Creando una "device".
Y aquí empieza la parte oscura.
Primero hay que localizar el directorio de "devices" de Studio One.
En mi caso:
C:\Audio\Studio One\devices
Ahí sale la lista de "fabricantes".
Para un fabricante XXX tendremos una carpeta XXX
C:\Audio\Studio One\devices\XXX
En mi caso, ya existe la Behringer BCR2000, pero el controlador deja bastante que desear, sólo permite usar 32 encoders y 28 botones, cuando podemos usar 56 encoders y 60 botones... comorrr??? Bueno, la cosa es sacar provecho a los 4 bancos de control, así que hay que modificar la "device".
En el caso de TouchOSC, hay que crear una carpeta y una subcarpeta en ella.
Carpeta: Fabricante
Subcarpeta: Modelo
Por ejemplo, démosle al controlador que nos inventaremos el nombre TouchME (éste y la marca, TouchOSC, son de libre elección...)
C:\Audio\Studio One\devices\TouchOSC\TouchME
Hasta aquí, fácil... veamos, qué hay en cada carpeta? Pues entre 3 y 5 archivos, normalmente...
Todos los podremos editar en nuestro Notepad o Write... evitad Office u otras suites. También pueden ser útiles los editores de código, sobretodo para el XML.
TouchME.device
TouchME.png
TouchME.txt
TouchME.surface.xml
XXXXX.js
Alguien escribió:
TouchME.device
Contiene información respecto a qué archivos contienen la información. Un índice...
<?xml version="1.0" encoding="UTF-8"?>
<DeviceDefinition
classID="{4BD69047-D52D-4F50-8761-03424504055C}"
category="Keyboard"
vendor="TouchOSC"
name="TouchME"
surfacePlacementSize="16"
nativeCode="ControlSurfaceDevice"
surfaceFile="TouchME.surface.xml"
/>
El valor ClassID hay que inventárselo, y no tener la mala suerte de que haya otro dispositivo con el mismo número.
En Presonus no he encontrado directrices para ajustar éste valor, pero modificando los últimos 4 valores ("055C") suele funcionar.
Categoría: Creo que no tiene incidencia en el comportamiento, por si acaso, no tocar.
Vendor: fabricante
Name: Modelo
Native code: no editar.
Surfacefile: nombre del archivo donde va la programación/listado XML. Si no está escrito correctamente, no encontrará nada...
Alguien escribió:TouchME.png
Una imagen para mostrar, tomad la de base como referencia para medidas y hacedla a placer. Es un PNG con transparencia.
Alguien escribió:TouchME.txt
Una descripción o mensaje que queráis leer sobre cómo instalar, qué patron de referencia hay que tomar para controlar, poner vuestro teléfono, mote, alias... etc..
Alguien escribió:TouchME.surface.XML
El cáliz de la sabiduría. Aquí se concentran TODOS los valores, funciones y programación.
Supongo que hay funciones avanzadas, pero Presonus no ha publicado ningun manual al respecto, así que hay que buscarse las garrofas y analizar los archivos ya existentes.
Aquí va un ejemplo muy simplificado
Alguien escribió:<?xml version="1.0" encoding="UTF-8"?>
<ControlSurface>
<Controls>
<Control name="controlb0001" title="Control1" type="knob" options="receive transmit nofeedback public">
<MidiMessage status="#B0" channel="0" address="#1"/>
</Control>
<Control name="Level[0]" title="Level[0]" type="knob" options="receive transmit nofeedback public">
<MidiMessage status="#B0" channel="1" address="#0"/>
</Control>
</Controls>
<Templates>
<Template name="ChannelStrip">
</Template>
</Templates>
<Mappings>
<Global>
</Global>
<!-- MIXER MAPPING -->
<DeviceMapping device="MixerConsole">
<PlacementBank target="RemoteBank" pagesize="16">
<!-- The Channel Strips -->
<foreach variable="$channel" count="16">
<Strip>
<Value control="Level[$channel]" param="volume"/>
<Value control="Pan[$channel]" param="pan"/>
<Value control="Solo[$channel]" param="solo"/>
<Value control="Mute[$channel]" param="mute"/>
<Value control="Rec[$channel]" param="recordArmed"/>
</Strip>
</foreach>
</PlacementBank>
</DeviceMapping>
<!-- TRANSPORT MAPPING -->
<DeviceMapping device="TransportPanel">
<Toggle control="Control128" param="start"/>
<Value control="playLED" param="start"/>
</Variant>
</DeviceMapping>
</Mappings>
</ControlSurface>
Alguien escribió:XXXX.js
Desde los comandos del XML se pueden hacer llamadas a funciones más complejas integradas en archivos java auxiliares, pero ahí no he llegado, porque las ventajas son mayormente para dispositivos que integran funciones de control de displays como el Faderport o la MackieControl, para la BCR, ésto no tiene demasiado uso ya que lo hace casi todo por CC's (aunque si alguien valiente se atreve, soporta sysex...)