Newsgroup: it.comp.musica
Titolo: Clickìi

Non so se sto per dirvi una cosa ovvia, comunque la dico: sempre
meglio ovvia che sbagliata >8)
Tutta la gente che usa giochicchiare un pò con le onde sonore in loop
prima o poi si trova ad avere a che fare con quegli odiosissimi
"clickìi" che talvolta i loop generano.
Talvolta sono facili da eliminare, talvolta un pò meno, altre volte
non ne volgiono proprio sapere di andarsene.
*** Da qui in poi credo che mi capirà meglio chi usa i tracker ***
Ecco, in questo ultimo caso,  avete mai pensato che la cosa potrebbe
essere dovuta a un'errata definizione del panning envelope?
Ad esempio, un envelope con un loop che, nel momento in cui l'envelope
sta per ricominciare, genera un clickìo, è stato probabilmente settato
con un inizio e fine di pan differenti fra loro, e la cosa ovviamente
genera clickìo!
Io dico "ovviamente" ora che me ne sono accorto... >8)
Un ottimo modo per rendersi conto di se il motivo è effettivamente
questo (se si usa un tracker) è vedere se la frequenza del "click" (o
"zonk" o "stak" o chi per esso >8) ) dipende o meno dalla nota a cui
si sta emettendo un suono: se la frequenza del click varia, allora
evidentemente deve dipendere dall'onda, altrimenti è molto
probabilmente un errore di panning envelope (la cui lunghezza appunto
varia coerentemente con il variare della nota suonata).
Naturalmente questo può accadere anche se si fanno salti bruschi nel
volume envelope, specialmente con una scheda sonora non proprio
"elitaria", ma l'effetto è di norma ridotto rispetto all'altro, e poi
questo noi già lo sapevamo, vero? >;)
Spero di essere stato utile, o quantomeno non dannoso.
Cià,
          It-Alien
napo...@inopera.it
http://www.inopera.it/~napodano

Spero di essere stato utile, o quantomeno non dannoso.
Anch'io anche se ho fatto tutta sta pappardella di teoria dell'envelope e delle
ipotetiche implementazioni di ipotetici programmatori che ipoteticamente
saprebbero programmare un'ipotetico tracker decente (come suono intendo)... :)
Ciao
   NeuRoTiX
___/__/_/ -+=NTXC3P=+- -+=/Program'r & Musician/=+-
___/__/_/      ---==oO NeuRoTiX / DMS Oo==---
___/__/_/ E-Mail : 
neur...@techno.org
___/__/_/ URL    : 
http://neurotix.303dim.com/
___/__/_/ DMS URL: 
http://www.dms.is.nl/
___/__/_/___________________________________________________________________

Ciao 
napo...@inopera.it
 (It-ALien (Fabio Napodano)),
 >Non so se sto per dirvi una cosa ovvia, comunque la dico: sempre
 >Ecco, in questo ultimo caso,  avete mai pensato che la cosa potrebbe
 >essere dovuta a un'errata definizione del panning envelope?
Solo con gli XM.
IT rulez.
  C++u,
      DeathStar::Froyd_the_Dreud
 
http://www.nigma.it/deathstar
 
http://www.logicom.it/deathstar
    -------------------------------
    fidonet:           2:335/244.15
    GSN:                 864:39/1.3
    iDN:                78:3901/1.4
    -------------------------------

Ciao 
neur...@techno.org
 (NeuRoTiX),
 >??? ?) ... non dovrebbe essere il contrario? (cioe' il
PanningEnvelope loop
 >sempre uguale indipendentemente dalla nota)
In IT il tempo di tutti gli envelope si misura in ticks, in FT dipende
dalle versioni... ?
 >1 - Non c'e' stato uno dei programmatori dei tracker oggi
disponibili che gli
 >sia venuto in mente di applicare una VolumeRamp (una specie di
interpolazione
 >fra i volumi - possibile via HW su GUS ma da nessuno considerata)
durante
 >l'esecuzione degli envelope. Intendo dire praticamente
l'interpolazione
 >dell'envelope.
E Jeffrey Lim?
 >2 - Nessuno ha mai pensato di fare la stessa cosa sul
