LOGIC JÁNOS: A Mindenek Késése, Avagy a Latency.

[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!)

[Tetsuo]

Na vegre! Olvasnivalo.

[mohawk]

Zsír Köszönet!

[Wheel]

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.

Sokszor szenvedtem a probléma miatt és a logic manuált figyelmesen tanulmányozva is csak felemás megoldásokat sikerült elérnem.

Köszi a cikket, rendkívül hasznos!

Van-e megoldás, ha már megtörtént a szétcsúszás? Lehet újra feljátszani mindent?

[A/D]

Sokszor szenvedtem a probléma miatt és a logic manuált figyelmesen tanulmányozva is csak felemás megoldásokat sikerült elérnem.

Köszi a cikket, rendkívül hasznos!

Van-e megoldás, ha már megtörtént a szétcsúszás? Lehet újra feljátszani mindent?

Igen, kézzel beigazítani "fülre". Ezt szokták csinálni, még a legprofibb helyeken is. Csak én UAD-ozom és MIDI-zem is elég erősen, és be kellett tömnöm a hiányzó rést. Annyit hozzátennék, hogy a Logic Trainerek képzésének legfelső szintjén sem tananyag ez, még érintőlegesen sem.

[JánosHorváth]

Nem akarok nagyképűnek tűnni, de a leírt lényeg úgy kb. ismert nekem. De ilyen jól megfogalmazott, pedagógiailag, didaktikailag rendbetett, szerkezetében megszerkesztett ismeretterjesztést már régen olvastam. Gratula! Írjál tankönyvet, mert nem tudom, van-e ilyen színvonalú magyarul. (vagy fordítottad ? )

[Wheel]

A túlnyomó része nekem is ismert volt, mert hónapokon keresztül kerestem a megoldást.

A baj az, hogy nem találtam sehol elegendő segítséget. Amit A/D leírt, annak részleteit megleltem, csak pont a rendszer és az összefüggések hiányoztak. Így pedig - számomra - megmagyarázhatatlan módon, egyszer működött helyesen a kompenzáció, máskor pedig szétesett. A rácshoz képest pedig mindig elcsúszva.... Az lett a vége, hogy elkerültem minden veszélyes helyzetet és csak audiót vettem fel, külső monitorozással. A külső midi hangszereket is rendesen feljátszva. Persze ettől csak jobb lett:-).

[Wheel]

Igen, kézzel beigazítani "fülre". Ezt szokták csinálni, még a legprofibb helyeken is. Csak én UAD-ozom és MIDI-zem is elég erősen, és be kellett tömnöm a hiányzó rést. Annyit hozzátennék, hogy a Logic Trainerek képzésének legfelső szintjén sem tananyag ez, még érintőlegesen sem.

Arra kíváncsi lennék, hogyan és mennyi munkával jutottál az ismerethez.

Jánossal pedig maximálisan egyetértek.

[A/D]

Nem akarok nagyképűnek tűnni, de a leírt lényeg úgy kb. ismert nekem.

Természetesen a profik ismerik a nagy részét a dolognak, amit muszáj volt tárgyalnom ahhoz, hogy egyáltalán fel lehessen fogni olyat, mint pl. a MIDI hangszer szoftver-monitoring időkorrekciójának a problémáját, ami kicsit sem triviális (A Pro Tools pl. nem tud MIDI-t kompenzálni más késéshez, Silk napokig vinnyogott emiatt), vagy hogy meg tudjunk egyezni az egyes csatornák fogalmában. Az automatikát is befejtettem, amiről fogalmam nem volt, de kb. akkora lenne terjedelemben mint ez az egész cikk, arra már nem vállalkoztam, bíztam abban, hogy ez megteremti az alapokat hogy valaki könnyen rájöjjön azokra az apróságokra is.

van-e ilyen színvonalú magyarul. (vagy fordítottad ? )

Saját munkám, amihez persze olvastam a netről is, meg próbáltam mások segítségét kérni (időnként sikertelenül, pl. a track parameterbox midi delay bug, amit a külföldi fórumokon se tudtak megugatni)

