PC-s virtuális zongorák buktatói

Botladozásaim a linuxos virtuális zongorával. Előzmények:

https://hup.hu/node/172274
https://hup.hu/node/172185
https://hup.hu/node/171915

A nagy sikerre tekintettel, és mivel régen nem jelentkeztem a témával, folytatom a dolgot! :-) 
Most nem gondoltam át annyira, hogy miről írjak - szal rögtönzés lesz - de sok minden történt. 

Először is történtek hardware fejlesztések:

vettem egy USB hangkártyát Behringer UMC202HD - ami egyrészt poénos a név miatt, másrészt nem írnak rosszakat róla.

UMC202HD

Igazából nem nagyon van összehasonlítási alapom, nem tesztelek tucatszámra hangkártyákat, de úgy vélem ez  elég jól szól - azért nem lett tőle WOW-érzésem. Ugye ennek a kártyának csak szimmetrikus ki/bemenete van, a zonginak meg aszimmetrikus ki/bemenete  - de így is meg tudja hajtani kellő hangerővel.  Igazából van ennek a hangkártyának egy olyan változata is (UMC204HD), amin van aszimmetrikus csatlakozás is, de az drágább, és ráadásul amikor vettem akkor szinte egyiket sem lehetett kapni sehol, hiánycikk volt és örültem, hogy egy ilyet találtam végül (viszonylag drágán - most lényegesen olcsóbb). Úgy van csatlakoztatva, hogy az alaplapi hangkártya kimenete van beledugva ennek az USB-s kártyának a bemenetére egy rendes kábellel. Ez azért jó megoldás, mert így az USB-s kártya dedikáltan a Linuxsamplerhez (továbbiakban: LS) és zongorához van használva Jack -en keresztül, és minden más pedig az alaplapi kártyát használja sima ALSA-val.  PulseAudio le van lőve induláskor, így az nem zavar be sehova (amúgy Ubuntu Studio-t használok).  Tehát így egy gombnyomással be tudom kapcsolni az alaplapi kártya jelét és közben párhuzamosan tud szólni a zongi is, nem zavarják egymást a keverést elvégzi UMC202HD.  Ez az a használati eset amikor YT-on nézem/hallgatom egy-egy darab előadását és közben próbálom magam is lejátszani. A probléma amit megold kettős: egyfelől van egy kizárólagossági dolog, hogy a LS Jacken keresztül fogja a hangkártyát és nem enged ALSA-s dolgokat hozzáférni addig; másfelől ha még engedné is valami módon, akkor is a zongi végletekig kihegyezett beállításokat igényel a hangkártyával kapcsolatban, hogy minél kisebb legyen a latency, ami már YT-os egyéb zenéknek eleve nem lenne jó. Tehát hardware szinten jó elválasztani a két dolgot. Thx @zitev -nek az ötletért!

A másik fejlesztés egy M.2-es PCIE-es 250GB-os SSD volt - kínai. Most nem emlékszem pontosan a sebességre, de brutál gyors 2300MB/s körül rémlik. Mivel a zongora hangminták újabban már ~50GB méretűek és extra gyorsan kell elérni, így ez nagyon nagy előre lépés volt. Az alaplap kb 10 éves PXIe 3.0 támogat. Mivel van alaplapon keresztüli video, így praktikusan a videokártya slotja lett egy bővítőkártya (szintén Kínából) segítségével felhasználva a csatlakoztatáshoz (ugye régi alaplapon persze nincs M.2-es csati). A rendszernek maradtak sima SSD-k (3 disk RAID 0-ban) onnan történik a bootolás, az M.2-es csak zongi mintáknak van fenntartva - nem is tudna arról bootolni.  A rendszer tömbje igy kb 700MB/s sebességet tud. Elég gyorsan tudok másolgatni a tömb és az M.2 között. Illetve van még egy HDD is ahova le lehet tenni az éppen nem használt mintákat, de ez a lemez alapból nem csatolódik és le is van állítva az induláskor, hogy ne kerregjen itt nekem. 

4GB-ról, 8-ra lett bővítve a RAM. 16GB mehetne bele amúgy, szóval itt még van fejlesztési potenciál. De nagyon drágák a RAM-ok aktuálisan! DDR3 1600 MHz-esek kellenek bele két 8GB-os. Egyenlőre 2x4GB-al 1333 kell beérnem. 

 

Szűk pár éves tapasztalat, hogy a virtuális zongorákkal kapcsolatos ismereteim, nem csak folyamatosan bővítendőek, de időről-időre felül is bírálandóak. Az ilyen zongorákkal szembeni szkepticizmust aktuálisan két dolog, tapasztalati dolog, határozza meg:

Az egyik a latency kérdése. Ugye itt arról van szó, hogy a billentyű leütés után mennyivel később szólal meg a hang, azaz mennyire direkt az érzés. Ezredmásodpercekről van szó. De az nagyon nem mindegy hogy <1ms vagy 5ms a késés! Ne essünk bele abba hibába, hogy azt vesszük alapul a késés vonatkozásában amit DAW v. egyéb szoftver mint tájékoztató értéket kijelez nekünk! Itt tisztázni kéne, hogy az az érték pontosan mire vonatkozik és az jó eséllyel nem az az érték amire nekünk szükségünk van. Nagyon markánsan érezhető a különbség a késleltetés vonatkozásában ha a digitális zongorámat önmagában használom, vagy ha csak keyboardként és a hangot a sz.gép állatja elő.  Természetesen a sz.gépen futó rendszer a neten fellelhetőek szerint már igen erősen optimalizálva van a virtuális zongora felhasználására. Ez egy dedikált gép, csak erre van használva. Sőt még azokon túlmenően is kísérletek történtek részemről további optimalizációs lehetőségek után kutatva. pl. a LS nem tud több magon futni egyszerre. Kapott egy dedikált magot amit csak ő használ. De egyébként alig terheli a procit. A dedikált magra helyezés nem javított semmit. Akkor eszembe jutott, hogy mi lenne ha azt csinálnám, hogy több példányban futtatnám a LS-t és a hangbankot a zongora mintákkal felosztanám köztük valami módon: pl. egyik LS példány a magas hangokat a másik a mélyeket; avagy az egyik csak a pedál nélküli a másik meg csak a pedállal módosított hangokat; avagy az egyik egy adott billentés erősségnél kisebb erejű billentéshez ill. a másik az annál nagyobb erősséghez tartozó hangokat játszaná és a LS példányok mindegyikét külön dedikált magra raknám? Na ezek kivitelezése azért igényelt egy kis tervezést. SFZ formátumot használok nagyon sok ezer hangmintával. Az ezeket leíró SFZ állományokat át kellet szervezni, a midi jeleket úgy kellett irányítani, hogy a megfelelő példányhoz jussanak stb.  Ez egy régebbi i5-ös proci 4 maggal. Ebből csak kettőt adhattam az LS példányoknak, mert a mások két mag a többi feladatokhoz kellettek. pl. visszhang effekt, YT -os böngésző stb. Egy szó mint száz, ezeket kipróbáltam és nem segítettek a latencyn. Csináltam olyan lebutított hangminta készletet ami elfért a rendelkezésre álló RAM-ban, és így a költséges disk-műveletek megspórolásra kerültek, a latencyn nem segített. Nem tudom, hogy mit lehetne tenni! Esetleg valami ultramodern alaplap proci kombó extra gyors RAM-mal segíthetne. A sok mag között még jobban elaprózhatnám a hangminta készletet és így a terhelés eloszlana a magok között. De lehet eleve halott dolog és ennél jobban ezt nem lehet PC-vel megvalósítani! 

A másik a minták felvételének/rögzítésének a kérdése. Ahhoz, hogy a sz.gépen futó LS le tudja játszani a zongora hangjait, azokat megelőzően valahogy fel kell venni egy akusztikus hangszerből. Figyeljetek, mert ez akkor is igaz, ha a szoftver ami előállítja a hangot (a LS-től eltérőn) nem mintavételes módon, hanem fizikai modellezés alapon állítja elő hangzást. Ugyanis ez utóbbi esetben is szükségesek a minták, hisz az az "etalon" azokhoz kell igazítani a modell által kiszámolt hangot. Tehát akár felvett akár kiszámolt hangok lejátszásával reprodukálja a szoftver -mint végtermék - a zongora hangját, a folyamat első lépéseként mindenképp fel kellett venni egy valódi akusztikus zongora hangját. Na ez az ami nem szokott sikerülni! Hogy lesz bemikrofonozva a zongora? Hova és milyen mikrofonokat fognak elhelyezni? Nyilván az amatőr felvételek nem úgy történtek, hogy a kibérelt Steinwayt bevitték a studioba és ott méregdrága óradíj terhe mellett elkezdtek hetekig szórakozgatni a felvételekkel. De ha egy nagy ívű vállalkozást is felvételezünk, akik ezt meg tudják tenni, és nem csak hangmérnöki tudás áll a rendelkezésükre, hanem eleve rendelkeznek már kimódolt koncepcióval milyen hangokat és miért kell rögzíteniük pl. nem csak húrok rezgését, de kalapács, a damper, a billentyűk és pedál mechanikájának zörejeit (amik mind részei a zongora hangzásának) illetve nyilvánvalóan ezeken túlmenően, hogy zongora mely részeire irányítsák a mikrofonokat: mint zongorista hallaná v. mint a közönség hallaná sztereó vagy binaurálos hangzás, mi lesz a visszhanggal(?) - megannyi kérdés - amiket ha sikerülne is jól megválaszolniuk akkor is van még egy bökkenő: hogy lesz az biztosítva, hogy minden billentyű esetében ugyanolyan erősséggel legyenek leütve? Tehát minden egyes billentyű esetében "sok" különböző leütési erősséghez tartozó hangot kell rögzíteni! Hogy mennyi a "sok" az itt a döntő kérdés! Erre vonatkozóan a kottákban 12-16 számú dinamikai jelölés van. Tehát mondhatjuk azt, hogy odaül egy képzett zongorista és elkezdi az egyik billentyűt leütni ismétlődve egyre erősebben. És akkor a leghalkabbtól a leghangosabbig ilyen számú felbontást tud produkálni. (fontos érteni, hogy nem csak arról van szó, hogy a billentés erősségével hangerő változik, hanem mellette - és ez a lényeg - a hang hangzása is megváltozik.) Oké, eddig megvagyunk! Akkor most jön a következő billentyű! Szerintetek képes arra az illető, hogy pontosan ugyan olyan felbontással és erősséggel üsse a következő billentyűt,mint az előzőt tette? És utána tovább végig a 88 billentyűn ugyan így? Hát persze, hogy nem! Ráadásul ez a felbontás még sehol nincs ahhoz az elméleti határhoz képest ami egy virtuális zongorát jellemez, mert ott 128 különböző erősség lehet. Épp ezért itt egy szerkezetre/gépre/eszközre van szükség amit odaillesztenek a zongora egy billentyűjéhez és akkor az 128 különböző erősséggel leüti a billentyűt és aztán ugyan ezt eljátssza a többi 87 billentyűvel is! DE! Ez a gép szükségszerűen mechanikai mozgást végez, ami hanggal/zajjal jár együtt! Lesz benne egy rugó? Vagy pneumatica működteti szelepeken keresztül? Értitek, ezeknek mindenképp hangjuk lesz - amit majd nem lehet eltüntetni a felvételről. Mi kizárólag a zongora hangját akarjuk felvenni és nem egy zongora és egy annak billentyűit nyomogató szerkezet hangját együttesen! Hogy lehet olyan eszközt/szerkezetet előállítani aminek működése kalibrálható egy adott zongorához, képes az ultraprecíz 128-as erősségű felbontásra a billentéshez, és neki magának nincs semmi hangja? Hát azért egy ilyen megalkotása nem egy triviális mérnöki feladat szerintem!  Ez a VSL Piano Robot.

