Questa è più che altro una domanda teorica, ma eccola:dissolvenza incrociata di potenza uguale nell'unità audio?
Sto sviluppando un'unità audio ad effetto e ha bisogno di una dissolvenza incrociata di potenza uguale tra segnali asciutti e bagnati.
Ma sono confuso sul modo corretto di eseguire la funzione di mappatura dal fader lineare al fattore di scala (guadagno) per le ampiezze del segnale di flussi asciutti e bagnati.
Fondamentalmente, l'ho visto fatto con funzioni cos/sin o radici quadrate ... sostanzialmente approssimative a curve logaritmiche. Ma se la nostra percezione dell'ampiezza è logaritmica per iniziare, queste curve che associano la posizione del fader a un'ampiezza non dovrebbero essere effettivamente esponenziali?
Questo è ciò che intendo:
Ipotesi:
signal[i]
significa il campione esimo in un segnale.- ogni campione è un float che va [-1, 1] per le ampiezze tra [0,1].
- il nostro controllo GUI è un NSSlider che va da [0,1], quindi è in linea di principio lineare.
fader
è una variabile con il valore di NSSlider.
Prima osservazione: percepiamo ampiezza in modo logaritmico. Quindi, se abbiamo un fader lineare e semplicemente aggiustare l'ampiezza di un segnale facendo: signal[i] * fader
quello che stiamo percependo (udito, indipendentemente dalla matematica) è qualcosa sulla falsariga di:
Questa è la cd chiamato crappy fader-effect: passiamo dal silenzio ad un drastico aumento di volume attraverso il segmento più a sinistra nel cursore e oltre il centro il volume non sembra diventare più forte.
Quindi per fare il fader "a destra", noi invece lo esprimiamo in una scala dB e poi, per quanto riguarda il segnale, facciamo: signal[i] * 10^(fader/20)
oppure, se dovessimo mantenere o dissolvere unità in [0, 1], che possiamo fare: signal[i] * (.001*10^(3*fader))
in entrambi i casi, la nostra nuova mappatura della NSSlider alla variabile fader che useremo per moltiplicare nel nostro codice, simile a questo ora:
Che è ciò che realmente vogliamo, perché poiché percepiamo l'ampiezza logaritmicamente, siamo essenzialmente mappi ng da lineare (intervallo NSSLider 0-1) a esponenziale e alimentando questo output esponenziale alla nostra percezione logaritmica. E si scopre che: log(10^x)=x
quindi finiamo per percepire il cambiamento di ampiezza in modo lineare (ovvero corretto).
Grande.
Ora, il mio pensiero è che un crossfade di uguale potenza tra due segnali (in questo caso un NSSlider orizzontale secco/umido per combinare l'input con l'UA e l'output elaborato da esso) è essenzialmente lo stesso solo con un cursore che agisce su entrambi i segnali ipotetici secco [i] e bagnato [i].
Quindi, se i miei campi di scorrimento da 0 a 100 e secco è full-sinistra e umido è pieno-destra), sarei andato a finire con il codice lungo le linee di:
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);
Il grafico di cui sarebbe:
E come prima, perché percepiamo ampiezza logaritmica, questa mappatura esponenziale dovrebbe effettivamente fare, dove si sente il crossfade come lineare.
Tuttavia, ho visto le implementazioni del crossfade utilizzando le approssimazioni per registrare le curve. Significato, invece:
Ma non sarebbero queste curve in realtà sottolineare la nostra percezione di ampiezza logaritmica?
Suggerirei di chiedere questo sul sito della sorella DSP: http://dsp.stackexchange.com/ –
Penso di averlo capito ora ma hey non sapevo di quel sito! – SaldaVonSchwartz
Fresco. Se hai capito, dovresti rispondere alla tua stessa domanda - io per primo vorrei sapere la risposta che hai trovato. –