Fecha actual 21 Sep 2017 23:03


Todos los horarios son UTC + 1 hora [ DST ]




Nuevo tema Responder al tema  [ 12 mensajes ]  Ir a página 1, 2  Siguiente
Autor Mensaje
 Asunto: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 26 Jul 2013 02:13 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
¿Cómo debe ser un Autopatch de Befaco?

Tenía preparado otro texto, pero creo que es demasiado formal, así pues, aquí va la historia relatada de los hechos.

Soy programador de autómatas industriales y un electrónico empedernido, así que un Controlador Lógico Programable (PLC) ha sido desde siempre, para mi, un motivo de estudio, no sólo como aplicación, también desde sus entrañas.

Tras las primeras conversaciones con Diego y con Jano estuvo claro que me motivaba el tema de poder capturar de alguna manera los patch y poder reproducirlos de nuevo en el modular. Ello comportaba dos problemas, la lectura de los cables de patch y la configuración con potenciometros y conmutadores fijos.

Estoy montando mis primeros módulos, tengo in mente los tres imprescindibles, VCO, VCA y VCF. Hice una primera incursión en el módulo OUT para comprender las formas técnicas y los medios Befaco montandolo tal cual y sin pensar. Ahora acabo de empezar el VCO el cual estoy analizando electrónicamente y eso me ha llevado a una serie de conclusiones que creo ya suficientes para poder empezar a postular la filosofía y el objetivo de un Autopatch.

Pero no quiero hacerlo solo...

(si marea tanto rollo, saltar a "Mis conclusiones", es más, yo tambien me lo saltaría, je je)

Tipos de estrategias para un Autopatch

- Soluciones exaustivas:
Se trata de abordar el problema buscando soluciones "a fuerza bruta", donde todos los cables de patch y todas las configuraciones sean llevadas al Autopatch y las pueda registrar y reproducir todas y a la vez. Pero, ¿es eso posible? o lo que es peor ¿es eso economicamente viable?

- Soluciones eurísticas:
Si pensamos que muchas conexiones y configuraciones no tienen sentido puede parecer, al menos útil, hacer una elección de "Patch & Conf" razonables. Aquellos patch que generan sonido de verdad, no porque el synte sea modular, son los que lo mueven en si. Se puede llegar a conclusiones de qué vale la pena autopatchear y qué no. Estaremos entonces abordando una solución eurística que nos permitirá ahorrar mucho tiempo y dinero

- Soluciones tipo "Sistema Experto":
Se llaman "Sistemas Expertos" aquellos que se basan en la EXPERIENCIA de hacer "Patch & Conf", cuyos organos de control llevan almacenados "casos" concretos, y cuyas conexiones al los organos de generación del "ruido" deben estar acordes con sus objetivos. Por experiencia, en automática sobre todo, sólo los sistemas expertos són los que alcanzan el exito por simple coherencia.


Tácticas que se pueden abordar

- Matrices mecánicas y patterns:
Una forma mecánica es reagrupar las bornas en una matriz de tantas filas y columnas como puntos a patchear, agurpadas en un único lugar, de manera que se pueda acoplar un pin por cruce o un grupo entero de pines formado un grupo pattern. El principal problema es que los cambios son lentos y requiere tantas placas pattern como configuraciones patch queramos tener. Además, el sistema no aporta nada a nivel de las configuraciones de potenciometros y conmutadores.

- Midi:
Mejorando con creces el sistema anterior, el midi abre las puertas al manejo desde un ordenador. A priori no tiene pegas, pero vista la filosofía Befaco, que aunque no esté escrita en ningún libro creo que está clara, que la complejidad para alcanzar un autopatch total "Patch & Config" lleva a una complejidad de protocolos y códigos contrária a los objetivos y aspiraciones normales en un músico.

- El synte controlado desde un PLC:
De entrada estaremos de acuerdo, un PLC industrial, y peor si es modular, haciendo de Autopatch, puede ser muchas veces más caro que un syntetizador convencional de mercado, y todo ello sin haber empezado a hacer nada. ¿Por qué?, los automatas programables industriales deben cumplir un montón de normativas: seguridad funcional, seguridad de las personas (aunque los syntes deberian pasar ITV por peligrosidad sonora, je je), alarmas funcionales internas, lenguajes de programación adaptados a las personas que los usan y progaman (sistemas operativos complejos), antideflagrancias, compatibilidad electromagnética, mantenibilidad, productividad... etc.