Képzeljük el a következőt: a zongora középső billentyűjét leütjük meghatározott erősséggel  mondjuk 64-es értékkel. A hangot felvesszük, így lesz egy darab wav fájlunk. Most azt akarnánk, hogy ebből a hangból a LS ki tudja számolni tetszőleges más erősséghez pl. 12 értékhez tartozó hangerejű változatát ennek a felvett hangnak. Ugyan azt fogjuk hallani csak halkabban. De ugye előbb említettem, hogy igazából nem csak a hangerő a különbség, hanem a hangzás is más. Nyilvánvalóan ezt a más hangzást a LS nem fogja tudni produkálni nekünk. Így ezen közepes erősséghez tartozó hangból generált (és más erősséghez tartozó) hangok a játék során idegenül fognak szólni. Hívjuk ezt vertikális átalakításnak (tehát amikor egy billentyűn belül vagyunk és annak különböző erősséghez tartozó hangját számoljuk az egyetlen felvett mintánkból).  A horizontális átalakítás pedig az lenne amikor a középső billentyű melletti, szomszéd billentyű hangját akarjuk kiszámolni a másik billentyű hangjából ugyan azon erősséghez tartozóan.  Tulajdonképpen ez inkább működik mint a vertikális - az adott billentyűnél mondjuk egyel magasabb hangú billentyűnek megfelelő hangmagasságra transzponálható a hang, és annak jellege nagyjából azonos lesz, mint ahogy az a billentyű szólna az adott leütési erősségen. De ez csak nagyjából igaz! Ugyanis ha alaposabban megvizsgáljuk hogy milyen összetevői vannak hangzásnak akkor meg kell tennünk az a megállapítást, hogy tulajdonképp a hangzás jellegzetesebb része a zongora húr rezgése. Most attól függően, hogy milyen hangolás van az zongorán az adott billentyű melletti billentyűhöz tartozó húr hangjának frekvenciája ismert, és arra a hangmagasságra transzponálható lenne a felvett húr rezgésének a hangja. Csak hogy nem pusztán a zongora húr rezgése adja a hangot, hanem a zongora egyéb részeinek rezgése, mechanikai hangjai is megjelennek abban. pl a billentyű mechanikájának hangja. Az viszont nem változik úgy a különböző billentyűkhöz tartozóan, ahogy húr rezgéséből származó hang magassága. Viszont a felvételünkön ezek hangja is szerepel mint a hangzás összetevője. És ha ezt a hangot transzponáljuk, akkor a billentyű mechanikának a hangja is transzponálásra kerül (pedig csak a húr hangját kívánnánk transzponálni, a mechanika hangja ugyan az kéne hogy maradjon). Így a horizontális átalakítás is csalás és fals hangzást eredményez - hacsak...mi lenne ha megpróbálnánk a felvett egyetlen mintánkat annak hangzás szerinti összetevőire bontani? Hisz van egy időbeliség, a mechanikai zaj a billentyű leütésekor keletkezik a hang elején. Utána csak a húr rezgését halljuk és a végén esetleg megint a mechanikai zajt a billentyű felengedésekor. Tehát úgy képeznénk meg a szomszédos billentyű hangját, hogy a felvett minta elejéről levágnánk a mechanikai zajos részt kb 0.01 másodpercet, illetve a minta végéről is ha ott is van "zaj". A megmaradt középső részt transzponálnánk a kívánt hangmagasságra majd levágott részeket visszaillesztenénk erre. 

Továbbá van egy másik jelenség is amit röviden ismertetni szeretnék: Sympathetic Resonance -nak hívják angolul. Ennek az a lényege, hogy ha zongora húrjai szabadon rezeghetnek, tehát le van nyomva zengető pedál, és leütünk egy hangot, akkor természetesen az adott billentyűhöz tartozó húr rezgésbe jön, de ezt a rezgést átveszik a magasabb oktávok ugyanazon hangjai is (amiknek frekvenciái egyébként egész számú többszörösei a leütött hang frekvenciájának) és így halkabban ugyan de így ezek a húrok is megszólalnak. pl Van olyan zongora, a Blüthner ahol tudatosan ilyen kiegészítő segédrezgő (alikot) húrokat alkalmaznak. Ezeket a húrokat nem üti meg a kalapács, csak maguktól (illetve fent nevezett jelenség következtében) kezdenek rezegni és ezzel színezik a hangzást. Valójában a dolog bonyolultabb, pontosan nem értem, hogy mikor milyen más húrok jönnek még mozgásba. Ha belegondolunk abba - leprogramozhatóság szempontjából - , hogy lenyomott pedálnál minden húr szabadon rezeghet, de a jelenség akkor is meg van, ha a pedál ugyan fel van engedve de bizonyos billentyűk a játék folyamán épp lenyomva vannak mondjuk az egyik kézzel (és így szabadon rezeghetnek), amikor a másikkal leütünk egy újabb billentyűt akkor meg kell vizsgálni, hogy vannak-e olyan hangok éppen lenyomva amik együtt tudnak majd vele rezegni. És a következő billentyűnél megint.  Szóval ennek megvalósítása elég komplikáltnak és erőforrás zabálónak tűnik. 

Szóval a fentiek alapján az az elképzelésem, hogy a zongora hangzása egy bika erős és gyors sz.gép birtokában valamiféle brute force-szal, a különböző kombinációs tényezők állapota szerinti (pl. zongora fedele fel van nyitva v. sem, pedál állások) rögzített hangminták visszajátszásával reprodukálható lenne elég naivnak bizonyult. A dolog végtelenül bonyolultabb - stílszerűen szólva elég komplikált üzleti logikát kell megvalósítani! Szerencsére a LS szkriptelhető direkt ilyen célokból - NKSP-nek hívják a szkript nyelvet. Igazából az iparági kvázi szabványnak számító Kontakt -nak van egy KSP nevű szkript nyelve, így nyilvánvalóan közelítőleg azt próbálják az LS-be implementálni.  Többek közt ez az a funkcionalitás amivel a LS kiemelkedik a többi sampler közül. De hiányoznak tutoriálok meg a szájbarágós magyarázatok. Számomra kicsit nehéz felvenni a fonalat. 

Még egy dolog eszembe jutott ami érdekes lehet. Ugye ma már természetes dolog, hogy zene az sztereo. Nem is tudnánk elképzelni, hogy mono is lehet, ami akár jobban szólhat mint a sztereo változat. (Az akusztikus zongora olyan nagy méretű hangszer, hogy a zongorista szemszögéből vizsgálva a magasabb hangokat jobbról, míg mélyeket inkább balról halljuk.)
Vegyük a fejhallgató esetét! A használatakor a bal és jobb csatornák közvetlenül a fülünkbe jutnak és hát képletesen, meg ténylegesen is az agyunkban összegződnek és a fejhallgató hangszórói által keltett hanghullámok nincsenek kihatással egymásra. Ezzel szemben amikor hangfalról hallgatjuk a sztereo zenét akkor a két oldalról jövő hanghullámok keresztezik egymást mielőtt elérnék a fülünket! Ezen kereszteződés során a hanghullámok attól függően,h milyen fázisban találkoznak erősíthetik ill. kiolthatják egymást, ami totálisan összezavarja a hangképet. Ez a jelenség a digitális és virtuális zongoráknál nagyon érződik. Monora átváltva egyből kitisztul a hangzás. Ég és föld a kettő. És olvastam, hogy még olyan nagy márkáknál is mint a Yamaha is tapasztaltak ilyet - nem éppen lowend szegmensben.  Ha nincsenek fázis-igazítva a hangminták akkor jobb monora váltani. 

Na most csak ennyi :-) Majd alkalom adtán írok még: pl. velocity görbék szerkeszthetőségéről,alkalmazásukról. A hangossági értékek manipulálásáról, mididingsről. 

Hozzászólások

Szerkesztve: 2021. 10. 21., cs – 08:49

A késleltetés témájához: jó esetben egy virtuális hangszer hard real time rendszerként működik. Ez azt jelenti, hogy ha egy t0 időpillanatban jön egy billentyű lenyomás esemény, akkor mindig pontosan ugyanannyi késleltetéssel szólal meg például t0+5ms időpillanatban a hang. Ez az 5ms ha már elindult a hangszer, akkor nem változhat és nem is változik.

Miből adódik össze a késleltetés?

 * Input késleltetése - RT kernel használatával lehet a legrövidebbre venni például.

 * Feldolgozás késleltetése - 1 puffer hosszától függ

 * kimeneti puffer késleltetése - 1 puffer hosszától függ, és attól, hogy hány puffer van előre bekészítve.

Látható, hogy ebben nincsen benne, hogy mennyi ideig tart a minták betöltése. Mert azt előre bekesseli egy ilyen rendszer - legalább az elejét, és a többit akkor tölti, amikor kell. Nem lesz kisebb a latency attól, ha gyorsabb a diszk. Ellenben ha lassabb akkor előfordulhat, hogy recseg, ha nem bírja adattal ellátni a szintetizátort a diszk. Másképpen a sebesség egy fix beállítás, aztán vagy bírja a vas, vagy nem. De ha gyorsabb a vas, attól nem lesz gyorsabb a lejátszás, ha a paramétereket nem állítjuk hozzá.

Tipikus megoldás, hogy 2 puffer van, amit éppen játszik a gép, és amit éppen előkészít. Az éppen előkészítés alatt lévő puffert akkor lehet elkezdeni tölteni, amikor a másikat elkezdi lejátszani, és legkésőbb akkor kell befejezni, amikor már ezt kell játszani. Tipikus megvalósításban ebben a körben kezeljük az inputot is, amint lehetséges (elvben lehetne úgy optimalizálni, hogy az időszelet legvégén kezeljük az inputot amennyire későn csak lehetséges...). Gondold el, az input a feldolgozás elejéig kell, hogy beérkezzen ahhoz, hogy a következő periódus végére hathasson, tehát ha 1ms a puffer hossza, akkor az 2ms szisztematikus késést jelent.

1ms körüli puffert szokás alkalmazni, de ez a pufferméret állítható, ezt kell a lehető legrövidebbre venni ahhoz, hogy kicsi legyen a latency. Ezt a beállítást nézted már? 1ms az ugye 44 minta, elvben 1-2 mintáig le lehetne nyomni ezt a puffert, az alá viszont nem.