PanningEnvelope (forse
 >perche' la GUS non ha questa funzione?). Interpolando l'envelope i
ticcketti non
 >si sentirebbero.
E Jeffrey Lim?
 >Quello che voglio dire e' che a 44100 Hz al massimo della velocita
 >(speed=1bpm=255) un tick (quindi 1 valore dell'envelope) e'
0.078sec. Che si
 >traducono 3458 sample... se durante il mixing il tracker
interpolasse l'envelope
 >avrebbe almeno 3458 stadi per portare un volume verso un'altro o un
panning
 >verso un'altro... il tick e' causato da questo appunto: per 3458
campioni hai
 >volume X poi bruscamente viene portato a X+N. Il cambiamento di
volume crea un
 >gradino (quindi una specie d'impulso). Lo stesso nel panning dove
per
 >implementarlo abbassi il volume da un lato per aumentarlo
nell'altro.
Complimenti.
Il problema è che sulle schede audio ci sono (al massimo) 255 livelli
di volume, per cui, se sei tra il livello 4 e il livello 28, al
massimo hai 14 livelli di volume.
Adesso, facciamo finta che questa limitazione HARDWARE non esista, e
pensiamo al miglior mixer software che esiste, e diciamo che non
abbiamo limiti di tempo.
L'uscita diciamo che sia 44 KHz 16 bit.
Abbiamo, quindi, per ogni singolo impulso, 65536 possibili valori
diversi (che ovviamente non vanno bene tutti 8-), se ti studi un po'
la casistica e la trasformata di Fourier (non ce n'è bisogno, ma fa
scena 8-), vedrai subito che è praticamente impossibile che ci siano
REALMENTE 3458 valori diversi fra cui scegliere.
Se siamo a lavorare col mix hardware, allora il volume del canale lo
possiamo impostare solo tra 255 valori reali, per cui c'è poco da
giostrare: 3458 > 255, fine.
Se siamo con mix software ancora c'è poco da giostrare.
Se lavoriamo a 16 bit anche internamente (bleah, FT suxxx) e dobbiamo
passare, in quel frattempo, da un volume 100 a un volume 150, avremo
uno shift MASSIMO di 12750 valori, nel caso migliore, cioè 3 unità per
ogni ciclo. Ma questo è un caso esageratissimo, per come sono fatti
normalmente gli inviluppi e i sample: cioè, in realtà questo è
praticamente impossibile. 8)
Molto meglio lavorare internamente a 32 bit, come fa Jeffrey Lim, e
moltiplicare quindi per 65536 il numero di possibili valori: moooolte
sfumature in +. 8)
Se poi ragioniamo con sample a 8 bit... buonanotte. 8)
 >Probabilmente il VelvetStudio (tracker che costa una barca di soldi
- $99 la
 >versione a 16Bit) ha questa funzione perche' gestisce gli envelope
come SPLINE e
 >non come spezzate.
Lavorare su spline e su linee è un conto, lavorare su spezzate è tutto
un altro conto.
Non sapevo che FT lavorasse su spezzate, ma è CERTO che alla fine in
digitale le curve continue non esistono, sono TUTTE spezzate, anche
quelle che escono dalla maggioranza dei vostri lettori CD di casa.
 >Anch'io anche se ho fatto tutta sta pappardella di teoria
dell'envelope e delle
 >ipotetiche implementazioni di ipotetici programmatori che
ipoteticamente
 >saprebbero programmare un'ipotetico tracker decente (come suono
intendo)... :)
Prenditela con i manifattori di hardware, che mettono, nel migliore
dei casi 255 livelli di volume e panning (AWE, GUSmax) e nel peggiore
soltanto 16 (GUS).
Visto che ci siamo, ecco come funziona l'uscita della vostra GUS o
SB16 e spesso anche del vostro CD audio.
All'interno abbiamo uno splendido campione a 16 44KHz che deve
diventare un segnale elettrico da tirare in una cassa acustica o in
una cuffia. Questo segnale è analogico.
Cosa fa il famoso convertitore D-A?
Cosa genera, nel tempo che passa fra una WORD e l'altra, fra un
impulso e l'altro?
Ecco il grafico di un campionamento mono fatto da 8 campioni (8 word)
                            *
       *                    !
*      !                    !      
!      !             *      !      *
!      !      *      !      !      !
!______!______!______!______!______!
Ed ecco quello che arriva alle casse:
                            *******
       *******              !
*******!                    !      
!      !             *******!      *******
!      !      *******!      !      !
!______!______!______!______!______!
Sarebbe meglio se fosse così:
                           -*-
  _,.--*-.                / ! \
*^     !  \_           _-*  !  *-_ 
!      !    \_ __..--*^     !     ^*
!      !      *      !      !      !
!______!______!______!______!______!
Ma sono pochi i convertitori D-A così intelligenti, è per questo che
ci servono sample rate sempre + alti, e risoluzioni sempre migliori.
Ricordiamo che tutto questo succede alla fine, quando ormai il
programma non può + nulla, il tempo che passa tra oguna delle nostre
lineette fatte di punti esclamativi e la successiva è un 44milesimo di
secondo, got it?
In questo frattempo sono tutti affari dell'hardware, quello che
succede...
E prima di quel frattempo siamo limitati dalla risoluzione...


ci servono sample rate sempre + alti, e risoluzioni sempre migliori.
Dici?