Arra kíváncsi lennék, hogyan és mennyi munkával jutottál az ismerethez.

Jánossal pedig maximálisan egyetértek.

Először elkezdtem "alternatív" módszerekkel dolgozni, ADAT-ra kötött Apolló és társai (Apolló is késik egyébként picit, csak hogy cifrább legyen a dolog), meg hogy hogy mérjük meg a késéseket plugineknél (buszos átkötések stb). Aztán az addigiakból kb. 2 hét alatt megcsináltam a jegyzeteimet és a méréseimet, és a cikket...kétszer kezdtem neki. Az első verzió olyan részletes volt, hogy soha nem készült volna el, újra kellett gondolni meg átszerkeszteni az egészet. Így a megírás olyan 6-8 óra lehetett szerintem összesen (nagyon gyorsan gépelek). Nem hiszem hogy hamarosan hasonló kaliberű dologra vállalkoznék, de talán nincs is már olyan téma, ami ilyen horderejű utánajárást igényelne. Mindenesetre a cikk születésének egyik okozója, hogy nagyon durván alábecsültem az ehhez szükséges időt. Ahogy szoktam

[JánosHorváth]

Pedig arra akartalak rábeszélni, hogy írj egy olyan kaliberű könyvet - vagy a neked leginkább jól fekvő részét - ami egy olyan magyar nyelvű alapmű lenne, ami alapján pl. nyugodt lelkiismerettel lehetne tanítani pl. tanfolyamokon. Tudod olyan Recording Handbookot, az azért még néhány órát igénybe venne, 3-4 szerző esetén is.

[A/D]

Pedig arra akartalak rábeszélni, hogy írj egy olyan kaliberű könyvet - vagy a neked leginkább jól fekvő részét - ami egy olyan magyar nyelvű alapmű lenne, ami alapján pl. nyugodt lelkiismerettel lehetne tanítani pl. tanfolyamokon. Tudod olyan Recording Handbookot, az azért még néhány órát igénybe venne, 3-4 szerző esetén is.

Erre kellene hogy legyenek emberek. Akik napi szinten ezzel foglalkoznak, ezzel keresik a kenyerüket. Ez nem a kereskedelem dolga ezen a szinten (bevallom, ehhez több kedvem lenne, mint ahhoz, hogy naponta csekkoljam a kíváló idevetődött külföldiek, a Friendly és a Muziker árlistáit és manővereit, akik kizárólag kereskedelmi tevékenységet fejtenek ki).

És végül, szerintem vannak, akik nálam sokkal jobban tudnak publikálni. Én láttam Silket előadni, ahogy elmagyarázta az impedancia illesztést, majdnem megkönnyeztem. De bizonyosan vannak még egyetemeken is megfelelő képességű emberek. Lehet, hogy velük kellene beszélni.

[dchord]

őőő, ebből már nem lesz semmi ... http://www.controlle...kerdeskonyv.php vagy/és csak fönnragadt a neten az oldal ?

Szerkesztette January 16, 2013 dchord

[A/D]

őőő, ebből már nem lesz semmi ... http://www.controlle...kerdeskonyv.php vagy/és csak fönnragadt a neten az oldal ?

Én arra tippelek, hogy ez a könyv egy jó összefoglalása lesz pár alapigazságnak. Gábor jól ír, valószínű egy hasznos darab lenne.

Csakhogy az ilyen "bevezetés a stúdiótechnikába" írásból (változó színvonalon) már Dunát lehet rekeszteni. Ilyet csinál mindenki, aki úgy érzi, hogy meg kell írnia első cikkét a témában, tele vele a net. Vagy épp tanfolyamot hirdet rá Azok az emberek, akik viszont alkalmasak lennének komolyabb értekezés összeállítására (mérnöki háttérrel), azok nem írnak, ugyanis nem fizetik ki őket. Ha nem a megélhetésükért küzdenének, nyilván karitatíve is bedobhatnák a köz javára, de tudjuk jól, hogy nem ez a helyzet. Szerintem az egyetemeknél van az aduász.

[dchord]

Szerintem az egyetemeknél van az aduász.

