Diseñar un sinte basado en EMU8030...

#121 por PaChus el 02/02/2015
klausmaria escribió:
Igual no es tan complicado con el nuevo Raspberry Pi Model B+


Ahora mismo estoy yo tratando de hacerlo. Estoy en ratos libres y tal, pero por ahora va bien.

Estoy tirando de Raspbian (el que viene de primeras) sin interfaz gráfica, usando fluidsynth (que es el más ligero) y alsaconnect, y limitando la polifonía bastante (alrededor de 24) no da ningún problema. A partir de ahí depende del instrumento y las capas que tenga. Tengo un preset orquestal muuy chulo que se cala en cuanto pasas de 24, y sin embargo, con el piano (una versión que reduje yo mismo a partir del salamander) tira con mas de 32 de polifonía. La latencia, por ahora, no ha sido ningún problema.

Quiero ver los límites que tiene esto y hasta donde se puede llegar, pero por ahora todo apunta a que el cuello de botella es el procesador (no la RAM, como yo pensaba de primeras) y por tanto, se pueden optimizar las diferentes soundfonts para trabajar sobre RPi, haciendo que haya que tocar lo menos posible la CPU.

Por lo que yo tengo entendido, la mejor forma de hacer esto es utilizar el menor número posible de efectos y de capas, y por la limitación de polifonía no hacer muchas mezclas (poner mezclados todos los samples). Por ejemplo, si quieres un piano + strings, samplear piano+strings y utilizar eso directamente como samples en la soundfont, en lugar de poner una capa de piano y otra de strings.

Bajar el rate no sirve de nada, he bajado de 48000 a 24000 e incluso a 16000 y la diferencia en la polifonía máxima (cuando empieza a rajar como una perra) es mínima. Lo mismo ocurre con la profundidad de bits.

También estoy mirando a ver si fuese posible ejecutar un módulo de fluidsynth, por ejemplo el que se encarga de la interpolación en punto flotante, en la GPU, pero por ahora no he avanzado nada en eso. Si se pudiese, estaríamos quitando una carga de procesador grande que podríamos emplear en aumentar la polifonía o incluso manejar efectos en tiempo real, descentralizando este tipo de operaciones repetitivas a las que la GPU, que tiene muchas unidades de punto flotante, puede procesar más rápidamente.

En fin, os iré informando conforme avance.

Edit: estoy utilizando alguna soundfont propia y también el GeneralUser, que me parece que tienen una buena relación calidad/peso.
Subir
4
#122 por KlausMaria el 02/02/2015
PaChus escribió:
Quiero ver los límites que tiene esto y hasta donde se puede llegar, pero por ahora todo apunta a que el cuello de botella es el procesador (no la RAM, como yo pensaba de primeras) y por tanto, se pueden optimizar las diferentes soundfonts para trabajar sobre RPi, haciendo que haya que tocar lo menos posible la CPU.


Con el nuevo Raspberry Pi B+ supongo que tendrías más polifonía, ¿no?. Enhorabuena por el proyecto :cuernos:

"Fiat iustitia et pirias mundus". (Haya justicia aunque arda el mundo)
"Ad maiora nati sumas". (Estamos llamados a obras mayores).
"Après moi, le déluge". (Después de mi, el caos).

Subir
#123 por vagar el 02/02/2015
PaChus escribió:
usando fluidsynth (que es el más ligero)


Yo hice un benchmark hace años y LinuxSampler era muchísimo más ligero.

PaChus escribió:

Bajar el rate no sirve de nada, he bajado de 48000 a 24000 e incluso a 16000 y la diferencia en la polifonía máxima (cuando empieza a rajar como una perra) es mínima.


Supongo que es porque lo que condiciona el número de puntos usados en el algoritmo de interpolación es la frecuencia de muestreo de la muestra en el soundfont, la frecuencia de reproducción sólo se usará en la fase de decimado que es relativamente ligera. Prueba a generar un soundfont con muestras a 24000.

PaChus escribió:
Lo mismo ocurre con la profundidad de bits.


Esto también es normal, me imagino que toda la aritmética se hará en 32 bits independientemente de las muestras.

PaChus escribió:

Por lo que yo tengo entendido, la mejor forma de hacer esto es utilizar el menor número posible de efectos y de capas,


Efectos sí.

Capas, depende de a lo que te refieras con ello, supongo que a disparar varias muestras con un solo evento midi. Creo recordar que esa posibilidad no existe en soundfonts, pero hace tiempo que no reviso la especificación.

Las capas de velocidad no, porque son una simple conmutación de muestra.

