Newsgroup: it.arti.musica.strumenti.tastiere
Titolo: Costruirsi un softsynth non convenzionale

Costruirsi un softsynth e` cosa forse non proprio banale, ma neanche troppo
difficile. Occorre risolvere due tipologie molto differenti di problemi:
1) il motore di sintesi
2) il link al layer del sistema operativo (DirectX
nel caso windows) per far "suonare" la scheda audio.
Premesso che il
problema 2) e` puramente sistemistico, benche` piuttosto semplice (si
tratta di aprire una fifo e scriverci dentro), non ho la benche` minima
intenzione di affrontarlo, senno` mi sembrerebbe di tornare a casa e ...
riprendere a lavorare ;-)
Mi interessa, invece, approfondire il motore
di sintesi.
Si e` parlato, ultimamente, di tecniche di sintesi non
convenzionali, sintesi granulare & co. e mi son messo a giocare anch'io in
questa direzione.
Lo schema di sintesi che sto utilizzando e`, nella
sostanza, quello in additiva. Quindi, niente filtri e trasformate, ma solo
somma di funzioni periodiche.
Il "rationale" matematico che c'e` dietro
e` sostanzialmente semplice, e quindi mi son messo a definirmi una
funzioncina in C che, per rimanere in tema, ho chiamato DCO(freq,t) che mi
fa da oscillatore con frequenza parametrica.
Poi mi son definito una
funzioncina DCA(t,vol) che mi fa da inviluppo.
Alla fine il "mattone" di
base sara` una cosetta del tipo 
DCA(t,DCO(freq,t))
che mi simula a tutti
gli effetti un inviluppo applicato ad un generatore d'onda.
Ma di questi
"mattoncini" posso definirmene quanti ne voglio, gli inviluppi posso farli
evolvere in maniera assolutamente libera (posso anche farli ciclare, o
muovere sul fronte stereo). Insomma, se vi "arrapate" di fronte
all'oonnipotenza di un analogico, con un "synth" di questo tipo potreste
provare un'...eiaculazione precoce! ;-)
Beh, ragazzi, se la cosa vi
interessa posso riorganizzare i sorgenti e includervi in questa
sperimentazione che, in questo momento, ha limite solo nella mia fantasia.
Fatemi sapere.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.iol.it

 Fatemi sapere.
Siiiiiiiiiiiiiiii! Ho appena fatto l'esame di teoria della patente 
e ora sono un uomo *libero*!!!!!
Io sono disponibilisssssssssssssimo...
Ciao
Francesco

all'oonnipotenza di un analogico,
Ehm, ... volevo dire MODULARE non ANALOGICO! Ma credo di aver reso l'idea,
stando alla *reazione* dell'amico Eidos ... ;-)
Ciao, Sandro


 Ehm, ... volevo dire MODULARE non ANALOGICO! Ma credo di aver reso l'idea,
In effetti non avrebbe avuto molto senso "analogico" a sè stante,
ma il succo (ehm... andiamo *scemando*) era un altro...
Bella l'idea dell'"infinitamente" modulare!
Ora vado ad informarmi un po' meglio su tutto ciò... 
Ciao
Francesco

 difficile. Occorre risolvere due tipologie molto differenti di problemi:
Ti invidio Sandro! Io non ho proprio tempo per queste cose e le farei al volo, ma
purtroppo il tempo è denaro dopo una certa età:)
bravo
LucA