erről beugrott, Sík Zoltán - Gerényi Gábor: MIDI (1992) (Alapozás és Protokoll), hátha valaki nem ismeri, http://gg.index.hu/g...dikonyv/map.pdf , gyűjtitek valahol ezeket a fórumon ( midikonyv/ - re rákerestem semmi)

ui. fenti könyvet azért kérdeztem mert szerintem már 2éve kint van, a Megjelenés: hamarosan!

Szerkesztette January 16, 2013 dchord

[sonnyCoca]

Hello!

Nagyon hasznos cikk lett! Egy kiegészítésem lenne:

> a szoftver hangszerek élőben kötelezően kvantálják a hangokat.

A (kulturáltan megírt) szoftver-hangszerbe beérkező MIDI jelek 1 puffernyi késést szenvednek, de nem kvantálódnak: a plugin az összes MIDI eseményt timestampezve kapja meg, és csak rajta áll, hogy a kötelező késleltetésen túl (mert csak pufferméret / parameter automation töréspontok esetén kezdődik új render ciklus) hogyan játsza le őket.

Általában figyelni szoktak arra, hogy a megfelelő sample-től kezdve kezdje csak el játszani a hangot, ellenkező esetben a DirectSound-os / külső DSP által agyonkésleltetett 2048 / 4096 -os pufferméret tartomány nemcsak játszhatatlan, de használhatatlan is lenne.

[A/D]

> a szoftver hangszerek élőben kötelezően kvantálják a hangokat.

A (kulturáltan megírt) szoftver-hangszerbe beérkező MIDI jelek 1 puffernyi késést szenvednek, de nem kvantálódnak: a plugin az összes MIDI eseményt timestampezve kapja meg, és csak rajta áll, hogy a kötelező késleltetésen túl (mert csak pufferméret / parameter automation töréspontok esetén kezdődik új render ciklus) hogyan játsza le őket.

Értem mit írsz, és mivel elképzelhetőnek tartom a kivitelezését, nem kételkedek szavadban, nyilvánvalóan te találkoztál ilyen pluginnel is. Én még nem, de ez a csodálatos a közösségi tudásban Szóval köszönöm, kiegészítettem a cikket, és megjelöltelek benne forrásként.

[wendelmar]

(megj: sem a Windows, sem az OS-X nem realtime operációs rendszerek)

Hát igen nem győzöm hangsúlyozni, linux a megoldás! http://www.redhat.com/products/mrg/realtime/ mondjuk most nem ez van fent, hanem egy ubuntu studio, de mindenhogy váltani fogok rhel-re, 3ms így is megvan ja és wine+wineasio+fl studio9-el, ami nem semmi szerintem, mert nem is natív a cuccos. Amúgy gitárnál vettem csak észre hogy "késik". Hangkártyám meg ennél nevetségesebb már csak a 24bit/48khz-s adataival... Egyébként a RHEL szakértők szerint az operációs rendszerek királya. Szerkesztette January 16, 2013 wendelmar

[nightray]

Nagyon tetszett a cikk!

De, én arra lennék kiváncsi, hogy pl. mi a helyzet a Virus Ti Snow esetében?

Tehát, ha USB-n keresztül használom, s szeretnék néhány sávot felvenni Logicban.

Sokat szivttam vele...

USB-n küldi a midi jelet a számítógép a Virusnak, de az audio jel a virusból a gépbe is az USB-n történik.

Maga a Virus is kompenzál...

Szóval, a kérdésem, hogy lehet Virussal normálisan késés nélkül felvenni, ha adott egy Mac, Apogee Duet (fw), meg a Virus Ti Snow?

Szerkesztette January 16, 2013 Night Ray

[A/D]

Hát igen nem győzöm hangsúlyozni, linux a megoldás! http://www.redhat.co...s/mrg/realtime/ mondjuk most nem ez van fent, hanem egy ubuntu studio, de mindenhogy váltani fogok rhel-re, 3ms így is megvan ja és wine+wineasio+fl studio9-el, ami nem semmi szerintem, mert nem is natív a cuccos. Amúgy gitárnál vettem csak észre hogy "késik". Hangkártyám meg ennél nevetségesebb már csak a 24bit/48khz-s adataival... Egyébként a RHEL szakértők szerint az operációs rendszerek királya.