Ugye a jelenlegi felállásban adott a hang keretrendszer - ami a zongi esetében a Jack - és annak a beállítási opciói amik elérhetőek számomra. Ez lényegében három dolgot jelent 1.)a mintavételi frekvenciát 48kHz, 2.)egy puffer méretet 64, és 3.) egy un. period értéket 2.  Ezek határozzák meg a Jack által kijelzett latency értéket ami asszem most 2.4 ms lehet. Ami extrán kicsi  értéknek tűnik, de hiába mert érzetre nagyon is van különbség a cél hardware (digitális zongora) és a PC-s virtuális zongora között játékélményben az eltérő késleltetés miatt. Ez a kijelzett 2.4 ms  csak valami rész érték lehet. 

Ubuntu Studioban nincs realtime kernel, helyette un. low latency kernel van. Van egy szkript ami lecsekkolja a latency szempontjából kritikus beállításokat: https://github.com/raboof/realtimeconfigquickscan

Ezekkel a beállításokkal nagyjából stabilnak tekinthető a rendszer, de pl az egyik tesztem a glissando, amikor a kezemet gyorsan végighúzom az egész billentyűzeten és közben a zengető pedált lenyomva tartom (ilyenkor tovább szólnak a hangok) ettől persze kifekszik rendszer és elkezd XRUN-okat dobálni. Vagy egy másik ilyen teszt, hogy szintén lenyomott pedál mellett egy oktáv különbséggel "pörgetek két hangot" (tremolo) - ilyenkor is felszalad az egyszerre szóló hangok száma - de azt nagyjából bírja egészen addig míg a pedált fel nem engedem. Akkor rögtön megjelenik vagy tucat XRUN.  Ez még megfejtésre vár számomra, h mi is történik itt pontosan. Valószínűleg az lehet a dolog mögött, hogy a billentyű felengedés esemény NOTEOFF nem csak lekeveri az aktuálisan szóló hangot a definiált burkoló görbe szerinti lecsengéssel, hanem le is játszik egy rövidebb (release) hangot, amit az akusztikus zongorán a damper a húrra való visszatérése vált ki. És a pedál felengedése triggereli ezt az eseményt, ami vázolt tremolo-s esetben sok - egyébként ugyanazon hang - release hangjának az azonnali lejátszását eredményezi, és ezt persze nem bírja teljesíteni és akkor jönnek az XRUN-ok. Amúgy a hangzásban nem venni észre a dolgot. Nyilván ez egy hibás működés következmény lehet - kicsit meglepő is h ezt nem kezeli le LS. De lehet h tévedek ezzel kapcsolatban. Még ki kell debuggolni! 

Természetesen a LS beállításai is erős kihatással vannak az alkalmazható latencyre. Ráadásul ezeket fordítási opcióként lehet megadni: ilyenek pl  preload sample értéke - azaz h egy hangból mekkora részt töltsön a memóriába az induláskor. Nyilván egy gyors disk rendszer esetében, mint az M.2 PCIe SSD nagyobb a mozgástér kevesebb memória elég neki ill. több hangot tud összeségében kezelni. Ennek akkor van jelentősége, h elkezdjük növelni a felvett hangminták számát a kölünböző kombinációs tényezők szerint. Korábban volt ~16 GB -nyi hangmintám lenyomott zengető pedál esetén, meg volt  még egyszer ennyi felengedett pedál esetén. Most hozzá jött az h ennek a pedálnak a "fél" állásában is lett 16 GB -nyi felvétel. És akkor még vannak egyéb hangok is pl. a release hangok, vagy a mechanika hangjai. Minél több hang van, annál több hangnak kell preloadjait betölteni az induláskor. És ezért kell a minél gyorsabb disk rendszer, h a preload mértékét alacsonyan lehessen tartani a szűkös memóriára való tekintettel.  De ugyan így fordítási opció a max polifónia azaz az egszsrre szoló hangok száma, vagy max disk streamek száma, vagy a subfragment size. Ezek kihatással lesznek a latencyre. 

Még az is eszembe jutott, hogy ha egy PC-ben ennyire problémás ez a buffer-kérdés/ütemezés/késleltetés hát akkor több PC -t fogok használni.Veszek vagy 4 db régebbi PC-t ami viszonylag olcsón beszerezhető és elosztom köztük a feladatokat. Mindegyik kap mondjuk két oktávot és azon hangokért felel, párhuzamosan dolgozhatnak az outputot meg egy olcsóbb mixerben összekeverem. Nyilván a négy házat el kell tudni helyezni úgy hogy ne zúgjanak; meg kell oldani a beállítások menedzselését; illetve hát csengetni kell utánuk a villanyszámlát is. Továbbá kell hozzájuk egy-egy hangkártya is. Ami így nyilvánvalóan az olcsóbb kategóriákból beszerzendő. 16 Bit-es 44.1 KHz -es lowlatency kártya van olcsón szerencsére. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Én azért megpróbálnám a 64 mintát és a 2-es periódust is lejjebb vinni. (Feltéve, hogy jól értem, akkor a period lehet 1 is, a minták száma pedig 32, vagy 16 is.) Ez adja az inherens késleltetést. Ez rendszer szintű konfiguráció, és ki lehet próbálgatni, hogy meddig lehet levinni úgy, hogy még működőképes legyen.

Az a lényeg, hogy real time rendszer esetén ameddig nincsen underrun (tehát azon eseteket kivéve, amiket leírtál), addig a késleltetés nem függ semminek a teljesítményétől, csak a beállításoktól. Tehát ha csökkenteni akarod, akkor azokon kell javítani. Mind a MIDI input, mint a Jack kimenet oldalon amennyire lehetséges.

 

Szerk.: Mi ez az LS program? Van rá linked? Szabad szoftver?

Persze ezeket már rég kipróbáltam. 64 sample buffer ami jó. Ha lejjebb veszem 32 -re akkor instabil lesz, egyezik a tapasztalatom azzal, amit @turul16 ír lentebb. A periodot nem lehet lejjebb vinni asszem. Régebben próbálkoztam ezek variálásával és most nem emlékszem már mi hol zavar be. De kihatással vannak a beállítások az LS (Linuxsampler) opcióira is. Tehát ha el is indul 1-es perioddal maga a Jack, még simán lehet h az LS nem indul. 

>Mi ez az LS program? Van rá linked? Szabad szoftver?

Nyilt forrású (de nem teljesen szabad). Ez az oldala: http://linuxsampler.org Én SFZ formátumot használok. Van neki saját formátuma is a GIG, meg támogatja a sound fontokat is. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Ha adnál neki egy rendes címet, még címlapra való előléptetés is lehetne.

trey @ gépház

Szerkesztve: 2021. 10. 21., cs – 10:55

Ha latancy-t tenyleg hallod, akkor lehet hogy nem 5ms rol van szo hanem 20ms -rol es nem ott van a latancy ahol keresed.
https://mikelococo.com/2017/09/usb-audio-latency/

Ahogy fentebb is irtak buffer meret szamit:
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance#pl…
Sok helyen van buffer egy szamitogepben, addig veheted le oket amig nem kezd el recsegni/akadozni,
alapvetoen alaplapi, vagy pci/pcie kartyaknal alacsonyabb kesleltetes varhato, hallottam USB nagy kesleltetesekrol, de
ez nem azt jelenti hogy nem lehet 1ms -re meni USB -vel. (Az egerem es billentyuzetem is 1ms korul megy)
https://wiki.archlinux.org/title/PipeWire#High_latency_with_USB_DACs_(e…

Ha birod CPU- val (egy core) elvben le lehet meni 1ms ala is, de nem erdemes,
regi idokben DAC bementere kozvetlenul tehettel jelet DMA nelkul..

BTW, mi van meg latancy testre ?
https://wiki.linuxaudio.org/wiki/jack_latency_tests

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Looback cabel nelkul monitor interfacerol:

Nem igazi jack, pipewire/alsa.
port nevek a 'jack_lsp -p'

$ ./jack_delay -I 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958) Monitor:monitor_FL' -O 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958):playback_FL'
       1024.011 frames   21.334 ms
       1024.000 frames   21.333 ms
       1024.000 frames   21.333 ms
$ PIPEWIRE_LATENCY=256/48000 ./jack_delay -I 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958) Monitor:monitor_FL' -O 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958):playback_FL'
        256.007 frames    5.333 ms
        256.000 frames    5.333 ms
        256.000 frames    5.333 ms
$ PIPEWIRE_LATENCY=32/48000 ./jack_delay -I 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958) Monitor:monitor_FL' -O 'Starship/Matisse HD Audio Controller Digital Stereo (IEC958):playback_FL'
         32.001 frames    0.667 ms
         32.000 frames    0.667 ms

Valamiert nem listazza line-int vagy micet ..

A Makefile LDLIBS sora kapott egy -L/usr/lib64/pipewire-0.3/jack -et.

/me atirtam a sajat letency defaultjaimat 256/48000 az /etc/pipewire/[jack,client].conf -ban, egy kicsivel jobb latency talan jatek kozben is jol jon ;-) Ha mar a kep 165/240Hz - jon.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Profilt kellett valtani es mar latja line int.
5ms korul mozog a latency jack par ms -el jobb ugyan azon buffer meretnel, de 32/48000 instabil, 32/48000 korul az alsa jack kozeli.
Ez ket irany, ki es be egy 3.5mm kabelen.

Az USB-s fulesem 100ms korul mozok. Eleg aggreszive audio feldolgozast vegez, remelem csak microfonon..

pipewire RT nelkul fut, user daemonkent.

5ms loopback IMHO nem rosz, ~2.5ms ket irnayba, 2x3 puffereles.

Egy igazi zongora, ha 1m -re kelti hangot az ~3ms delay hangforrastol a fulig.
Az ember lenyomas erzete az idegeken lassabban halad.
A zeneben 200bpm tempo gyorsnak szamit, ami 0.3 leutes per second. Az ember egy gomb lenyomasat, ha csak arra fokuszal 0.1s  alatt tudja megismetelni (legalabbis en),
~ 300ms leutesi kozeknel ~50ms pontosag nem rosz, lehet hogy meg fulesem sem veszes 2x50ms -evel, ne de akkor is, azt hiszem merek meg egy par dolgot vele kapcsolatban, pl buta microfon + usb-fules kombot.
A fules kimentet szeretnem 25 ms alatt tudni.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hátő... Fogalmam sincs, ki kellene számolni. Gitárnál például vannak ilyenek, hogy csak egy ujjal megérintik a húrt, és az már szól is. Ha ilyen módon leteszed az ujjaidat sorban, abból nagyon rövid hangok lesznek.

Tapping a neve, itt van egy ikonikus példa, de szerintem ez még nem a leggyorsabb: https://www.youtube.com/watch?v=L9r-NxuYszg&t=206s  (Van Halen Eruption Guitar Solo) Ha akarod mérd meg mennyi idő van két hang között. Nyilván kották alapján ki is lehet számolni, egy csomó szóló le van kottázva, de most nincs kedvem.

Szerk.: ezt is nézzétek meg, türelmetleneknek a timestamptől, türelmeseknek az elejétől: https://www.youtube.com/watch?v=BynUZOJc8QI&t=458s (320 BPM - OFFICIAL WORLD RECORD GUITAR SPEED 2008 - Guinness World Records)

