A/D

Logic János vagyok, amatőr budapesti lakos, és feljegyzéseket készítek általában délelőtt. Míg mások dolgoznak. Ha valakinek meg kell élnie valamiből, akkor nem lesz ideje megfelelően elmélyedni a zenei szoftverének rejtelmeiben, tehát dolgoznia kell.

Kovács Zoltán olvasónk levele valóságos lavinát indított el, mikor azt írta, hogy, idézem: "...mán' szíjjelb.sz az ideg, a Pro Tools a MIDI hangszer hangját mindig előrébb veszi fel mint ahol a Note On-ok vannak! Segítsen mán' valakit!"

Rögtön beugrott az, hogy kb 10 felvételből amivel találkozom 9-ből az audio sávok el vannak csúszva. Láthatólag nem zavart senkit addig, míg nem szembesítették ezzel.

HOGYAN LEHETSÉGES EZ?

A problémát alaposabban megvizsgálva hamar levonhatjuk a következtetést, hogy a mai zeneszerkesztő programok alapszinten túli kezelése nem halandóknak való feladat. Megpróbáltam leírni az egészet töviről hegyire, de a tizedik oldal után sem voltam még sehol, és az A4-es jegyzeteim is 6 oldalt tesznek ki apróbetűvel, címszavakkal. (Most kezdem újra, hogy leegyszerűsítsem).

Az tehát, hogy valaki ezen szempontokat mind szemelőtt tartsa munka közben elég embertpróbáló feladat lehet, úgyhogy a hatékonyság jegyében annyira egyszerűsítem az “ábrát” amennyire csak lehetséges. A haladás kedvéért sok alap dolgot meg sem magyarázok (ez a Logic kezelésével kapcsolatos), és még így is szép anyag lesz, nagy szükség lesz az olvasó kitartására. Ha kérdés van, azt úgyis felteszitek, és a közösséggel együtt megválaszoljuk.

FONTOS EZ?

Ha a felvételek nem elég pontosak, akkor inkább a demók esetleges, rögtönzött, kidolgozatlanságát idézhetik, amin sem hangszínszabáylzó, sem kompresszor nem segít.

A következő fejezetekben megpróbálom érinteni a latencyvel kapcsolatos legtöbb problémát, és adok rájuk valami megoldást is. Révilágítok a mixelésnél, felvételnél, sőt, bounce-olásnál felmerülő nehézségekre, megmutatom, hogy hogy esik ezektől szét a mix, hol kavarja be az automatikát. Érinteni fogom a MIDI hangszereket is és a hangkártyák gaztetteit is leleplezem.

A Logic szoftvert fogom alapul venni, de örülnék, ha más szoftverek ismerői kiegészítenék a leírtakat, amiket hozzá fogok csatolni az értekezésemhez. Mivel a cikk megírásához szintén véges idő áll rendelkezésemre (értsd, tolvajtempóban írom és így is tekintélyes időt kellett ráfordítanom), helyenként hibák fordulhatnak elő, amiket nagyon szívesen kijavítok. Mindettől függetlenül a cikket egyaránt ajánlom maszületett bárányoknak és az iparban dolgozó profiknak is. Aki már most elriadt a terjedelemtől, de nem szeretné, ha a napja hiába telt volna, annak a következő tanácsokat adnám, ha el akarja kerülni azt, hogy a felvételei rossz helyre kerüljenek vagy rossz helyen játszódjanak le:

• Ne használjon semmiféle késést okozó plug-int (ennek kiderítésének módszerét lentebb tárgyalom). De ez még nem lesz elég )
  
   
• Kapcsolja ki a software monitoring funkciót (monitorozzon direktbe vagy mixeren keresztül)
  
   
• Ne használjon külső MIDI hangszert, külső szoftver hangszert, effekt processzort, digitális kibejáratot.
  
   
• Ha a buffer értéket átállítja, mindig indítsa újra a Logicot. Mindig
  
  Ha ezek nem tarthatók, akkor sajnos most a biztonsági öveket kérem becsatolni!
  
  (Ha valaki úgy gondolja, hogy nagy spíler, rögtön ugorjon a cikk végére, és próbálkozzon meg a teszttel, amit nyilvánvaló haszna mellett a szórakoztatás céljával állítottam össze)
  
  MINDEN KÉSIK.
  
  Az itteni lehetőségek nem teszik lehetővé, hogy mindent alapszinten taglaljak, viszont a fogalmakban meg kell állapodjunk, máskülönben nem lesz érthető amit írni fogok. Ami most jön, az muszáj sajnos. Kezdjünk is neki!
  
  A latency az az idő, ami ahhoz szükséges, hogy a hang eljusson a forrástól a céljáig. Ez alapján többféle latencyt definiálhatunk, például a közvetítő közeg alapján:
  
  Akusztikus késés, ami a hanghullámok terjedésének sebességéből adódik: ez 340 méter másodpercenként a levegőben.Gyorsszámoláshoz vehetjük azt, hogy 1 métert 3 milliszekundum alatt tesz meg a hang, és a kb. 10ms (3 méternyi távolság) eltéréssel megszólaló forrást a jobb képességű emberek már két külön hangnak képesek regisztrálni.
  
  Analóg késés, az elektromos jel terjedsének sebességéből adódó késés. Az analóg jel kb. kétharmad fénysebességgel terjed a vezetékben, ami durván 200,000 km / s. Ez olyan tartomány, amit gyakorlatilag elhanyagolható latency szempontból, azonnalinak vehetjük.
  
  Digitális késés: mivel a digitális jel egyfajta absztrakciója az eredeti akusztikus ill. analóg jelnek, ezért ellenére annak, hogy ez is vezetéken terjed, lényegesen lassabban teszi mindezt. Okai a digitális-analóg, az analóg-digitális átalakítók késése, illetve a bufferek, melyeket a különféle szinkronizációk érdekében kell bevezetni.
  
  Tudniillik egy számítógép, vagy egy processzor teljesítménye véges, és a rendelkezésére álló idő bizonyos részében tud csak zenei feladatokat ellátni (megj: sem a Windows, sem az OS-X nem realtime operációs rendszerek). Amíg mással foglalkozik (pl. kirajzolja az egér ikonját egy új helyre), egy átmeneti tárolóban, ebben a bizonyos bufferben gyűjti feldolgozásra váró, eredeti jelet reprezentáló adatokat, majd azokat egy szuszra processzálja, hogy megint mással tudjon foglalkozni. De szinkronba kell hozni a más-más adatátvitelből adódó eltéréseket is, pl. a PCIe vezérlő és az USB közti különbségből adódóakat, stb.
  
  Jegyezzük meg: a digitális rendszer átviteli jellemzőiből és működéséből adódóan ilyen átmeneti tárólókat, másnével buffereket kell alkalmazni, melyek méretükkel arányosan KÉSLELTETIK a jelet a valós időhöz képest. Ez elég nagy kalamajkát is tud okozni.
  
  Jegyezzük meg: zéró latency nem létezik, mégha a gyártók ezt is reklámozzák. Nem marketing csapda, csak egyszerűsítve szeretnék megértetni az egyszeri felhasználókkal, hogy a hangkártya képes direct monitoringre (később tárgyalom), ezzel olyan kis késést produkálva, amit nem érzékelünk már annak.
  
  BÁBELI ZŰRZAVAR
  
  Az, hogy kit milyen mértékben zavar adott késés személyenként változik. Egy templomi orgonista hozzá van szokva nagy késéshez (távol ül a sípoktól), ami viszont sok lenne pl. egy elektromos gitáron játszó zenésznek, aki még feszesnek érzi a játékát 1-3 méterre az erősítőjétől (3-9ms). Egy énekes viszont a saját belső rezgéseinek köszönhetően gyakorlatilag azonnal (<1ms) hallja a saját hangját, ahhoz van szokva, így őt az ennél sokkal nagyobb késések már zavarhatják az előadásában akkor is, ha az jóval 10 ms-en belül van.
  
  A cikket mindenki saját szájíze szerint értelmezheti, úgy határozza meg a határértékeket, ahogy neki tetszik. Itt az elveket próbálom tisztázni.
  
  Egy nagyobb színpadon két egymástól 15 méterre levő zenész már rendesen szívni fog: 45 ms elteltével hallja az egyik a másikat, amire az újabb 45 ms múlva tud csak reagálni, ami egy csepp tempóbeli változás lekövetését is lehetetlenné teszi, miközben a közönség őket egy időben hallja egymástól szétcsúszva. Szóval a monitorozás nem csak azért van, hogy halljuk magunkat, hanem hogy időben halljuk a másikat!
  
  Ennyit érdemes legalább tudni az előadáshoz kapcsolódó késésekről, de mi van akkor, ha nem feljátszunk (recording), hanem visszahallgatunk? Láthattuk, hogy a színpadon távol levő egyik zenészt (ha nem kell tempóváltozást lekövetnie) nem fogja különösebben zavarni az, hogy ő sok idő múlva reagál pl. a dobos diktálta ritmusra. A közönség viszont érzékelheti a két hagszer késését egymáshoz képest, amiről ő mit sem tud.
  
  Egy zenei szoftver ha lejátszik, akkor viszont mi mindnyájan “közönség vagyunk”, és a sávok ill. események közötti csúszások eltérései bizony zavarni fognak bennünket. Az egyik hang 5ms-t csúszik későbbre, a másik 7-tel korábban lesz felvéve, ami kapásból 12 ms relatív különbség, késés. Ezek a számok a gyakorlatban hamarabb összejönnek, mint gondolnánk.
  
  Lehet, hogy elsőre nem fog leesni, hogy a hangok megszólalásának pontossága miatt halljuk rossznak a mixet, melyek ellen mégrosszabb reakcióval pl. kompresszorokkal tüntetjük el az erről árulkodó indítótranzienseket, ezáltál egy végtelen spirálban fogjuk anyagunkat a totális amatőr végeredmény felé zülleszteni. Ha viszont tudjuk, hogy a feszes lejátszás milyen fontos, és tudatosan jól veszünk fel, mixünk új szintet léphet szívnonalban.
  
  Jegyezzük meg: a késés zavaró jellegének megítélése környezet és személyfüggő. De jó irány az, ha tudjuk, mivel kell számolnunk, és tudatosan kezeljük a jelenséget.
  
  A DIGITÁLIS KÉSÉS ÖSSZETEVŐI
  
  Az eddigi cikkeket amiket láttam a hangkártyák késésével foglalkoztak, ami azt jelenti, hogy a szerzőket kizárólag ez zavarta. Ez viszont csak a jéghegy csúcsa. Ha átlagon felüli eredményt szeretnénk elérni, a profikhoz hasonlóan igyekezzünk kell megérteni a teljes problémát. Ismerkedjünk meg a 3 alapvető digitális késés típussal!
  
  1. Audio I/O latency
  
  Audio bemeneti késés (A/D latency): az idő, mely az analóg elektromos jel digitalizásához szükséges. Konverter típusától változik, tipikusan 1 ms körüli érték.
  
  Audio kimeneti késés (D/A latency): az idő, mely a digitális tartományból az analóg tartományba jutáshoz szükséges. Konverter típusától változik, tipikusan 1 ms körüli érték.
  
  2. Plug-in latency
  
  A zenei szoftveren belüli késés, melyek bizonyos plug-inek használatakor keletkezik. Milyen meglepő: a pluginek sem egyformák. Meg kell ismernünk tehát, hogy melyek ezek a pluginek, hogy tudjuk megmondani, hogy késnek, illetve ha igen, mennyit, mi módon hatnak ki a munkánkra, és hogy lehet korrigálni a hatásukat. (Erről majd később)
  
  3. MIDI latency
  
  Erről is meg szoktak feletkezni, pedig a külső hangszerek újra reneszánszukat élik, és az ő késésüket általában csak manuálisan tudjuk korrigálni. Ő is a digitális tartomány része (még akkor is, ha a hangszer történetesen analóg , és együtt, szinkronban kell szóljon a többi felvett audióval! Meglehetősen komplex probléma ez. Két fajtát definiálunk:
  
  MIDI bemeneti késés: az idő, mely a billentyű leütésétől vagy kontroller mozgatásakor eltelik a szoftverbe (DAW) érkezéséig. Meglepő módon a különböző MIDI vezérlők elég széles skálán helyezkednek el fürgeség szempontjából.
  
  MIDI kemeneti késés: az idő, mely a MIDI üzenet kiküldésétől a hangmodul megszólalásáig telik el. Itt egészen drámai értékeket is sikerült mérnem, volt hangszer, ami 20ms-nál is lassabban reagált a MIDI üzenetekre. Érdemes tehát valamiféle módszer szerint megvizsgálnunk azt, hogy hangszerünk mire is képes.
  
  A következő részben szemügyre veszem az egyes tényezőket, de megjegyzem, hogy mivel mindenki más zenét csinál másféle módszerrel, ezért nem mindenkit érintő problémákról lesz szó. Lesznek azonban olyan részek is, amik azokat is érintik, akik kizárólag a szoftveren belül dolgoznak.
  
  AUDIO I/O LATENCY
  
  Ha számítógép kerül a képbe, ez a tényező mindig fennáll. Láthattuk, hogy konverterek révén a jelet előbb digitálissá alakítjuk, ekkor tudjuk feldolgozni azt a szoftverünkkel (DAW, esetünkben a Logic), majd újból analóg jellé kell alakítanunk. A jel teljes útjának megtételéhez szükséges időt úgy hívjuk, hogy ROUNDTRIP LATENCY, vagyis az az idő, amely alatt az analóg jel eljut a bemenettől a szoftveren át a kimenetig.
  
  Megjegyzés: a Logic roundtrip latencyt jelenít meg, de ha a nem használunk analóg bemenetet mert pl. csak belső szoftveres hangszerekkel játszunk, akkor ez az érték kisebb mint az itt jelzett érték. Általában De más szoftverrek, pl. Live lebontva mutatja a ki- és bemeneti késéseket.
  
  Az Audio I/O latency két részből áll, egy úgynevezett buffer értékből, melyet a gazda szoftverben (Logic) állíthatunk be, és egy nem buffer-értékből, mely a konverterek késéséből, a meghajtó szoftver működésének sebességéből és egyéb átmeneti tárolókból áll, amire a felhasználónak nincs se rálátása, sem beleszólása. Az előbbi tehát változtatható, az utóbbi egy statikus, konstans érték. A kettő összege a roundtrip latency.
  
  Az Apple összefoglalója a témában itt található.
  
  K: Miért fontos ez a szám?
  
  V: Nagyon egyszerű oka van ennek: mikor audio felvételt készítünk, akkor a szoftver ez alapján kompenzálja azt. Tudatában annak, hogy a roundtrip latency érték mondjuk 3.3 ms, a felvett hangot ennyivel korábbra teszi le a playheadhead pozíciójához képest! Ezt el ne felejtsük, ez lesz az alaphelyzet. Sajnos hamarosan látni fogjuk, hogy ez ennél sokszor komplikáltabb tud lenni.
  
  K: Honnan tudja a szoftver, hogy mennyi a hangkártya roundtrip latencyje?
  
  V: Nagyon egyszerű: a meghajtó (driver) közli azt a programmal. Sajnos olykor hibásan: találkoztam nem egy olyan hangkártyával, amelyik egész egyszerűen hibásan jelentette ezt az értéket. Szerencsére a roundtrip latency mérésére van pár működő módszer, úgyhogy ezt magunk elvégezve a Logicban lehetőségünk van kompenzációként megadni.
  
  TANULJUNK MEG SZÁMOLNI!
  
  K: Adott buffer mekkora késést okoz a jelben?
  
  V: A buffer méretét mintákban szokás megadni. Pl. egy 64 mintából álló buffer 44.1kHz-es mintavételezési frekvencia mellett 64 / 44.1 = 1.45 ms, egy 128-as buffer pedig 128 / 44.1 = 3ms időre elegendő mintát tud tárolni, ez fog késésként megjelenni. A roundtrip latency esetében ez a buffer kétszer is jelentkezik. Pl. egy 256-os buffer 256 / 44.1kHz x 2 = 11.6 ms-mal késlelteti a kimenő audió jelet a bementhez képest, ami többek számára alkalmatlanná teszi arra, hogy valós időben monitorozza így a hangkártya bemenetét a szoftveren keresztül (monitorozásra más módszerek is vannak, erről majd később).
  
  Ehhez természetesen hozzá kell még vegyünk a nem-buffer késéseket is, ami viszont hardverfüggő, és független a buffer méretétől.
  
  Ha pl. 64-es buffert választunk, és emellett a rendszer 4.9 ms latencyt mutat, akkor az annyit tesz, hogy van 64 / 44.1 x 2 = 2.9 ms bufferből adódó késésünk, és 4.9 - 2.9 ms = 2 ms nem bufferből adódó késésünk. Utóbbi a konverterek sebességéből, a meghajtó szoftverből és egyéb bufferekből jön össze. (A 2ms érték az Apogee Symphony IO a saját kártyájával együtt, egy RME FireFace 800 esetében ez az érték 4.7ms-nek adódott). Mégegyszer mindez akkor, ha a szoftverünk helyes értéket jelenít meg!
  
  Az Apogee Symphony IO interfész a saját PCIe kártyájával, majd USB2 kapcsolaton keresztül:
  
  
  
  VONJUK LE KÖVETKEZTETÉSEINKET!
  • Nagyobb bufferméret nagyobb késést okoz és kisebb terhelést jelent a processzornak (nem kell annyira kapkodni a feldolgozással), kisebb bufferméret pedig kisebb késést okoz, és nagyobb terhelést jelent a processzornak (a számítógépet állandóan megszakítja a sok apró beérkező bufferben levő adatcsomag).

    Az, hogy a gépünket mennyire terheli az adott bufferérték elsősorban a hangkártyától függ, és nem pedig a számítógépünk sebességétéől. Egy USB 1.1-es vagy 2.2-es hangkártya sokkal jobban fogja a processzort, mint egy firewire-ös eszköz. Természetesen a PCIe hangkártyák (ill. most már Thunderbolt!) a nyerők, azokon belül is azok, amik direkt nagysebességű kommunikációra lettek tervezve (ilyen pl. az Apogee Symphony rendszere)

    Ezek szerint a buffer méretét úgy kell megváltoztatnunk, hogy a gépünk le tudja játszani recsegés, megállás nélkül a sessiönt, de az élő játékot ne zavarja a késés. Minél inkább mestere valaki a hangszerének, annál jobban fogja zavarni ez a fajta késés. Én úgy vettem észre, hogy 128-as buffer felett már olyan latecny értékek adódnak, ami egyértelműen kockáztatja az elődásunk feszességét. Többen azt fogják mondani, hogy ők ennél nagyobb bufferrel is elvannak. Én azt gondolom, hogy nem hasonlították össze a játékuk eredményét a kisebb bufferrel lett változattal, vagy úgy játszanak, hogy “nem ez a szűk keresztmetszet” (sorry, de a profik és az amatőrök játéka között ez egy lényegi különbség). Én a szubjektív részt nem akarom firtatni, mindössze annyit mondok, ha valaki igényes szeretne lenni, és nem szeretne kutatásokba bonyolódni, a legjobban teszi, ha egész egyszerűen nem forszírozza a 15ms feletti latency értékeket. És ez 2013-ban sajnos nem is olyan könnyen teljesíthető kritérium.

    Sajnos másik oka is van a dolognak: a valaki veszi a fáradtságot, könnyen rájöhet pl. arra, hogy a szoftver hangszerek élőben kötelezően kvantálják a hangokat. A kedves olvasó már bizonyára kitalálta, hogy a kvantálás alapja nem más, mint maga a buffer hossza. Tehát: két egyszerre leütött hang közül az egyik jó nagy késéssel szólal meg a másikhoz képest, ha pont egy újabb bufferciklus kezdődik (ehhez elég akár egyetlen milliszekundummal lemaradnia, és MIDIről lévén szó két note on között ennyi különbség bőven lesz is!), illetve tökegyszerre fog megszólalni két nem egy időben leütött hang, ha ugyanazon bufferciklus alatt érkezik be a számítógépbe. (Mégegyszer: ez a szoftverhangszerekre vonatkozik).

    Verdikt: felvételkor minél nagyobb a buffer, annál “darabosabban” lesznek kvantálva a bejövő hangok ÉS(!) a kontrollerek is! Lejátszáskor más a helyzet: a szoftverhangszerek az eredeti felvételnek megfelelően az események sample pontosan kerülnek visszajátszásra.

    Update: SonnyCoca fórumozónktól tudjuk, hogy ez nem mindig van így. Kultúráltan megírt szoftver hangszerek arányosan tudják kezelni az időbéjeggel ellátott MIDI eseményeket, így azokat buffernyi késéssel, de helyükön fogják kezelni. Ezek tehát felvételkor is pontosak.

    Jegyezzük meg: élő bemenet esetén sem a hardver hangszerek, sem a szoftver hangszerek nem sample pontosak. (Előbbi a MIDI jitter miatt). A szoftver hangszerek lejátszáskor lesznek azzá, a hardverek pedig lehetnek minta pontosak, amennyiben a billentyűzetüket használjuk közvetlenül a megszólaltatásukra (és az audió kimenetüket vesszük fel).

    VIGYÁZAT! A Logic megbízhatóság szempontjából sajnos nem a csúcsok csúcsa, és nem pont ezzel a szóhasználattal jutott eszembe, mielőtt leírtam volna. Egy jól működő hangkártya latency értékét is néha rosszul regisztrálja. Továbbá szinte minden esetben rosszul fogja megállapítani a roundtrip latency értéket, és összevissza fog kompenzálni, ha buffer méretének változtatása után nem indítjuk újra a szoftvert! Lehet, hogy a munka hevében nem tűnik fel, hogy össze-vissza vesz fel audiót, és épp ez benne a legveszélyesebb. Ezért a bajt megelőzendő találjunk ki egy fix buffer értéket, állítsuk be azt, lépjünk ki, majd újra indítsuk el a Logicot, különben az életünk pokollá változhat.

    AUDIO I/O LATENCY MÉRÉSE

    Tudjuk, hogy felvételkor a rendszerünk a roundtrip latency ismeretében korrigálni fogja a felvett audió jelet. Ehhez nélkülözhetetlen, hogy ezt az értéket helyesen kapja meg. Ennek ellenőrzésére ismertetek egy egyszerű módszert Logicban:

    A hangkártyánk egyik bejáratát összekötjük egy kijárattal. Nyitunk egy audio csatornát, amire berakjuk az I/O plugint, amin beállítjuk az előbb összekötött kibejáratokat. Ekkor nyomunk egy “ping” gombot, mire a szoftver megméri, hogy az általa kiadott tesztjel mennyi idő alatt érkezik a vissza bemenetére. Ha ez az érték nem nulla, akkor azt jelzi, hogy a Logicnak rossz ideája van arról, hogy mennyi valójában a roundtrip latency érték, és az I/O Plugin ezt a késést kompenzálja a sávon lejátszáskor (erről részletesebben a plug-in-ek okozta késésekről fogok még beszélni).

    Ezen a képen az I/O plug-in itt 59 minta eltérést talált a korrekt roundtrip latency értékhez képest. Valami gubanc van!

    

    Ha ez bekövetkezik amiatt, mert a hangkártya rossz értéket jelent (és nem azért van, mert nem indítottuk bufferváltás után a Logicot!), akkor kézzel kompenzáljuk a Recording Delay elnevezésű paramétert. Ha tehát az I/O plugin ping funkciója mondjuk 58 sample késést mutat, akkor a Recording Delay paraméterre -58-at írunk be az audio résznél a preferencesben. Ez tehát azt biztosítja, hogy a felvételeinket 58 mintával előbb teszi le, a rendszer más paramétereit nem módosítja, az I/O plugin továbbra sem nullát fog jelezni.

    Mit tudtunk meg tehát? Azt, hogy a latency értékünk ms-ban mennyi. Az, hogy ez hány minta, azt ez a módszer nem árulja el, minthogy a Logic tizedes pontossággal jelenti csak ezt, ami kb 5 mintán belüli tévedés. Oké, ez szőrszáhasogatásnak tűnik, de nem ez az egyetlen jelenség, ami kételyt ébreszt bennünk, hogy a Logic audio részét mennyire tervezték pontosra. Nekem inkább alulspecifikáltnak tűnik, én pedig őszinte híve vagyok a ráhagyásoknak. Tévedni itt vagyok én, az ember, a számítógép meg azért van, hogy legyen pontos!

    (Haladó, kényszeres elmebetegeknek: ha ennél pontosabb mérést szeretnél -aminek természetesen semmi értelme-, akkor csinálj egy audio regiont egy egységnyi tüske (=1 minta széles) impulzussal, küldje da sávot ki a kimenetre ami vissza van kötve a bemenetre. Egy újabb sávot jelölj ki felvételre aminek a csatorna bemenete az előbb említett visszacsatolt fizikai bemenet, a csatorna kimenete pedig legyen ugyanaz a fizikai kimenet, mint amin az impulzust küldted ki az előbb. Ezen a sávon vegyél fel egy keveset, és kapsz egy sor impulzust. Az impulzusok közti távolság sample-ben a rendszer sample pontos roundtrip latency értéke lesz).

    Ha a rendszerünk roundtrip latency értéke korrekt, akkor elértük azt, hogy pluginek használata nélkül a bejövő jelet már jó helyre fogja felvenni a rendszer! Vagy mégsem?

    Visszacsatolás alapú latency mérés Logicban, 256-os bufferrel:

    

    DIGITÁLIS AUDIO I/O LATENCY

    Mint megtudtuk az előbb, a hangkártya drivere a Logic tudtára adja az analóg kibejáratok latency értékét, és ennyivel korábbra igazítja a felvett jelet. De mi a helyzet azokkal a hangkártyákkal, amiknek van digitális kibejárata? Ha hangkártyánk ADAT csatlakozóira felcsatolunk egy újabb konvertert, egy dologban biztos lehetünk: a Logicnak (vagy bármilyen más DAW-nak) lövése sem lesz a roundtrip latency értékek alakulásáról. Ő továbbra is az analóg csatlakozók késését veszi alapul, azt kompenzálja. Tehát ha mondjuk van egy Focusrite Saffire Pro 40-ünk, amire rákötünk ADAT csatlakozón egy külső konvertert, akkor biztosnak vehetjük, hogy a külső konverterről bekötött jel nem ott fog landolni, ahol az eredetileg a valóságban történt.

    Megoldás: a fent említett módszerhez hasonlóval egy hurokkal megállapítjuk a digitális rendszer roundtrip latency értékét, és ezzel az értékkel korrigáljuk a digitális kibejáratokat. Hogy ezt hogy tegyük? A Logic Environmentjébe létrehozzuk az adott digitális bejárat input elemét, és berakunk egy sample delay plugint, amit a késés értékére paraméterezünk.

    Most végre atompontos szinkron lesz az analóg és a digitális csatlakozók között!

    AUDIO JEL MONITOROZÁSA

    Mostmár tök jól tudunk felvenni audiót a helyére, de szeretnénk hallani azt, amit felveszünk és azt is, ami az alap. A kettőt együtt, és szinkronban. Erre alapvetően három módszerünk van:

    1) Az egyik, mikor valami fizikai, hardver keverőpulton keverjük össze a bemenet (mondjuk egy mikrofon) hangját a hangkártya kimenetével. Ekkor a keverő egy speicális routing révén a rákötött mikrofont a hangkártya bemenetére küldi. A hang, amit hallunk és amit veszünk szinkronban lesznek egymással, gond egy szál se.

    2) Monitorozhatunk a hangkártya beépített keverőjével is. A zenélésre kitalált hangkártyáknak van egy úgynevezett direct monitoring funkciója, mely a bejövő jele(ket) saját maga keveri össze a szoftverből szóló alappal. Azokat nem továbbítja a gép felé, így megússza a további késést, hanem rögtön maga elvégzi a keverést, és a kimenetére teszi. A késés ilyenkor olyan pici, gyakorlatilag elhanyagolható. Ez a megoldás ugyanazt eredményezi, mint az előbbi, külsős keverőpultos változat. Olyan, mintha a keverőpultot beépítették volna a hangkártyánkba.

    3) De mi van akkor, ha szeretnénk a szoftverünk plug-in effektjeit használni valós időben? Nos, ebben az esetben az úgynevezett software monitoring, vagyis a szoftveres monitorozás az, amit keresünk. Ekkor nem úszhatjuk meg azt, hogy a hangkártya direct monitoringját kihagyva a jel végül bejusson a szoftverbe, és itt megindul az óriás lavina a késésekkel. Itt már észnél kell lenni rendesen!

    SZOFTVERES MONITOROZÁS

    A szoftveres monitorozás magával hozza a fent említett latency problémakört kiegészülve a MIDI és a Plug-in latencyvel. Szépen belemártjuk a nagylábujjunkat a sűrűjébe.

    A Logicban van egy software monitoring funkció, mely segítségével a Logic lejátsza a bejövő jelet amennyiben a sávot felvételre jelöljük ki, vagy input monitoringre tesszük.

    Ekkor az előbb elhanyagolható késések itt már komoly értékekre duzzadnak, “hála” a driver és a buffer késéseknek .

    Tudjuk jól, ha a buffert nagyra választjuk, akkor a késésünk oly mértékűre nő, hogy képtelenek leszünk pontosan, feszesen játszani. Válasszuk kicsire (max 128 minta), és oldjuk meg, hogy a gépünk le tudja játszani a sessiont. Erre jobb tippem nincs. Bounce-oljunk, freezeljünk, mute-oljunk.

    Ha audiót monitorozunk, két késéssel kell számolnunk. Az egyik az előb tárgyalt audio I/O latencyből , a másik pedig esetlegesen a plug-in latencyből tevődik össze. Ez utóbbi kompenzációját PDC-nek fogom hívni.

    Lesznek plug-inek amik nem okoznak késést, és nem befolyásolják az eddigiket, viszont lesznek olyanok, melyek igen. Ilyenek a pitch korrektorok, lineár fázisú szűrők, speciális limiterek és olyan kompresszorok, melyek “lookahead” paraméterrel dolgoznak.

    Logic esetében ezek a plug-inek okoznak késést:

    • Nagyobb mintavételezési frekvencia kisebb késést okoz és növeli a prcoesszorterhelést.

      [*]Space Designer (alapból nem, csak ha a "latency compenstation" gombot bekapcsoljuk! ááá! )

      [*]Enverb

      [*]Pitch Correction

      [*]Pitch Shifter II

      [*]Vocal Transformer

      [*]Adaptive Limiter

      [*]Limiter

      [*]Multipressor

      [*]Noise Gate (!)

      [*]Silver Gate

      [*]Ducker

      [*]Linear Phase EQ

      [*]Match EQ

      [*]Denoiser

      A nem Logic pluginek közül ilyen kb majdnem minden Universal Audio UAD kártya plug-in, vagy bármely DSP támogatású plug-in. Nagyon sok késést okoz minden lookahead paraméterű plugin, pitch correctorok (pl. Autotune), speckó lineár-fázisú szűrőket alkalmazó eljárások, vagy komplikáltabb IR plug-inek, vagy olyanok, mint pl. a Lexicon natív zengetője.

      K: -HONNAN TUDJUK AZT, HOGY MELY PLUGINEK KÉSNEK?

      V: -A Logicban nincs lehetőségünk ezt megtudni úgy, ahogy pl. a Pro Tools ki tudja írni egyes csatornáinak teljes késését. Ha nem akarunk méricskélni, van egy praktikus módszer azért.

      A Logic csomag része a MAINSTAGE nevű applikáció, mely viszont meg tudja mondani a csatornák késését. Egyszerűen behívjuk az adott plug-int, megcsavarjuk valamely paraméterét, és ki fogja írni, mennyit késik. Az ábrán látható Manley Massive Passive UAD-2 plug-in például egy elég rendes 24.5ms-et. Ugyanakkor látatjuk, hogy a legtöbb gyári Logic plugin semmennyit se. Íme, hogy néz ez ki a gyakorlatban:

      

      MIT JELENT TEHÁT A PLUG-INEK OKOZTA KÉSÉS A GYAKORLATBAN?

      Na most tessék figyelni: ha a képen látható 1-es sáv audiót játszik le, az 24.5ms-et késik a többihez képest, ami nagyon durva. Ezeket a sávokat szinkronba kell tehát hozni. Hogy lehetséges ez?

      PLUG-IN DELAY KOMPENZÁCIÓ (PDC)

      A fenti példában tehát szétcsúsznak a sávok. A Logic, és bármely modern DAW ezt úgy tudja orvosolni, hogy rendelkezik egy úgynevezett Plug-In Delay Compensation paraméterrel, ami esetünkben egy globális beállítás (Preferences). Itt három opciónk van: A) OFF (kikapcsolva, tehát nincs szinkron, szétcsúszik), Audio and Software Instrument Tracks (mely a szinkronról gondoskodik audió és szoftver hangszer típusú csatornákon) illetve C) ALL, mely B-hez még hozzáveszi a többi csatorna típust is, KIVÉVE A BEMENETI CSATORNÁKAT (az Environment “input” típusú csatornáit). Ezek tehát: audio, software instrument, bus, aux és output csatorna típusok.

      Itt található a szóbanforgó paraméter:

      

      Elemezzük hát az utóbbi kettőt!

      PDC AUDIO AND SOFTWARE INSTRUMENT SÁVOKON

      A csatornákon jelentkező plug-in késést lejátszáskor úgy kompenzálja a rendszer, hogy a többi csatornához képest előbb játsza le a rajta átfolyó audiót (negatív késleltetés).

      Az előző példából kiindulva a Logic az 1-es sávra felvett audio jelet egész egyszerűen 24.5 ms-mal korábban játsza le, mint a többi sávot, így szinkronban a ráccsal és a többi sávval is. Tiszta sor.

      Most azonban ha a jelet elküldjük AUX sávra, ott berakunk egy 11ms késést okozó plug-int, akkor a szinkron elvész. Az audió sávunk ugyan 24.5 ms-mal korábban lesz lejátszva, viszont az AUX sávon levő plug-in 11ms-os késésel fog csak hangot kiadni, tehát elvész a szinkron. Ez a probléma tehát így nem megoldható.

      Ide valami más kell. Egy másik PDC mód!

      ALL MODE PDC

      A fenti problémát orvosolja ez, mely azt csinálja, hogy az 1-es sávot 24.5ms-mal korábban játsza le, ezt a jelet pedig továbbküldi az aux sávra, ahol az 11ms-ot késik. Ezt kompenzálandó a send pontja után mesterségesen késlelteti az audio csatorna jelét, így mindkét sáv szinkronban marad. Érthető ez így? Mégegyszer. Az 1-es sáv audió file-ját 24.5ms-mal korábban játszuk le, elküldjük AUX-ra, ahol majd lesz vele valami, de még mielőtt elérné az outputot, a Logic késleltetet rajta mesterségesen 11ms-ot. Ez idő alattpárhuzamonsan az AUX a plugin miatt is elszenved 11ms-ot, így mindkettő egyszerre érkezik a kimenetre.

      Képzeljük el, hogy az ALL mód minden szinkronhibát kijavít. Minden audio útvonalat úgy szinkronoz, hogy bármilyen elágazás mentén adjuk össze a késéseket, a kimeneten mindig ugyanannyi teljes késést kapunk.

      Jegyezzük meg nagyon: az audio és szoftver insrument csatornákon jelentkező késést a Logic úgy oldja meg, hogy a forrásukat KORÁBBAN játsza le, a többi csatornán (Bus, Aux, Output) jelentkező késést pedig úgy kompenzálja, hogy a többi csatorna jelét KÉSLELTETI.

      Most úgy tűnik, minden rendben van, de ne örüljünk: csinál egy másik galibát. Most a playheaddel nem lesz szinkronban az egész session úgy ahogy van: ezzel a bizonyos 11ms-mal késni fog a hang a rácshoz képest. Amint majd látni fogjuk, ez óriási probléma lesz ez.

      PDC KÜLSŐ MIDI HANGSZEREK MONITOROZÁSAKOR

      Ha a Logic MIDI-t és audiót játszik le egyidejűleg, a szinkronitás problémája magától értetődő. A MIDI ugyanis alapból a playheaddel (ekként a ráccsal is) szinkronban van, az audió ehhez képest meg mindig lemaradva valamennyivel.

      Két eset lehetséges:

      1) MIDI hangszer hangját a hangkártya beépített keverőjén, vagy a külső keverőn keresztül monitorozzuk. Ekkor a Logic alapból nem kompenzálja az audio és a plug-in latencyt a MIDI-re vonatkozóan. Tehát késni fog az audió a MIDI-hez képest a hangkártya output audio latency-je és a plug-in latency kombinált értékével. További hátrány, hogy a Logic-ban futó plug-ineket nem tudjuk használn a külső hangszer hangján

      2) A MIDI hangszer hangját bevisszük a Logic szoftveres keverőjébe, és ott software monitoring révén szinkronba hozzuk az audióval. Előnye, hogy a Logic plugineket alkalmazhatjuk a hangszer hangjára, hátránya, hogy a MIDI hangszer késni fog most már a roundtrip latency értékével (ami ugye az input latencyt is beveszi a játéba), a saját MIDI latency értékével, továbbá opcionálisan a PDC-vel, ha úgy döntünk, hogy maradjon szinkronban a többi sávval is.

      Bármelyik stratégiát is választjuk, mindkettő esetben lesz dolgunk bőven.

      Az 1-es esetben a szinkron abból áll, hogy A) kompenzáljuk a hangszer MIDI késését (vagyis hogy a szoftverből jövő MIDI üzenet indulása a hangszer audió kimenetén mennyi idővel később okoz változást) Kompenzáljuk az audió kimeneti késésést a MIDI-re nézve (az audió jel szenvedi ezt el a valós időhöz, vagyis a playheadhez képest) C) kompenzáljuk az esetleges késést a plugineknek. Erről részletesebben hamarosan.

      A 2-es esetben a szinkron abból áll “mindössze”, hogy a Logicba belépő audió jelét a hangszernek összeszinkronozzuk a lejátszott audióval, mivel a kettő nem ugyanazt a késést szenvedi el.

      De jó is lenne, ha a MIDI hangszerek felvétele ill. monitorozása azonos probléma lenne a sima audio jel felvételével, monitorozásával és lejátszásával, de sajnos nem az. Mindkettőre külön stratégia kell, de hogy a dolgot megértsük, kezdjük az audió monitoring problémájával!

      AUDIÓ FELVÉTEL SZOFTVERES MONITOROZÁSSAL

      Tegyük tehát fel, hogy a szoftveres monitorozást választottuk amiatt, hogy a hangot (legyen az pl. az énekesünk hangja) plug-in effektekkel használjuk. Mivel kell számoljunk?

      Először is, már beszéltünk arról, hogy a monitoring esetén nagyon nem mindegy az előadás szempontjából, hogy a zenész milyen késéssel hallja magát. A "megfelelő", vagy a "jó" ide kevés, mert alapvetően befolyásolni fogja az előadás minőségét az, hogy mennyire “feszes” a játékérzete. Én személy szerint egy 10ms-nál nagyobb roundtrip latencyt mutató rendszerrel nem érzem magam jól.

      De ez csak a kezdet, mert amit most írok, az több háztartásban ki fogja verni a biztosítékot:

      SOFTWARE MONITORING ESETÉN A LOGIC NEM TUDJA KIKOMPENZÁLNI A KÉSÉST OKOZÓ PLUG-IN LATENCY-T.

      Eredmény: a felvett audió rossz helyre fog kerülni, nem oda, ahova fel lett játszva!

      Elevenítsük fel: mi okozza a késést? A buszokon, auxokon és outputokon elhelyezkedő késést okozó plug-inek. Ezek mind audió késést okoznak (igen, a beépített metronómét is), és természetesen a playhead is sietni fog ahhoz képest amit hallunk. A lényeg, hogy szoftver monitoring esetén a Logic a playhead aktuális helyére fogja “letenni” az audiót, ami ugye időben korábban jár a játékunkhoz képest, ami viszont a késő metronómmal van szinkronban, és a Logic ezt utólag se kompenzálja. Bentmaradt egy Adaptive Limiter vagy egy Pitch Corrector valahol a sessionben miközben a PLC mode “ALL”-ra van állítva? A felvett audiónk minimum 40 ms-mal el fog csúszni ahhoz képest, ahogy mi azt játszottuk a valóságban.

      Megoldások erre a problémára:

      1) Felvétel idejére kikapcsoljuk a software monitoringot. Ezt a gombot ki lehet rakni a transport barra, és gyorsan lehet kapcsolni. A probléma ezzel az viszont, hogy nem fogjuk hallani a játékunkat a monitorban, hacsak nem direct monitoringet alkalmazunk (külső keverő vagy a hangkártya beépített keverője révén), de abban az esetben sem fogjuk hallani a monitorban a Logic effektjeit. Viszont a felvet audió a helyén lesz, és talán egyetértünk, hogy ez a legfontosabb.

      2) Kiszedjük a késést okozó plugineket. Megint: mi okoz plug-in késést? Az Aux, Bus és Output csatornákon levő késő plug-inek, amennyiben a Latency Compensation ALL-ra van állítva (és arra lesz, különben a sávok csúsznak szét). De itt áljunk meg:

      Jegyezzük meg jól: a késést okozó pluginek bypass-olása önmagában nem szűnteti meg a kését Latency Compensation All Mode-ban, csak ha konkrétan eltávolítjuk őket!

      3) Low Latency MÓD

      A Logic bevezetett egy úgynevezett Low Latency módot (LLM), ami segít mindkét előző problémán. Sajnos a gépkönyv is elég szűkszavúan magyarázza el, úgyhogy én most ezt tovább göngyölítem. Annyi bizonyosan fontos, hogy LLM bekapcsolt állapotában a teljes pluginek okozta késés legfeljebb annyi lesz, amilyen küszöbszintet beállítunk, és ez lehet a maximális eltérés a felvett audio felvett és tényleges helye között. Ha nullára állítjuk, akkor minden körülmény között halálpontosan ott lesz a felvett hang, ahova azt játszottuk.

      A Low Latency Mode a Preferencesben beállítható funkció, két paraméterrel: a transport barra is kirakható on-off kapcsolóval, és egy küszöbértékkel. Bekapcsolt állapotában a küszöbértéket meghaladó késéssel bíró plug-ineket bypassolja, vagy kikerüli azokat. Ezek tehát a bus, aux és output és minden input enabled audio csatorna.

      Működésének eredményeképp persze megváltozik a hangkép (bypassol), de legalább a szinkron megmarad arra a felvétel idejére, ahol a monitorozás és az késés kompenzációja fontos.

      Apropó. A LLM bypass-e úgy látszik, hogy narancssárgák lesznek azok a pluginek, amiket hatástalanít késésük miatt. Ekként:

      -Megszűnteti a felvételi sávon keletkező késést a pluginek bypassolásával

      -Emiatt megszűnteti a késés kompenzálását is

      -Kikapcsolja a késéssel bíró sávokra vonatkozó sendeket is a felvételi sávon

      Utóbbi okozhat problémát (szétcsúszik a mix), amire bevezették azt, hogy az adott send gombra jobb kattintással kiválaszthatjuk a “Low Latency Safe” módot, ekkor nem fogja bántani (szét is csúszik, de mondjuk ez egy zengető esetében nem akkora probléma).

      Még két dolog:

      1) Plug-In Compenstation All mode-ban az output csatornán nem fogja kiszedni a késést, hanem trükkösen azt teszi, hogy megtartja az összes plug-int, és a felvételre kijelölt csatorna hangját az utolsó késést okozó plug-in után köti be! (erre írtam, hogy nem csak bypassol. hanem megváltoztathat jelutat is)

      2) Plug-In Compensation Mode= Off vagy Audio+Software instrument állásában csak akkor bypassolja a felvételi csatornán levő késő plugineket, ha a késésük meghaladja az output csatornán levő plug-in késést, illetve az ouptut csatornán levő késést csak akkor szűnteti meg, ha a felvételi csatornán késést okozó pluginek vannak. Szép!

      Láthatjuk tehát, hogy a LLM egész elfogadhatóan megoldja a monitorozás késésének problémáját és azt is, hogy a felvett audió a helyén legyen.

      Ez igaz is, de csak addig, míg nincs külső MIDI-s hangszerünk a mixben. Uhh.

      Ha ugyanis külső MIDI hangszert software monitoring révén hallgatunk, akkor a LLM módban az MIDI hangszer visszatérő audio csatornája nem lesz szinkronban a többi sávval (amennyiben történik effektív késés kompenzáció, vagyis vannak késést okozó pluginek), mivel az LLM nemcsak a felvételi sáv, hanem a monitorozásra kapcsolt sávok késését is megszűnteti, ahol a MIDI hangszerünk audió jele visszatérne.

      Itt van egy kivétel: ha External Instrument Plug-innel vezéreljük a hangszert. Az External Instrument Plug-in, azonban két okból sem tökéletes megoldás (ahogy a többi sem): 1) a sáv hangereje és panorámája állat módon a MIDI hangerő és panoráma üzeneteket használja, aminek az a következménye, hogy egy több partos MIDI hangszeren nem tudunk sávonként MIDI hangerőt és panorámát állítani, illetve egyik kihat a másikra. 2) Egy ilyen plugin sávja MIDI eseményeket tartalmaz, tehát ha fel szeretnénk venni az audiót bármilyen módon, az ezzel a módszerrel nem kivitelezhető

      További módszerek:

      -A felvétel idejére kikapcsoljuk a MIDI sávokat. A hátránya nyilvánvaló, kényelmetlen, főleg ha sok sáv van.

      -A MIDI sávokon a track delay parameter box-ban be lehet kapcsolni az “Auto Compensated Delay Offset” funkciót, ami rendet tesz, de csak addig, míg ki nem kapcsoljuk a LLM-ot, mert akkor megint minden kiesik a szinkronból.

      -Ha audio csatornán monitorozzuk, akkor felvesszük a hangszer hangját audióba, ami tényleg pofonegyszerű. Én ezt tenném, ha késést okozó pluginekkel dolgozunk.

      BOUNCE

      Az előző megoldások között kvázi bounce-oltunk, mikor felvettük a külső MIDI hangszer hangját, és ha már így kiveséztük a szinkron kérdést, vegyük szépen ide az ezzel kapcsolatos problémákat!

      Amit szeretnénk, az az, hogy akár Bounce In Place, akár Export Region / Track , akár Output Bounce esetén a felvett audio szinkronban legyen az eredetivel.

      (Az Export Region / Track egyébként azonos a Bounce In Place funkcióval azzal a különbséggel, hogy utóbbi hozzáadja az audio file-ot az arrange-hez)

      Itt egyetlen teendő van: bármiféle bounce előtt a Plug-IN Compensation-t ész nélkül“ALL”-ra kell állítani. Mégegyszer hangsúlyozom: a Bounce In Place rosszul fog működni, ha az előző paraméter nem ALL, és vannak késő plugin-ek.

      HARDVER MIDI HANGSZEREK

      Ha valaki arra adta a fejét, hogy vasakat használ, most újragondolhatja. Tekintsünk el az új megoldásoktól most, mint pl. a MOTU VOLTA vagy az EXPERT SLEEPERS SILENT WAY, beszéljünk hagyományos MIDI-s hangszerekről. MIDI, SCSI, CV/GATE, legyen az bármi, engem nem tántorít el, úgyhogy akik így vannak ezzel, azokat tökéletesen megértem, és így a Pokolban nem leszek egyedül.

      Megértettük az előbb az audió jel monitorozásának és felvételének problémáját, és találtunk megoldást is azokra.

      Miért tér el ettő a MIDI hangszer audió jele?

      Hát pont a MIDI miatt, mely kompenzálásáról nekünk kell gondoskodni, ahogy azt fentebbb említettem. Most viszont a módszereket tárgyalom.

      MIDI HANGSZER HANGJÁNAK FELVÉTELE

      Mielőtt belekezdünk, vegyük úgy, hogy nincsenek most pluginek, egyedül I/O latencyvel kell számolnunk.

      Itt van az első és lefgontosabb szabály: bármilyen hangforrást a monitorozás HELYÉN kell felvegyük. Tudom, hogy ezt nem lesz egyszerű megérteni, de megpróbálom elmagyarázni.

      Az elv az, hogy a monitorozás helyén (tehát ahol hallgatjuk a mixet), minden szinkronban fog szólni, ezt szeretnénk legalábbis.

      Ha ez adott, az csakis úgy lehetséges, hogy az addigi sávok, csatornák stb mind megfelelő módon össze lettek szinkronozva.

      Ha egy külső MIDI hangszert (a MIDI jelet a Logicból kapja mindenképp) akarunk felvenni egy analóg keverőn, ahol együtt szól a Logic audio részével, akkor problémánk semmi.

      Viszont ha szoftver monitorozásra adtuk a fejünket, tehát a hangkártyán és a Logicon keresztül halljuk a hangját, akkor bizony nagyon kell figyelnünk most.

      Ha ugyanis szoftverből monitorozzuk a hangszert, akkor az alapelvet, vagyis hogy a monitorozás helyén vesszük fel a hangszer hangját nem tudjuk teljesíteni csak úgy.

      Ha most egy MIDI hangszert megpróbálunk audióban rögzíteni a sessionünkkel úgy, hogy még csak plug-int sem használunk, azonnal megtapasztaljuk azt, hogy a felvett hang SIETNI FOG a Logic metronómjához képest! Hogy mennyire, az a hangszerünk reakciójának sebessége és a hangkártyánk latency értékének kombinációjából adódik.

      K: Hogy lehetséges mindez?

      V: A Logic a roundtrip latency értékével kompenzálja a MIDI hangszer hangját, mivel ennyi a teljes távolság a monitorozás fizikai helyéhez képest. Másképp szólva, a külső hangszer hangja “túl korán” lép be a láncba a metronómhoz, vagy a rácshoz képest.

      K: Hogy kezeljük ezt a problémát?

      Azon kívül hogy nem törődünk vele, mert szuper kicsi latencyvel dolgozik a kártyánk, gyorsak a hangszereink és ennek mértéke nem zavar, van valami, ami nagyon sokat segít kis kellemetlenségért cserébe.

      A Logic Environmentjében létrehozzuk az audio bemeneti csatornákat, melyeken felvesszük a hangerőt, és kimenetüket egy buszra küldjük. Az audio csatornán ha a buszt jelöljük meg inputnak, akkor a MIDI hangszerünk hangját tökéletesen pontosan fogja felvenni. Egyedüli hátránya az, hogy a bemenet elnevezése nem lesz beszédes, hanem az lesz hogy “Bus 1” vagy “Bus 5” stb.

      K: Miért működik ez?

      V: A Logic a buszról jövő jelet NEM fogja kompenzálni a roundtrip latency értékével!

      A MIDI LATENCY RÉSZLETESEBBEN

      Korában elmagyaráztam miből áll ez a dolog, hogy itt is bufferek, meg MIDI késés, de most néhány apróságot meg kell magyarázzak.

      A MIDI folyamatában úgy zajlik, hogy a MIDI vezérlő (vagy szinti) érzékeli, hogy lenyomták a billentyűjét, amire generál egy "Note On" eseményt melyet MIDI-n vagy USB-n eljuttat a számítógépbe, ott a különböző meghajtó programok révén bekerül a zenei szoftverbe (bufferek, stb).. A MIDI átvitele nem hasonlít az audióéra, amit most nem taglalok, de annyit jó tudni, hogy minden egyes "Note On" üzenet továbbítása kb 1 milliszekundumot igényel. Egyszerre csak egy üzenet továbbítható, ami azt jelenti, hogy a MIDI latency értéke NEM KONSTANS, hanem folyamatosan változik. A késések változását JITTERNEK hívjuk. Ha leütünk egy 4 hangból álló akkordot, a 4. hang 4 ms késéssel tud csak megszólalni az elsőhöz képest, stb. Ezért fontos az, hogy a MIDI kontrollerünk ne küldjön fölösleges üzeneteket (pl. aftertouchoz, ha nem használjuk).

      Én a MIDI hangszerek késésének a kompenzációjával (tehát azzal, hogy egy hangszer egy midi kontroller note on üzenetétől számítva mennyi idő múlva produkál hangot, és ezt a késést kompenzálni) mindenképp foglalkoznék. Nagyon is!

      KÜLSŐ MIDI HANGSZEREK KÉSÉSÉNEK KOMPENZÁCIÓJA

      A külső MIDI hangszerekről tudjuk, hogy egyérszt a MIDI latency létezése miatt bizonyos szinten késnek. Ezt lejátszáskor akarjuk kompenzálni azért, hogy a rácsra igazított MIDI hang pont ott szólaljon meg, vagyis a MIDI eseményeket picit korábban szeretnénk lejátszani, pont a rájuk jellemző MIDI latency-vel.

      Miután elértük azt, hogy a MIDI hangszer hangját a megfelelő helyre vegye fel a Logic, ezt gyerekjáték kikompenzálni.

      Tényleg csak röviden:

      -Csinálunk egy teszt midisávot, ahol mondjuk negyedhangonként kiküldünk note-ont minden hangszernek, melyek hangját felvesszük.

      -Ebből látni lehet majd azt, hogy a MIDI hangszerek hangja mennyit késik egymáshoz képest. Ez egy változó érték lesz, mert a MIDI esetében van jitter is. Tehát átlaggal kell dolgoznunk, 1ms-os pontosság elgendő lesz.

      -Meg kell keresni a legtöbbet késő hangszert, és ahhoz késleltetni a fürgébbeket a track delay paramter boxban beírva a számot.

      -Ekkor a hangszerek egymáshoz képest szinkronban lesznek, most kell tehát megadni egy globális MIDI kompenzációt (All MIDI Output paraméter), hogy a közös késéssel korábban küldje ki a MIDI jeleket (Preferences Menü MIDI sync rész).

      -Ha mindez sikerült, akkor a MIDI hangszereink félelmetes pontossággal fognak igazodni a metronómhoz, egymáshoz, vagy bármihez a dalban.

      FIGYELEM: egy apró megjegyzés: ne hagyjuk ki a számításból a klasszikus-ordas Logic hibát, nevesen hogy indításkor az első ütem “csonka”.

      Nálam valahogy ez így nézett ki:

      

      Ezeket összekombinálva a kiberjáratok késésével meghatározhatók a sávok késése és a globális MIDI késés kompenzáció, ami nálam így alakult:

      (Látható, hogy a leglassabb hangszereimet, az EII-t és az SE1x-et nem kompenzáltam, mert azok annyit késtek, hogy emiatt nem akartam a többi hangszert "büntetni". Vállaltam, hogy kézzel odahúzom majd, ahova kell, de azért tudom mennyit késnek).

      

      FIGYELEM: haladó Logic felhasználókban esetleg felmerülhetett, hogy miért nem használom a track MIDI delay paraméterbox késleltetését (az auiocompenstation-ről már írtam, most az értékekről beszélek). Az oka az, hogy nem működik. A bug rendkívül körülményesen kerülhető meg, nem javaslom a használatát. A region delay paraméterét meg azért nem javaslom, mert az meg a dal tempójához van kötve, ami újabb problémákat generál, kerüljük ezt is, maradjunk az audio inputok késleltetésénél. Ez van. Jó Logicozást...

      SZOFTVER HANGSZEREK (Plug-in-ek)

      A szoftver hangszerek általában önmagukban nem növelik a rendszer késését, megszólalásuk “fürgesége” tehát csupán a rendszerre vonatkozó latency lesz. Ezen tényezők:

      1) MIDI bemeneti késése:, amit előbb tárgyaltunk.

      2) A zenei szoftver a buffer méretének megfelelően késleltetve produkál valamiféle audio jelet, amit a szokásos nem-buffer tipusú késések követnek.

      Jegyezzük meg: a szoftver hangszerek lejátszásának késését a MIDI késése, az audio I/O késése, és a járulékos plug-in késések összege határozza meg.

      AUTOMATIKA

      Eredeti tervem az volt, hogy kifejtem az automatika problémáját a késés viszonylatában, de ez még az eddigiekhez képest is komplikált, viszont nem akkora tragédia, mint pl. egy rossz helyre felvett hang. Tényleg csak egy mondat erejéig: az automatika problémáját az okozza, hogy az automatizálni kívánt paramétert megelőzi egy késést okozó plug-in. Ekkor az automatika és az audio file szinkronja elvész, az audio pl. korábban játszik le, de az automatizált plug-in az előtte levő késő miatt annyi késéssel avatkozik csak be. Főleg buszra küldéssel lehet megoldani a problémát kombinálva a teljes késés kompenzáció bekapcsolásával.

      TESZT

      Ha valaki eljutott idáig, most leellenőrizheti, hogy mit értett meg a cikkből!

      Mit nevezünk roundtrip latency-nek? (+10 pont)

      Spoiler

      A teljes audió jel késését a bemenettől a kimenetig.

      Hogy tudjuk megmondani legegyszerűbben, hogy plug-injeink vagy csatornánk mennyit késik éppen? (+10 pont)

      Spoiler

      A Mainstage szoftverben a plug-inek behívásakor kijelzi a csatorna késést .

      A zenei szoftverünk bufferét 256 mintára állítottuk, mivel így tudja stabilan, pattogás és recsegés nélkül lejátszani a sessiont. Mennyivel fogja késleltetni a lejátszott audiót az egyéb, nem bufferi tényezőkön kívül milliszekundumban? (+10 pont)

      Spoiler

      256/44.1=5.8ms

      Az egyik buszon egy késést okozó plug-int használunk, miközben a Compensation Mode ALL-ra van állítva, és nincs bekapcsolva a Low Latency Mód. Egy audio sávon felvételt készítünk, és azt tapasztaljuk, hogy az audio siet az eredeti előadáshoz képest. Miért van ez? (+10 pont)

      Spoiler

      A Logic szoftveres monitorozás esetén nem tudja kompenzálni a plug-inek okozta késést

      Hány milliszekundumos eltéréstől tudjuk megkülönböztetni azt, hogy a két külön hangot hallunk? (+10 pont)

      Spoiler

      Kb. 10ms

      Hogy lehetséges az, hogy a Logicból vezérelt külső MIDI-s hangszer hangját felvéve az audió siet a többi sávhoz képest? (+10 pont)

      Spoiler

      Szoftverből monitorozunk a hangszert, és onnan próbáljuk felvenni, nem pedig a kimenetről.

      Meg szeretnénk szűntetni egy késést okozó plug-in hatását. Mondj két módszert erre Logicban! (+10 pont, fél válaszért +5 pont, rossz válaszért -40 pont)

      Spoiler

      Rossz válasz a plug-in Bypass-olása, jó válaszok a Low Latency Mód bekapcsolása és a plug-in eltávolítása.

      Ha késést okozó plug-ineket használunk, mire kell ügyelni Bounce-kor? (+5 pont)

      Spoiler

      A Plug-IN Compensation-t “ALL”-ra kell állítani. 

       

      A Low Latency Compensation Mode LLM milyen esetben nem bypass-olja a plugineket "ALL" mode-ban? (+15 pont)

      Spoiler

      Output csatornákon az élő sávokat az utolsó késést okozó plugin után köti be, az előtte levőket nem bypass-olja.

      Ha tetszett a cikk, oszd meg másokkal is a linket! (Kérlek, ne másold ki innét és vidd el másik oldalra!)