A realtime operációs rendszerek vaóban izgalmasak. Volt a kezem alatt egy Fairlight CC-1es rendszer, az ütött vágott, szerintem az lehetett a fedél alatt. Mindez nem jelenti azt, hogy a Linux júzereknek nem kell számolni plugin, vagy MIDI latencyvel. Ezért és emiatt pontosan ugyanazok vonatkoznak rájuk, min t a nem realtime OS-t használókra. Sajnos

De, én arra lennék kiváncsi, hogy pl. mi a helyzet a Virus Ti Snow esetében?

Tehát, ha USB-n keresztül használom, s szeretnék néhány sávot felvenni Logicban.

Sokat szivttam vele...

USB-n küldi a midi jelet a számítógép a Virusnak, de az audio jel a virusból a gépbe is az USB-n történik.

Maga a Virus is kompenzál...

Szóval, a kérdésem, hogy lehet Virussal normálisan késés nélkül felvenni, ha adott egy Mac, Apogee Duet (fw), meg a Virus Ti Snow?

A VIRUS mint plugin úgy működik, mint az External Instrument plugin, amit már érintőlegesen tárgyaltam a cikkben azzal a szerencsés kiegészítéssel, hogy az automatika probléma nem érinti a multi kimenetek miatt. Ha tehát ilyen USB-s plug-in hangszerknt használod, ott totális és tökéletes késéskompenzációnak kellene lennie papírforma szerint. MIDI-n pedig ugyanaz a helyzet, mint bármilyen MIDI hangszerrel. Én soha nem használtam még felvételen Virust sajnos, szóval ha nem így működik, azt valami Virus gurunak kellene megnéznie (az már nem Logic vagy DAW probléma)

[Tetsuo]

Én arra tippelek, hogy ez a könyv egy jó összefoglalása lesz pár alapigazságnak. Gábor jól ír, valószínű egy hasznos darab lenne.

Csakhogy az ilyen "bevezetés a stúdiótechnikába" írásból (változó színvonalon) már Dunát lehet rekeszteni. Ilyet csinál mindenki, aki úgy érzi, hogy meg kell írnia első cikkét a témában, tele vele a net. Vagy épp tanfolyamot hirdet rá Azok az emberek, akik viszont alkalmasak lennének komolyabb értekezés összeállítására (mérnöki háttérrel), azok nem írnak, ugyanis nem fizetik ki őket. Ha nem a megélhetésükért küzdenének, nyilván karitatíve is bedobhatnák a köz javára, de tudjuk jól, hogy nem ez a helyzet. Szerintem az egyetemeknél van az aduász.

Ezt nem ertem. Miert tuti buko egy ilyen konyv (penzugyileg)? Szerintem rengetegen megvennek, valoszinuleg le is forditanak, ha tenyleg jo.

[Shatva]

Igen, kézzel beigazítani "fülre". Ezt szokták csinálni, még a legprofibb helyeken is. Csak én UAD-ozom és MIDI-zem is elég erősen, és be kellett tömnöm a hiányzó rést. Annyit hozzátennék, hogy a Logic Trainerek képzésének legfelső szintjén sem tananyag ez, még érintőlegesen sem.

Nem tananyag? Akkor mivan ezekkel?

No akkor most már dupla szánalom a logicnak! Egyszerűen nem értem hogy tehetnek ilyet 21. században! Nekem volt egy nagy csalódásom amikor a vasaimat akartam bemidizni! És macen logic 8al! Nem volt elég hogy hamisak a hangszerek! Még ott volt az hogy mindig máshol vette fel! Hát megőrültem mire kifundáltam azokat amiket írtál! Hogy újra kell indítani! Hogy ez az amaz! Egy dolog működött az meg az 5ms asio latencyaztán jóvan! Lehetett minimálkodni pár sávon!

De aztán a végső lökést az adta meg hogy nem volt benne audio quantization (akkor még), aka Ableton warp. Vettem is akkor egy Ableton 6ost gyorsba.