bravo
Mi
basta che ci dai qualche idea, di quelle ... "strane"; per il resto, se ti
fa piacere, ti farei sapere i risultati della sperimentazione man mano che
ottengo qualcosa di notevole.
A settembre daro` i sorgenti a chiunque li
volesse, come al solito.


Se può interessarmi? Beh...
A quando la versione per Mac? =8-P''''
Un Paolo arrapato
-- 
Paolo Tramannoni
Porto Recanati, Italy

 ottengo qualcosa di notevole.
un joystik che pilota quattro funzioni ( che so : ampiezza , modulazione ,
intonazione ecc...)
o quattro "moduli" , e che naturalmente nelle posizioni intermedie è in
grado di mixarle
è troppo convenzionale ?

è troppo convenzionale ?
Assolutamente no! Anzi, e` una bella idea (molto wavestation). In ogni caso
in questo momento mi sto concentrando sugli aspetti essenziali della
sintesi, piu` che sui controlli real-time.
Se c'e` qualcuno che vuol
farsi carico del "gancio" sistemistico non potrei che esserne lieto ;-)


 farsi carico del "gancio" sistemistico non potrei che esserne lieto ;-)
guarda , se fosse alla mia portata ne sarei ben lieto pure io
:-)
ciao e buon lavoro

 nel caso windows) per far "suonare" la scheda audio.