És azt kell még érteni, hogy az hogy egyszerre szóljon minden, az egy zenésznek nagyon fontos, ezt gyakorolják évekig :-) simán zavaróak ezek a pár milliszekundumok, a zenészek hallják és főleg érzik.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4456887/  Reakcio ido az embernek nem tul jo (~220ms), de erdekes modon az audo erzek szerv to brain delay csak 8~10ms , mig  a vizualis 20~40ms.
A fentebbi irasban valaki azt irta 25ms delayt eszre vesz a zeneben. Nem tudom mit lehet tenyleg eszre venni, szerintem <3ms delayt valoszinutlen.

https://www.highfidelity.com/backlog/how-much-latency-can-live-musician…
"By changing roles and trying various instruments, we were able to learn that much below about 10 milliseconds of one-way delay, they typically could not discern the impairment, but that by about 20 milliseconds they would uniformly report the experience as highly undesirable."
Mas forrasok  10~20 ms koze tettek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egy idegen szituban nem valószínű h pár ms különbség érzékelhető. De egy jazz zongorista aki hozzá van szokva a Nord digitális zongora 0.6-0.8 ms késleltetéséhez mert azon gyakorol illetve koncertezik napi 8+ órában leül egy olyan zongora elé ahol 5 ms ez az érték, hát annak ég és föld lesz a kettő. 

Most különböző szoftverek kijelzik a latency értéket, amiről nem lehet tudni h pontosan mit jelentenek, helyesek-e illetve releváns adatot mutatnak-e mindez megterhelve gyakorlatlanok szubjektivitásával, nem csoda ha net-szerte olvasható mindenféle megállapítás ezzel kapcsolatban. A magam részéről érzem a különbséget sz.gép és a digitális zongorám között. Mondjuk hónapokig csak sz.gépet használom, és akkor jön egy ingerenciám a másikra, és rá szoktam csodálkozni h az mennyivel direktebb.  Persze nem féltétlenül ugyan az hang szól a kettőn, bár megvan szgépen az ominózus zongora hangja is, és pl ha más a hang felfutása (attack) az is elég eltérő élményt tud jelenteni. Az egyik estben mondjuk 2ms a másiknál 6ms a felfutás, hát azért az érzékelhető eltérés lesz a megszokotthoz képest.  Tulképp az akusztikus zongorának is van késleltetése, hisz az egy mechanikai szerkezetet mozgat - és mondjuk klasszikus zenében nem is igénylik annyira a direktséget, mint egy jazz zongorista. Hogy annak van egy ilyen méltóságteljesebb késése, ami megszokott. Egyszer olvastam erről valahol. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

"Nord digitális zongora 0.6-0.8 ms" A zongora lehet kiteszi jelet ennyi ido alatt egy analog kimentre, de ha mondjuk speakereket teszel ra es ~1m -re ulsz tole az 3ms kesleletetes egy analog fuleshez kepest.
Analog fules es analog speaker kozott hallod -e latancy kulombseget ?
A jel gyorsabban halad a kabelen, mint a levegoben.
Analog nem bufferel, nincs digitalis szuro/jelfeldolgozas. digitalis is lehet gyors, ha nem csinal orultseget kozben.

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance#mi…
A midi latancy eleg veszesnek tunik, ez is loopback test tehat be es kimenet egyszerre.
Average latency: 22.53 ms (1081.35 frames)

Ha az tenyleg midi loopback latancy (3 byte data) es nem valami mast irtak oda akkor ott baj lehet.

https://hup.hu/node/165412 1ms billentyuk elott ~25ms -em volt (typikus),  nem igazan erzed a kulombseget, de elvileg hagyanyi elonyt jelent ha
emberek ellen jatszol. Mintha hamarabb mozdulna karakter, de fene se tudja hogy blind testben is azt mondnam -e.
A merest eger es billentyuzet gombja helyezett targyra ejtett dolog ido kulombsebol vettem,
igy egyszerre megnyomva, tehat csak azt tudom, hogy a gamer eger jelehez kepest menyi volt ill lett a latency.

 

Rendeltem egy midi<->usb -t kinabol, szeretnem magam latni azt a loopback testet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

https://jamkazam.freshdesk.com/support/solutions/articles/66000122530-s…
verified that the audio processing latency for your Behringer UMC204HD with these settings is actually 8 milliseconds. 

Nem tiszta hogy az software meg hardvare vagy csak hardver latency.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

USB-fules  alaplpai microfon lemegy 40ms . alaplapi bemenet ~2.5ms kesleletetet (software oldal included).
7.1->2.0 converzio kikapcsolasa nem valtoztatott.
Azt hiszem nezek masik USB-s valamit, ha megtalalalom, utana USB tuning opciokat.

szerk:
Nincs meg a masik USB audio-m, de nem csak nekem nem akkar low latancy-t az USB-s resz:
https://www.reddit.com/r/HyperX/comments/kag0nd/audio_latency/
Gyanitom hogy egy kicsit tul toltak szurest meg ilyesmit a kulso reszen.
Attol tartok a megoldas:
https://www.ebay.com/itm/393160969727?hash=item5b8a384dff:g:OWQAAOSwLIh…

Keses "gyanus" volt  jatekban, csak nem gondoltam volna hogy a fules az oka, ha tenyleg van.

szerk:
Egyesek szerint 100ms latency sem baj egy jateknal:
https://gamedev.stackexchange.com/questions/74973/maximum-audio-delay-b…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

https://twitter.com/tarik/status/1316308737657888768

Pro gamer nem vette eszre hogy 100ms -et kesik csak jatek bealitasa miatt a hang.
cs:go uj default 25ms, regen 50ms volt.
Ha kernelt forditok sok-sok szalon nem realtime thread ehezhet 22ms-et,
egyebkent siman tudok ~2ms -es buffert tolteni, 8ms nem real-time max ehezes ha csak ht-thread szamig terhelem a gepet.

Lehet tul reagalom a fules keslelteteset.
Mint device ~10ms buffert javasol , amibol egy-kettot illene  tartani a device oldalan.

Ha mindent feltornaznik hang oldalon, akkor lehet hogy nehany jatekban hang elobb jonne mint a kep ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

rollback cs:go nem szereti az uj hang configokat, desync/lag . A hang jo, de jatek ugy megy mintha 200 as pingem lenne csomag vesztessel,
es valoszinu hogy a configgal fuggott ossze.

update:
valami mas nem klapol, nem az audio bealitas a ludas,
lehet hogy egyes random szervereket nem szeret, lehet az ISP-m csinal valami furcsat.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az elején szépen leírtad a zongorahang-minták rögzítésének a problémáit. Elméletileg érdekes, bár nem tudom, számunkra milyen gyakorlati haszna van ezen ismereteknek.

Itt van egy újabb szempont: a zongora általában valamilyen zárt térben szólal meg. Ennek a térnek lehet tucatnyi típusa (jazzklub, lakószoba, kamaraterem, koncertterem, mindez egyenként is különféle akusztikával). Fel lehet venni egy zongora hangját süketszobában, és aztán utólag alávetni a virtuális tér-szimulációnak, léteznek erre is VST-k, meg méregdrága komplett szoftvertermékek.

Azt h mások számára milyen gyakorlati haszna lenne az itt foglaltaknak azt nem tudom,  talán ezt mindenki magában eldönti! Nekem olyan szempontból érdekes ez a téma, hogy mennyiben vethető fel érvényesen PC-s virtuális zongora kvázi hangszerként?  Aki némileg érdeklődik a téma iránt, az nem mehet el vélemény nélkül amellett, hogy igen komoly és nagy volumenű fejlesztések történnek a virtuális hangszerek terén lásd pl: https://www.vsl.co.at/en - akik hát mondjuk úgy költőien, h "nem szarral gurítanak" :-) vagy mondjuk a Kawai híres japán zongoragyártó cég olyan midi billentyűzetet gyárt a sz.gépes zenéléshez, aminek mechanikája egy valódi koncertzongoráéhoz hasonlítható - és ezzel egyedül álló a piacon: https://www.thomann.de/hu/kawai_vpc1.htm . Miközben komoly komolyzenészek részéről fel sem merül, hogy az akusztikus hangszeren kívül másnak is lenne létjogosultsága. Hogy az Ukrajnában gyártott 50 éves pianinonak is lelke van, míg a digitális és sz.gépes zongoráknak ilyenjük természetesen nincs, így ezeken az előadó valójában nem is tudja kifejezni magát. Valentína Lisitsatól is olvastam ezt, amikor valaki tanácsot kért és a tőle megszokott kedvességgel próbálta az illetőt terelgetni az akusztikus hangszer irányába, de hozzá tette, hogy egyszer játszott egy Yamaha digitális zongorán és azt elég jónak találta. Ebben nincs semmi marketing rizsa, neki nincs szerződése a Yamaha céggel, a Bösendorferrel volt akkoriban ilyen kapcsolatban. Na most ez egy extrán drága digitális koncert zongora, de kompaktabb és bútorszerű kistestvérei elérhetőbb, de még mindig magas áron beszerezhetők a bérből és fizetésből élők számára is. Azonban a nagy veszély a dologban, h ha abban elromlik valami, akkor a hiba feltárása és annak szakszerű javítása hááát...nem is tudom, h miként kivitelezhető.  Nekem is egy ilyen hangszerem van, és fogalmam sincs milyen számot kéne felhívnom ha baj lenne vele. Ezért az a koncepció, hogy ne egy kompakt és drága hangszert vegyünk, hanem legyen külön billentyűzet, külön pc ami előállítja  a hangzást, külön hangkártya, külön hangfalak olyan szempontból előnyösebb, h ha bármivel gond lenne, hát legfeljebb csak annak az árát bukja az ember, nem a teljes kompakt hangszerét. Ráadásul akinek van műszaki érdeklődése az ezzel való foglalatosság és az ilyen rendszer által biztosított variabilitási lehetőségek sajátos örömet okozhatnak. Kergetve van a tökéletes zongora hangzás ideája és közben egy csomó minden ismeret rárakódik az emberre. Hát talán ez lehet a "gyakorlati haszon". Nem tudom, h ez Neked jelent-e valamit?

Egy studio természetesen úgy van kialakítva, hogy ott nem kívánt visszhangzás ne jelentkezzen. Az ilyen akusztika kialakítása egy studióban -amennyire tudom- talán az egyik legnagyobb tétel költség. Sokba kerül nagyon! Vannak basszus csapdák, egyéb akusztikai elemek amiknek kiválasztása, méretezése, pozicionálása az adott helység sajátosságainak figyelembe vételével illetve kívánt hatás elérése érdekében nagy precizitást és szakértelmet igényel. Másfelől meg vannak legendás studiók pl. Abbey Road amiknek akusztikai sajátosságai az ott rögzített felvételek számára hozzáadott értékként akceptálandó. 