Si le quitamos todas esas cosas, un plc para autopatch se puede resumir en un ciclo de escan, en una caja de relés (reles "alfa") y una serie de I/O analógicas (12bits mínimo) gobernadas desde contadores que pueden a su vez ser leidos y preseteados desde su microcontrolador, todo ello almacenable en una memoria flash. Su ergonomia se puede basar en una pantalla de dos líneas alfanumérica y un teclado externo tipo USB.

"alfa"= relés rápidos de reacción y de contactos rozantes para garantizar una buena conductividad


Mis conclusiones

Porque el esfuerzo de horas y horas, dias y dias de trabajo construyendo módulos es un valor que no se puede perder, o estaríamos tirando por la borda nuestro oro, ese tiempo que nos regalamos en nuestras invenciones, del fruto de nuestras creatividad, ya sea como electónicos, como músicos o como ambos. Haciendo mias palabras de Diego De Leon <perdiendonos buscando el synte perfecto>.

Se puede construir un módulo Autopatch, pero con "humildad", de estrategia a lo "sistema experto" y táctica a lo PLC, tan opcional como cualquier otro módulo de Befaco, cuyo comportamiento sea capaz de memorizar patches y configuraciones, de repetirlas, de reproducir drones, de cambios de estilo y de puestas enteras en escena, sin que ni un solo módulo de la "family" sea llamado al destierro por incompatibilidad formal con la filosofía del Autopatch.

Es más, si alguien debe adaptarse ese es el Autopatch.

... y es por eso que no puedo hacerlo solo.

¿Que opinais?
¿Cómo debe ser un Autopatch de Befaco?


Un saludo

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 26 Jul 2013 16:30 
Avatar de Usuario

Registrado: 13 Dic 2010 01:20
Mensajes: 88
Hola Autocet,

Yo tb he divagado muchas veces con Diego y Jano no por el autopatch en concreto sinó por el hecho de introducir módulos con cerebro digital que puedan expandir funcionalidades.

Entiendo que el enfoque que le das es en base a que tienes rodaje al tema PLC pero creo mucho más asequible y que podría implicar a más creadores el usar algo como Arduino. Como bien sabrás es una placa programable en C preparada para entradas y salidas con lo que se le puede conectar controles, lectura voltajes, ... y existe una gran comunidad en internet con ejemplos, librerias, etc.

Yo mismo intenté arrancar con el tema con placas de desarrollo y tal ... pero abandoné por falta de tiempo y porque aunque sé programar me quedo encallado en la parte electrónica.

Con arduino se podrían hacer arpegiadores, secuenciadores multipista, memorizar patches, ...
Y el arduino DUE es algo con capacidad potente de proceso.
http://arduino.cc/en/Main/ArduinoBoardDue

Por ejemplo, conceptualmente el tipo de mutable instruments hace algo que se parece.
http://mutable-instruments.net
Tiene cacharros con partes analógicas como el filtro, pero combinado con cerebro digital.
Ahora lo aplica también a módulos eurorack http://mutable-instruments.net/modules/braids

Pues nada, tu que tienes conocimientos de programación y electrónica podrías sacarle el jugo a fondo a este tema del Arduino. Te animo a explorarlo. ;)


Arriba
Desconectado Perfil  
 
 Asunto: ¿Que és un ciclo de scan?
NotaPublicado: 26 Jul 2013 23:18 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
Una táctica de "modulos con cerebro" me parece a priori un encarecimiento, sin embargo, si desde la filosofía befaco se toma esta idea como una progresión tecnológica escalonada donde el visitante pueda decidir si la toma o no, justificaría ampliamente el encarecimiento. Aunque esto sería modularizar el módulo puede que valga la pena.

¿Se ve factible modularizar los módulos?

Por supuesto, Arduino es una buena baza, todavía mejor desde la popularidad que goza, de hecho conozco programadores de PLC que han adoptado este módulo, tan sólo es cuestion de si tiene un ciclo de scan y si no programarselo.

... Pero,

¿Que és un ciclo de scan?

El término scan es una de esas palabras inglesas que por no querer decir nada puede estar queriendo decir casi cualquier cosa. El sentido de scan aquí es el de una lista de intrucciones de procesador, ordenador, microcontrolador que desempeñan un trabajo.

