UNREAL vs Unity - kustomizacja interfejsu
Tak,
zgadza się, unreal posiada przyzwoity system snappowania okienek, jest całkiem usable.
Okej, nie TAK używalny jak Programy wideo od Adobe (AFTER EFFECTS)
W after effects możemy poprosić o dowolną ilość okien typu Viewer, dających wgląd na dowolną kompozycję - blokujemy widok małą kłudeczką - niezablokowane zmieniają się kontekstowo.
Unity, ku mojej wielkiej uciesze, kustomizuje się jeszcze o wiele bardziej. Nie tylko można mieć tam dowolną ilosć Inspektorów (odpowiednik Effect Control z AE), ale także dowlną ilość okien Project (super, w AE brakowało mi tego okrutnie), dowolną ilość okien hierarchii (chociaż niestey nie działają zupełnie rozdzielnie). Do tego, co jest jedną z największych zalet edytora Unity - nie jesteśmy ograniczeni do rzeczy z którymi przychodzi program. Dodanie nowego okna czy nowej pozycji w głównym Menu jest równie proste jak napisanie Hello World; - po prostu przed funkcją którą chcemy z menu wywołać dodajemy dekorator. [MenuItem("MyMenu/Do Something")]
To w zasadzie temat na cały wpis, i mam nadzieję ze kiedyś taki powstanie, tu chciałem jeszcze na chwilę wrócić do Unreala
Jak widać, w unreal snapowanie okienek działa mniej więcej tak jak byśmy oczekiwali,
okienek można mieć kilka (cztery viewporty z których każdy dzieli się jeszcze na cztery
wystarczają, cztery okienka Details wystarczjaą też.
Jednakże, niektórych okien po prostu nie można mieć kolejnych. Za to winnych miejscach nie da się otworzyć pewnych rzeczy (edytor materiałów, edytor blueprintów, edytor animacji) BEZ otwierania kolejnego okna, bez względu na preferencje które sobie ustawiliśmy.
Sama sekcja z ładowaniem layoutów jest komicznie różna - unreal ma piękne ikonki przy
połowie featuresów, ale layout zapiusje po prostu jako preferencja do pliku .INI gdzieś
u siebie w Program Files. Reset spowoduje ... no właśnie, co, reset moich do domyślnych,
czy reset aktualnych do moich? Na Unreal Market można kupić plugina do zarządzania plikami
INI który umożliwia przeładowywanie innych layoutów (choć chyba z restartem edytora). Dla
porównania na screenshocie z unity widać jak ładnie zintegrowały się pozycje dodane
przez pluginy (MidiJack, ConsoleE, UI Extensions) - są nie do odróżnienia od funkcjnalności
natywnej. W unnity jeżeli masz do zrobienia jedną rzecz więcej niż 10 razy na przestrzeni
paru dni to warto rozważyć napisanie małego throwaway scriptu uruchamianego z menu, który
robić będzie za nas dokładnie tą rzecz - przy użyciu całego API edytora i gry.
Porównanie obydwu silników zaczać można od spojrzenia
detal:
vs
na pierwszy rzut oka - wyglądają prawie tak samo. Unity jest szare i biurowe, design utrzymany w klimacie wczesny makintosh, unreal wygląda jak pomodowany laptop alienware, ale filozoficznie zdają się nie odbiegać od siebie zbytnio.
Różnic jest wiele, o czym zamierzam pisać dziś jeszcze przez chwilę, ale skupmy się na dwóch drobnych różnicach, nie do końca widocznych gołym okiem, ale wartej odnotowania. Po pierwsze, Osie Y i Z są w unrealu odwrotnie niż w Unity.
Unity traktuje XY jako tablicę przez którą patrzysz na świat, a Z jako odległość od 'płaszczyzny ekranu'. Obiekty bliżej lub dalej od nas poruszają się w osi Z, w głębi. Jest to jeden z popularnych i użytcznych układów odniesienia.
w Unrealu, twoja pozycja na mapie wyznaczona jest przez X i Y, niczym samolotu na mapie lotniczej, a twoja wysokość nad podłożem opisana jest przez Z.
To w zasadzie drobiazg ale drobiazgi tego typu potrafią napsuć krwi przy importach exportach.
Winner : none, different philosophies
Project Window vs Content Browser
Project Window w unity w zasadzie mogłoby nie być. To małe okienko pełniące funkcję Findera, Explorera, o scope działania oganiczonym do katalogu Assets, wewnątrz katalogu aktualnego. W ogóle w Unity każdy katalog,
który zawiera podkatalog Assets, jest automatycznie projektem Unity. Poważnie, wystarczy założyć pusty katalog Assets, i można w Unity zrobić na jego parent dir wykonać akcję 'Open Unity Project'.
Unity 'pod maską' dodaje do każdego zaimportowanego (przy czym każdy plik w katalogu Assets uważa się za zaimportowany, stan ten unity sprawdza i koryguje przy każdym powrocie focusa do jego okienka) plik .meta .
Dopóki nie poznałem Unreal Engine 4 traktowałem pliki .meta z nieufnością. Pliki meta, jeżeli zagubione, zostaną przez UNITY odtworzone następnym razem kiedy odzyska focus okienka, natomiast jeżeli zmieniła się jakaś ze zmiennych środowiskowych, np. wersja unity, pliki .meta dostaną inny globalny indentyfikator, co często gęto owodcuje 'rozlnikowaniem' assetów w ramach edytora - słynne 'missing script'.Array
Pliki meta są jednak niczym manna z nieba, w porównaniu do dziwności serwowanej przez unrealeditor
Sekcja Transform o dziwo działa w dość zbliżony sposób w obu silnikach. Trzy wektory3 na trzy typy transformacji - translacja - w Unity3D rozumiana jako zmiana Position, a w Unreal rozumiana jako zmiana Location,
Rotation, rozumiana tak samo, przy czym unreal daje suwaki do obrotu (YAY!), a w unity trzeba klepać. Mamy wreszcie Scale, rozumianą tak samo, oraz w UnrealEditor mamy przełącznik 'Mobility', pomiędzy Static a Movable. To w zasadzie także jest tak samo jak w unity (w unity funkcję tą pełni toggle STATIC na przeciwko nazwy obiektu.
W tym samym miejscu oba silniki mają też małą kłudeczkę - która działa w nich tak samo, tzn wyłącza kontekstową zmianę zawartości okienka Inspector/Details.
Obydwa okienka pod sekcją transform wyświetlają kolejno panele ustawień dodatkowych, doczepionych do danego obiektu komponentów - tu jest z grubsza podobnie.
Przyciski Add Component w Unreal i Unity robią już jednak co innego, w unrealu mamy obok drugi Blueprint/AddScript, poniżej mamy wewnętrzną strukturę Aktora, tu mamy już różnice, o których będę piszał jeszcze nie raz (przestanę pisac jak zrozumiem)
Warto jednak przyjrzeć się bliżej tym dwóm obrazkom, są tu bowim dwie ciekawe różnice. Pierwszą jest układ odniesienia - po stworzeniu domyślnego sześcianika, aby zrobić sobie
z niego podłogę, potrzebuję wyciagnąć go w osiach X (od lewej do prawej) jak i w Z (w głąb), a oś Y (w górę i dół) zostawić lub zmniejszyć. Wpisałem skalę x10 (czyli 1000 %) w tych polach.
W Unreal dla osiągniecia tego samego efektu, potrzebuję patrzeć na sytuację z lotu ptaka, wyciągnąć sześcian na wschód-zachód (X) i na północ południe (Y) a zostawić jego wysokość (Z).
To w zasdzie detal i to powszechnie znany, w dodatko obydwa programy trzymają się konwencji kolorystycznej gdzie X to czerwony, Y to zielony a Z to niebieski, więc można 'ogarnąć się' gdzie jesteśmy
na bazie małych podpowiedzi (busola 3D) w rogu - ją programy mają bardzo podobną.
ale zauważyłem jeszcze jedną różnicę. Drugi domyślny sześcian przesunąłem do krawędzi mojej nowej podłogi, w unity punkt który sobie upatrzyłem wypadał około trzech metrów w głąb ode mnie. Unreal wymagał ode mnie
przesunięcia o 300.0 cm w poziomie. I tu różnica jest już ciekawsze. W zasdazie oba systemy są równie 'workable', i tak rzadko wpisuje się te liczby z palca, więc kogo obchodzi co napisane jest w okienku. W zasadzie racja. Problemy tego rodzaju występują jednak w każdym programie do 3D na jakimś etapie - 3DSMax jest pod tym względem chyba najgorszy.
Ale ten przykład pokazuje nam dość ciekawą różnicę - Unity często stara się nic nie narzucać. Te 3 jednostki o które przesunąłem sześcian - mogą być dla mnie metrem, mogą być pikselem (jest tak w widoku canvas), mogą być dla mnie koordynatami logicznymi na mapie, albo dzielnicami miast jeśli mam taki kaprys - mogę je traktować jako kilometry i dalej nie mieć większych problemów z silnikiem, o ile nie mam za blisko/za daleko ustawionego near/far culling w kamerze.
Unity stara się, gdzie tylko to możliwe przestrzegać pewnych uniwersalnych zasad, tzn jeżeli jest do opisu czegoś standard ISO to prawdopodobnie został użyty.
Unreal reprezentuje filozowię pt 'napiałem mój edytor tak, nie podoba się to nie używaj', i wspomniane wyżej cm są tego subtelnym, ale czytelnym przykładem. Podejrzewam, że
pierwotnie program działa po prostu w calach. Cale są OK gdy mówimy o obiektach wielkości telewizor, koło, ekran komputera, wysokość stołu, więc nie dziwie się, że Amerykańcsy projektanci są do nich przywiązani.
Bezmyślnie jednak, zamaist metra, jako jednostkę podstawową zastosowano centymetr (jako analogię do cali jak mniemam) - podejrzewam że jest to dalsza konsekwencja stosowania systemu imperialnego -
jeżeli pracujemy w układzie jednostek SI, to przejście z centy na kilo to mnożenie / dzielenie przez odpowiednią potęgę dziesiątki. przeliczanie z cali na mile nie jest już takie proste dlatego
sprawa opisania moich 300 jako centymetr wydawała się projektantom wazna.
Unreal nie uznaje też zaokrągleń w polach gdzie wyświetla floata, wiec zatrzymawszy np animację obrotu możęsz zobaczyć kąt np 127', ale po poszerzeniu okna może się okazać że kąt to 60.34420127'
Unity stara się wyświetlać liczby w 'rozsądnych' zapisach
Taką prawdziwą, jak Visual Studio. Bosko, naprawdę VSCODE który już dawno wysunął się u mnie na pierwsze miejsce edytorów kodu zostawia właśnie konkurencję jeszcze dalej w tyle.
Aby ją włączyć (domyślnie jest wyłączona), należy zmienić false na true w pliku settings.json (F1 >settings)
Jak większość ludzi zaczynających przygodę z Unity, pierwszym edytorem który stosowałem był MonoDevelop - domyślne środowisko z którym Unity przychodzi. Tak jak wielu zaczynajacych z arduino używa arduino IDE (fork Processinga) Warto jednak zainteresować się dostępnymi alteranatywami. Najbardziej popularnym (i słusznie) IDE do pisania w C# jest Microsoftowy Visual Studio (darmowy w wersji Community Edition, choć wymaga rejestracji). Jest to istny kombajn do pisania kodu, a internet jednogłośnie rozpływa się zachwytach nad jego zaawansowanymi funkcjami.
Visual Studio ma jednak dla mnie dwie wady. Pierwszą i najważniejszą jest dla mnie fakt, że jest to aplikacja Windows Only - nie ma wersji na OSX [ EDIT 20171103: pisałem to w nieświadomośći, od dobrych czterech dni w sieci była już wersja makowa Visual Studio !]. Drugą, mniejszą, jest to samo co jest jego główną zaletą - jest to poważny kombajn, i bywa, że ilość funkcji dostępnych naraz na ekranie w polu widzenia staje się nieco przytłaczająca. Niezbyt wygodne było też dla mnie przechodzenie pomiędzy plikami, oraz dość złożony system skrótów klawiszowych (niektóre komendy wymagają wciśnięcia po sobie dwóch różncyh kombinacji np ctrl+k ctrl+d.
Jak się okazuje istnieje (i zyskuje na popularności) trzecie IDE - Visual Studio Code. Jest to edytor pierwotnie napisany w Microsofcie, luźno bazujący na Visual Studio, ale oparty na zupełnie innym silniku (pod maską używa z tego co pamiętam klona silnika Atom używanego w edytorze node.js). VSCode jest natywnie wpspierane przez Unity od wersji 5.5, ale można spiąć go także z wcześniejszymi wersami za pomocą instalacji odpowiedniego plugina.
VSCode działa na maku identycznie jak na windowsie, jest darmowy i open source, podobnie jak dwa pozostałe IDE ma pełną obsługę Debuggera Unity, przynajmniej dwie funkcje których VS nie ma - przede wszystkim liczenie i wskazywanie referencji metod i pól. Funkcja ta jest dostępna w Visual Studio ale nie w darmowej werjsi Community. _podobno_ można dodać tą funkcję (znaną w VS jako CodeLens) do darmowej wersji instalując SSDT Preview, ale mi sztuczka ta się nie udała (do tego od dwóch dni dostaję na fejsbuku głównie reklamy szkoleń z SQL). Nieco Łatwiejsza dla mnie jest też nawigacja po projekcie, ale ledwo minimalnie, i kwestia to subiektywna. tym co odróżnia VSCode od VS, to minimalistyczny interfejs - poza kolumną z lewej strony zawierającą pięć ikon (pliki, wyszukiwanie, debugger, git, extensions), w zasadzie cały ekran zajmuje nam okno z kodem, opcjonalnie podzielone na dwie części. Zestaw funkcji dostępnych z menu górnego sprawia wrażenie że mamy doczynienia z notatnikiem a nie powaznym IDE (gdy VS raczej nie zachętca do otwierania górnego menu, poniżej screenshot z visualstudio (nie jestem pewien czy menu tools zmieniło się po moim eksperymencie z SSDT czy nie)
W VSCode z menu górnego wnioskować by można że program generalnie nie posiada funkcji, jest to jednak wrażenie mylące, które mija po wciśnięciu F1
ale jest to wrażenie mylące - większość funkcji programu jest bowiem dostępnych z poziomu automatycznie chowanego pola do wpisywania poleceń. Wciśnięcie F1 (lub shift+cmd+p) - i nie jest to okienko pmocy powoduje otwarcie linii komend poprzedzonej znakiem > dającym dostęp do funkcji programu - zmazanie go powoduje przejście do wydawania komend skoku do innej sekcji kodu bądz innego okna. Jak się okazuje, znacznie łatwiej jest mi wcisnąć F1 i zacząć pisać 'form' aby znaleźć funkcję 'format document' albo 'ins' żeby znaleźć insert snippet, niż pamiętać analogiczne skrót z Visual Studio
Proste i nieinwazyjne rozszerzenie edytora składające się z definicji atrybutu (dekoratora - umieszczanego przed zmiennymi publicznymi, w miejscu gdzie można definiować atrybuty takie jak [HideInInspector] albp [Range(0,1)]) który powoduje że zmienne publiczne oznaczone tym atrybutem wyświetlają się w edytorze, w trybie tylko do odczytu. Częstym zastosowaniem jest dla mnie wyprowadzenie w celach debugowych pewnych zmiennych, bądź nawet całych stringów typu statusowego do wyświetlenia w edytorze. Atrybut nie chroni zmiennych przed zmianą z poziomu kodu ale uniemożliwia zmiany z poziomu edytora, co osobiście znajduję bardzo użytecznym.
W trakcie kilku ostatnich miesięcy intensywnej pracy w środowisku Unity, udało mi się uzbierać przetestować dość znaczną ilość fragmentów kodu i pluginów. Sporo pluginów do Unity jest pisanych przez amatorów, i napisanie własnych o podobnej funkcjonalności często bywa prostsze niż usunięcie niedoskonałości ze znalezionych w sieci, niemniej jednak zdażają sie także absolutne perełki. Ponieważ niektóre z nich nie są wcale takie proste do znalezienia (Asset Store dostępny z wewnątrz środowiska jest zdominowny przez produkty płatne, i wersje demo produktów płatnych, natomiast rozrzucone po sieci bywają fragmenty kodu zupełnie niebywałe. Kiedyś (zanim zacząłem interesować się tym środowiskiem) popularnym serwisem tego typu było [nie dzialajacy link UNIY WIKI LINK], ale od jakiegoś czasu strona ta nie działa. Niektóre fragmenty kodu trafiły na postawioną w zamian Unity Community Wiki i zdecydowanie warto jest przejrzeć to repozytorium, ale wiele projektów jest obecnie rozrzuconych po GitHubie, po stronach indywidualnych developerów itp.
Moim absolutnym faworytem, olśnieniem w kategorii "Darmowe pluginy" jest ZIOS . Wiele wieczorów spędzilem kodując, i czynnikiem, który nie dawał mi spokoju, jest jedno z dwóch ograniczneń w darmowej wersji Unity. Pierwszym, mniej ważnym, ograniczeniem darmówki, jest brak możliwości usunięcia splasha Made With Unity który jest automatcznie odtwarzany przed startem aplikacji zrobionych na darmowej wersji. Drugim ograniczeniem, które paradoksalnie wkurzało mnie znacznie bardziej, jest konieczność używania domyślnego, jasnego theme.
Z niedowierzaniem czytałem kolejne wątki w których ktoś wskazywał na to, że możliwosć zmiany theme na ciemny dostępna jest wyłącznie w werjsi PRO, płatnej (i to nie aż tak mało).
Po powrocie do domu z naszego drugiego stereokowego testu użycia Unity do mappingu 3D na imprezie (czyli w warunkach generalnie ciemności), po raz kolejny zacząłem szukać rozwiązania. Trafiłem na informacje o jakimś patchowaniu binarki za pomocą hex editora (czyli w skrócie należy złamać zabezpieczenia siłowo) i byłoy to dla mnie prawie do przyjęcia, gdyby dało się znaleźć aktualne informacje na ten temat - a niestety indeksy i ciągi do wyszukiwania znajdywałem jedynie dla starszyh niż aktualna wersji.
Wreszcie trafiłem na informację o Zios Themes i z początku wyglądało to na bycie zbyt pięknym aby było pawdziwe. Gdy rozszerzenie zadziałało mi na windowsie, dla aktualnej stabilnej wersji (5.5) byłem pewny że zaraz okaże się że nie działa na maku albo że wywraca jakiś ważny moduł. Ku mojemu zaskoczeniu - działa na maku, wszytko pracuje ok, do tego można sobie dalej modyfikować kolory, czcionki itp (choć zrobienie od nowa całego theme to misja bardzo karkołomna - Unity nie dokumentuje API którego wewnętrznie używa do rysowania interfejsu - właśnie po to żeby chronić się przed istnieniem pluginów tego typu.
Zios przychdodzi z jednym nowym zestawem ikon (Simplicity) ale za to z z jeśli naliczyłem dobrze - 44 wariantami kolorystycznymi, i 30 zestawami fontów czyli dotajemy ponad 1000 możliwych kombinacji wyglądów - z których niektóre stworzone zostały ewidentnie z poczuciem humoru, ale każdy znajdzie tu coś dla siebie. Poniżej cztery przykłady.
Korzystając z tego że Zios Themes ma ikony zestawu simplicity w postaci folderów z plikami PNG, dokonałem jednej modyfikacji która ułatwia życie w moim osobistym przypadku - często zapominałem że zablokowałem dane okno inspektora, i wpowadzałem zmiany nie na tym obiekcie na którym myślałem że wprowadzam. Dzięki pokolorowaniu ikony zamkniętej kłudki na czerwono, elementy gdzie założony jest lock są znacznie bardziej widoczne.
Breaking news: pomiędzy momentem jak napisałem powyższy tekst, a momentem gdy wrzucam go na stronę, wyszło unity 5.5.1, i oczywiście powoduje ono lawinę komunikatów o błędach ze strony Zios Themes ; ) Ja póki co zostaję po prostu na 5.5, przynajmniej dopóki nie pojawi się alpha 2 nowego Video Playera, wtedy pewnie przejdę na 5.6
Jedną z moich głównych bolączek na począktu pracy z Unity był bałagan w plikach. Unity nie wymusza absolutnie niczego jeśli chodzi o strukturę plików (no dobrze, pliki edytora powinny być w katalogu Editor, ale to w zasadzie wszytko), i przy braku wdrożonego systemu organizacji, szybko kończy się to drzewem gdzie rzeczy są porozrzucane trochę gdzie popadnie, co prawda zazwyczaj teksuty w Textures a materiały w Materials, ale ilość katalogów z materiałami rosła proporcjonalnie do ilości importów plików FBX, i wersji shaderów itp. Gdy katalogów zaczęło się robić sporo, coraz więcej czasu poświęcałem na nawigację po niezbyt wygodnej przeglądarce plików Unity (okno Project) zastanawiając się czy jest jakaś możliwość, aby wizualnie poddróżniać od siebie foldery. Jak się okazuje, jest.
Enter Rainbow Folders.
Rainbow folders pobrać można za darmo https://github.com/PhannGor/unity3d-rainbow-foldersEditL: autor postanowił jednak zacząć brać za rainbowa pieniądze, dosłownie od paru dni (względem edita z 2017 maja) githobowa wersja ofjcialnie nie bdzie dalej rozwijana, teraz trzeba go kupic z asset stora - poki co jednak pewnie dziala.
moim jedynym zastrzeżeniem jest, że pomimo obietnicy -The Rainbow Folders asset doesn’t require to be in the root of you project, you can freely move it wherever you want. Then just go to Edit → Preferences → Rainbow Folders and update the folder location, nie jest do końca tak pięknie - przy każdym a przynajmniej przy niektórych sytuacjach przenoszenia projektu z maszyny na maszynę, ta preferencja potrafi się zgubić a nasza konsola jest wtedy zalewana przez komunikaty o błędach które nie chcą ustać dopóki nie poprawimy ścieżki - a logowanie do konsoli jest jedną z droższych operacji jakie można zrobić w unity.
Witam wszystkich czytających, zgubione dusze i nie-poznanych fanów sprzed lat. Nadszedł w moim zyciu, mam nadzieję ze już na stałe, pewnego rodzaju nowy okres. Zająłem się programowaniem w środowisku Unity3D, i totalnie zakochałem się w temacie. Ponieważ od kilku miesięcy pochłaniam wiedzę w zasadzie coraz szybciej, a temat jest dla mnie niezwykle ekstyctujący, postanowiłem wykorzystać moment żeby zacząć pisać tutaj o kolejnych rzeczach których się uczę, wynikach eksperymentów, czy ciekawych fragmentach kodu znalezionych w sieci.
Znalazłem ostatnio zdjęcia sprzed kilku lat, gdzie gram sobie z maszynek, i naszła mnie przy tej okazji pewna refleksja. Zauważyłem, że tak jak w wielu dziedzinach mojego życia miało już miejsce kilka tur zmian, tak jeśli chodzi o granie muzyki zmieniło się bardzo niewiele, a w zasadzie nic, przez ostatnie, nie wiem, sześć, osiem lat? Obecny setup bardzo odpowiada mojemu trybowi pracy, i pozwala mi zagrać to, co chcę zagrać bez specjalnego kombinowania (kwestia : czy jest to ładne? to już osobny temat). Pomyślałem że być może warto opisać ten setup nieco dokładniej, być może
ktoś znajdzie tu jakiś pomysł dla siebie
Źródła dzwięku
Jeśli chodzi o źródła nie ma tu w zasadzie nic odkrywczego. Po przetestowaniu ładnych kilku, ostatecznie używam dwóch instrumentów - Korga ESX i x0xb0xa.
Moim koniem roboczym jest klasyczny Electribe, Korg ESX (wersja czerwona, samplerowa, w odróżnieniu od niebieskiej, romplerowej), z którego można naraz odtworzyć do 14 sampli/próbek. Jego ograniczeniem jest 26MB pamięci na próbki, więc trzeba je wybierać bardzo dokładnie (częstokroć konwertuję je do 32kHz a nawet 22kHz tam gdzie nie ma specjalnie wysokich częstotliwości, aby oszczędzać czas próbkowania), oraz brak możliwości sciszenia kanału przed jego odmutowaniem (niedopatrzenie w firmware), choć tą drugą niedogodność obchodzę kontrolerem. Zaletą jest na pewno bardzo hands-on workflow - praktycznie wszystkie funkcje maszyny dostępne są od razu, one-knob-per-function z panelu czołowego, nie ma kombinacji klawszy (poza szczególnym przypadkiem part mute), nie ma głębokich menu (menu jest ale bardzo płytkie i czytelnie opisane na panelu czołowym), od razu po odpaleniu maszyny można grać a przy tym ma swój silny charakter brzmieniowy.
Choć na początku nie byłem przekonany do lamp (myślałem że jest to bajer i że tylko świecą) to jednak w moim odczuciu potrafią one bardzo wzbogacić brzmienie maszyny. Są wariaci wymieniający je na model niskoszumny, albo wręcz zwierający piny w stopniu wyjściowym żeby lampy obejść (faktycznie, w porównaniu do bardziej 'studyjnych' syntezatorów lampowe wyjścia electribe nie są szumowo obojętne) ale jest coś bardzo muzycznego w tym jak lampy te potrafią 'zaśpiewać' jeżeli zastosujemy głośne próbki stopy i basu, podbite dodatkowo przez jego wewnętrzne EQ - zwłaszcza że zestrojone jest to tak, że pomimo maksymalnego podbicia basu tym efektem, nie występuje przester po stronie cyfrowej, za to zaczyna się już bardzo poważny przester na lampach jeżeli ustawimy ich gain wysoko. Do tego bardzo fajnie, zestrojone są zakresy parametrów - czasy obwiedni, parametry pracy lfo i tak dalej, łatwo jest intuicyjnie trafić gałką w odpowiednią wartość i trudno ukręcić coś niefajnego - a nie wszędzie tak jest.
Oprócz 10 zwykłych, one-shotowych, perkusyjnych ścieżek (z których dwie ostatnie mogą pracować parami jako kanał stereo, za to nie mogą grać naraz w mono, mają na stałe ustawiony wzajemny choke, co bywa przydatne, choć bywa też denerwujace) mamy także dwa kanały 'Keyboard' które odtwarzają próbki chromatycznie, i pozwalają sekwencjonować ich wysokości, dwa kanały STRETCH które odtwarzają próbki jako loopy (tak jakbyśmy mieli dwa kanały z Abletona, dopasowujące tempo loopa do tempa utworu), i kanał SLICE który robi coś podobnego jak stretch, ale umożliwia trigger tylko niektórych kroków sekwencji i odtwarza wtedy od zadanego fragmentu a nie od początku. Dobre do wrzucenia pre-programowanej sekwencji np. bębnów i odpalenia jej z wariacjami na górze tego co wyskrobaliśmy korzystając z one-shotów, dla smaku
Moim drugim instrumentem jest x0xb0x, czyli open-source klon roland TB-303. Jest to prosty monosynth (jedna nuta naraz, jedna fala naraz) z charakterystycznie brzmiącym filtrem, slide i akcentem. x0xb0x nie brzmi w 100% jak TB303, ale można podejść dość blisko do wielu klasycznych brzmień tej masznyny, ale oferuje kilka rozszerzeń. Łatwiejsze (i dostępne w locie, bez zatrzymywania zegara) programowanie patternów, zmoddowany firmware - SOKKOS pozwala na zabawy w rodzaju loopowania dowolnych kroków (można więc zagrać acidową arytmię, loopy na 5, 7 kroków gdy sekwencja jest na 16), puszczenia kroków od tyłu, zwolnienia tempa dwa razy itp. x0xb0xowe community obfituje też w opisy modów jakich można dokonać na maszynie, a jak już się zacznie, ciężko trochę skończyć - ja skończyłem gdy x0xb0x przestał się zamykać z powodu zbyt dużej ilości dodatkowych kabli do przełączników. Najciekawsze i zdecydowanie warte wprowadzenia mody to przede wszystkim regulacja czasu ataku filtra (TB303 miało bardzo krótki czas ataku filtra, gdy czas ten wydłużamy zaczyna brzmieć dużo łagodniej, aksamitnie), i czasu decayów nut z akcentem i bez akcentu osobno. Dodatkowo wiadomo, różne rodzaje przesteru, ale zauważyłem że najczęsciej używam go jednak nie przesterowanego, grającego środkiem pasma.
Z wad wymienić należy słabe przyciski, i wolno reagujący mikrokontroler, mam także wrażenie że potrafi czasmi zgubić ramkę zegara (ale być może to tylko mój egzemplarz i nie jestem pewien czy poprawnie zalutowano tam transoptor) i bywa że po pół godziny gra już nieco z tyłu, na szczęscie w nowym sokkosie dodano możliwość przesuwania sekwencji - co prawda z racji wolno reagujących przycisków wymaga to często wielu podejść, ale jednak metoda polegająca na wyciąganiu kabla midi i próbie włożenia go z powrotem w takim momencie żeby sekwencja poszła dalej równo była jeszcze gorsza.
MIDI
Gdyby nie część MIDI tego setupu, w zasadzie nie miałby sensu ten artykuł, tu bowiem znajduje się sedno tej opowieści. Punktem wyjścia do niej niech będzie fakt, że jak wspominałem wcześniej, w ESX nie da się odmutować cicho kanału który był głośno przed zmutowaniem. Wynika to z konstrukcji urządzenia - parametry edycji dostępne są dla ostatniego 'dotkniętego' kanału, więc musimy dotknąć przycisku odpowiadającemu danemu kanałowi, ale działanie to jest równoznaczne z anulowaniem MUTE zapiętego na ten kanał. To powoduje że jeżeli mieliśmy np. głośno walącą stopę, wyłączyliśmy ją za pomocą Mute a następnie przeszliśmy na inny kanał, to nie da się wrócić do kanału ze stopą i sciszyć go zanim go odmutujemy. Jest to w zasadzie jedyna poważna bolączka tej masznyny. Kombinując jak to zagadnienie obejść przypomniałem sobie, że mam kontroler Behringera BCR2000, skądinąd świetny. Pamiętałem że ma wiele funkcji, ale maszyna ta nie przestaje mnie zadzwiać.
Z punktu widzenia pracy z ESX pierwszym zaskoczeniem było dla mnie że BCR posiada pełną obsługę komunikatów NRPN. ESX posiada łącznie więcej niż 127 parametrów do sterowania, a wszystkie kanały maszyny można ustawić na ten sam kanał MIDI, więc przestrzeń 127 parametrów CC skończyła by się i tak, stąd użycie 14bitowo adresowanych ramek NRPN. Obsługa ramek tego typu wcale nie jest takia częste - np. Ableton nie potrafi ich obsłużyć (widzi je jako sekwencję CC98,CC99 i CC6 po sobie), w zasadzie mało jaki program poza BomeMidiTranslatorem potrafi pracować z NRPN. BCR pozwala nawet automatycznie się ich uczyć (trzeba tylko pamiętać żeby ustawić zegar ESX na external bo ramki zegara burzą transmisję dłuższych ramek NRPN w trybie Learn). Można też ustawić zakres pracy gałki i zmapować np. cały obrót gałki na wartości od zera do połowy - czego użyłem przy mapowaniu punktu startu sampla - rzadko kiedy coś ciekawego znajduje się pod koniec sampla, zazwyczaj jest tam tylko ogon, ale jego równa połowa to często ciekawe miejsce zwłaszcza przy samplach rytmicznych, więc mogę tam skoczyć szybko, kręcąć gałą opór w prawo
Po drugie, BCR ma pełen MIDI feedback, tzn gałka przypięta do danego kanału kontroli nie tylko transmituje go, ale także odbiera, wyświetlając na pierścieniu LED aktualną wartość. Odbywa się to nawet gdy jesteśmy na innej stronie urządzenia, albo gdy mamy kilka gałek przypiętych do jednego parametru. Urządzenie posiada też wiele trybów pracy, od najbardziej 'komputerowych' gdzie w systemie pojawia się on jako dwa inputy (jedno zewnętrzne midi IN i gałki) i trzy outputy (dwa zewnętrzne MIDI out i gałki), aż po całkowicie bezkomputerowe, gdzie routing pomiędzy inputem, dwoma outputami a gałkami odbywa się całkowicie wewnątrz maszyny a komputer nie jest potrzebny. Łącząc MIDI OUT z ESX do MIDI IN na BCR2k mogłem nauczyć BCRa kolejnych parametrów, a łącząc drugim kablem MIDI obie maszyny w drugą stronę, mogłem sprawić że nie tylko kręcenie gałką na electribe powoduje wyświetlenie tego obrotu na kontrolerze, ale także obrócenie gałki na kontrolerze powodowało update wartości na samplerze, na którym mozna więc było mieć otwartą edycję innego kanału a mimo to kręcić parametrami tego pierwszego. Od tej pory mogę więc sterować głośnościami kanałów, które są aktualnie zmutowane. Ta-Dam.
Ale ale, jeżeli MIDI IN na ESX jest zajęte przez BCR, a MIDI IN na BCR jest zajęte przez ESX, to jak doprowadzić do systemu zegar? Niestety wymaga to dodatkowego pudełeczka, MIDI Mergera, czyli kostki zawierającej dwa wejścia MIDI i jedno wyjście, na którym pojawiają się zamki pochodzące z obydwu wejść (MIDI nie da się po prostu zewrzeć, potrzebny jest mikrokontroler do kolejkowania ramek). W moim setupie merger dodaje zegar z zewnętrznego źródła (a więc z mojego komputera, lub ze splittera gdy jammujemy), do tego co wypuszcza BCR, i ta suma wchodzi do ESX, dając mu możliwość podążania za zewnętrznym zegarem. Ponieważ ESX ma także wyjście Thru (gdzie nie wysyła swoich komunikatów ale przesyła dalej to co dostał na wejściu), nie ma problemu z podłączeniem x0xb0xa.
Miksowanie
Na koniec jeszcze parę słów o miksowaniu. Używam bardzo kompaktowego (jak na ilość funkcji) miksera ETEK AD1823 (kiedyś mniejszego AD1223), na którym pierwsze cztery kanały zajmują cztery wyjścia z Electribe (tak tak, niby zabawka ale ma cztery outputy). Łatwiej wyobrazić to sobie jako dwa wyjścia stereo, mamy więc główną parę wyjść, lewy prawy (1/2), i alternatywną parę 3/4 - w ustawieniach danego kanału możemy wybrać czy chcemy aby był routowany przez główne wyjście (lampowe) czy szedł alternatywną ścieżką, omijając lampy (można tak łatwo sprawdzić jaką zmianę powodują same lampy), i trafiał na drugą parę wyjść. To co gram jest jednak w większości monofoniczne i tak, wszystkie sample jakie wgrywam są wcześniej monofonizowane (aby oszczędzać pamięć samplera), w zasadzie jedyna 'przestrzeń' pochodzi z pogłosu (używam RV600 dodanego na wysyłce pre-fader z powrotem na swój własny kanał przez co dostaje na mikserze swój własny Equalizer, a także wysyłkę więc można usawić feedback), więc na początku nie wiedziałem za bardzo jak mogę tych dodatkowych wyjść użyć, aż nie nastąpiło olśnienie.
Zasadniczo mogę to co wychodzi z maszyny podzielić na dwie sekcje, podstawę stanowią stopa i bas, które zdecydowanie muszą iść przez lampy i efekty, ale są też różne odgłosy, przeszkadzajki, loopy, rzeczy którym spokojnie wystarczy podłos dodany na mikserze, lub nie potrzebują efektów wcale, te rzeczy mogą spokojnie wychodzić na wyjściach 3/4. I teraz, każda próbka ma swoje pokrętło od panoramy, w położeniu skrajny lewy nie gra kanał prawy i na odwrót. A mój miker posiada funkcję CUE, czyli przycisk przy każdym kanale, pozwalający odsłuchać na słuchawkach tego co wchodzi na kanał, pomimo tego że suwak danego kanału może być sciszony na maksa. Czaicie już na pewno do czego zmierzam - gra sobie stopa z basem i cała reszta, np przez wyjscia lewe, a ja, jeżeli mam jeszcze wolne kanały na maszynie, mogę sobie ustawić zupełnie co innego, korzystając z kanału prawego, i dopiero gdy jestem zadowolny z efektu jaki mam na słuchawkach, przejść nimi stopniowo na kanał lewy a więc na głośniki. Alternatywnie, mogę zgłośnić nowe elementy na mikserze, zagrać przejście, a następnie sciszyć to co grał kanał lewy na mikserze, wejść tam z CUE i kombinować już co zagrać za chwilę, na słuchawkach. Tą samą technikę można stosować także w maszynie która posiada tylko jedną parę wyjść (a więc np. starsze Electribe, czy też nowszy Electribe2 który także nie posiada drugiej pary wyjść), ale gdy mamy dwie pary, można to podnieść do kwadratu, i np. mając już trzy ściezki wpuszczone w mikser, odsłuchiwać sobie na czwartej kolejny kanał. Można też prosto ustalić co gra co bez potrzeby wyłączania śladów. Można też, korzystając z wysyłki pre-fader, wprowadzić jakiś dzwięk najpierw delikatnie, jako 100% wet powrót z pogłosu a dopiero potem odkryć go w wersji DRY itp.
Możliwość wcześniejszego odsłuchu kanału przed jego wpuszczeniem do miksu przydaje mi się ogromnie, bo niektóre z dzwięków które mam w maszynie potrafią być dość inwazyjne, i zanim wpadłem na pomysł z użyciem wielu śladów i cue, denerwowałem moich kompanów w tracie grania odsłuchiwaniem próbek na głośnikach. Teraz możliwe są nawet takie sztuczki że jedna z lamp pracuje w dużej saturacji, przesterowujac mocno bas, ale jest mocno sciszona na mikserze, i brud który dodaje ledwo słychać, a w tym czasie druga lampa grając zupełnie co innego, pracuje sobie w normalnym punkcie pracy grając czysto, do tego omijając lampy grają sobie hihaty a ja na czwartej scieżce na słuchawkach wybieram sobie loopy.
Próbki
W zasadzie nie tylko dlatego, że znalazłem zdjęcia, zdecydowałem się napisać parę słów. Główną okazją było to, że zrobiłem ostatnio poważne porządki w pamięci samplera, wywalając próbki które słabo działały w praktyce podczas grania (a było takich wiele), a w odzyskane miejsce ładując parę nowych propozycji. W zasadzie doszło do mnie że zestaw próbek którym grałem na jamach ostatnich kilka lat, pochodził chyba z 2011. Przesortowałem je, układając blisko siebie te których często używam razem, umieściłem w nazwie loopów ich długości, one-shoty syntezatorowe nastroiłem itp. Tu wpomnę tylko, że choć 26MB całej dostępnej pamięci na sample to bardzo mało (przykładowy content z którym przychodzi Ableton to chyba gigabajt próbek), ale paradoksalnie, dobrze dobrane próbki (warto na dzieńdobry wywalić wszystko co korg nam dał firmowo, poza nastrojonymi przebiegami Sin, Saw itp), potrafią bardzo dobrze wpływać na kreatywność.
Gdy na rynku zaczęły się pojawiać używane Pushe w dobrych cenach nie mogłem się powtrzymać, i myślałem że to dla mnie koniec etapu hardware only i że wracam do Abletona, ale paradoksalnie gigabajty branków próbek, tysiące presetów kilkunastu wtyczek VST, choć możliwości brzmieniowe poszerzają tysiąckrotnie, powodują u mnie pewien rodzaj blokady kreatywnej. Może chciałbym tu dodać pianinko. Jakie? Do wyboru mamy kilka abletonowskich, dwie darmowe wtyczki, pare banków do Kontakt Playera itp, samo przesłuchanie i wybranie właściwego pianina zajmuje minimalnie kilka minut, do tego czasu można zapomnieć co w zasadzie chciało się zagrać. A na ESX jest tak - chciałbym tu dodać pianino, aha nie, nie mam tu żadnej próbki pianina, ale za to chyba mam tu loopa gdzie jest jakiś akord na gitarze, będzie musiał wystarczyć :)
Slice
Wreszcie na koniec, wspomnę o bardzo ważnej funkcji Korga ESX, której znaczenie nie jest wprost wypisane w instrukcji, a sam dowiedziałem się o nim przypadkowo, z jakiegoś tutoriala na youtube. Slice wykoanany na samplu powoduje przejechanie go algorytmem detekcji peaków, i zapisanie wykrytych punktów jako markery, których następnie używa kanał typu Slice podczas odtwarzania swoich próbek. Proste? Ano proste. Ale jest jeszcze jeden aspekt, który totalnie zmienił sposób w jaki pracuję z tą maszyną (zdaje się że stąd właśnie w 2011 była ta wymiana sampli - dnia którego nauczyłem się o slice po prostu MUSIAŁEM przerobić cały zestaw na nową metodę pracy), a mianowicie - markerów od Slice można także używać do wyboru fragmentu próbki odtwarzanego przez zwykły kanał 'one shotowy'. Domyślnie odtwarza on całą próbkę, ale gdy w widoku PartEdit zejdziemy o pozycję niżej, wchodzimy w edycje parametru Slice selection, i możemy zamiast ALL wybrać fragment próbki i tylko ten fragment zostanie otworzony. Dlaczego jest to zmiana rewolucyjna?
Gdy zacząłem pracę z tą maszyną, i wgrałem tam swoje próbki, okazało się że większość z nich jest dość krótka, pojedyncze uderzenia bębnów czy ósemki zagrane jakimś VST nie trwają zbyt długo, i na długo zanim skończyło mi się miejsce w pamięci, zaczęły konczyć się sloty na sample (maszyna udostępnia ich 256). Gdy jednak użyjemy Slice, możemy przygotować wcześniej kompozytowe, dłuższe sample, np jeden który zawiera szesnaście sampli stopy, drugi który zawiera siedem werbli, trzeci który zawiera pięć otwartych hihatów itp. Próbki te po wgraniu przejeżdzamy 'slice' i zapisujemy sobie jako 'szablon' projektu ustawienie w którym wszystkie kanały domyślnie grają tylko jeden slice. Dzięki temu zyskujemy dwie ważne rzeczy - po pierwsze, nagle odzyskaliśmy masę slotów na sample, po drugie nawigacja w celu wyboru właściwej próbki staje się znacznie łatwiejsza i przyjemniejsza. Zamiast scrollowania się przez pięćdziesiąt wariantów sampli perkusyjnych żeby doscrollować się do poszukiwanego sampelka wokalnego, mam teraz całe bębny zajmujące z grubsza piewszych ~ 10 slotów sampli, pogrupowanych według rodzaju, więc mogę znacznie szybciej wybrać np CLAPS jako sampel, a następnie przejść do wyboru konkretnego sampla z klapem przechodząc już tylko wewnątrz widoku 'slice' - a więc bez ryzyka że pojadę za daleko i zacznę grać coś co klapem nie jest. Z jednowymiarowej listy robi się nam więc dwuwymiarowa tabelka, i przy odrobinie pracy włożonej we wcześniejsze spreparowanie sampli, proces wyboru brzmień podczas grania na żywo staje się super intuicyjny.
Aha, i jeszcze tylko przypomnienie - do ESX dostępny jest świetny darmowy edytor banków - OpenElectribeEditor, choć wgrywanie sampli po jednym na kartę i do maszyny jest zdecydowanie możliwe, to możliwość poukładania ich w odpowiedniej kolejności za pomocą myszki to jednak duża oszczędność czasu i nerwów.
Disclaimer: dołożyłem starań aby schemat na górze był możliwie poprawny, ale na potrzeby czytelności rysunku zamieniłem kolejności wyjść i wejść MIDI na ESX, oraz wejść i wyjść na RV600 względem rzeczywistych, za niedogodności bardzo przepraszam.
Zwrócono moją uwagę na fakt że na stronie nie ma już prawie filmików ani śladu po tym że zajmowałem się robieniem wizualizacji. Otóż cała działalność VJska i filmowa mojej skromnej osoby (przynajmniej jej część nie opowiadająca o przesterach) przeniosła się teraz na nasz fanpage Stereoko.Tv
Przy okazji dodałem trochę zaległych filmików tutaj.
Haha ale klasyk się znalazł, robimy wizualki we dwojkę z Izą, mikser wideo, sprzętowy sekwencer MIDI odpalający przebiegi CC sterujące playheadami - niby minęło 11 lat a tak naprawdę
niewiele się zmieniło.
Tu duże podziękowania dla mojej Izy która nagrała fantastyczny materiał.
Z innych newsów - moje konto na Facebooku zostało zablokowane, ze względu na podejrzenie użycia fałszywego nazwiska. To już drugi raz kiedy tracę konto. W sumie ciekawe - dzień stał się drochę dłuższy.