Saját tapasztalatok!

Sajnos nagyon sok nemjó!

Főleg akkor ha precííz vagy akkor! Hogy miért! Mert akkor soft monitoringot használsz mert pl utálod azt hogy a hardware monitorban másképp szól mint amikor lekonvertálódik egy file-á a DAW-ban! Ez pl gáz! De ezen is túl kell tenni magad,és a mixing részt egy másik munkafázisba tenni, szépen megtanulni használni az eq-t!

Itt viszont további kompromisszumot kell kötni ha rossz a latencyt!

Hogy miért!?

Ha rossz a latency-d rosszul fogsz midizni mert olyan sánta lesz mint bicebóca egy arpeggátorod...5 ms felett ne nagyon menjünk fel mert nemcsak latency jelentkezik!!hanem jitter ami mégrosszabb!

A logic ezekszerint roppant amatőr ilyen téren és nem is értem! Mert az egyik kedvenc producerem már régóta használja vasakkal is!

AbletonLIve!

No a másik mumus! Más a késése ha recordarm on van egy track vagy midi track mintha sárga input monitoron lenne. Az arpeggátor effektbe biztosak lehetünk hogy nem tudja kompenzálni a midi jelet vissza -ba. Szóval itt is az 5ms győz! És ha olyan kis béna géped van mint nekem akkor be kell érned pár sávval, és gondolkozni azon milyen effekteket engedhetsz meg magadnak a projectben! Nehéz ügy!

Másik megoldás hardware monitoring! de attól még a midi jitterem nem lessz jobb...!

Több projectnél szerkeszteni arrangementet halál egy gyengébb gépen! Komolyabb zenei dolgokra emiatt eléggé besülős az egész! 10másodperc ha play közben átraks egypár kockát ide vagy oda...

A live engine-je mivel live ezért gondolom ilyen minél több sávon vagy annál rosszabb!

ezen kívül még Cubase ami a legnyerőbb! Sőt! Egy álom a többihez képest ha vasakkal jól akarunk bánni!

Egérgörgővel beállítjuk szépen a midi track delay-t vissza és élőben monitorozik stabilan.

És a jitter sem tűnik fel!

A cubase midiben magasan veri az összes DAW-ot! Valahogy az engine-t is jól pakolták össze!

De mivel az engineje nem livera van tervezve így a stoppokat többször kell nyomnod.

Viszont most van nekem egy új üdvöske. Ha elektronikus zenéről van szó. Az pedig a Renoise...

Azt viszont annyira nem hiszem hogy egy 4 note on az 4ms késés! Akkor strummolna nem tudna játszani polifón jelleggel!

Szerkesztette January 17, 2013 Shatva

[Shatva]

Apropó!

Kis latency-nél bizony takarékoskodni kell a procival, ezért előnyös ha egykattra van bounce in place!

Cubase-el két katt ,ha macro-t is használsz! Szóval az is megoldva!

Ableton Live-ban freeze-és kihúzod a sávot bár az kókány módszer! Mert a freeze nekiál az egész sávnak nem tudsz Szeleteken dolgozni!

Studio S1 ben meg ctrl+b és meg is vagy! ott ebben okosak! Midiben nagyon nem!

Szerkesztette January 17, 2013 Shatva

[Shatva]

Ableton Live-ban freeze-és kihúzod a sávot bár az kókány módszer! Mert a freeze nekiál az egész sávnak nem tudsz Szeleteken dolgozni! Megoldásom erre a újrabekötés egy másik sávra és élőben felvenni ami kell!

Szerkesztette January 17, 2013 Shatva

[boka]

Jo cikk lett.

A/D, kovetkezo kerdesem lenne : Tonnanyi sample-t hasznalunk/hasznalnak ma a studiokban. Szepen WYSIWYG ranagyitva ket pergo, labdob, akarmilyen mintakra latszik hogy a kezdeti tranziensek tokre mashol vannak. Termeszetesen ehhez nagyon ra kell nagyitani, de sokszor mar alapban is latszik az innen-onnan mar ki tudja honnan osszetarhalt mintaknal. Professzionalis kornyezetben ezt mikent kezelik? Ranezesre slip/slide editing, esetleg fazis korrekcio?