Por ejemplo, una lista de la compra sería el concepto de un scan como lista de recolección. El problema aparece cuando llegas al supermercado y resulta que los items de la lista no están puestos por orden de estanterias conforme circulamos por el super. ¿Qué solución adoptamos?, pues la de ir repasando la lista (ciclos de scan) para ver si nos olvidamos de echar algo al carro.

Efectivamente, esta es una de las estrategias que puede usar un programador para automatizar procesos, crea su programa completo una sola vez como una lista de la compra cuyos item son las funciones a las cuales pondrá en marcha según vaya leyendo los estados de perceptores, detectores, estados de memória y según sus combinaciones las realiza o no.

Un ciclo de scan se compone de las siguintes partes:

- Lectura de entradas físicas, captadores, sensores, detectores, guardando su estado en una memoria intermedia como si fuera una foto de la realidad.

- Escrutación del programa, o lista de funciones preprogramadas, que se ejecutaran en función del estado de la foto de la realidad. ( debe hacerse así para evitar que la realidad cambie mientras se escruta un scan ) de lo contrario podria salir un disparate.

- Escritura a las salidas, pues si alguna de las funciones fué activada, habrá producido algún cambio y estos habra que reflejarlos a los puertos de manejo de nuestro dispositivo ( encender un led, apagar un relé, añadir un valor a un contador, etc.. ). Durante la escrutación los datos se almacenan en una memoria intermedia de salidas y es en este instante cuando los actualizamos a la realidad.

Terminado el proceso (lecturas-escrutación-escrituras) hay que volver a repetir el scan indefinidamente.

Puede que no siempre sea necesario que escrutemos la lista de la compra, así pues, mientras escrutamos decimos que estamos en modo RUN, y si no queremos parecer zoquetes fuera del super pondremos a nuestro ciclo de scan en modo STOP.

La técnica del ciclo de escan no sólo se aplica a autómatas programables, quien quiera que el procesador esté atento a acontecimientos para actuar "al salto de la liebre" adoptará una solución de tipo ciclo de scan tan sofisticada como necesite.

Es curioso que una hoja de cálculo como es Excel puede funcionar con este principio, de echo una hoja Excel llena de formulas reacciona una única vez cuando efectuamos un cambio en ella, es decir, actua por evento disparando un unico scan o iteración. Sin embargo Excel tiene un control que permite decir cuantas iteraciones debe realizar cuando hagamos un cambio en una casilla. Pues poniendo este parámetro a iteraciones continuas he conseguido hacer funcionar una hoja excel como un plc, un ciclo de escan a modo RUN indefinido, lo único que me faltó es comunicar por el DDE a entradas y salidas físicas del ordenata y habría conseguido un autómata manejable por formulas booleanas, pues Excel las tiene.

Se que si me meto en Arduino me pondré a buscar como montarme un ciclo de scan, o me questionaré si ya lo tiene implementado de alguna manera desde el código que lleva como sistema operativo, buscaré además las preciadas funciones booleanas AND, OR, NOT con las que se puede crear un controlador universal completo y creyendome que he alcanzado mis máximas aspiraciones descenderá mi interés por explorar más contenidos de Arduino, suelo ser así de torpe :-) Sin embargo, si se cree que dotar de inteligencia a los módulos es una via de avance del synte esto se podría volver muy interesante.

He visto gente con Arduinos por Hangar, ¿hay alguien metido ya en utilizarlo como Autopatch?

Hablando del Autopatch, como táctica me parece explorable, debería profundizar más para ver si me vale la pena, de todas formas, eso no cambia para nada mi preferencia a una idea estrategica basada en la experiencia.

¿Qué opinais?
¿Cómo debe ser un Autopatch de Befaco?


Autocet

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 27 Jul 2013 18:09 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
Voy a seguir con la idea del Autopatch aprovechando ratos muertos

A nivel de conexionado el módulo Autopatch debe tener los siguientes elementos:

- Pares de cables de banana apilables ( cantidad de pares segun criterio, por ejemplo 8 pares ), esos pares de cables salen del frontal directamente sin banana, asi me ahorro algo.

- Salidas de c.v., entregadas por un OpAmp, el cual lee del R+2R, que a su vez lee de un contador, facilmente de 16 bits, preseteable. Podria ser gobernable por un tren de pulsos procedente de un eje rotativo en el frontal, mejor tener tantos como cv tenga previstos por patch

