La idea es buena y a hay algunas cosas hechas por ahí aunque la mayoria son programas stand-alone (JSynthLib p.ej. ), pero si descartamos el sysex estan dejando fuera muchos modulos que solo manejan ese tipo de datos a no ser que hagas algún tipo de conversión. Yo de synthedit no tengo ni idea, estoy haciendo algo para mi uso personal, por ahora pero es en C++ y no funcionará como un VST debido a los problemas que tu mismo comentas del sysex.
Suerte con el asunto.
Yeah, synthmaker permite el Sysex, pero no sé si estoy preparado para seguir perdiendo horas y horas para que los dumps funcionen... creo que me limitaré a los editores.
Cuando hablas de dumps te refieres a dump completos o de presets? Que problemas tienes con ellos?
Desde mi punto de vista si un editor no lleva una gestion de bancos y presets decentes pues la verdad le quita interes al editor, ¿ para que currase un editor que luego no puede gestionar como dios manda lo que creas con el?
...
Una cosa... y si en lugar de synthedit lo haceis/mos en pure data? Tengo que mirarme si puede manejar sysex (diria que si porque creo recordar movidas con el bend) pero lo que si maneja seguro es Midi, OSC y HID. Acepta la creación de "objects" en c++ y cuenta con una comunidad grande además de ser open.
Crear "patches" de cada "cacharro" o función es relativamente sencillo y se pueden integrar unas con otras ya sea mediante "abstractions" o comunicandolas entre ellas por OSC.
Se podria hacer (si no está hecho ya) un "patch" que transforme y comunique Midi a OSC y OSC a Midi para ponerlo como input de cada "cacharro". Además el OSC es multicast y envia mensajes de 10bits (si mal no recuerdo) y open source también.
Si quereis os adjunto links de como hacer objects y de documentación que necesiteis. Yo la semana pasada hice mi primer curso de pure data y aunque me falta tela, los ejemplos se puede destripar (un nanokontrol virtual sin ir más lejos).
También hay hardware open source para gestionar/crear controladores Sysex, OSC y HID por usb.
Ya me direis.
...
...
Si y trato de despertar consciencias a la par. Te apuntas?
...
Apuntado... aunq dudo tener tantos concimientos siempre trato de aprender cosas q sirvan y si no sirven peor son interesantes, venga!! de paso
saludos
Diego
Pues yo optaría por MAX, aunque claro... las demos duran (o duraban) 30 días... más que nada porque luego con Pluggo es muy fácil exportar VST's.
Lo que no tengo claro es si en PureData hay alguna manera de exportar a VST... aunque si no me equivoco todo el trabajo hecho con Puredata se puede importar a MAX y exportarlo como VST todo del tirón. Luego se reinstala el sistema operativo y queda listo para la siguiente hornada de plugins.
Mudo, muy buena idea! Además, si no me equivoco con PD/MAX se pueden usar las salidas MIDI, y vaya, desde el propio interfaz de algunos plugins Pluggo creo recordar haber visto eso de poder enviar datos a algún puerto midi. VAya, que se puede acceder a un puerto midi desde el plugin, sin pasar por el host.
Otra cosa importante es hacer un "USMC" Universal Synthesizer Midi Control, yo lo llevo usando hace algún tiempo, pero ahora que he dejado Logic Audio y que tengo 2 BCR's de behringer me doy cuenta de que se pueden llegar a usar los 128 CC's Midi para controlar y no sólo 64 como hasta ahora. Total, crear bloques de controladores para seccioones y parámetros comunes en sintetizadores "maomeno" estándar.
Pues eso, a ver si nos coordinamos.
Así, el USMC podría servir para controlar los plugins que vía Sysex controlarían el hardware... y con una superficie de control un poco completita podríamos programar cualquier cacharril!!!
Por cierto, no por no "saber" dejéis de colaborar... la idea es que cada uno aporte lo que pueda. y siempre os podéis llevar algo de premio... no?
...
Pues tengo malas noticias para ti y otras un poco mejores.
Pluggo ya no existe, Cycling se lo cargó para reciclarlo en maxforlive (digan lo que digan).
En cuanto al tema de vst en pure data, hay cosas pero se hacen un poco redundantes. Te explico:
Maxmsp tiene el soft (privativo) por un lado, el runtime por otro y la posibilidad de crear standalones (que necesitan el runtime y las librerias externals que tenga el patch en concreto). Pure data se instala todo porque es open y au.
Las buenas noticias es que supongo que ya hay faena hecha y que si que debe controlar sysex. Incluso se puede implicar a la comunidad de pure data para llevar a cabo un proyecto asi. Precisamente, a mi modo de ver, lo que le falta a pure data precisamente es esto: implicación de músicos más clásicos o lo que vendria siendo proyectos no tan "frikis". Por ponerte un ejemplo, casi no hay secuenciadores en pd y la mayoria de "expertos" se tiran al noise...
De ahi pasan a programarse las cosas en c++ pero pierde flexibilidad, claro.
En cuanto al USMC, estoy de acuerdo y por eso creo que pd es ideal. En el caso de que se hiciera algún "object" en c++ especifico se puede mirar de usar "Flext" y hacerlo multiplataforma (compatible con maxmsp y para cualquier OS).
Sopesemos bien y decidamos. Una parte en c++ o algun entorno de programación + synthedit, pure data o lo que se os ocurra (se podria hacer a pedazos si me apuras) tampoco es una opcion nula.
no?
...
Mmm... Sí, cierto, lo sé que pluggo está fuera del mercado, pero sin embargo deben correr por algún lado los últimos ejemplos. Al fin y al cabo, pluggo no eran más que plugins VST hechos con MAX, aunque eso sí, si los modificabas, para compilarlos como VST había que usar la demo de MAX. Prohibitiva sí, pero sólo hasta cierto punto... la demo dura un mes. Da tiempo a entender cómo programar a nivel básico.
Yo, viniendo de Synthedit y SynC Modular tardé apenas una tarde en hacer todo el tutorial de pluggo y crear los 10 plugins de los 10 ejemplos. Incluso hice un compresor multibanda a partir de un ejemplo que encontré por ahí.
Synthedit, para empezar no está nada mal.
Lo del USMC va como sigue:
Contando con que hay ciertos CC's que no permiten su uso como cualquier otro CC convencional, hay que evitarlos. por ello, se empieza a asignar en el 9 (el CC11 controla el volumen de muchos aparatos) y saltamos al 12.
Hay que evitar:
CC00
CC01
CC07
CC10
CC11
CC32
CC64
CC>120
Y éstos... son peliagudos...
CC02
CC06
CC38
Bueno... ahora miro de poner un link a un googledoc...