Otra buena forma de reducir el uso de CPU sería rellenar las regiones de desafinación para no tener que interpolar (si no se usa pitch bend). Por ejemplo, si una muestra de la nota C4 se usa típicamente también para B3 y C#4, generar esas dos muestras offline e incorporarlas al soundfont para no tener que recalcularlas. Evidentemente se triplicaría el uso de RAM y sólo funcionaría si el motor está trabajando a la misma frecuencia a la que están muestreadas las notas.

PaChus escribió:
si fuese posible ejecutar un módulo de fluidsynth, por ejemplo el que se encarga de la interpolación en punto flotante, en la GPU


Infórmate bien antes de invertir tiempo en eso, según tengo entendido el protocolo de comunicación con la GPU no está pensado para trabajar a baja latencia.

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
1
#124 por PaChus el 02/02/2015
Dios, muchas gracias por las respuestas tan rápidas!

klausmaria escribió:
Con el nuevo Raspberry Pi B+ supongo que tendrías más polifonía, ¿no?. Enhorabuena por el proyecto


Es la que tengo ahora mismo (nuevecita de esta navidad). Pero justo hoy acaba de salir la Raspberry 2, aumentando procesador, subiendo hasta 1GB de RAM... y al mismo precio. Me podía haber esperado un mes xD

lgarrido escribió:
Yo hice un benchmark hace años y LinuxSampler era muchísimo más ligero.

Linuxsampler más ligero? Tendré que probar entonces.. Tiré de fluidsynth por recomendación de un compañero, la verdad, y al ser dedicado a Sounfonts pensé que era lógica. Haré la prueba y os comento.

lgarrido escribió:
Capas, depende de a lo que te refieras con ello, supongo que a disparar varias muestras con un solo evento midi. Creo recordar que esa posibilidad no existe en soundfonts, pero hace tiempo que no reviso la especificación.

En la última especificación, o al menos por lo que yo puedo hacer, el concepto de "capas" es muy flexible. Puedes poner varias muestras en un rango determinado de velocidades y de notas, y algunos rangos superpuestos. Por ejemplo, una muestra de piano en FF para notas 60-70 y velocidades 80-100, a la vez que una de strings en notas 60-70 y velocidades 90-120 y un trombón en notas 60-80 y velocidades 110-127. En este caso si tocas la nota 65 con velocidad 95 (no me meto en más parámetros) dispara la muestra de piano y la de strings, y si tocas la misma nota con velocidad 115, dispararía solo los strings y trombón, pero no el piano... A mi ésto me ha dado la vida, al crear una soundfont un poco mash-up de otras y algunos sonidos propios: http://chusocol.sourceforge.net, el preset Full Orchestra está puesto de esta manera. Por supuesto, con la RPi va regular, y la polifonía total sin rajar baja a 8 o así..

En fin, mil gracias!
Subir
#125 por PaChus el 12/02/2015
Ya tengo la RPi2!! He hecho un par de pruebas preliminares y se nota una barbaridad. La he overclockeado también para que no se pare mucho con el tema de procesador, y por ahora solo me ha dado problemas de polifonía con un piano de varias capas con el pedal pulsado y dandole al teclado con el brazo entero y muy rápido, así qeu parece que la cosa va bien.

Cuando tenga tiempo haré más pruebas de performance, con números de verdad, pero la cosa parece muy prometedora.
Subir
2
#126 por vagar el 18/04/2015
Up con alguna otra experiencia con la RPi2

http://linux.autostatic.com/2015/04/18/raspberry-pi-revisited

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#127 por vagar el 09/06/2015
Otro proyecto relacionado:

http://www.samplerbox.org/

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
1
#128 por Los Hilos de la Marioneta el 10/06/2015
mola.-

Sin derechos de autor para tener una firma graciosa o cool.

Subir
#129 por KlausMaria el 10/06/2015
lgarrido escribió:
http://www.samplerbox.org/


Es casi casi lo que proponía desde el principio. El coste de "la placa base" es insignificante y no creo que fuese complicado integrarlo todo en una carcasa sencilla con un teclado controlador (uno comercial). Y aun haciéndolo artesanalmente hablaríamos de 300€ de coste máximo incluso con bonitos acabados retro en madera y metal ;-)

Personalmente creo que sería más sencillo utilizar un formato como SFZ o SF2 que son muy populares... pero por lo simple de la carga de muestras (incluso con varias capas y demás) creo que sería una chorrada crear un "editor" para PC/MAC para prepararlas, o incluso se podría hacer en un servicio web y de paso compartir las muestras y crear una comunidad alrededor del sinte.