- Controles sustitutivos auxiliares, son selectores que inevitablemente tendre que desconectar por debajo de frontales y llevarlos al Autopatch, con un conector intermedio que de no disponer del Autopatch pueda recuperar la función habitual del módulo

A nivel de mando:

- Selector de Patch, un conmutador rotativo, el cambio de estado del selector deberá disparar las cargas de los presets de cv

- Editor de Patch, únicamente sería editable aquel patch que tenga activo por el selector, de otra forma requeriría si o si de procesador, y de momento no lo quiero. Pero para evitarme planchazos mejor disponer de un pulsador de disparo de la grabación del patch en curso

La intención es almacenar los patch en el módulo sin tener que escribir nada, lo que sí deberé saber es donde puse un patch concreto y como conecte sus pares y sus cv (etiquetando por ejemplo), por eso no voy a querrer centenares de patch vacios para poder ir olvidando donde los puse, utilizaré pocos pero bien trabajados.

Un patch almacenado implicará:

- Estado de los pares
- Estado de los cv
- Estado de los auxiliares

El problema del selector de patch es si quiero que pueda ser progresivo o poder saltar de un patch a cualquier otro, por no complicarme voy a empezar con un conmutador rotativo y componer progresivamente diversos patch que encadenados puedan componer una pieza.

Hacer algo más avanzado es hacer un secuenciador, y esa no creo que sea la idea,

Posteriormente se tratará de sustituir el conmutador rotativo por un control digital governable de alguna otra forma, por ejemplo, haciendo una extensión de él hasta el teclado.

Seguro que he escrito muchas burradas... pero para eso es un foro ¿no? :roll:

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 04 Ago 2013 03:30 
Avatar de Usuario

Registrado: 06 Feb 2011 23:20
Mensajes: 55
Hilo muy guapo!

Yo le he dado bastantes vueltas al tema de como se podría hacer un sistema de memorias en un modular (desde la ignorancía). Diría que lo sencillo podría ser utilizar midi y almacenar valores en una memoria interna, o en un ordenador via usb para tener infinitos presets (como pueden hacer los minitaur, dave smith etc), con mensajes de NRPN / Midi CC y un modulo convertidor midi/volt adaptado? me suena el analog four trabaja así..
Pero claro, el tema se pone peliaguado cuando hablamos de un sistema dinámico... modulos nuevos que van saliendo cada poco...Claro quesi le quitasemos el factor modular y lo preconfigurasemos en un semimodular sería más viable.
Creo lo más cercano es el Model 225e de Buchla, PERO..guarda la posición de los potes y no las conexiones, aún así ya es un salto.
Imagen

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 04 Ago 2013 20:28 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
bananaman y diegodeasturias, gracias por vuestras respuestas,

por mi parte, sigo dando vueltas al tema,
esta sería una primera propuesta de frontal

Imagen

los círculos blancos de la derecha representarían las salidas de los cables,
los botones gris y rojo serían sets y resets del Par, donde cada par és un relé,
la selección de patch direccióna pares y c.v.
los ovalos verdes indican los estados,
los tres selectores de ajuste son de giro contínuo,
el display V/Octava indica el estado actual del c.v. y del patch seleccionados,
el patch seleccionado se indica en el display superior (actual 17),
los pulsadores azules almacenan en memoria el patch en curso borrando así el estado anterior,

Aunque sea empezar la casa por el tejado... lo demás sólo será transpiración! :roll:

¿Que opinais?
¿Cómo debe ser un Autopatch de Befaco?

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 20 Sep 2013 12:41 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
Hola de nuevo,

Necesito... por abrir la boca que no quede... un encoder rotativo, estandarizado en Befaco, similar a lo que se describe en este foro:

http://www.hispasonic.com/foros/como-fu ... diy/390757

lo más adecuado sería que fuera compatible al nuestro boton clasico, creo yo,

¿tenemos algo?
- ¿no, y hay que definirlo?
- ¿no, y para qué le queremos?, en este caso yo respondería, para el autopatch :D
- ¿si, y no sabias tú que le teníamos? :shock: :?, :)

Un saludo


Adjuntos:
images.jpeg
images.jpeg [ 6.57 KiB | Visto 8717 veces ]
200px-Eagle-parts-IncrementalEncoder.png
200px-Eagle-parts-IncrementalEncoder.png [ 26.89 KiB | Visto 8717 veces ]
200px-Eagle-parts-ENCODER_SW1_sym.png
200px-Eagle-parts-ENCODER_SW1_sym.png [ 12.29 KiB | Visto 8717 veces ]

