Az előző rész több mint két hónapja jelent meg, a végén azt ígértem, hogy ezúttal a kiszolgáló számítógép, a host computer lesz a téma. Ez egy elég száraz, mégis igen izgalmas diskurzus, ráadásul ezeket a feladatokat ezerféleképpen lehet megvalósítani, most ismét a saját példámmal tudok szolgálni. Ezek az írások arra hivatottak, hogy akik érdeklődnek a téma iránt, ami az Avantis keverőpult rendszerbe integrálása, ezen a konkrét példán keresztül egy kis segítséget kapjanak, ha valami hasonlóba szeretnének kezdeni. Az írásnak nem célja átfogó tudást adni, de talán segíti az útkeresést és gondolatébresztőnek, vitaindítónak is megfelel. A 4. részben elmeséltem a történetet, hogy bővült az egyszerű keverőpult egy összetett többcélú rendszerré, és bár a gyártók ezt nem ajánlják, ennek ellenére főleg kényszerűségből, helytakarékossági és anyagi megfontolásból, egy számítógépbe és egy Waves szerverre szorítottam az összes szoftvert, valamint a hozzájuk tartozó perifériákat. Eltartott egy darabig, mire minden kiadta, de mára minden összeállt, és bátran mondhatom, hogy évek óta stabilan működik. Beillesztem ide is a blokkvázlatot, amin keresztül remélem, könnyebben tudom szemléltetni az egyes alkotórészek kapcsolatát.
Először írnék néhány sort a számítógép kiválasztásáról, bár ez kb. 7 éve történt, amikor még nagy szó volt egy NVMe SSD és egy 8. generációs Intel processzor - a szempontok szerintem továbbra is aktuálisak maradtak. A választásnál a legnehezebb számomra az volt, hogy a szoftverek gyártói a rendszerkövetelményeket nagyjából kivétel nélkül úgy határozzák meg, mintha egy workstationt vagy laptopot kizárólag az ő programjuk futtatására használnánk. Nem is tehetnek máshogy, gondoljunk csak bele, hány variációt kéne tesztelni, ha ilyen terveik lennének. Nyilvánvaló képtelenség, néhány kivételes esettől eltekintve. Tehát olyan számítógépet kell választani, aminek minden porcikája megfelelő ahhoz, hogy minden szoftvert, amire szükségünk van, egyszerre futtasson. Ezekre a feladatokra a legtöbb esetben a világ gazdagabbik felén szerintem külön gépeket használnak külön operátorokkal, vagyis kell egy host gép a Waves SoundGrid szervernek az audio plu-ginek vezérléséhez, aztán egy a felvételhez és virtual soundcheckhez, egy harmadik a Smaartnak és a teljesség igénye nélkül egy negyedik a távvezérlő programoknak - esetünkben az Avantis Directornak. Ez utóbbi okoz némi fejtörést, mivel Windows alatt nem hajlandó csakis 100% -os kijelző méretezéssel megjeleníteni saját magát teljes mivoltában, nemhogy állítva használt monitorral. Remélem születik erre valami megoldás, mert elég kényelmetlen. Szóval nem túl életszerű, legalábbis az én esetemben, hogy kipakolok a táskámból a keverő mellé három-négy laptopot, bekapcsolgatom, összekábelezgetem, aztán jönnek a töltők, ethernet kábelek, kis jack stb. Így alakult, hogy a többlaptopos kipakolósdi után úgy döntöttem, megpróbálom belepaszírozni egy gépbe a dolgaimat.
Hazudnék, ha azt mondanám, hogy tudom, hogyan kell kiszámolni vagy előre modellezni pontosan, milyen erőforrásra lesz szükség adott feladatokhoz, így kb. csak a tapasztalatomra hagyatkozhattam. Szerencsére jól tippeltem, mire lesz szükség. Azt tanácsolom mindenkinek, aki nem rendelkezik megfelelő tapasztalattal, kérjen segítséget rutinos szakemberektől, illetve, ha van lehetőség vásárlás előtt, mindenképpen érdemes kipróbálni adott feladatra az adott számítógépet.
Én végül egy épített PC mellett döntöttem, aminek nem írom ide a pontos konfigját, mert ma már nem relevánsak ezek az alkotóelemek, de a szempontok, ami alapján választottam, igen. Nemcsak az ára, hanem néhány egyéb fontos szempont is vezérelt.
Legyen rackelhető számítógépház, hiszen hurcolni szeretném a Waves szerverrel, egy monitorral, billentyűzettel, hanyattegérrel együtt, ráadásul ne legyen csak 25 cm mély, hiszen nagyon fontos a helyspórolás. Ez nem is volt egyszerű feladat, napokig túrtam a netet, mire találtam egy 1.5 U magas és 25 cm mély rackbe szerelhető számítógépházat, amiben elfér minden - főleg egy még épp megfelelő teljesítményű, csendes, tartós processzorhűtő. Itt csak megemlítem a hűtés fontosságát, aki építésre adja a fejét, kénytelen lesz ezzel is foglalkozni, hiszen 40 fokos hőségben is lesz néha beállás, sőt néha koncert is. Kizárólag mini-ITX méretű alaplap jöhetett szóba, hiszen ezt fogadta az emlegetett ház. Elég kicsi, mégis rendelkezik az összes hardveres követelménnyel. Feltétel volt két alaplapra integrált gigabites ethernet port, amit korábbi laptopos próbálkozásaim alapján most is teljesen megalapozottnak tartok. És ami ma már alapvetés, hogy a SATA3 SSD mellett - akkor még ennek volt létjogosultsága - fogadjon legalább egy gyors, NVMe SSD meghajtót. Ez utóbbira került a rendszer, előbbire pedig a felvételek készülnek a mai napig.
Az említett két ethernet port fontos része a történetnek, ezért talán kezdem is a sztorival, miért lett az alaplap mindkét ethernet portja szerves része a projektnek. Amikor még az volt a terv, hogy a szép új laptopommal fogom bonyolítani a Multirack hostot, a régiről a felvételt - ekkor még a Smaartról szó se volt -, akkor a Waves azt kommunikálta - online vizsgát is tettem belőle, hogy a SoundGrid hálózaton egyéb IPv4-es forgalom is bonyolítható.
Már akkor se értettem igazán, lehet félreértés volt az egész a gyenge angolom miatt, mindenesetre a következő történt. A Multirack tette a dolgát, akkor még a GLD scene-ek vezérelték a snapshotjait, és láss csodát, a felvételben gyanús pattogások keletkeztek. Nem szaporítom a szót, amikor a SoundGrid hálózatra egy gigabit switchen keresztül ráeresztettem az IPv4 midit, amin keresztül a snapshotok közlekedtek, gyakran dropoutos lett a felvétel. Persze elkezdtem bújni a manuálok troubleshooting fejezeteit, azt találtam, hogy ilyen esetben tiltsam le az IPv4-es hálózatot a SoundGridet használó ethernet adapteren, vagyis szó se lehet a SoundGrid forgalmon túl bármit rábütykölni a szent Waves hálózatra. Nincs mese, két ethernet adapterre van szükség, az egyiken csak a Waves audio, a másikon a mindenféle egyéb vezérlés közlekedhet.
A Waves hivatalos hibaelhárítási protokollja az audio dropoutokkal kapcsolatban.
Mielőtt belemélyednénk a szoftverek és azok kapcsolatainak ingoványos mocsarába, fontos megemlítenem, hogy minden számítógépen vannak alapvető BIOS és OS szintű beállítások, amik elkerülhetetlenek a sikerhez. Ezeket nem fogom taglalni, számtalan leírás található a témáról az interneten, de erősen ajánlott az aktuális szoftver gyártójának ajánlásait betartani. Beteszek néhány linket, hogy mire gondolok, a teljesség igénye nélkül:
A Waves windowsos segítsége.
ProTools- felhasználóknak nagyon fontos írás, de másoknak is hasznára lehet.
Ezt a linket régóta használom a Focusrite jóvoltából, rádásul rendszeresen aktualizálják, igazán hasznos írás.
For MacOS
RTFM
Szerintem nagyon érdemes átnézni és betartani ezeket az ajánlásokat, sok kudarctól és kínlódástól szabadíthatnak meg. Sokszor okozott nehézséget az ilyen jellegű itinereknél, hogy angolul vannak és hiába fordítottam le az adott menüpontokat, mégis okozott nehézséget megtalálni egy-két menüpontot a magyar Windowsban. Szerencsére Win10 óta át lehet állítani angolra a teljes Windowst. Erről jut eszembe a kínlódás a billentyűkombinációkkal egy magyar billentyűzeten, gondolom nem kell ragozni, milyen csodálatos élmény, amikor esetleg alapvető funkciókat is csak nagy nehezen talál meg az ember, nemhogy a ProTools feketeöves hármas kombinációit. A megoldás egyszerű, USA billentyűzetet kell használni, amit aztán akár a magyar Windowsban is angolra kell állítani. Ezzel az egyszerű megoldással könnyű elkerülni a magyar karakterek használatát, ami sokszor okozott nem kis fejtörést bizonyos fájlnevek estén, bár manapság nem találkozom ezzel a problémával. Jobb a békesség, jó szívvel ajánlom az ékezetek nélküli karakterek használatát.
Valóban jogosan merül fel mostanra az olvasóban a kérdés, hogy oké, a Win alatt mennyi nyűg van, de mi a helyzet a MacOS -szel? Én többnyire Windowst használok, de főleg stúdiós munkáim során volt szerencsém bőven dolgozni Mac-en is, és hát mit is mondhatnék azon túl, minthogy semmiképp se indítanék vallásháborút ez ügyben, de szerintem kb. egy kutya. Legalábbis a szoftver- és hardvergyártók által ajánlott brand PC-k esetében ezt bátran ki merem jelenteni anélkül, hogy bárki oldalára állnék.
Nem kis bátorságot színlelve belekezdek a szoftverek és azok kapcsolatainak leírásába. Ebben a részben a Multirack lesz a téma, ami a legfontosabb és leginkább központi szerepet tölt be. Tudom, hogy már nem aktuális, megszűnt a támogatás, nem is kapható, illetve már a SuperRack van helyette, de a rendszerben betöltött szerepe ugyanaz. Létezik SoundGrid és Native verzió mindkettőből, a SuperRack performerrel pedig már native futtatható bármelyik gyártó VST3 plug-inje. Most a SoundGrid verzióról fogok írni, amikor a plug-in processzálás egy külön DSP szerveren történik, és a Multirack gyakorlatilag csak a képernyőn való megjelenítést és a kezelhetőséget teszi lehetővé. Minden egyéb erőforrást igénylő számítás a DSP szerveren történik, jelentős terhet levéve ezzel a host gép válláról. Nagy előnye ennek a technológiának, hogy a DSP szerver akkor is működik tovább, ha a host gép valami hiba miatt kiesik a rendszerből, pl. lefagy, de akár egy kontaktos kábel is okozhat gondot. Redundanciára is van lehetőség, két Waves server is futtatható egyszerre, és ha az egyik meghibásodik, a másik megy tovább. Természetesen ennek is van hátránya, például, hogy bár szól tovább a koncert, de ha az irányítás elvész a DSP szerver felett, akkor előfordulhat, hogy beleragad az ember egy nem kívánatos beállításba. Ezt mindenkinek a fantáziájára bíznám, hogy ki milyen vicces történeteket tud kreálni ez ügyben.
Az én egyszerű esetemben a Waves hálózat úgy néz ki, hogy az Avantisban lévő Waves I/O kártya egy ethernet kábelen csatlakozik a DSP szerverhez, egy másikkal a host géphez. Az A&H Waves V3 kártyában egy háromportos switch van beépítve, ezért én nem használok a SoundGridhez külön switchet, elég a három port, de kettő is, ha valaki SQ-t használ.
Még a v.1-es Waves kártya, ezen is három port van, az előző részekben már emlegettem.
A szerverrel többé - jó esetben - nincs több feladatunk, teszi a dolgát. A számítógép azon portját, ahova a Waves kártya csatlakozik, érdemes átnevezni SoundGrid portnak, és a fentebb linkelt leírások alapján kizárólag az IPv6-ot és a SoundGrid hálózatot engedélyezni rajta. A Multirack szoftverben most már be lehet állítani, hogy ezzel az ethernet porttal kommunikáljon a Waves kártya és a benne lévő switchen keresztül a szerver. Ha több hálózati adapter lakik a számítógépünkben, érdemes ezt az adaptert MAC address alapján azonosítani.
Multirack System Inventory
A System Inventory ablakban vehetjük leltárba a SG hálózat alkotóelemeit, ebben az egyszerű esetben a Multirack szoftvert, a SG drivert, az I/O kártyát és egy DSP szervert. Itt érjük el a Waves kártya setup felületét és frissíthetünk firmware-t.
Az aktuális Superrackben ez a felület teljesen máshogy néz ki, de lényegét tekintve mégis megegyezik.
A SG hálózaton kétféle audio stream közlekedik, a “Multirack” típusú, amin plug-ineket futtathatunk a DSP szerveren, fontos, hogy ez a stream csak a DSP szerveren megy keresztül, a host gépen nem, a Multirack csak a megjelenítést és a kezelést teszi lehetővé. A másik a SG driver audio, ami tulajdonképpen egy Waves ASIO driver, vagy Mac-en Core Audio driver, aminek segítségével, mint bármelyik hangkártyát tehetjük láthatóvá a DAW-ok és egyéb audiót használó szoftverek számára a Waves I/O kártyát. Ehhez a szerverre nincs szükség, ez az audio stream azon nem megy keresztül, ha például csak felvételt szeretnénk készíteni vagy konzerv hangot bejátszani.
Soundgrid Connections
A fenti SG Connections ablakban lehet ezeket a kapcsolatokat létrehozni, és természetesen ezen az egyszerű példán túl külön laptopot használni a felvételhez, a bejátszásokhoz vagy akár a Smaart-ozáshoz. Ebben az ablakban határozhatjuk meg, hogy pl. egy 128 csatornás kártyának melyik csatornáit szeretnénk pl. Multirack inzertben használni és melyikeket felvételre, esetleg egy másik laptopról néhányat bejátszáshoz, virtual soundcheckhez.
Megpróbálnék néhány hasznos gondolatot írni azzal kapcsolatban, hogy érdemes használni a plug-ineket, hogy nekem mi vált be és mire érdemes szerintem figyelni. Alapvetően a Multirack, ahogy a neve is árulkodik, egy olyan szoftver, ami inzertálható rackeket tartalmaz, amiknek segítségével a keverő egyetlen inzert-pontjába több plug-int is beilleszthetünk. Legyen az EQ vagy bármilyen dinamikaszabályzó, effekt, tényleg szinte csak a képzeletünk szab határt, mindenkinek a saját alkotóművészetére van bízva. Váltogathatjuk a beállításokat snapshot-okkal, egyeseket safe-be téve, hogy amikor helyspecifikus beállításokat csinálunk egy adott helyszínen, akkor azok ne változzanak meg, amikor előhívunk egy beállítást. Tipikusan ilyen például egy master EQ stb.
Van viszont egy nagyon fontos tényező, amiről szerintem nem beszélünk eleget a plug-in-ezgetéssel kapcsolatban, mégpedig a latency. A latency (késleltetés) az a jelfeldolgozáshoz szükséges idő, amíg esetünkben az audio jel egy készülék vagy rendszer bemenetétől a kimenetéig jut, mértékegysége általában milliszekundum vagy sample. Fontossága vitán felül áll onnantól kezdve, hogy a zenész nem hallhatja a monitorjában késve magát egészen odáig, hogy a PA rendszerből a színpadra késve visszaérkező hang is lehet zavaró, sőt egészen odáig, hogy különböző csatornák különböző késéssel szólalnak meg. Ezekre a dolgokra a mai digitális világban különös figyelmet kell fordítanunk, mivel a gyártók szeretik elhallgatni a pontos adatokat és sokszor nem adják meg a kellő segítséget sem, hiszen azt feltételezik, hogy szakemberek fogják használni a cuccaikat, akik tájékozottak és kellő figyelmet fordítanak a témára. Nézzünk egy teljesen hétköznapi példát:
- a gitárművész a színpadon rádiós jeltovábbítót használ, ami kb. 3 ms-ot késik
- azt beledugja egy Kemperbe, nincs adat a manuálban, saját mérés alapján 5 ms- ot késik
- azt bedugjuk egy keverőbe, ami pl. 2 ms- ot - ez teljesen elfogadott gyakori adat (az Avantis, dLive stb. üdítő kivétel, mindössze 0.7 ms-ot késnek)
- utána jön egy rendszervezérlő processzor, szintén 2 ms-os késés
- utána egy rádiós digitális fülmonitor – kb. 3 ms.
Én 15 ms-ot adtam össze, ami több mint 5 méter; barátok között is igencsak kellemetlen lehet. Dolgoztam olyan gitárossal, aki már az 5 ms-ot is zavarónak találta. 10- et már szinte mindenki észrevesz, a 15 az a határ, amikor már teljes joggal panaszkodhat a zenész zavaró késésre, persze ez is szubjektív.
Tehát nem ritkán fordul elő, hogy a 15 ms-os késéshez kell hozzászámolni még a Waves rendszer plug-injeit. Nem túl biztató.
A Waves SoundGrid rendszerben négy helyen keletkezik késés: a network, a driver, a plug-in és az ASIO/Core Audio driver latency. A network és a driver buffer méretét a SoundGrid inventory ablakban állíthatjuk, az ASIO/Core Audio driver bufferét pedig az aktuális DAW-ban. A kisebb értékek kisebb késést eredményeznek, viszont minél kisebb értéket állítunk be, annál jobban terheljük a rendszer aktuális részeit és fordulhat elő annak túlterhelése. A buffer méretekkel szoros összefüggésben van az órajel. Kétszer akkora órajelen ugyanakkora buffer méretnél többnyire feleakkora lesz a késés. Azért többnyire, mert a plug-inek esetében ez nem mindig igaz. Technikus legyen a talpán, aki ezt átlátja :).
A fenti ábra az egyetlen, amit találtam a témát szemléltetve egy régi Multirack Setup Guide-ban. Már nem elérhető, ezért nincs link, sajnos a Superrack-hez se találtam semmit, ami szemlélteti a kérdéskört. Sajnos ez az ábra se tökéletes, hiányzik róla a szerver és a plug-inek, azt képzeljétek hozzá a Multirack SG nevű laptophoz az ábrán. A Waves által hirdetett extra kis latency, a 0,8 ms csak a szerveren keresztül igaz 0 ms-nál többet késő plug-inek nélkül. Igen, vannak 0 mintát késő plug-inek, kompresszorok, EQ-k, effektek is, különösen ajánlott élő felhasználásban ezeket használni. A felvételhez, virtual soundcheckhez használt SoundGrid driver késését ehhez kell még hozzáadni, és az Asio/Core Audio driverek buffere okozta késéssel is számolni kell.
Tehát a DSP szerveren keresztül a Soundgrid Multirack vagy Superrack esetében:
Network latency + plug-in latency.
A SG driveren keresztül:
Network latency + SG driver latency + ASIO/Core Audio latency, amivel számolni kell.
Akinek esetleg volt türelme végig bogarászni a fenti agyrémet, már látszik, hogy a Waves elég menő rendszer. Ha a késés nélküli plug-injeit használjuk, tényleg tudja a 0.8 ms-os latencyt, ami egy Avantis keverő insert pontjában bemenettől kimenetig összesen 1,5 ms. Ettől még persze lehet hülyeséget csinálni és egy Linear Phase Multiband Compressort a főénekre insertálva elkésleltetni 3840 sample- lel, ami 48 kHz-en barátok között is 80 ms. Szerencsére kis körültekintéssel kordában tartható a késés, pl. jó trükk - ahogy az előző részekben említettem - külön monitorcsatornákat használni, ahova egyáltalán nem, vagy csak a nagyon szükséges plug-ineket insertáljuk. A mixhez használt csatornákon már kicsit szabadabban plug-in-ezhetünk, az se feltétlen probléma, ha összeszedünk néhány ms-ot, viszont itt meg arra érdemes figyelni, hogy a csatornáink ugyanannyit késsenek. A Waves Multirack/SuperRackben erre a problémára plug-in delay kompenzációt tudunk használni. Külön csoportokat hozhatunk létre, pl., ha valaki több fizikai csoportot szeretne használni különböző késésű plug-inekkel, erre a célra be tud állítani egy külön Latency Groupot, egy másikat pedig az input csatornáknak. Ennek a módszernek az alapfeltétele, hogy minden csatornának vagy mixnek legyen Multirack/SuperRack insertje. Előfordulhat, hogy nem szeretnénk minden csatornánknak plug-in insertet csinálni, ilyenkor a keverőpult csatornánkénti delayt használva időzíthetjük a csatornákat.
A tapasztalatom az, hogy ha van elég csatornánk a Waves kártyán, egyszerűbb az életünk, ha mindegyiknek beállítunk Multirack/SuperRack insertet, még ha plug-int nem is használunk rá, mivel ez szinte semennyi erőforrást nem igényel, viszont tuti plug-in delay kompenzációnk lesz minden csatornán.
A konklúzió, hogy körültekintően kell alkalmaznunk ezt a technológiát, illetve legyünk tisztában hol, mi, mennyit késik, és akkor kedvünkre tekergethetjük kedvenc kompresszorunkat, nem érhet kellemetlen meglepetés.
A következő részben előzetes terveim szerint a virtual soundcheckről és a midi kapcsolatokról fogok írni.
Reménykedem, hogy lesztek néhányan, akiknek hasznos volt ez az írás, és továbbra is tartom, ha valakinek kérdése, más véleménye, tapasztalata van a témával kapcsolatban, írjon, szívesen válaszolok, beszélgetek, a Messengeren elérhető vagyok.
Drobek Attila