mmm...
diciamo che mi interessa.
il problema, come al solito, sara' quello di conciliare queste cose
con il Politecnico... :-(((
Per quel che mi riguarda sono piuttosto interessato anche al punto 2...
Tienimi informato non appena decidi di iniziare.
ciao!
Geo

Tienimi informato non appena decidi di iniziare.
Gia` fatto. Proprio
ieri sera ho messo in piedi il primo moduletto di sintesi, con una
componente sinusoidale ed un inviluppo esponenziale inverso.
Poi mi son
fatto il layer per la produzione in formato standard WAV del suono
sintetizzato; i risultati li ascolto con il lettore multimediale (e credo
che i primi suoni interessanti provero` ad importarli con Vienna cosi` da
provarli "al tatto").
Il cacchio e` che le librerie matematiche del mio
compiler C hanno il seno che va a minchie per alcuni valori (!). Ergo mi
son fatto un'approssimazione per polinomi del seno, ed ho ottenuto una
sinusoide quasi perfetta!
Adesso puo` partire la vera sperimentazione.
Ho intenzione di sommare, sottrarre, sfasare moduletti di questo tipo.
Devo anche organizzare un LFO, che dovrebbe essere una cosetta proprio
semplice. A quel punto, facendolo girare a frequenze in banda audio, potrei
sconfinare anche sulla FM!
Azz! Spero solo di avere il tempo necessario
per togliermi tutti questi sfizi ;-)
Comunque a settembre vi rilascio
tutti i sorgenti, e la sperimentazione la proseguiamo tutti insieme (almeno
gli interessati).
Ciao, Sandro.
P.S. Cominciate a pensare al punto
2). Con le librerie MFC di C++ dovrebbe essere relativamente semplice (ma
il condizionale e` d'obbligo). Anche se i cavoli piu` amari verranno dai
vincoli di real-time da applicare ad un modello di sintesi che, per sua
natura, e` abbastanza cazzuto e computazionalmente pesante.


piega nuova
Ti faccio un follow-up solo oggi, perche` non ti nascondo
che, intuitivamente, avevo disaccoppiato il motore di sintesi dai controlli
real-time.
A dire il vero il tuo mex solleva un problema di non poca
valenza: ha senso progettare schemi di sintesi fantasiosi se poi i vincoli
del real-time non ti consentono di "suonarli"? Anche quando si fa software
real-time di controllo si tende a separare la parte procedurale dallo
schema esterno di controllo. Ma il tutto "funziona" solo se si hanno chiare
a-priori caratteristiche di performance della piattaforma sulla quale le
procedure andranno eseguite (cioe` chi programma deve sapere quanti
nanosecondi se ne vanno in un'assegnazione fra interi ...).
Io, in tutta
onesta`, questi conticini non me li son fatti. Ma l'architettura la sto
prevedendo a-priori per il controllo real-time; pertanto non mi stupirebbe
che alla fine avro` un bel giocattolo che non riuscira` a suonare in
diretta, perche` fa troppi calcoli ...
Pero` mi e` venuta un'idea, di
facile realizzazione. Alcuni di voi hanno ricevuto in pvt un mio "sfizio"
giovanile, un parser midifile; basterebbe poco per unire i due giocattoli
per fare un piccolo render audio di un midi.
Ma non mettiamo troppa
carne sul fuoco ...


perchè non progettarlo su piattaforme trasportabili (veloci da caricare,
stabili e freeware)? (es: DOS)
Sam


Infatti. Sto usando il mitico C600 per MS-DOS.


 Infatti. Sto usando il mitico C600 per MS-DOS.
Il dos sarà "veloce da caricare" ma proprio stabile no!
E nemmeno freeware (certi si...)
Ciao
Francesco

 natura, e` abbastanza cazzuto e computazionalmente pesante.
Le MFC *sono* computazionalmente pesanti. Perchè non
ti dovrebbero bastare le DirectX?
Ciao
Francesco



Sicuramente e` piu` stabile di Win. Inoltre,
potendo pilotare in modalita` reale i dispositivi (cioe` senza passare dai
vari layers di sistema) e` il S.O. migliore per le applicazioni davvero
real-time.
Quando avevo la MPU401 con BigBoss e DOS 3.30 i ritardi midi
non sapevo neanche cosa fossero (ah, bei tempi quelli ... ;-))



(Per rispondere rimuovi _ dall'indirizzo).

 ha scritto nel messaggio
news:195Z223Z220Z65Y...@usenet.iol.it...

sono interessato alla cosa .......
per il momento ti invio alcuni link relativi alla spectral modeling
synthesys
ed a xavier serra uno dei maggiori esperti
www.iua.upf.es/~sms/
www.iua.upf.es/~xserra/
ciao sandro a dopo le vacanze

 schema esterno di controllo.
Sandro
il successo di un synth software dipende naturalmente anche dall'interfaccia che
avrà e quindi anche dai controller in realtime. Più permetti di arrivare al
singolo elemento, più il pubblico troverà troppo difficile programmarlo. Potresti
arrivare a delle macro, ma perderesti parte della potenza del synth, e anche i
controller in realtime potrebbero essere meno intuitivi di quel che si pensi.
Quando una persona chiede un determinato controller lo fa perchè ha già in mente
uno schema di connessione dei parametri, ma quando tu offri lo stesso controller a
chi non ha compreso la connessione possono nascere più problemi (ma anche
soluzioni interessanti) etc etc etc
ciao 
LucA

 ti dovrebbero bastare le DirectX?
concordo con le DirectX
non sono forse fatte apposta?
--
Gerolamo



Abbiamo tutti ragione! ;-)
Intendevo le librerie MFC perchè hanno già predisposto l'environment per il
link a DirectX. In realtà sono le API DirectX che dovranno essere chiamate.
In rete ci sono un sacco di esempi in formato sorgente di programmi con le
DirectX. Chissa che non si possa trovare un ... canovaccio da sviluppare ai
nostri fini.
Ciao, Sandro.


 Bastano poche righe di C,
Sono felice, lusingato ed onorato che
la mia idea abbia scatenato tanto interesse, da parte di persone
sicuramente preparate ed appassionate.
Grazie davvero. Datemi il tempo
di organizzare il lavoro e poi vi invio i sorgenti.
Ciao, Sandro.


 Ciao, Sandro.
ciao
P.S.
azz... ti devo ancora far sapere per il sito...
non temere, prima o poi riceverai notizie :-)))))
--
Gerolamo

soluzioni
interessanti)
Domandina. Ma tu che parametro di sintesi vorresti poter
controllare in real-time in ambito di additiva?


 una sufficiente granularità!
non ho seguito con attenzione questa parte di thread, per cui magari
dico una vaccata---------
Vaccata:
Hai considerato l'idea di tabellare il seno e di estrarre i valori dalla
tabella?
Molto meno oneroso computazionalmente e mediamente altrettanto preciso.
--
Gerolamo

"vista", mi sembra più che decente. E poi, non dovevamo forse sperimentare?
Utilizzando le proprietà di seno e coseno del tipo sin(pi/2-x),
cos(pi/2-x) si potrebbe riportare il valore addirittura a quello in
[0, pi/4] e a questo punto, per la max. velocità di calcolo, la
funzione sin(x) della libreria potrebbe essere davvero sostituita con
buone prestazioni da una tabella e qualche interpolazione, come ha
suggerito Gerolamo, o da qualche termine di una serie di Taylor scelta
ad hoc. 
Ho fatto una rapida prova in Matlab, calcolando sin(pi/4), che per la
serie è il caso peggiore:
utilizzando la serie x-x^3/6+x^5/120 si ottiene un errore relativo
e=-5.1283e-5, che forse è troppo, perchè il max. errore di
quantizzazione a 16 bit è 7.9245e-6.
Utilizzando x-x^3/6+x^5/120 -x^7/5040 l'errore scende a 4.4069e-7,
ovvero 0,000044069%. Mi pare niente male.
Siccome a pi/8 l'errore della serie del quinto ordine decresce a
-7.4511e-7, per evitare 2 moltiplicazioni (ma non so se ne vale la
pena) si potrebbe dividere ancora l'intervallo [0, pi/4] in due parti:
[0,y] e [y, pi/4) utilizzando nel primo intervallo la serie di
MacLaurin di cui sopra e nel secondo intervallo la serie di Taylor di
punto iniziale y, scegliendo magari l'y opportuno per minimizzare
l'errore massimo.
Ho fatto anche un veloce programmino MATLAB per verificare gli errori
calcolando il seno con tabella e interpolazione lineare: utilizzando
tra 0 e pi/4 una tabella con 100 valori equispaziati e interpolando
linearmente, il max. errore è 1/7.8672e-6. Con 1000 valori è
1/7.7261e-8.
Sempre se non ho fatto casini....
Bisogna vedere quali tra le due soluzioni sia meno onerosa
computazionalmente, se si preferisce qualche moltiplicazione o la
ricerca in una tabella.
Oops, forse sto esagerando......Sono un pò esaurito, si vede? :-))))


Molto meno
oneroso computazionalmente e mediamente altrettanto preciso.
Non č
affatto una vaccata. Anzi!
Rispondo a te e ad A.Zabatta.
Ho pensato
alla soluzione di Alessandro cosě come alla tua, e le ritengo entrambe piů
che valide. Certo, sui costi computazionali si dovrebbe fare qualche
calcoletto, ma vedrň se in azienda ci ritroviamo un performance tester per
applicazioni real-time, e poi vi faccio sapere.
Ad ogni buon conto
l'approssimazione mediante parabole, che č analiticamente semplice e
abbastanza precisa, mi sta "suonando" abbastanza fedele ad una sinusoide,
abbastanza per ritenerla, in questa fare assolutamente preliminare, un
onesto punto di partenza.
Stanotte ho intenzione di esplorare
"addizioni" atipiche. Lunedě vi faccio una breve rassegna dei risultati.


> L'approssimazione del seno, a "vista", mi sembra più che decente.
Anche la sinusoide dell'Andromeda non è perfetta, eppure l'A6 costa 7,5
milioni! ;-)
--
Bye-by:
Stv
----------------------------------------------------------------------------
La musica è al tempo stesso il linguaggio più completo per
comunicare i sentimenti e il più difficile da interpretare. (A.S.)
ste...@inwind.it
 (Generic E-Mail)
s...@libero.it
 (Music E-Mail - SoundOnSound Recording Xtudio)
ste...@ondanomala.com
 (Ondanomala E-Mail)
http://www.ondanomala.com
 (Sito ufficiale Ondanomala)
http://free2.kyberlandia.it/Steeve/
 (Sito con Links, Infos & Patches)
----------------------------------------------------------------------------

milioni! ;-)
Beh. Che importa se il seno non e` perfetto. L'importante
e` che sia ... sodo!


 Ciao, Sandro.
ciao!
--
Gerolamo

 "addizioni" atipiche. Lunedě vi faccio una breve rassegna dei risultati.
io sono un po' sconvolto in questi giorni... (si si... piu' del solito...)


a proposito della grafica....
Allora. Supposto di voler viaggiare con una risoluzione di 44.1 KHz e 16
bit dovremmo essere in grado di produrre un intero a 16 bit in un tempo
inferiore a circa 0.25 millisecondi. Ma per poter riempire il buffer di una
fifo e stare tranquilli che non "cliccki e poppi" dirante il playback
dovremmo, IMHO, scendere alla meta`; diciamo che se non siamo in grado di
produrre un sample in meno di 0.1 millisecondi e meglio abbandonare tutto
...
Ma 0.1 millisecondi sono un'eternita`, sia per leggere da una
tabella, sia per fare qualche calcolo aritmetico, quindi non dovrebbero
esserci problemi.
Sul fronte della precisione, invece, credo che il
problema non si ponga affatto. Poiche` lavoriamo ad una risoluzione di 16
bit, dobbiamo "castare" i valori del campione in un intero a 16, e quindi
tutta la precisione eventuale in virgola mobile se ne va a donnine ...
RISOLUZIONE: la strada che ho intrapreso utilizza numeri in virgola mobile
a 32 bit per tutta l'architettura del motore di sintesi. Solo lo step
finale, quello di produzione del file wav, tronca la precisione del float a
32 in un int a 16.
Come al solito, se ritenete che stia prendendo un
abbaglio fatemelo sapere per tempo ... ;-)
Ciao, Sandro.
P.S. Avevo
detto che i costi di computazione mi sembravano grossi. Smentisco. E` la
scrittura su wav che e` lenta, ma il motore mi sembra sufficientemente
veloce.


 veloce.
voglio il codice!!!! :-)))))))))))
P.S.
scrivendo su it.comp.giochi.sviluppo ho trovato un'altra
persona interessata alla cosa.
Gli ho detto di scrivere a te per i dettagli...
Ho fatto male?
--
Gerolamo

Ho fatto male?
Scherzi???
Ciao, Sandro.


32 in un int a 16.
Mi sembra una ottima soluzione; non ho idea di come fare, ma il tutto
sarebbe perfetto se il troncamento a 16 bit fosse fatto con il
redithering. Si tratterebbe di risolvere il problema teorico di
trovare il "giusto rumore" da aggiungere, per il resto la cosa è
banale.
Aspetto conferme da chi "sa", ma ho l'impressione che molti programmi
software, che lavorano internamente quasi tutti a 24 bit, facciano i
calcoli in aritmetica intera. 
Bisognerebbe trovare però una libreria nativa a 24 bit, certamente
fare i conti con i float e convertire a 24 non fa che far perdere
altro tempo, e scrivere a 24 bit le function che servono mi sembra
troppo.
Chissà se c'è un incremento di prestazioni, io credo di si, mah...


troppo.
Questo
non e` detto. L'aritmetica fp si basa sempre e comunque su calcoli fra
interi, applicati agli interi che rappresentano mantissa ed esponente del
numero in virgola mobile. Quindi non vedrei grosse differenze di
performance fra un fp a 32 bit ed intero a 32 bit (ma potrei aver detto una
gran cazzata ... ;-))
Grazie Alessandro!
Ciao, Sandro.


 performance fra un fp a 32 bit ed intero a 32 bit (ma potrei aver detto una
Forse... può dipendere anche da che parte della CPU è coinvolta
nel calcolo?
Ciao
Francesco
P.S. Quando hai un po' di sorgenti li passi pure a me? Che hai usato
per compilare? GCC o Visual C++? Grazie!

nel calcolo?
Certo! Moltissimi processori hanno l'unita` di calcolo fp
gia` implementata a livello hardware. Tuttavia, per motivi di portabilita`,
la stragrande maggioranza dei compilatori tende a ricostruire via software
le primitive in virgola mobile, lavorando con mantisse ed esponenti interi.


 breve, il valore dell'esponente.
Ok se č cosě č chiaro, grazie!
Ciao
Francesco