Esto es en realidad una cuestión más teórica, pero aquí va:igual potencia de fundido cruzado en la Unidad de audio?
Estoy desarrollando una unidad de audio con efectos y necesita un fundido de igual potencia entre señales secas y húmedas.
Pero estoy confundido acerca de la forma correcta de hacer la función de mapeo desde el fader lineal al factor de escala (ganancia) para las amplitudes de señal de las corrientes secas y húmedas.
Básicamente, lo he visto hecho con funciones cos/sin o raíces cuadradas ... aproximando esencialmente curvas logarítmicas. Pero si nuestra percepción de la amplitud es logarítmica para empezar, ¿no deberían estas curvas mapear la posición del fader a una amplitud ser exponencial?
Esto es lo que quiero decir:
Supuestos:
signal[i]
: es la muestra i-ésima en una señal.- cada muestra es un flotador que varía [-1, 1] para amplitudes entre [0,1].
- nuestro control GUI es un NSSlider que va desde [0,1], por lo que es en principio lineal.
fader
es una variable con el valor de NSSlider.
Primera Observación: Percibimos la amplitud de una forma logarítmica. Así que si tenemos un atenuador lineal y simplemente ajustan la amplitud de una señal haciendo: signal[i] * fader
lo que estamos percibiendo (audiencia, independientemente de las matemáticas) es algo a lo largo de las líneas de:
Esta es la así llamado Crappy Fader-Effect: pasamos del silencio a un aumento drástico de volumen en el segmento más a la izquierda del control deslizante y más allá del medio, el volumen no parece ser más alto.
Así que para hacer el fader "a la derecha", en su lugar, lo expresamos en una escala de dB y luego, en lo que respecta a la señal, hacemos: signal[i] * 10^(fader/20)
o, si tuviéramos que mantener unidades de fader en [0, 1], que podemos hacer: signal[i] * (.001*10^(3*fader))
de cualquier manera, nuestro nuevo mapeo de la NSSlider a la variable atenuador, que vamos a utilizar para multiplicar en nuestro código, se parece a esto ahora:
Que es lo que realmente queremos, porque como percibimos la amplitud logarítmicamente, somos esencialmente mappi ng desde lineal (rango NSSLider 0-1) a exponencial y alimentando esta salida exponencial a nuestra percepción logarítmica. Y resulta que: log(10^x)=x
por lo que terminamos percibiendo el cambio de amplitud de una manera lineal (también correcta).
Genial.
Ahora, mi idea es que un fundido cruzado de igual potencia entre dos señales (en este caso un NSSlider horizontal seco/húmedo para mezclar la entrada al AU y la salida procesada del mismo) es esencialmente el mismo que con un deslizador que actúa en ambas señales hipotéticas seco [i] y húmedo [i].
Así que si mi control deslizante varía de 0 a 100 y seco es completamente a la izquierda y húmeda está lleno-derecha), que iba a terminar con el código en la línea de:
Float32 outputSample, wetSample, drySample = <assume proper initialization>
Float32 mixLevel = .01 * GetParameter(kParameterTypeMixLevel);
Float32 wetPowerLevel = .001 * pow(10, (mixLevel*3));
Float32 dryPowerLevel = .001 * pow(10, ((-3*mixLevel)+1));
outputSample = (wetSample * wetPowerLevel) + (drySample * dryPowerLevel);
El gráfico de los cuales sería:
Y mismo que antes, porque percibimos amplitud logarítmica, esta aplicación exponencial en realidad debería hacerlo cuando oímos el fundido cruzado lineal.
Sin embargo, he visto implementaciones del crossfade usando aproximaciones para registrar curvas. Es decir, en su lugar:
Pero no estas curvas de hecho hincapié en nuestra percepción de la amplitud logarítmica?
Sugiero que pregunte esto en el sitio de la hermana DSP: http://dsp.stackexchange.com/ –
Creo que ya lo tengo pero ¡ojalá no supiera de ese sitio! – SaldaVonSchwartz
Cool. Si lo resolvió, debe responder su propia pregunta: por mi parte, me gustaría saber la respuesta que se le ocurrió. –