El que sea multitímbrico o no casi da igual, pueden crearse sets de samples con 2, 3 o 20 instrumentos distintos distribuidos por el teclado. Molaría eso si disponer de controles mínimos, ADSR, filtro y FX (reverb y/o chorus) ya sería la pera.

"Fiat iustitia et pirias mundus". (Haya justicia aunque arda el mundo)
"Ad maiora nati sumas". (Estamos llamados a obras mayores).
"Après moi, le déluge". (Después de mi, el caos).

Subir
#130 por vagar el 10/06/2015
Igual me equivoco, pero así a ojímetro a mí me cuesta horrores creer que, por muy sencillo que sea, un sampler programado en python con entrada y salida por USB ejecutándose sobre Linux en un ARMv7 a 900 MHz produzca esa polifonía a esa latencia sin petardear como una Vespa de los años 40.

klausmaria escribió:
filtro y FX (reverb y/o chorus)


Por pedir... si te conformas con que sea monofónico a lo mejor cuela.

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#131 por vagar el 10/06/2015
OK, le he echado un vistazo rápido al código fuente y ahora se entiende lo de la polifonía: a no ser que se me haya escapado algo, no tiene interpolación. Eso significa que nada de usar pitch bend, y que tienes que proporcionarle un sample para todas y cada una de las notas que quieras usar. Es básicamente un media player controlado por midi.

Edito: confirmado, y yo no pondría muchas esperanzas en el futuro de este proyecto. El tipo no parece que tenga mucha idea del asunto. Si es que la realidad es tozuda.

http://www.samplerbox.org/forum/7

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#132 por KlausMaria el 10/06/2015
lgarrido escribió:
OK, le he echado un vistazo rápido al código fuente y ahora se entiende lo de la polifonía: a no ser que se me haya escapado algo, no tiene interpolación.


De los instrumentos que ofrece para descarga el Lately Bass tiene 49 muestras, así que supongo que sí, que es una por tecla. Pero el instrumento 0 Saw tiene sólo 3 muestras... a menos que ese sólo suene en 3 teclas (la 60, 48 y 36) me da que sí interpola.

El Grand parece tener como 4 muestras por octava con 16 capas de velocidad (!). Yo diría que sí hay cambio de pitch.

"Fiat iustitia et pirias mundus". (Haya justicia aunque arda el mundo)
"Ad maiora nati sumas". (Estamos llamados a obras mayores).
"Après moi, le déluge". (Después de mi, el caos).

Subir
#133 por KlausMaria el 10/06/2015
lgarrido escribió:
Edito: confirmado, y yo no pondría muchas esperanzas en el futuro de este proyecto. El tipo no parece que tenga mucha idea del asunto. Si es que la realidad es tozuda.

http://www.samplerbox.org/forum/7


Dice que no tiene implementado el Pitch Bend, pero sí el cambio de pitch para "missing notes". O al menos es lo que se entiende en el foro.

"Fiat iustitia et pirias mundus". (Haya justicia aunque arda el mundo)
"Ad maiora nati sumas". (Estamos llamados a obras mayores).
"Après moi, le déluge". (Después de mi, el caos).

Subir
#134 por vagar el 10/06/2015
OK, he mirado más a fondo y ya he visto donde está. Estaba buscando llamadas a alguna librería como SRC o Rubberband, pero efectivamente hace interpolación lineal a mano, siempre hacia arriba.

Líneas 56, 57, 72 y 73:

https://github.com/josephernest/SamplerBox/blob/342349db927713d28e0ebd474045734e3eb9fcb6/samplerbox_audio.pyx

Por la calidad del código sigo sin verle mucho futuro ni creerme la polifonía. A ver si hay suerte y me equivoco.

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#135 por KlausMaria el 10/06/2015
lgarrido escribió:
Por la calidad del código sigo sin verle mucho futuro ni creerme la polifonía. A ver si hay suerte y me equivoco.


Por el coste que tiene estoy por hacerme con el Raspberry Pi y probar. Tampoco es que se pierda mucho y siempre puedo reaprovecharlo para otras cosas. Es difícil de creer, pero mira, ahí lo tienes tocando piano con sustain. Ya lo decía Schumpeter, la innovación no es tanto un logro de la inteligencia como de la voluntad ;-)



Supongo que si todo el problema es la capacidad de proceso ya no tardará gran cosa en aparecer un dispositivo que pueda lidiar con ello holgadamente. Es lo bonito de la ley de Moore ;-)

"Fiat iustitia et pirias mundus". (Haya justicia aunque arda el mundo)
"Ad maiora nati sumas". (Estamos llamados a obras mayores).
"Après moi, le déluge". (Después de mi, el caos).

Subir
Respuesta rápida

Regístrate o para poder postear en este hilo