_________________
Imagen
Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 18 Feb 2014 20:48 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
Siguiendo algunas indicaciónes vuestras he estado estudiando el midi como un medio para llegar al Autopath, mi sorpresa ha sido que he encontrado todo tipo de circuitos, que a nivel físico, me dan todas las soluciones, pero cuando empezaba a emocionarme con el nivel lógico, el código MIDI, he llegado a una especie de nuvarrón, llamado Caos After-Midi, que me ha dejado un tanto desorientado.

Por experiencia con mis instrumentos musicales, y con los ordenadores, es que el midi practicamente ha desaparecido, si antes era algo que simplemente encontraba en la más simple targeta de sonido ahora todo es USB, incluso el instrumento de mi avatar lleva ese formato y el MIDI brilla por su ausencia.

Si me planteo caminos de futuro debo tener claro por donde ando, y desde que he asociado musica electrónica con sistemas modulares y DIY en el formato de Synte Modular Eurorack no paro de dar vueltas sin aterrizar en un camino, no hace falta que sea serio ni seguro, simplemente se trata de que sea UNO.

Como quiero desbloquear el dilema ahí van algunas propuestas:

1- Construir un autopatch es una anecdotá a base de componentes MIDI, por tanto no hay prisa en este punto.

2- Si USB es el camino actual, el autopatch debería estar basado en un controlador con esta capacidad incorporada (PIC, Arduino, Android... etc), pero no quisiera hipotecar un ordenador para poder tocar.

3- Autopatch debe tener capacidad de memoria y de secuenciación, por tanto deberia incorporar algun tipo de inteligencia, eso puede ser un microcontrolador con uart inteligente, gestor de red y una conexión USB tipo A de cara al exterior.

4- A nivel interno, debido a que el Bus de alimentación sólo incorpora dos hilos (CV, Gate) de comunicación entre módulos parece razonable utilizar una capa física similar al RS485 y protocolos de nivel físico USB haciendo compatible el bus actual con la futura estructura. El hecho de incorporar los 5V lo hace una cuestión trivial.

5- USB como medio de capa física no está reñida con protocolos de control de acceso al medio (MAC), prefiriendo un token ring basado en IEEE802.5, ya que siendo una red determinista podrá existir un control preciso del tempo entre módulos del synte, y digo basados, ya que no hay que sincronizar un centenar de máquinas si no un centenar de módulos a lo sumo.

6- Autopatch debería poseer o estar conectado a una base de datos estructurada, donde la información fluiría del módulo a la base de datos y de la base de datos a los módulos. La música no sería así una consecuencia de un programa sino el resultado del flujo de datos.

7- Al parecer, existiría por lo menos un lenguaje llamado METRIX (que no tiene nada que ver con la marca de testers), y digo al parecer porque me está costando horrores conseguir información al respecto, por lo que tengo entendido está basado en el planteamiento sistemático Partitura+Instrumento+Instrumentista=Música, entendiendo tal forma como un sistema paramétrico (no programático) donde la música se configura y siendo un lenguaje se puede hacer que la música fluya por si misma. Y tambien, al parece, está más cerca de protocolos MPEG4 que del MIDI.

Me pregunto qué habrá más modular que todo esto,

Agradeceré quien me pueda poner al dia,

Saludos,

P.D. METRIX: Lenguaje de descripción musical para control de un sintetizador basado en modelos espectrales. Autor: Xavier Amatriain. Escuela Técnica Superior de Ingenieria de Telecominicaciones de Barcelona

No tengo enlaces

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 06 Mar 2015 02:22 
Avatar de Usuario

Registrado: 06 Feb 2011 23:20
Mensajes: 55
Autocet escribió:
Por experiencia con mis instrumentos musicales, y con los ordenadores, es que el midi practicamente ha desaparecido, si antes era algo que simplemente encontraba en la más simple targeta de sonido ahora todo es USB, incluso el instrumento de mi avatar lleva ese formato y el MIDI brilla por su ausencia.


