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

[xbitz]

no offense plííz , nálam ez nem értelmi hanem érzelmi síkon dőlt el, elindultam a minőség irányába (én ugyancsak három éve hangkeltőzöm) van egy Virus Desktop-om meg egy Roland SonicCell-em (jó ez nem minőség de van ) DAW-okból van Cubase-m, Studio One-om, Ableton Live-om, Reason-om (ismerem az : FL Studio-t, Reaper-t is) , ezekből egyedül a Reason-al való pepcselgetést élvezem, ezvan, most forduljak pszichológushoz ? )))

ui: jah ilyenkor nem téged mindig magamat győzködöm a Reason-ról , de érzelmeket nem nagyon lehet észérvekkel befolyásolni sajna-vagy nem kitudja, a kérdésem mindig magam felé : érdemes-e a minőségre törekednem ha a hozzávezető utat nem élvezem ... perpill a válaszom: nem, de kitudja mi lesz a későbbiekben

Szerkesztette March 1, 2013 xbitz

[Shatva]

no offense plííz , nálam ez nem értelmi hanem érzelmi síkon dőlt el, elindultam a minőség irányába (én ugyancsak három éve hangkeltőzöm) van egy Virus Desktop-om meg egy Roland SonicCell-em (jó ez nem minőség de van ) DAW-okból van Cubase-m, Studio One-om, Ableton Live-om, Reason-om (ismerem az : FL Studio-t, Reaper-t is) , ezekből egyedül a Reason-al való pepcselgetést élvezem, ezvan, most forduljak pszichológushoz ? )))

ui: jah ilyenkor nem téged mindig magamat győzködöm a Reason-ról , de érzelmeket nem nagyon lehet észérvekkel befolyásolni sajna-vagy nem kitudja, a kérdésem mindig magam felé : érdemes-e a minőségre törekednem ha a hozzávezető utat nem élvezem ... perpill a válaszom: nem, de kitudja mi lesz a későbbiekben

 

Tudom én hogy működik a győzködés...Az érzelmek a fontosabbak, úgyhogy jó úton jársz Másfelől talán inkább csak egó kérdése és lustaság, hogy mennyi időt és tanulást vagy hajlandó rászánni egy program helpjére. Sok időt kell az biztos. Viszont zenei tanárod is lehet,,. (pl ha megnézed mit takar egy körfelvételezés, vagy a kvantálás opciói, az audio take-ek menedzsmentje, loopstartpont könnyű belállítása, jó dobszekvencer felület) Ezek alapvetően fontosak. Tény hogy több kitartás kell egy nehezebb programhoz. De csak azért mert többet tud. több eljárást találtak ki hozzá egy zene elkészítéséhez. Annyi szufla van benne hogy évek használata után se nagyon ismerik ki  a logic teljes tudását az enviroment kötözgetős moduláris rendszere miatt.

Szerkesztette March 1, 2013 Shatva

[Shatva]

Jah és elfelejtettem mondani hogy a clip(object) based delay időzítése mennyire fontos dolog, és mennyire nincs sehol sem ahol a madár se jár. Még Cubaseben is csak trackenként, reaperben trackenként, abletonban trackenként mind buta  logichoz képest. Pedig ez nagyon fontos dolog. Az újgenerációnak akik ilyen programokon dolgoznak fogalmuk nincs erről, mert nem találkoztak ilyennel. Nem úgy van az hogy mindennek a vonalzón kell lennie mert összevesznek egymással.

[Shatva]

Itt megleshető, és ez volt az ami teljes mértékben meggyőzőtt engem.

 

http://www.soundonsound.com/sos/apr08/articles/logictech_0408.htm

 

 

velocity based midi writing...semmi hanglerakás aztán majd valamikor beállítom a velocityt. egyszerre megy..ha egymásfeletttakarásban van kettő esemény akkor szenvedhetsz a velocitykkel, ne mindkettőt állíítsd.

Full beállítható hyperedit paletta.

hangonként delay, és grid sűrűség és tempo signature...phöff és lecsapott vadernagyúr

Ilyet nem találsz sehol...cubase kicsit megtudta közelíteni

Szerkesztette March 1, 2013 Shatva

[xbitz]

ahha ,  és tud olyanokat is ez a Logic srác mint amiket Bitwig fog (aminek ugye nem mellesleg tetszőleges modulját is lehet majd módosítani egy javascript alapú api-n keresztül) 

vagy fog, nem támadás jelleggel írom tényleg érdekel (főleg ami 1.50 után zajlik a videón) Szerkesztette March 1, 2013 xbitz

[A/D]

Itt megleshető, és ez volt az ami teljes mértékben meggyőzőtt engem.

 

http://www.soundonsound.com/sos/apr08/articles/logictech_0408.htm

 

 