A studiokban kevésbe szoftveres megoldásokat, inkább célhardvereket un. effekt-processzorokat használnak. Ezek szintén nagyon drága dolgok. Pl Lexicon a reverb-ek kapcsán elég ismert gyártó. Természetesen vannak szoftveres megoldások is. Én is használok szoftveres megoldást, mostanában convolution reverb-et. Ez egy olyan program aminek egy wav fájlt kell megadni, ami wav fájl által megjelenített hang egy adott helyiség akusztikai jellemzőit tartalmazza a visszhangzás vonatkozásában. És a program (pl. jconvolver) ezen wav fájl alapján teszi hozza a visszhangot a zongora hangjához.  De nem csak helyiségek tekintetében, hanem egy sörösdoboz, vagy gitártest vagy épp egy zongora kulisszája alapján is előállítható ez a wav fájl. És nekem van is ilyenem, ami egy a zongora testében keletkező visszhangzást tárolja. Ez alapján képzett "visszhang" a zongora hangát élőbbé dinamikusabbá tudja tenni - tehát ez esetben nem a helység hanem a zongora testének akusztikájáról van szó. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

További gyakorlati ismertető: a nyitóban kitértem arra a problémára, hogy a felvett hang egyben tartalmazza a mechanika és a húr rezgésének hangját. Ez nem csak akkor jelent gondot a ha a felvett hangot akarnánk transzponálni más erősségű leütésre v. más billentyűhöz tartozó hangra. Van egy hangforrásunk, de amin lejátsszuk ezt a hangforrást legyen hangfal, v. fejhallgató kisebb nagyobb mértékben módosít a hangzáson. Emiatt szinte mindig szükséges belenyúlni a hangzásba EQ-val. Na most itt is ugyan az a probléma! Akarsz egy kicsit erőteljesebb közép-magas hangzást a húrnak és 3400 Hz körül emelsz 1-2 dB -t, az el fogja vinni a mechanikának is a hangját, h az zavaró lesz a hang elején.  
Egyenlőre csak azt a megoldást látom erre h külön kell venni a hang elejét a többi részéről és külön kell EQ-zni a részeket. Ehhez nem kell feldarabolni több részre a hangot. Csak úgy kell megírni az SFZ fájlt, hogy játssza le x.wav 0-0.02 sec es azt küldje ki az 1 csatornán; majd játssza le 0.02-től és ezt küldje ki a 2 csatornán, és akkor a 2-es csatornára rárakhatom az EQ- mert így ez elejét nem fogja bántani a hangnak. Ezen dolgozom most. 
Ha feldarabolnának a hangot, akkor az további problémákat vethetne fel. Akkor az a linuxsampler szempontjából több fájlnak és hangnak minősülne és befolyásolná azokat a beállításokat amik a polifóniára ill. a hangok preloadjára és lemezkezelésre (disk stream) vonatkoznak. 
Valójában nem időpontokat kell neki megadni, hanem sample számokat. És úgy lehet egy hangfájlon belül meghatározni a lejátszandó részt. 

Viszont így az ADSR envelope integritása sérül. Hm...lehet mégsem lesz így jó!

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

"Ugye ennek a kártyának csak szimmetrikus ki/bemenete van" - mert pont nem ilyen célra készült elsődlegesen, amire te használod. Egyébként meg lehet szimmetrikus bementet "hajtani" asszimetrikus kimenetről is - kell egy szimmetrizáló trafó, célszerűen minél közelebb a jelforráshoz, hogy a zajérzékeny szakasz minél rövidebb legyen.

> mert pont nem ilyen célra készült elsődlegesen, amire te használod

Mán h nem hangkártyának készült?  ;-D

Amúgy alapvetően fejhallgatóval van használva. Az elképzelés az h lesznek majd un. near field studio monitor hangfalak is. És azokhoz lett véve előrelátóan. Most a zongora erősítője és hangszórói vannak használva, abba van bedugva - van rajta vonal szintű asszimetrikus bemenet (+ még van egy sztereo a kis-jack -es bemenete is a zonginak).  Így is jól szó (ez nem ilyen gagyi műanyag vacak) - egyenlőre le is tettem a hangfalakról ezért. 

Inkább visszafele lenne a gond, ha a zongi hangját akarnám ezen a kártyán keresztül felvenni a sz.gépre. Akkor az asszimtertikus jel menne a szimetrikus bemenetre. Ez az eset amit írsz. De a zongi hangját nem akarom így felvenni - mivel erre van saját beépített megoldása és egy usb-s pendrivera fel tud venni. 
Anno amikor csináltam az első virtuális zongimat (lassan egy éve) akkor is így rögzítettem a zongi hangját. Hogy ne legyen DA majd AD konvertálás. Szépen meghajtottam midin keresztül a sz.gépről az összes billentyűhöz tartozó hangot 16 különböző erősséggel a zongi meg rögzitette 16-bit 44,1 kHz wav -okba a rá dugott pendrívera. És akkor ezekből lett a sz.gépen egy virtuális hangszer ami úgy szólt mint az eredeti digitális zongi. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Valóban, ránézésre van hasonló. Annyiban más ez, hogy a tényleges érintési felület jelenleg nem a teljes háromszög, hanem a linkelt kép szerinti kisebb hatszög, hogy a szélen csúsztatva diatonikus glissandót is lehessen játszani, ill. kvartra, kvintre is lehessen csúsztatni. (Ez átállítható, a Trianagle class konstruktorában a this.shape = 'hexagon' helyett circle-t vagy triangle-t írva.)

Más az is, hogy minden sorban hat lépéssel eltolva ismétlődő hangok vannak. 

Persze külső keyboard esetén ez a rész nem csinál semmit, csak a player rész szól mint bármelyik midi hangszer.

https://diyaudio.barjak.eu/pictures/hup/b-k-circle+hexagon.jpg

Szerkesztve: 2021. 10. 23., szo – 09:55

Utananezegtve hang latecy temanak.

~3ms
 - Zero latency-nek reklemozott audio eszkozok
 - az enekes kepes eszlelni sajat hangjan >3ms
 - Nintendo Jatek oldali buffer size, valoszinuleg ertelmetlen ala menni
 - 50Hz digitalis low pass filter latency
 - hangdeamonon keresztul alaplapi hang kartya latency egy iranyban
~ 5ms
  - ket hangesemeny kozott ido kulombseget kepzett ember hallhatja
     Ha egy zongorista egy billentyujet 5ms latency -re teszuk ki szurhatja
  - alaplapi hang kartya hang deamonon keresztuli ki/be latency osszege relative kis bufferrel
~ 10ms hangszeres zenesz kepes eszre venni ha minden kesik ujabb 10ms -el
    Nem hinem hogy tapintas alapjan kiszurhato, de ha hallja is hogy meg birizgalta hangszert akkor volszinu
~ 20 ms zenesz zavaronak is talaja az eszlelet kesleltetest
~ 25 ms az emberek 90% -a kepes felisrmerni ekkora elterest ket kozlli hang esemeny tavolsaga kozott (hangjegy elmozditasa)
>100 ms a hang kesese kephez kepest ha csak nezzuk az esemenyeket (egyesek szerint 50ms, ha jatszuk)
>200 ms zavaro hang keses nezokent (kortol fuggoen nagyobb is lehet)

Ugy latszik az ember hozza szokott ahhoz, hogy amit ~30m -re latt (~100ms hang keses), ahhoz hozza tartozik a hangja.

IMHO tapintas -bol eredo eszleles es latasbol eredo eszleles kozott a tapintas kivan gyorsabb hang valaszt. (fajdalom gyorsabb mint a tapintas)

Ha jol emlekszem vannak olyan hang kartyak amik a kulso bementet kepesek rogton kimenetre tenni szoftware segitseg nelkul,
ez akkor lehet jo ha monitornak akkarja valaki hasznalni.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Vannak mechanikus orgonák ahol jelentősen nagyobb a késleltetés, az orgonisták hozzá vannak szokva, plusz még egy templom utánzengési ideje is hozzá jöhet ami nem hallgat el egy pedál felengedésére. Gyakorlatilag sosem azt hallják egy ilyen hangszernél amit éppen játszanak.

Ami meg meglepo volt hogy egy zenesz 25ms loopback letencyt hasznalt (nem teljes rendszer latancy, csak a zene progri beallitasa),
es csinalt egy videot amiben lejebb veszi mert az elozo videoban komentellok szerint
nem jok a beallitasai, nem hallas alapjan persze.

https://www.pnas.org/content/111/36/12974
"even a trained musician will hit a drum beat slightly ahead or behind the metronome (with a SD of typically 5–15 ms"
Ez kb az az elteres amit training utan hallhat az ember.
Latszolag utemre syncronizalodasban jok az emberek, szinronizalsakor az embernek sok mindenre szabajoznak.
Ha megszokott hangszer helyett egy nagyobb/kisebb latency-s jon, akkor lehet hogy szokni kell, const keseshez
lehet alkalmozkodni egy szintig.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Linux pipewire felveszi versenyt MaS oprendszerekkel, erdekes modon Apple vs MS  -nel MS jon ki gyoztesen (specialis driver /bealitasdok).
pulseaudio nagyon nem volt jo, velhetoleg ezert lett linuxnak rosz hire latency korokben, jack nem volt rosz, de nem minden ment vele,
ugyhogy valasztani kellett.
pipewire elvileg veri a jack -et, ill. jack/pulse replacement.
pipewire tipikusan user sessionben fut, rtkit -en keresztul lehet prioritast novelni, ha user  daemon akkor csak egy felhasznalonak van hangja.

pipewire midi loopback test nem volt meggyozo (egy forras), azon meg tornazni kellhet.

Elvileg lehetne alacsonyabb a hang latancy mint amit bermelyik OS-nel lathatunk, de nem vagyok megyozodve rola,
hogy tenyleg erdemes akku ido rovasara lejebb menni, illetve hogy ott ahol latency baj van az OS vagy daemon buffereles a fo problema.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

alsa -n ebay midi usb loopback latency valaki 1.07ms avg -re merte, kicsi jitter (<0.1ms).
jack -en csak egy merest talaltam a neten, egy masik USB loopback latency ~5ms.

classikus midi billentyuzet scan jitter 1.26 ms, 5ms halott idok, vagyis nem hiszi el ha 5 ms nem rovidebb ideig van lenyomva vagy felengedve, szerializalas latency 0.832 ms (velocity) 3 byte note start/stop bit 31250 baund, vagyis ~2ms max keses.
"The pianist played the key B7 a staggering 824 times in 60 seconds – that's more than 13 hits a second"

Az usb midi atalakto loopback eseten nem mutata nagy jittert, de egy tenyleges eszkozrol erkezo jel akkar 1ms -et keshet (polling periodusok miatt, "full speed" eszkoz).
pcie midi portos eszkozok ara az egekben, lehet megeri egy pcie->pci atalakitoval egy regebbi kartyat hasznalani, mar ha valakit tenyleg erdekel a latency kulembseg.

snd-hda-intel documentacioja nem javasol 128 byte-nal kisebb adat atvitelet , ami 32 frames buffereket jelent (2x16 bit).
- device
- device next
- hang deamon
- alkalmazas
 4*0.66ms ~ 2.64 ms latency kifele. (sok midnet maskep csinalva lehetne kisebb)

Ha usb-s midi billenyuk van es feltetelezzuk maga az eszkoz max 1.3 ms -et kesik (min 0.3ms ).
Az 5ms max latency egyaltalan nem rosz ertek egy PC -s midi gepen foleg ha nem szegunk ajanlott minimum atviteli szabalyokat.