Buenas Autocet!. realmente el midi está más vivo que nunca, aunque lo que cada vez se ve menos es el conector clásico 5pin en favor de usb.
Protocolos midi hay más simples y más complejos, para el tema de patches sigue usandose mucho midi cc + SysEx (desde los 80s y aguantando!), al menos mi moog minitaur va así (VIDEO se puede hasta controlar el sinte desde un plugin de abletron), y me suena que casi todo lo que hace dave smith, elektron y otras empresas que se meten a controlar digitalmente señales analógicas tiran de sysex. Se almacena en formato .syx, hay editores por ejemplo para guardar presets de sintes que casi no te permiten editar en el panel, y la gente se monta plugins visuales para trabajarlos en el ordenador con un interfaz más amigable y enviarle el sysex por puerto midi al sinte. Eso si todos estos bichos van controlados digitalmente ya de por sí, cuando mueves un pote, hay un circuito digital que le envia la señal al circuito analógico (con conversion midi-cv de por medio claro), más o menos un controlador midi conectado a un sinte (dicho de forma basta).
El problema que un modular se controla todo de forma analógica y la conversión a digital para poder almacenar parametros tendría que ser a posterior en un modulo o algo así, utilizando un convertidor de cv a midi (lo inverso al que ya tenemos jeje) y ahí ya teniendo los valores en digital, se podría desarrollar el sistema de almacenarlos internamente , trabajarlos como sysex, transferirlos por usb o puerto midi etc!
Me suena el nuevo Music easel de Bucha trabaja algo así! VIDEO, pues no deja de ser un modular parcheado internamente(semimodular) que envia todos esos parametros a una placa digital donde se convierten los cv a midi CC o similar (el modelo original de los 70s creo que lo hacía con un sistema de resistencias! jaj ), o incluso se envian por sysex a la aplicació que tienen para el ipad o viceversa. Pero ya solo viendo el tamaño de la placa impone tanto micro, da la sensación que no debe ser sencillo desarrollar algo ni parecido, aunque estos le han metido hasta wifi, display, etc
Tambien por hispasonic de cuando en cuando hay algún artículo interesante y en castellano sobre temas midi, pero ya más técnicos para meterse a desarrollar ni idea!, aunque no está de más echarles un ojo par ir viendo por donde va el mundillo ahora (NRPNs!).
http://www.hispasonic.com/tutoriales/sy ... exsy/37924
http://www.hispasonic.com/tutoriales/co ... midi/38078
http://www.hispasonic.com/reportajes/protocolo-midi/13

_________________
Imagen


Arriba
Desconectado Perfil  
 
 Asunto: Re: ¿Cómo debe ser un Autopatch de Befaco?
NotaPublicado: 06 Mar 2015 12:58 
Avatar de Usuario

Registrado: 27 May 2013 19:13
Mensajes: 116
Ubicación: Barcelona
Analizando lo que tengo y lo que puedo conseguir comercialmente no puedo plantearme el uso del teclado midi como solucion al autopatch, y mucho menos para mi sinte.

Un Autopatch de Befaco, basado en protocolos MIDI no me soluciona la conectividad a los módulos. Una parte del problema está en las señales, y si se quiere hacer vintage pues está bien, la digitalización de los CV y de los Gate no es problema desde el MIDI. Pero creo que es mejor utilizar componentes actuales sin necesitar tantos enrutadores y pasarelas.

Hay protocolos mucho más abanzados y quedarse en el MIDI es imponerse un futuro limitado. Por mi parte conozco estructuras de datos y sus bases de datos dinámicas, no solo las secuencializadas de las bases de datos tipo SQL, tambien las de tiempo real como los supervisores tipo Factory Link o Monitor 77, aplicadas en el mundo industrial. Observar esa tecnologia en la música electrónica es plantearse una Autopatch orquestral (como las orquestas de laptops).

No estamos hablando ya de programas mecanismo que mueven datos, son los propios datos los mecanismos que mueven más datos.

Saliendome de madre, es como si un fa bemol saltara a la base de datos y al zambullirse otras notas salieran salpicadas por distintos instrumentos de la orquesta.

No puedo imaginar eso con el MIDI

_________________
Imagen


Arriba
Desconectado Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 12 mensajes ]  Moderadores: Pascual, jano Ir a página 1, 2  Siguiente

Todos los horarios son UTC + 1 hora [ DST ]


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro
No puede enviar adjuntos en este Foro

Buscar:
Saltar a:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net
Traducción al español por Huan Manwë para phpbb-es.com