velocity based midi writing...semmi hanglerakás aztán majd valamikor beállítom a velocityt. egyszerre megy..ha egymásfeletttakarásban van kettő esemény akkor szenvedhetsz a velocitykkel, ne mindkettőt állíítsd.

Full beállítható hyperedit paletta.

hangonként delay, és grid sűrűség és tempo signature...phöff és lecsapott vadernagyúr

Ilyet nem találsz sehol...cubase kicsit megtudta közelíteni

Digital Performer dobeditora valaki? Az elég jó. Sőt. Nagyon jó. Egyébként tényleg jó a Hyperedit, no question, de lesz, akinél nem tudja ellensúlyozni az ordas bugokat.

[A/D]

Jah és elfelejtettem mondani hogy a clip(object) based delay időzítése mennyire fontos dolog, és mennyire nincs sehol sem ahol a madár se jár. Még Cubaseben is csak trackenként, reaperben trackenként, abletonban trackenként mind buta logichoz képest. Pedig ez nagyon fontos dolog. Az újgenerációnak akik ilyen programokon dolgoznak fogalmuk nincs erről, mert nem találkoztak ilyennel. Nem úgy van az hogy mindennek a vonalzón kell lennie mert összevesznek egymással.

cserébe viszont a track delay nem működik, és össze-vissza van, hogy az egyik tick-hez kötött (ami a dal tempójához kapcsolódik), a másik pedig sample-höz (ami meg nem). aki ezt megcsinálta, arra vonalzóval olyat ütnék, hogy arról kódulna. Protoolsnál csodálatosan működik a nudge, szóval ez nem annyira kardinális kérdés.

[Jonas73]

cserébe viszont a track delay nem működik, és össze-vissza van, hogy az egyik tick-hez kötött (ami a dal tempójához kapcsolódik), a másik pedig sample-höz (ami meg nem). aki ezt megcsinálta, arra vonalzóval olyat ütnék, hogy arról kódulna. Protoolsnál csodálatosan működik a nudge, szóval ez nem annyira kardinális kérdés.

Húúú A/D akkor ezek szerint teljesen lemondtál a Logicról? Áttértél Digital Performerre?

[A/D]

Mindig is volt Digital Performerem, de az esetek 95%-ban Logicot használok. a Logic-kal nem az a baj elsősorban hogy bugos, vagy hogy mik a hibái, hanem hogy nem látom a jövőjét. Nekem nem úgy tűnik, hogy az Apple nyakát törve igyekezné kijavítani az évek óta ismert hibákat. Ez a bajom.

[Shatva]

Mindig is volt Digital Performerem, de az esetek 95%-ban Logicot használok. a Logic-kal nem az a baj elsősorban hogy bugos, vagy hogy mik a hibái, hanem hogy nem látom a jövőjét. Nekem nem úgy tűnik, hogy az Apple nyakát törve igyekezné kijavítani az évek óta ismert hibákat. Ez a bajom.

 

Igazából a hyperedit szinte tökéletes. Futólag megnéztem a digital performert, egyszer mikot még volt mac-em, de nagyon darabosnak éreztem az egészet, meg elmaradottnak. youtubeon néztem a dobszerkesztőjét de egyenlőre elég kevés amit láttam. kapcsolós a velocity-je nem épp ideális. Meg nem is zsugorítható tetszőlegesen.

A hípereditben azt nem értem hogy ha velocity-t ilyen jól kitalálták hogy rajzolni lehet balklikkel jobbal meg törölni, és a jobb bal klikk tanítható teszőlegesen. Akkor azt miért nem találták még ki hogy a gate (leütéshossz) is rajzolható legyen, mondjuk egy toolal vagy egy modifikáció billel (ctrl pl) ? Annyira apróság integrálni egy ilyet

Szerkesztette March 2, 2013 Shatva

[A/D]

Shatva, akkor ajánlom figyelmedbe a DP tüzetesebb tanulmányozását. A dobeditora nagyon durván jobb a Logicénál, mindig is az volt. Most felupgrade-eltem 8-asra, és nagyon sok területen igazi "hűha". A Hyperedittel pedig az a baj, hogy bár nagyon sokat tud, nem túl hatékony, komplikált, körülményes használni.

 

A Live kevesebbet tud, de abban hatékonyabb. Pl. jobb szeretem annak a kvantált envelopejait.

 

A DP-nél pedig az, hogy különböző változatokat készíthetsz a dalodból egy sessionön belül (eltérő kieverővel, pluginekkel) vagy hogy a dobeditorában egy tracken belül akár több sávot is használhatsz (pl. egy midi instrument lábdobját, egy másik pergőét stb) meg hogy a kvantálása egyértelműbb és hatékonyabb a logicénál...ott nincs kérdés.

 

A Logicot továbbra sem szeretem. Kényelmetlen, pedig jópár évet nyomtam bele. Lehet, hogy neked is egyszer eljön majd az a pont. MIDI editre és kísérletezésre többet használom már az Ableton Live-ot, audiót editálni meg CSAK Pro Tools, semmi más.

 