Latency of an Acoustic Piano accustikus pianot itt ~5ms kesesunek mondjak.
A kalapacs keses fugg a leutes erejotel/gyorsabbodol 1~5ms , mire zongiristahoz is eljut hang tobb ido is eltelhet <10ms.
A kalapacs sebbessege 1~6 m/s , tavolsag (blow distance) ~48mm, nekem mas jon ki, de nem biztos hogy almat hasonlitok almahoz a vegen.
model: https://www.instructables.com/Grand-piano-action-model/ , ugy latom van "szabadon repules" szakasza a kalapacs mozgasnak, legalabb azt  az idot lehetne latencynek tekinteny."
The free flight of the hammer ranges from almost zero at louder tones up to 20 ms at very soft keystrokes, with some outliers up to around 40 ms at the Yamaha piano"
https://www.researchgate.net/publication/7603558_Touch_and_temporal_beh…

Gyors leutes:
"
At such keystrokes, the key bottom times are between 3.5 and 0.5 ms before hammer- string contact, thus a range of the order of 3 ms. "

"At that typical dynamic range, key bottom times are even more unlikely to be perceived by the pianist separately
from the sound hammer-string, since those temporal differences are there of the order of a few milliseconds. However,
the differences between key bottom and hammer-string can be up to 40 ms in extreme cases which is of the order of or just beyond just noticeable differences for perceiving two
separate events
Askenfelt and Jansson, 1992b, p. 345."

"the changes in travel times due to varying intensity might not be directly relevant for the player since they are at the thresh-old of perceivability. "

hang kesleltetest midi -rol leginkabb ugy lehet merni, ha az ember egy microfont es egy kimenti speakert (microfonos fejhalgato) kozel tesz egy gombhoz,
es hangosan megnyomja mikozben rogziti a microfont, aztan siman megnezi a hangrogzito programban a ket esemeny idobeni elterest.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

https://books.google.cz/books?id=TZnnCAAAQBAJ&pg=PA70&lpg=PA70&dq=perce…

<3msec ket esemeny nem megulomboztetheto.
<10msec tapintas/vizulis esemeny nem megkulomboztetheto
3msec .. 30msec, ket hang esemeny megkulomboztetheto, de hallgato nem tudja melyik volt elobb.
>>30msec, esemenyek sorrendje megmondhato.

Hmm, lehet hogy a midi keses >10ms felismereseben megis van szerepe a tapintasnak.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Technikailag elerheto olyan latency egy PC -n (sokmindent maskep csinalva, de mondjuk perifiriakt vehetek/epithetek ha driver iras nem eleg) aminel softveresen kene kesest hozza adni, hogy az igazi hangszernek megfeljen.
Ha video/audio syncet akkarjuk nulara hozni, kereskedelemben nem kaphato olyan grafikai eszkoz, aminel nem szamithatunk >=4.3ms kep kesesre egy jatekbol. Nekem csak 6~13ms kene, hogy muszerek jonak talaljak,
egy nem gamer PC -nek 40~24ms is jo volna. Gamerek tuti nem finanszirozzak a projektet ;-)

Ha midinel akkarunk superb latency-t elszor is egy olyan billentyuzet kene ami elvileg tudja  a jo latency-s eszlelest es le tudja kommuniklani azt.
USB full speed nem eleg, high speedel tenylegesen <0.3ms elerheto volt, usb 3.0 -val <0.03 msec (ha tenyleg usb3 modban van).
midi 2.0 jon valamikor, nem feltetlen jelenti hogy epiteni is fognak ilyen billentyuzetet.

Hang mintak lejetszasa gomb nyomasra, ha csak keveres kell akkor muszerekkel nem igazan merheto keses is elerheto,
specialis hang kartya elvben keszitheto, ami OS -t megkerulve jatszik le a main memoriabol billentyuzetrol jovo jeleket (ha nagyon tul akkarunk loni a celon).

Hang szimulalas lehetne GPU -n csinalni ha mintazas nem eleg jo, lehetne hang visszaverodesket szamolni illetve lehet sympatikus rezonancit szimulalani.
Jelenleg a jatekok kepesek par anyagrol valo visza verodest ill. athaladast bele szamolni hangba.
A low pass filter csak azert kesett 3ms -mert megvarta meg egy kulso bementrol bejon n db jel, ha szimulalunk akkor nincs igazi input wait.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> hang kesleltetest midi -rol leginkabb ugy lehet merni, ha az ember egy microfont es egy kimenti speakert (microfonos fejhalgato) kozel tesz egy gombhoz,
es hangosan megnyomja mikozben rogziti a microfont, aztan siman megnezi a hangrogzito programban a ket esemeny idobeni elterest.

Ez elsőre jónak tűnik! Ki kell próbálnom! Telcsivel fogom felvenni a hangot  - nincs mikrofonom. A körmömmel fogom leütni a billentyűt h koppanjon, és utána jön hang. A kettő közti távolság a rendszer teljes késése beleértve a midit, hangot, mindent.  Jó lenne tudni a telcsi milyen formában rögzíti a hangot, de majd úgy is kiderül. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Az ember uj nagyon gyorsnak mondhato ha 13m/s -el megy, 18 mm es utazasa is lehet billenyunek (tipustol fugg).

midi velocity mereshez ket utazas kozbeni erzekeles kozotti idot meri a gomb mozgasnak (az ut egy szakasza, nem teljes gomb mozgas),
egy project a  ~2ms idot mar leghangosabb gombhoz rendeli 80ms -t a leghalkabbhoz.
A Nord hangszernel irtal 0.6-0.8ms input latencyt. A variacio osszefughet billentyuzet scan frekvenciaval, ill. az ido meres pontossagaval,
Egy masik bilentyuzetnel a scan idot 0.3ms -nek adtak meg, de a leiras alapjan ugy tunt, hogy nem megy folyamatosan, csak 1.26ms -onkent nez ra.

Ha gomb tetejen levo koponast mered konnyen lehet hogy >3ms -el tobbet mersz.
Az aljat lenne erdemes hangossa tenni ha nem az, mondjuk egy penz erme.
Ha ez nem megy akkor
ha valami hoszabb muanyag/fa darabbal ki tudod egyensulyozni gombot, hogy meg pont nem nyomja meg az erzekelot (<2mm) es egy fix magasagrol valamit rejteni az egyensulyozu palcara
az is jo lehet. Az ejtes valoszinuleg konyebben reprodukalhato, mint ugyan ugy megnyomni.

Es ne feled a hang levegoban lassu. ~3ms per meter.
(fem hur gyorsabb)
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Köszi, értem! Amúgy a jobb billentyűzetekben három érzékelő van már - az enyimben sajnos nem. Vagyis egy leütéshez három időérték tartozik. Ennek előnye a nagyobb felbontás és h így egyfajta karakterisztika is képződik a billentésről, ami felhasználható a hangzásban. Illetve a lenyomott billentyűt félig visszaengedve és ismét lenyomva újabb (sajátos) hangot lehet lejátszani. 
Megpróbálom majd kiegyensúlyozni valahogy! De ugye az alsó érzékelő holtpontját kéne eltalálnom, mert annak elérésekor megy a midi jel. De ez azzal jár, h velocity értéknek a legkisebb lrtlk fog megjelenni, mivel a felső érzékelőt már jóval korábban elhagyta billentyűzet a kiegyensúlyozás előtt. Szal így nagyon halk hang lesz csak, ha egyáltalán lesz - attól tartok! Bár sztem van olyan beállítás h fix velocity értéket adjon leütési erősségtől függetlenül - sose használtam, de most jól jöhet! 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Szerinetem kene olyan bealitasnak lenie hogy nem velocity erteket ad.
Ill -szokas nem lienaris gorbet is hasznalni a velocity ertekeken, gorbet csak max -ra tenni is jo.

Ill van olyan billenyuzet is ami erot (is) mer, pl. force sensing resistor-ral, talan ez az "aftertouch" .

Lehet elsore nem kell olyan pontosan, ha zavoronak talald konnyen lehet hogy 25ms felett vagy.
ill midi cuccoknak a halk hangokat lehet nem csak halkitani kene hanem idoben is eltolni, ha igazibb zongora erzet kell.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Fúú 0.06-0.08 sec közt van a köröm koppanástól a hang kezdetéig. 

http://i.imgur.com/eGxox9U.png

többet is csináltam. Ez itt 0.066 

Brutál soknak tűnik!

Ez nem volt kiegyensúlyozva - csak leötöttem a billentyűt

Valószínűleg valamit elrontok - pedig szög egyszerű a feladat - vagy a telcsi tréfál meg! 

De kipróbáltam úgy is, hogy a magát a digitális zongorát mértem, szal sz.gép nélkül - ugye ezt direktebbnek szoktam érezni. És igazolt is, hogy így 0.05 körül, de az alatt van az érték. Tehát ez a különbség amit érzek a kettő közt. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Az általam mért dolgot még picit emésztenem kell, mert nagyságrendileg nem stimmel. Ezred- és nem századmásodpercekre számítottam.  Nyilván valami hiba van mérésben, mert ezek extrém értékek lennének, amikkel nem lehetne zongorázni. Szal leginkább csak egymással hasonlíthatóak össze (már a digizongi meg sz.gép). A zongi egy tőkéletes gyári hangszer ami hibátlanul működik és ott is ez a nagyságrend. 1-2 századmásodperc eltérés van köztük. Ami nyilván érzékelhető, de már az is túl nagynak tűnik. Meg kéne nézni ugyan ezzel a módszerrel egy igazi zonginál is a késést! 

Tehát a jegyzőkönyv kedvvért: úgy vettem fel, hogy mobilon elindítottam a felvételt; odatartottam közel a billentyűzethez és hangszóró felé fordítottam; körömmel leütöttem egy billentyűt és lenyomva tartottam. Így a sz.gép-es zongora esetén 6-8;a digitális zongora esetén <5 századmásodperc volt a különbség a köröm koppanásától a hang kezdetéig. A mobil 44100Hz -es mono felvételt csinált. Ezt nyitottam meg a sz.gépen Ocenaudio nevű programban és az mutatta grafikusan a felvett hangot, és a két pont közti időeltérést. Utána csináltam olyan felvételeket is, hogy nem körömmel hanem ujjbeggyel ütöttem le a billentyűt h ne legyen koppanás. Direkt azért, nehogy valami mást véljek vizuálisan a köröm koppanásának, amikor grafikusan megjeleníti a hangot a sz.gép. Biztos, h a köröm koppanása volt az, amit annak gondoltam. 

A zongi billentyűzete olyan midi kábellel van összekötve a sz.géppel, aminek egyik fele DIN csatlakozós a másik USB. Van benne valami elektronika is. De mivel önmagában a digitális zongora is ugyan ezt nagyságrendet produkálta, így nyilvánvalóan nincs olyan hiba a kábellel v. a sz.géppel ami felelős lenne a kapott érték nagyságrendi eltéréséért. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Lehet meg kene probalni valami nagyon egyszeru beepego hangszerrel, lehet hogy zongora mod csinal valami furcsat, vagy szandekos kesest.

