Néhány kisebb hiba:
Azert azt fontos am kiemelni, hogy nem tekintettem ezt meg alpha verzionak se, ahogy irtam is
Szoval szerintem joval tobb gond van benne annal is, mint amit irtal ... Mindenesetre a "release often, release early" jelmondat szellemeben probaltam eljarni.
- D/A módban csak a 0. csatornának kellene szólnia 4-szeres hangerővel, a többi ilyenkor tiltott (de a számlálóik továbbra is futnak)
Na ezt pl nem tudtam
En nagy naivan azt gondoltam, hogy siman lehet D/A modban hasznalni a 0-as csatit, kozben a tobbivel "zenelni" ... Tenyleg nem lehet ilyet?
Illetve: mi van ha pl csak a tone 0 bal csati van D/A modba kapcsolva? Akkor az tone1 es tone2 bal csatija nem lesz hallato, de a right mukodni fog? Illetve ilyenkor a zaj csatival mi van (nem mintha azt jelenleg implementaltam volna)?
- a +/- 1 tartományra korlátozás jelenleg torzítást eredményez, ha egynél több csatorna aktív; a 31.5-el való osztásokat 126-ra kellene cserélni (kivéve a D/A módban)
Ezen sokat gondolkodtam, oszinten nem tudom, hogy szokas normalisan digitalis audio jeleket mixelni. Marmint amire gondolok: ha feltesszuk, hogy pl egy MOD/XM/stb playert irunk, amiben mondjuk 32 csati van, akkor egy csatornara 32-ed resze juthat csak? Ez azert fura, mert ugye ha eppen csak egy csati szol az igen halk lesz ... Es a "valo vilagban" siman meg lehet csinalni hogy pl 32 hang szol es nem lenyegesen hangosabb az eredmeny, mintha 1 szolna, mert ugye normal esetben sokszor kioltjak egymast a hangok vagy legalabbis gyengitik ha pl eppen ellentetes fazisban vannak, vagy kozel abban. Magyaran: eleve ez az osszeadas kerdes kicsit nekem santit, hogy ez igy jo, ahogy van.
Ha jol remlik, anno meg pont az emlitett mod/stb player-ek idejeben x86 assemblyben nem is adtak ossze, hanem mindenfajta tablazattal "mixeltek" pont a fenti problemak miatt. Imho - bar lehet tevedek - igazi EP-n sem igaz, hogy pl 3 hangcsatornan jatszott hang egyutt pont 3-szor hangosabb, mintha 1 szolna, vagy igen?
Ezert indultam ki abbol, hogy annak valoszinusege kicsit, hogy pont ugy adodik ossze a csatornak jele, hogy jelentosen tullepi a -/+ 1 tartomanyt, mert lehetnek ellentetes fazisban stb is. Anno jo regen lattam ilyen kodot, ott nem is siman adjak ossze, hanem vmi pre-calculated logaritmikus izevel, viszont az ilyen audio processing dolgokhoz sajnos pont kevesbe ertek
- ha jól látom, a hanggenerátorok frekvenciája túl alacsony (egy oktávval mélyebb, de nem teszteltem, hogy valóban így van-e); 125000 helyett valószínűleg 250000-el kellene osztani
Azt a kepletet egy doksibol vettem, ha jol emlekszem. Viszont lehet rosszul ertelmeztem kicsit
Most atirtam az osztot.
- ennek ugyan viszonylag kevés jelentősége van, de a kimenetek valójában nem lehetnek negatívak, és a DC offszetet felüláteresztő szűrővel kellene eltávolítan
Soha nem csinaltam meg semmiben komolyabb hangprogramozast, ahol ilyen kerdesekkel kellett volna foglalkoznom, meg a web audio API-val is kb 2 napja talalkoztam eloszor
Imho a web audio API koveteli ezt csak meg, bar valoszinu nem tortenne semmi fatalis, ha 0...1 tartomanyba maradna, elobb-utobb audio lesz belole amikor "kijon" a hang a gepbol, ott meg a DC offset amugy is el szokott tunni, ha mas miatt nem, hat az erositoben alkalmazott kondik miatt
Egy digitalis szurot implementalni kicsit korulmenyes lenne JS-ben, bar ehhez se ertek igazan. Elvileg a web audio API tud amugy olyanokat hogy van benne implementalva pl szuro stb is, es ezeket egymashoz lehet "huzalozni" programbol, az implementacio meg optimalizalt kod akkor, nem JS, mivel az mar a web audio API epitokovei a broswer oldalrol. Egyszer majd csak rajovok
A daveTick() függvényt célszerűbb lenne 250000 (vagy 166666.67, ha a BFh port 1. bitje 1) Hz frekvencián hívni, akkor a különböző
frekvencia konverziók elkerülhetők lennének, és talán még gyorsítana is az emuláción.
Ez igy van, sot erre gondoltam mar en is. Az biztos, hogy az emulator ujrastrukturalasa elobb-utobb szuksegszeru lesz, jelenlegi felepitese inkabb idezi a kezdeti elso lepeseket, hogy "lassuk, eljutunk-e az EP logoig egyaltalan, a tobbi nem fontos". Az emulatorban _jelenleg_ a nick slot frekvenciahoz van minden idozitve, annak es a fenti altalad is megadott frekvenciaknak nincs egesz szamu kozos osztoja. Enelkul is persze mehetne a dolog, hiszen a counter-ek jelenleg sem egesz szamok (JS-ben amugy is egy numerikus tipus van, nincs kulon float/int, kiveve a typed array nevu jelenseget, de az mas tema). A BFh porttal meg total nem is foglalkoztam eddig semmilyen szinten
Jó minőségű hanghoz ezt kellene újramintavételezni kisebb (pl. 44100 Hz) frekvenciára, de az Javascriptben talán túl lassú lenne. Ha működik tetszőleges mintavételezési frekvencia lejátszása, akkor azzal lehetne próbálkozni, hogy például 41667 Hz legyen a D/A frekvencia, és a kimenet 6 vagy 4 (a BFh port 1. bitjétől függően) DAVE hangminta átlaga.
Hat a resampling kisse lassu lenne imho JS-ben. Most az van, hogy a web audio API default mintavetelezesi (nalam 44100-at ad) frekvenciaja lekerdezheto, de ez lehet nem ugyanaz mindenkinek a gepen, szoval nehez eset. Azt, hogy a web audio API tud-e resampling-ot, szamomra meg nem tiszta. Sajnos ez meg szabvany draft a w3c-nel is, a chrome-os implementacio pl kisebb eltereseket is mutat, vagy nincs benne vmi, amit w3c specko alapjan tudnia kene ... Firefox-ban meg igazabol tamogatva sincs (config:flags hackekkel igen, de furan viselkedik), es el tudom kepzelni, hogy ott is lesznek elteresek. Szoval ez eleg uj dolog a web vilagban, hogy adjunk ki JS-bol generalt hangot, nekem foleg uj
Ezt regebben amugy ugy ganyoltak, hogy flash-ben irtak audio generalast, aztan javascript - flash kozott adtak at adatokat, de a flash resze adta konkretan a hangot. Ilyet azert nem szeretnek, na meg flash-hez meg tenyleg konkretan semennyire sem ertek, az meg a masik.