Megvettem a Bitwiget is, épp csak belenéztem, az is tetszik, bár bugos mint a disznó. Ott per note lehet lejátszási paramétert variálni, elég advanced. 

 

A Logicban nem tudok azzal kibékülni hogy igénytelen. Sokat tud, de nem.elég.jól. Ami fontos, abban harmatgyenge: hatékonytalan, pepecselős a crossfade, a transient detect (ennél fogva a minták kreatív felvagdosása használhatatlan, főleg a sample konvertálás révén ahol az EXS24-ben NUMERIKUSAN tudod állítani a sample start-end loop start-endet), a strip silence funkció, pontatlan az audió, ahogy kinéz a hullámforma, az automatika editora kaka. Gyenge a timestretch és a pitching algoritmus. Level metering még mindig hulladék hogy hirtelen csak párat említsek. És idegrohamot kapok az ilyenektől mint pl. a drummer plugin, igazi vendéglátós szint. A Pro X egy vicc, fícsört fejlesztettek, pedig minőségi update-re lett volna szükség.

 

Állítólag a Cubase is igen okos manapság, de nekem ott az UI olyan, hogy képtelen vagyok nézni Szeretem ha egy program szép letisztult.

 

Az új Reasonben is csodaklassz dolgok vannak, szóval el tudom képzelni arról is, hogy valamiben kivételesen erős.

 

A Logicról nem tudok olyat, amiben tényleg nagyon jó volna. Rajtam nem segít sokat, hogy a beépített pluginjei viszonylag jónak számítanak. Gyors MIDI editben pedig a Live sem rossz, én elég gyorsan dolgozom vele. Pl. nem kell transzformátort használni egy note length kvantáláshoz

 

Persze a leírtak az én munkamódszereimmel szemben támasztott igények, és ami nekem fontos, az másnak nem biztos hogy az. A vita pedig azért van, mert univerzális DAW nincs. Meggyőződésem, hogy a leghatékonyabbak minimum két szoftvert használnak.

[xbitz]

Állítólag a Cubase is igen okos manapság, de nekem ott az UI olyan, hogy képtelen vagyok nézni Szeretem ha egy program szép letisztult.

8-asban történt némi előrelépés (menthető "workspace"-ek, pár dolog dokkolódik stb.) szóval jah letisztultabb lett(az más kérdés, hogy a sötét alapon neon színek, meg a mindenhol megjelenő lekerekítések kinek mennyire jönnek be), összehasonlítás az előző verzióval, Greg Ondo-tól (Steinberg mester szintű kiképző)

Szerkesztette December 14, 2014 xbitz

[palimix]

Ekkor: 2013. 01. 15. at 21:41 írta 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)

      Hidden Content

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

       

      Hidden Content

      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)

      Hidden Content

      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)

      Hidden Content

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

      Hidden Content

      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)

      Hidden Content

      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)

      Hidden Content

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

      Hidden Content

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

      Hidden Content

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

Tudom ez nem a kérdezz felelek helye, de az Logic fejlesztői nem állnak velem szóba, hiába jeleztem nekik a következőket.

Elolvasva a cikket, nem tudom megállapítani, hogy az én problémámat mi okozza. Nyíregyházán dolgozom a Vakok Egyesületében és Logic Pro X-et használók hangfelvételire, egy sávon általában, felolvasásokat rögzítek.

Többször kell javítanom felolvasás közben, amikor is lejátszásból megyek át rögtön felvételbe (visszaadva a felolvasónak a végszót) az "R" billentyű megnyomásával.

Az első ilyen akciónál kb két-három másodperc múlva kezd el rögzíteni (így lemarad a szöveg eleje) és minden egyes ilyen lejátszásból felvétel kombinációval csökken a késés, kb 15 művelet után nincs késés. Tehát reggel úgy kezdem, hogy megcsinálom ezt 15-ször, és amíg nem zárom be a Logic-ot (csak a projekteket), addig nem jön vissza ez a hiba.

Focusrite Saffire Pro 40 hangkártyával használom "Catalina" alatt, de High Sierra is ezt csinálja a munkahelyi és az otthoni gépem is, hangkártya nélkül is.

Ha valaki tudna segíteni nagyon örülnék neki, mert ez szörnyen idegesítő, főleg ha elfelejtem "bejáratni" felvétel előtt.

[djuice]

57 perccel ezelőtt írta palimix:

Ha valaki tudna segíteni nagyon örülnék neki, mert ez szörnyen idegesítő,

Másik szoftver, ha ez ennyire gáz?

(Amúgy jó régi topic került most a felszínre, azóta ki tudja merre tart már az egész szoftver, s mi igaz az itteniekből... Mindenhol hallani hogy az újak már nem olyanok mint a régiek, se Cubase, se stb. stabilitásban, funkciókban.)