Ill . elvileg lehetne valami regi eszkozbol kiberhelt speakert tenni a midi adat vonalra ha szerencsed van csak akkor recseg amikor megnyomsz egy gombot,
ezzel lehetne meregeti .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azért ms-os nagyságrendű időkülönbséget már nem a "gyere cipó, hamm, bekaplak" dolog mérni... 10ms-os nagyságrendű időméréshez kell ms-os pontosságú mérési összeállítás (nem csak az órának kell ezt tudnia, hanem a teljes összeállítás valamennyi halmozódó késleltetése/hibája _összesen_ kell, hogy maximum ebbe a nagyságrendbe essen).

"A zongi billentyűzete olyan midi kábellel van összekötve a sz.géppel, aminek egyik fele DIN csatlakozós a másik USB. " - USB-MIDI átalakító kábel, ami egész jó késleltetésgenerátor :-) tud lenni (a MIDI-adatcsomag beérkezése a "dobozba" és az "adat megjelenik a szoftvered bemenetén" között) :-) bár ezt a direktben MIDI-bemenettel bíró hangkártyák is "tudják" - ott is döntően a drivertől függ, hogy a "beesik az adat" - "megszólal a hang" között mennyi idő telik el.

Manapsag egy hangfelvevo ~20 usec idokozonkent kb ~usec pontossagal (100..20ppm) minta vetelez, ha siman csak felveszed hangot,
nagyobb hiba jon abbol hogy hova teszi az ember a kezdetet es veget ..

Ja es persze a tavolsag hang forrastol szamit es kalkulalni kell vele.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Eleg valoszinutlen.
Az en egerem 4 ~ 5ms hangot csinal, az elejet vagy a veget nezed ?
Lehet hogy csak szuntet mered ?

Egy (jofele) micro kapcsolo kb 5ms -ig rezeg, az elejenel szokas jelet kuldeni gyors eszkozoknel, usb polling period az en "draga" egeremnel 1ms, szoval ilyen pontosan johet az eleje.

Nem real time vagy dedikalt magos hangnal, tul kicsi buffer valasztas underfillt eredmenyezhet, defaultbol egyik OS -sem valal be tul kicsit,
sot ahogy neztem a spec driverek sem szoktak megadni az ABS minimumot .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mert a "jobb", azaz billentésérzékeny eszközök a billentés sebességét(!) érzékelve adják a velocity értéket, emlékeim szerint a billentyű kódjával együtt, de ennek még utána kéne nézni, mert régen nézegettem a midi működését. Zongora, illetve minden olyan hangszer esetén mindenképp "meg kell várni" a velocity-t is ahhoz, hogy megszólalhasson a hang. Általában már az alsó holtppont ("koppan" a billentyű) előtt megvan minden adat, és megszólalhat a hang, de ezeknek az időzítésével (érzékelők fizikai elhelyezésével) is igen sokat lehet alakítani a játékélményen. Azt a mechanikus rendszert, ami a valódi zongorában van kell(ene) lemodellezni a midi eszközökben - a jobbak nagyobbrészt fizikailag valósítják meg, mások meg inkább matekoznak a billentyű pozíciója és sebessége alapján. És az egészre ráül még a pedálok állapota, illetve állapotváltozása is, azoknál a hangszereknél, ahol ez létező paraméter.

Persze, együtt megy a billentyű kódja meg a hozzátartozó, aktuális velocity értéke. Az érzékelők időkülönbségeiből számítja ki a sebességet és azt helyezi el 1-127 tartó skálán. Ezt küldi a billentyűkóddal egyszerre. Felteszem a zongin belül is ezt a megképzett midi jelet használják fel! De ebben azért nem vagyok biztos. Lehet h ha megkerülik a midi megvalósítását akkor könnyebb alacsonyan tartani a latencyt, így a zongin belül lehet másképp van, nem kell szabványos felületen átadni az jelet. Annak csak kifele van jelentősége. Illetve kintről is jöhet midi jel, ami meg tudja hajtani a zongit. 

Az általam elkövetett mérés egy dolgot igazolt, h az érzetem, hogy gyorsabb a zongi nem tévedés volt, mert ez következetesen látszott. De a kapott értékek olyan tartományba esnek, ami megkérdőjelezi a mérés érvényességét.  Aktuálisan nem az a kérdés számomra, hogy miért gyorsabb zongi (lehet h a midi kábel miatt), hanem h mi lehetett az elkövetett hiba a mérésnél? Lehet h telefon mintavételi felbontása alacsony? Sajnos nincs rendes mikrofonom v. hangfelvevőm ezért használtam a telcsit! 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Ha a visszajatszott hangon a hang magassaga (freqvencia) stimmel, akkor valoszinuleg a telefon jo.
Ha valami el van rontva, akkor nagyon el szokott rontva lenni.

44100 mintavetelt ha lejatszol 48000 -en (konverzio nelkul) meg lehet azt is hallhatod hogy nem stimmel, de az is csak ~9% elteres.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A mikrofon+ADC-ben nem nagyon lehet hiba, mert akkor az egész rendszer hasznavahetetlen volna.

Amiből mérési hiba adódhat:

 * hang terjedése a levegőben - a hangszórótól a mikrofonig, ezzel lehet számlni a távolságot megmérve és hangsebességgel számolva a terjedés idejét

 * A hang tömörítése a vevőben: erről nincsen pontos ismeretem, hogy a kodekek csinálnak-e valamilyen szintű időbeli elcsúszást a hangban, de nem tartom teljesen kizártnak. Például hogy nem lesz fázishelyes a minta, azt eléggé sejtem. Ezért én tömörítetlen (vagy veszteségmentesen tömörített) felvétellel mérnék, hogy biztosra menjek.

Ha jól olvasom, az a kérdés, hogy a billentyű megmozdulásától a hang megszólalásáig mennyi idő telik el. Nomostan ez attól függ, milyen erővel, azaz milyen gyorsan történik a billentyű leütése - mennyi idő alatt jut el addig a mechanika, hogy legyen velocity érték _is_. Mivel kézzel üti le a billentyűt, így vagy kellően sok mérést végez, és a mért adatsort dolgozza fel, mint tudottan hibával terhelt mérési adatokat, vagy pedig egzakt módon megismételhetően csinálja meg a billentyű lenyomását - mondjuk egy adott magasságból leeső fémgolyóval mozgatja végkitérésig a billentyűt - a lényeg, hogy a billentyű elmozdulásának az időtartama minden esetben azonos legyen.

Igen, mivel MIDI-ben már az első jelben benne van a velocity érték is, ezért egyértelmű, hogy az időmérés második pontja után jön csak az esemény. Talán úgy lehetne javítani a mérésen, ha a velocity értéket loggolnánk, és csak az egyformák számítanának a mérésben. Az áramkörbe belemérve kiderülhetne az is, hogy a két jel között milyen idők vannak.

Igen, erre írta korábban @turul16 a kiegyensúlyozást. Ezt eddig nem csináltam, és nem is loggoltam a velocity értékeket. Valójában a köröm koppanása és az alsó érzékelő elérése közti idő lenne ezzel nagyjából kiiktatva. Mindenképp megfogom így próbálni. De szerintem ez akkor is csak ezred és nem század másodperceket befolyásol. Minthogy a telcsi távolsága a hangszórótól is.  20 cm mondjuk.  Talán 1 ms-t számít. 

Amúgy nem tennéd meg, hogy kipróbálod Nálatok, így telcsivel felvenni zongorátokat? Ha felteszed valahova a fájlt akkor már kiértékelem.  5 perc az egész! Csak nem tudok most másik zongorát találni, ahol csönd is van annyira, h a köröm koppanása hallatszon. Lehet h mindenhol ennyi az érték, és az ezredmásodpercekről szóló értekezések meg  csak rész dolgokról szólnak valójában.

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

A cikked szerint az elso 10ms -et kivagjak a zongora felvetelekbol, hogy gomb nyomasa ne hallatszodjon.
Az igazi zongora feltehetoleg 10~120 ms kozott add vissza hangot a billenyu tetejenek erintesetol a fulig jutasig, az erossegtol fuggoen valtozva, nagyon erosen lenyomva talan ~6ms. (tegla ejtes 2m-rol, ful a zongoraban, lehet eleri <3ms is)
A vilag rekord leggyorsabb (13/s) ugyan azon zongora billentyu ismetelt lenyomasa ~40 ms lenyomasi idokkel ment (fel periodus, az uj velhetoleg allt is valamenyit), nyilvan egy egyszeri lenyomas (kar is benne lehet) lehet joval gyorsabb.

A cikked szerint csak a hangerot valtoztatjak a velocity ertek szerint elso kozelitesben, de kesest nem. Lehet hogy zongi csak berakta egy fix kesesre ?

A midi serializalas  megkerules belul csak ~ 0.8ms elonyt jelent, jo volna tudni hogy a szamitogep fele ki adja -e jelet <5 ms allatt,
es hogy szamitogep mas okok miatt kesik -e (mindenfele buffer meret miatt). Alaplapi hang kartyaval (pci/pcie) nezted vagy USB -vel ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Jaj, félek, h itt több dolog is félre értve! Billentyű leütés nem kerül kivágásra. A billentyű mechanikájának hanga a zongora hangzásának szerves része.  

> Az igazi zongora feltehetoleg 10~120 ms kozott add vissza hangot a billenyu tetejenek erintesetol a fulig jutasig,

Kíváncsi lennék, h telcsivel mit mérnék!

> A vilag rekord leggyorsabb (13/s) ugyan azon zongora billentyu ismetelt lenyomasa ~40 ms lenyomasi idokkel ment

De ennek nincs jelentősége most - mert ez komplexebb dolog. Nekünk nem a teljes ciklus kell, pláne nem annak ismételhetőségi jellemzője, hanem csak egy billentyűlenyomás, az érintéstől a hangig terjedően. Sem a billentyű elengedése, sem az újbóli lenyomhatósága most nem tárgya a vizsgálódásnak. 

> A cikked szerint csak a hangerot valtoztatjak a velocity ertek szerint elso kozelitesben, de kesest nem. 

Persze, mert a késés a billentyű lenyomása, a velocity érték előállítása, során képződik és nem az alsó érintkező elérése után. Az alacsony velocity értékhez tartozó hangnak nem kell később megszólalnia, mint a magas velocityhez tartozónak - mivel az alacsony velocity érték már eleve a lassabb billentyűlenyomással jön létre - és ez az oka a nagyobb késésének.   

> A midi serializalas  megkerules belul csak ~ 0.8ms elonyt jelent 

Hát ez akár még így is lehet, de honnét veszed?

> jo volna tudni hogy a szamitogep fele ki adja -e jelet <5 ms allatt

De ennél az általam tapasztalt késés egy nagyságrenddel nagyobb ~50ms körül van digi zongoránál, míg sz.gpépnél 60-80ms körül. Megnéztem egy másik hangszer (marimba) hangjával is, ugyan akkora késést tapasztaltam a zonginál. Majd megmérem még a laptop mikrofonjával is. Illetve másik grafikus audio  programmal fogom kielemezni az időket. 

A sz.gép esetében a nyitóban jelölt USB-s hangkártyát használom.  

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