mas:

Native Instruments-cel nem keveset ugattam sample pontossag miatt. Teszt baromi egyszeru volt. Dob mintak audio savra, ugyanezek a mintak midibol VSTi-n keresztul (Battery), mindketto render, majd invert phase-zel nagyon nem nullaztak ki egymast. Mindenfele PDC, latency ertekkel jatszottam, mindig uj ertekekkel probaltak lerazni, es nem ment. A support szo szerint hulyenek nezett, hogy ez nekem miert problema. Kimertem mindent, hogy mi a baj, orakat oltem bele a screenshotokba, szamolasokba. Reapert hasznalok ami kiirja a csatornankent a latencyt es egy RME Multiface 2-esem van. Akkoriban mikor ez volt, egy Mac Pro-ban voltak ezek a kartyak, de ugyanez van most az i5 quad windows-os rendszeremnel. Eljutottam oda, hogy leszarom, nem erdekel. Mellesleg a supportos srac is Reaperben dolgozott, szerinte ilyen problema nincs, minden NI plugin sample pontos Probaljatok ki ezt az egyszeru tesztet, akar playback-nel is, ha nullat kaptok akkor boldogsag.

Szerkesztette January 17, 2013 boka

[Shatva]

Jo cikk lett.

A/D, kovetkezo kerdesem lenne : Tonnanyi sample-t hasznalunk/hasznalnak ma a studiokban. Szepen WYSIWYG ranagyitva ket pergo, labdob, akarmilyen mintakra latszik hogy a kezdeti tranziensek tokre mashol vannak. Termeszetesen ehhez nagyon ra kell nagyitani, de sokszor mar alapban is latszik az innen-onnan mar ki tudja honnan osszetarhalt mintaknal. Professzionalis kornyezetben ezt mikent kezelik? Ranezesre slip/slide editing, esetleg fazis korrekcio?

mas:

Native Instruments-cel nem keveset ugattam sample pontossag miatt. Teszt baromi egyszeru volt. Dob mintak audio savra, ugyanezek a mintak midibol VSTi-n keresztul (Battery), mindketto render, majd invert phase-zel nagyon nem nullaztak ki egymast. Mindenfele PDC, latency ertekkel jatszottam, mindig uj ertekekkel probaltak lerazni, es nem ment. A support szo szerint hulyenek nezett, hogy ez nekem miert problema. Kimertem mindent, hogy mi a baj, orakat oltem bele a screenshotokba, szamolasokba. Reapert hasznalok ami kiirja a csatornankent a latencyt es egy RME Multiface 2-esem van. Akkoriban mikor ez volt, egy Mac Pro-ban voltak ezek a kartyak, de ugyanez van most az i5 quad windows-os rendszeremnel. Eljutottam oda, hogy leszarom, nem erdekel. Mellesleg a supportos srac is Reaperben dolgozott, szerinte ilyen problema nincs, minden NI plugin sample pontos Probaljatok ki ezt az egyszeru tesztet, akar playback-nel is, ha nullat kaptok akkor boldogsag.

Szerintem profi körökben is eltérően csinálják! De ha rendezettlen hangmintád van. Először egy startpont majd levágod ahol a következő bar jön. És time toolal. vagy ami a logicban strechel behúzod vagy kihúod a vonalzó egy barjához. Onnan már tudni fogod a tempoját,ha hosszabb a loop és a többi résznél már könnyebb a dolgod.

Mégegyszer mondom...nagy latencynél nagyobb jitter, és ez ahogy tapasztaltam vst-re is vonatkozik...ÉS ez pláne nagyobb terhelésnél

Nem fontos a sample pontosság, ha jó a tempod a kutyát nem zavarja, a hallgatót se. Mert lehet benne sok minden effekt ez az,amitől nem sample pontos.Pl reverb-en van valami nem temposync mod stb..Inkább akkor van baj amikor érezhető hogy lötyög a ritmus és nem tudsz a zenédbe dinamikát vinni..

Szerkesztette January 17, 2013 Shatva