>Persze, mert a késés a billentyű lenyomása, a velocity érték előállítása, során képződik és nem az alsó érintkező elérése után. Az alacsony velocity értékhez tartozó hangnak nem kell később megszólalnia, mint a magas velocityhez tartozónak - mivel az alacsony velocity érték már eleve a lassabb billentyűlenyomással jön létre - és ez az oka a nagyobb késésének.   

kalapacsos grand pianorol beszelunk ?
A kalapacs a gomb also vegehez eresekor meg nem erte el hurt. 0.5ms..40ms kozotti repulesi idokrol beszelunk, a gomb aljanak elerestol szamitva.
A gomb nyomasa kozben is mozog a kalapacs, ez csak az a szakasz ami gomb leerese utan mert, ami nem feltetlen esik egybe a tenyleges szabad repulessel.
Zongora tipusatol fugg a szabad repules, valamelyiknel csak 30ms a leglassabb "normalis" szabad repules. A gyors gomb nyomashoz rovidebb szabad repules tartozik, lassuhoz hoszabb.
Tehat nem csak a gomb lenyomasi ido telik el a hur rezgeteseig..

https://www.youtube.com/watch?v=bSRVngFGyIM  Ez 420 fps, vagyis ha egy kepkockan belul megurana az lenne 2.3ms ,
Itt nem csak a szabad repulest latod, a gomb nyomas kozbeni kenyszeres repules is benne van, ill. nem feltetlen a gombnyomas kezdetenel kezd el mozogni.
24fps -es video, 57ms -et latsz  1s lejatszason belul ha minden igaz.
IMHO ez egy viszonyalg gyors tempoju jatek lehet, eleg gyorsan ujra vannak nyomva a gombok.

> Hát ez akár még így is lehet, de honnét veszed?
Fentebb irtam , baundrate rate, csomag meret. Cdak a velocity jel (3 byte + start/stop bit), elvileg johet melette lenyomas kod is (2 byte).

> A sz.gép esetében a nyitóban jelölt USB-s hangkártyát használom.
Ha van masik hangkartyad  (alaplapi) lehet erdemes megnezni, hogy elter -e.

loopback testnel vagy speaker kiminetet kotod kozvetlenul a line-in -be ha van,
vagy elleneallasokon keresztul mic bemenetbe .
A loopack test altal mutatott ertek kb a 2x -e kimenti kesesnek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> kalapacsos grand pianorol beszelunk ?

Nem ez a kérdés.  A [jobb] digitális zongoráknál is megvan a kalapács mechanika imitációja. Nem tudom miért gondolod, h az érzékelőket az általad "gomb" ként hivatkozott billentyűkre teszik közvetlenül? A billentyű alsó állásához tartozó érzékelő aktiválása váltja ki midi jel küldését. Utána már nincs és nem is szükséges semmi késleltetés. A késés előzetesen úgy valósul meg h ha lassabban nyomják le a billentyűt akkor később éri el az alsó álláshoz tartozó érzékelőt, ha gyorsabban nyomják le akkor meg gyorsabban éri el. És azt h milyen gyorsan nyomták le az érzékelők időkülönbségéből tudja, ebből kiszámolja a velocity értéket ami együtt van elküldve a billentyűt meghatározó értékkel.  Természetesen az akusztikus hangszereken nincsenek sem érzékelők, és nem küldenek velocity, midi jeleket sem. 

https://youtu.be/Y6ZGBhVF95c?t=319

Majd kipróbálom alaplapi hangkártyával is az érdekesség kedvéért! De ugye mindenféle szgép és midi-kábel és hangkártya nélkül is, a digi zongora önmagában hasonló nagyságrendet produkált a késésben - és ez az ami számomra nehezen emészthető.  És ez azt mutatja, h ugyan szgép lassabb valamivel, de a nagyságrend azonos kb.  Szal legalábbis egyenlőre mindegy h a hangkártya most 2 vagy épp 5 ms latencyt produkál.

Amúgy van egy olyan cég, ami különböző kit-eket árul amivel akusztikus zongora alakítható át midi vezérelt zongorává. Az érzékelőket kell megfelelően elhelyezni. 3-8000 USD körül van az ára egy-egy ilyen kit-nek. Ami elég drága és ráadásul nem is jó minden zongorához. De van amiben van olyan mechanika, h úgy játsszik vissza midiről, hogy közben mozgatja a billentyűket is.  Ami elég fun!  (A nagy zongoragyártóknak Bosendorfer, Steinway van  gyári megoldásuk erre: egyszerre akusztikus és digitális, és tudja mozgatni a billentyűket is.)

https://www.qrsmusic.com/default.php

PNOScan meg PNOMation

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Az a mechanika nem tartalmazza a szabad repulest, de
https://hup.hu/comment/2691270#comment-2691270
Itt van egy tudomanyos cikk az accustikus pianok keseseirel es a modelrol aminek a nem lasitott videon is lehet latni, hogy
kenyszer nelkul szabadon is repul a kalapacs. Ha nem lenne szabad repules, a kalapacs nem tisztan megutne, hanem lefogna a hurt (vagy tobbszor utne meg).

Eleg sok billenyuzet elektronika neztem az utobbi par napban, tudom hol van az erzekelo egy tipikus midi billentyun  ;-)
Mechanika keses az electromos billentyun nincs lenyomas utan, kesest akkor kene hozza adni ha igazi accustikus zongorat szeretnel imitalni,
es radasul nem is fix kesest, hanem velocity ertek fuggoen valtozot.

Ha midi eseten <35 ms -alatt kijon a hang akkor nem kene bajnak lennie.
IMHO ha <10ms osszehozol akkor mar nincs mit megjavatini.
<6ms elvileg elerheto jo eszkoz valasztassal es beallitasokkal. (Nem ar fuggo, low latency modot "elfelejtettek", nem draga, ~20 eve alapbol megvolt a PC-ben, DOS+SB16)
Ha tenyleg par ms kene  valoszinuleg nagyon bele kell nyulni a dolgokba, de nem lehetetten, ha "csak" zenelesre kell nem igazan esszeru vele foglalkozni,
ha hangkartyadat vezerlesre/folyamat iranyitasra akkarnad hasznalni inkabb lenne ertelme bele piszkalni.
Ha garantaltan 1 ms ala akkarsz menni, akkor billentyuzet electronikaval kezd.

Az embernek hangal kapcsolatban ket dologban jo:
 - frekvenciak megkullombeztetes (330000 frekvencia megkulomboztetese 20~20khz kozott)
 - ritmus erzek (~6 hangjegybol (>>30ms tavolsag)  2 -t kicsivel 5~25 ms elcsusztatol, viszajataszkor eszre lehet venni hogy mas)

const kesesre joval nagyobb limiten belul nem erzekeny,
de >>30ms elteres eseten meg tudtad kulomboztetni a PC -t zongi tol, kivancsi lennek ha mindketto <30ms, <20ms, <10ms alatt lenne mene -e.

Itt kisebb mint 50ms en beluli hang esemenyek oszemosasarol beszel es egy regi tanulmanyrol mely szerint 100ms tol rovidebb note tavolsagot nem tartottak igazi zenenek:
https://www.youtube.com/watch?v=h3kqBX1j7f8

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egy digitalis studioban 10~12 ms elfogadhatonak mondott.

https://music.stackexchange.com/questions/30323/when-does-audio-latency…

It boils down to, roughly, optimal values of around:

  • vocals < 3ms;
  • drums < 6ms;
  • guitars < 12ms;
  • piano < 10ms;
  • keyboards (pads, etc) < 20ms

Szerintem ezek monitor latecy ertekek lehetnek, vagyis nem teljes hangszer hanem amitol bement feldolgozoba (microfon, cabel, synth kiment, pedal ..) es vissza jutott egy speaker/vagy fejhalgatoba.
vocals ~3 ms az eszleles, 7ms ami mar zavarhatja oket, olyan mertekben hogy meglatszik a teljesitmenyukon.

~100 ms az latency amivel meg lehet zenelni hangszeresen, de nagyon zavaro, -e felett nem igazan lehet ritmusban maradni egy zenkarral vagy metronommal. (teszt: ket zongorista koze mestersegesen 100ms latency adva)
~50 ms "challange accpted", zavaro, de ha muszaj akkor megoldhato.

https://repository.up.ac.za/bitstream/handle/2263/58578/Greeff_Influenc…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A valódi konfliktus az abból ered, hogy míg az akusztikus zongoránál a billentyű lenyomásakor azonnal jelentkezik hang (a mechanika hangja), addig ez a digitális zongoráknál nem feltétlenül van így. Persze abban is van mechanika, ami ad hangot - de ugye gyakran fejhallgatóban hallgatjuk (ami jó esetben kizárja ezt a hangot) vagy épp felvesszük a szgépre amit játszunk (és abban természetesen nem lesz benne mechanikusan képződött hang). Ilyen szempontból úgy kell vennünk, h a digitális zongora akkor kezd el hangot kiadni amikor a billentyű elérte az utsó (2. v. 3.) érzékelőhöz tartozó pozícióját. Addig árva nyik sem jön ki belőle, mig az akusztikus zongora rögtön ad hangot a billentéssel.  A szgépes zongoráknál előfordul h külön hangminták vannak a mechanika hangjára. De ezeket is csak akkor tudja lejátszani a szgép amikor a midi jel már előállt, azaz a billentyű megtette az útját a billentés során. De épp ez a baj. Mert azt a hangot a billentés ideje alatt kéne lejátszania. És a végén az utsó érzékelőnél már a zongora húr hangját kéne produkálnia. 

Tehát ideális esetben a digitális zongorának úgy kéne működnie, hogy a hozzáér a billentyűhöz >> első érzékelő aktiválódik >> eltárolja az időt >> elkezdi a mechanika hangját lejátszani >> második érzékelő aktiválódik >> eltárolja az időt >> harmadik érzékelő aktiválódik >> eltárolja az időt >> kiszámolja az időkből velocityt >> lekeveri a mechanika hangát és elkezdi lejátszani a húr hangját... és aztán csináltja a többi dolgot az most itt nem fontos.

Épp ezért úgy kéne működnie a midi keyboardoknak, hogy külön jelet kéne küldeniük az első érzékelő aktiválásakor. És egy újabb jelet az utsó érzékelő elérésekor.  Ezzel szemben csak az utsó érzékelő elérésekor küldenek jelet. Tulképp ez elég érthetetlen, h miért van így!? 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

https://en.wikipedia.org/wiki/Envelope_(music)
https://en.wikipedia.org/wiki/Envelope_(music)#/media/File:ADSR_paramet…

Ha idot mersz lehet erdemes az attackot/delayt minimumra venni.
Sok esetben az attack/release (time) tul kicsi erteke zavaro clickhez vezet , de most idot merunk ;-)

piano aleg nagy attack dolgozik:
https://www.dummies.com/art-center/music/recording-music/dynamic-music-…

Gyors zenenel le szokas menni 100ms rol 15~20 ms electromos billentyunel,
illetve mintha lenne oszefugges a kozott hogy menyi attackal dolgozik egy hangszer es hogy mikortol nem lesz kepes a zenesz syncronban maradni.

A klik hangot ~15ms attacknal hallom , hi pass filterrel is el lehet tuntetni. (A rendszerem elvileg jo alacsony freq lejatszasnal, lehet nem mindenutt feltuno)
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.