.Array[1]. audio audiovideo
 


 
 
 
05:09:2017 GIT todo:prma#325

Ten wpis będzie o tym, dlaczego warto zacząć używać GITa, nawet jeśli nie zamierzamy nigdzie publikować kodu.

Jeżeli napisałeś/aś kiedykolwiek kod dłuższy niż dwie strony, to na pewno był taki moment, kiedy teraz nie działa, chociaż wiesz na pewno, że wczoraj działało. Coś się zepsuło, i trzeba szukać co. Czasami prosciej niż cofać mozolnie wszystkie zmiany które się ostatnio zrobiło, jest cofnąć się do backupu, i napisać jeszcze raz to co się chciało - warunkiem skuteczności takiej operacji jest istnienie odpowiedniego backupu. Bardzo długo procedura polegała u mnie na semi-regularnym wykonywaniu paczki .ZIP z aktualnym projektem, jednak wymaga to po pierwsze systematyczności, a po drugie może mieć katastrofalne skutki - trzeba uważać żeby zrobić snapshot zapsutgo projektu na wypadek gdyby okaząło się że backup był jednak starszy niż myśleliśmy, i że właśnie nadpisaliśmy sboie ostatnie dwa dni pracy. been there one that. a ile razy okazywało się że ZIP zawieał jednak nie wczorajszą, jak myślalem wersję, a zeszłotygodniową, i kończylo sie na mozolnym, manualnym, wycofywaniu się z błędnych zmian.

A jednak, jak pewnie wielu z was, długo myślałem że ZIPY są ok, a git nie jest mi po prostu potrzebny, ze to overkill z którego muszą korzystać tylko duże zespoły, aby zarządzać zmianami wprowadzanymi w wielu miejscach jednocześnie. Miałem tu o rację o tyle, że starsze systemy Version Control (jak SVN czy SubVersion) są w przy większych projektach absolutną koniecznością, bez nich w zasadzie umierasz w bloku startowym, ale jednak wymagają one każdorazowo utworzenia gdzieś na serwerze repozytorium, i faktycznie do jakichś szkicy w processingu czy arduino czas zakładania repo SVN powoduje pewien overhead. Ale GIT reprezentuje tu nieco inną filozofię, i odkąd nieco go poznałem (zaznaczam że nieco, bo moja znajomość go jest napawdę dalej bardzo niewielka) to w zasadzie każda rzecz nad którą zamierzam pracować dłużej niż jeden wieczór dostaje u mnie repozytorium. Słyszałem głosy chwalące gita w zasadzie odkąd szturmem przejął monopol kontroli wersji w świecie open source. Bardzo długo jednak moja prywatna kontrola wersji polegała na wykonaniu co jakiś czas paczki .ZIP

Ale zacznimjmy od wyjaśnienia czym git różni się od 'klasycznych' systemów wersjonowania, i dlaczego była to taka rewolucja. W klasycznym version control istnieje centralny punkt, serwer, który zawiera repozytorium, zaczynasz pracę od check-outu aktualnej, usalonej wersji kodu, wprowadzasz swoje zmiany, a pod koniec dnia robisz ich check-in, wpisujesz je do rejestru zmian, tak aby w razie popełnienia błędu (które są jak wiemy nieuniknioną codziennością, całe to programowanie jest waleniem głową w mur własnej słabości), móc dojść do tego gdzie błąd został popełniony (i ewentualnie zwolnić winnego), oraz przywrócic ostatni stabilny stan - naprawienie błędu popełnionego dzisiaj jest znacznie prostsze niż odkrycie że powstał on gdzieś na przestrzeni ostatniego miesiąca.

Git jest inny w tym, że nie istnieje żaden centralny punkt. To znaczy tak, projekt przy którym pracuje więcej osób oczywiście musi posiadać jakieś umówione 'miejsce zbiórki', gdzie nasze wysiłki łączą się (dokonujemy merge), ale GIT jest systemem rozproszonym, w którym poza umownym wskazaniem tego głównego w ramach zespołu, możemy mówić bardziej o chmurze repozytoriów (dlatego nazywa się go systemem rozproszonym) niż o drzewie z ustaloną strukturą. W gicie bo moje loklane repozytorium (a wszystkie commity idą najpierw do mojego lokalnego repo, w zasadzie nie ma tu commitów do remote, jest lokalny commit a potem push który rozprowadza zmianę) ma w nim równe prawa co repozytorium autora.

Oczywiście GIT nie zabrania ustawienia sobie tego wszystkiego jako struktura drzewiasta, ale sieć ta może przebiegać w bardzo różnych kierunkach (można robić push do kilku źródeł, origins, do różnych branchy, w zasdzie z tej dowolności w tym 'co dalej' wynika to że gita trzeba się nieco nauczyć żeby robić coś więcej. Ale nie ma obowiązku robienia nic więcej.

Piękno gita polega bowiem na tym, że żaden, ani jeden serwer nie jest konieczny. W momencie wskazania gitowi nowego katalogu, i wykonanie komendy inicjalizacji, git zakłada tam nowe, pełnoprawne repozytorium, i rozpoczyna śledzenie zmian. I w tym momencie już zaczynają się benefity. Nie muszę być online, nie musze informować kogokolwiek co robię, żeby czepać profity z sieci bezpieczeństwa jaką daje nowoczesny system version control. Git jest fantatycznie wydajny, i jego obecność nawet tam gdzie masz doczyeninai z tysiącami plików, nie powoduje żadnego obicążenia dla twojej maszyny (analiza zmian ma miejsce tylko na etapie Stagigng). Jedynym kosztem używania go do wszystkiego jest konieczność uruchomienia na chwilę swojego ulubionego klienta w danym katalogu i wydanie komendy Init, nie musisz nigdzie zakładać żądnych kont - tylko BAM i masz repozytorium.

klientów gita jest co niemiara, dla każdego coś miłego. Oczywiście dla hardkorów zawsze będzie wersja command-line, czyli jedyny prawdziwy git, jedna metoda na wykonanie najbardziej rzeźnickich salt wymagających wizard-class skilli, ale istnieje wiele uproszczonych (i dzięki temu przystępnych) narzędzi takich jak SoucrceTree, GitHub Desktop, czy mój prywatny faworyt, Git Kraken.

Wystarczy spojzeć na interfejs krakena, żeby domyśleć się co w nim się podoba. Jest ładny. JEST CZARNY. Żeby oceniać go od strony technicznej nie mam jeszcze dość wiedzy, ale używam go od paru miesięcy i w zasdzie jedyne do czego mogę się przyczepić to że nie sygnalizuje on że trwa tzw Fetch, czyli odpytanie naszego repozytorium nadrzędnego o zmiany - czasami trwa to nawet minutę, podczas której myślimy że jesteśmy na szczycie, a kraken do piero po chwili wyświela historię nowych zmian. Ale dobrze, starczy tego wprowadzenia, czas na to co tygrysy lubią najbardziej.

DEMONSTRACJA:

Załóżmy że mam projekt, nad ktorym chce pracować w katalogu c:\MojProjekt. Tworzę ten katalog, uruchamiam krakena, i proszę o utworzenie (inicjalizację) tam nowego repo

Bam, repozytorium utworzone, właśnie utworzyłeś repozytorium kodu. Oczywiście na razie nic tam nie ma (poza ukrytym katalogiem .git gdzie pracujący w tle demon gromadzi notatki na temat tego co robisz), i nowo utworzonym plikiem README.MD, ale sytuacja szybko się zmieni gdy dodamy tam pierwszy plik. Trzymanie w katalogu głownym repozytorium pliku readme.md nie jest obowiązkowe, ale jest dobrym zwyczajem - w dobrym tonie jest umieścić tam krótki opis zawartości. pliki. MD to zwykłe pliki tekstowe, korzystające z bardzo prostej składni formatowania zwanej MarkDown, ale nie będziemy się tym zajmować. Zacznjmy od wywalenia pliku readme i dodania pliku test.txt, o dowolnej treści

Gdy przełączymy się z powrotem na krakena, zauważamy, że pojawiła się nowa linijka, zawierająca tekst '//WIP' i dwie małe ikonki. WIP oznacza Work in progress, czyli nowe zmiany w projekcie, zielona ikonka to uwtorzenie nowego pliku, a czerwona to usunięcie istniejącego.

Po kliknięciu na to pole, dosajemy krakenowską interpretacje tzw. staging area - jest to lista wszystkich zmian jakie zostały dokonane od ostateniego Commita (o tym ze sekundę). Możemy wybrać albo wszystie, albo tylko niektóre ze zmian, i zmienić ich status z Unstaged na Staged. Przejdą one do pola Staged files, jest to peron z którego odjeżdzają commity, rodzaj poczekalni gdzie możemy zgromadzić naszą 'drużynę' która zabierze się następnym commitem do wieczności. Poniżej zanjduje się pole do wpisania tzw Commit Message, czyli obowiązkowego, krótkiego opisu tego co się zmieniło. Oczywisćie gitowi opis jest wszystko jedno, i jak chcesz możesz tam wstawić tylko np. spację, ale za to że musisz wpisać COŚ dość szybko będziesz gitowi wdzięczny, dzięki temu jako człowiek masz szansę orientacji w historii projektu.

W momencie gdy wcisnę przycisk commit, zmiany zostają zespolone przez GIT do obiektu nazywanego Commitem. Commit to snapshot całego projektu, a nie tylko plików które uległy zmianie - to dosyć istotny niuans, bo git nie pozwala prosto wyciągać z commitów pojedynczych plików - aby nie dopuścić do istnienia rozsynchronizowanych stanów - przywracając później stan z danego commita, przywrócimy stan wszystkich plików, które w danym momencie były już trackowane (tzn były STAGED przyanjmniej raz). Ale idzmy dalej, dodajmy drugi plik tekstowy. Załóżmy że popełniem w nim błąd, z którego zdałem sobię sprawę po wykonaniu drugiego commita. Poprawiłem błąd, co dzieje się dalej?

W krakenie nasza historia commitów wygląda póki co tak

.

Po zaznaczeniu commita możemy podejrzeć zmiany - na czwrono są linijki usunięte, na zielono dopisane - zmiany traktuje się jako usuniecie poprzedniej i dodanie w to miejsce innej linijki.

I teraz tak - piewotnie chciałem ten tekst mniej więcej tutaj skończyć - mój projekt jest już bowiem trackowany, jeżęli będę pamiętał o commitach od czasu do czasu, to korzystam już z najważniejszego dobrodzeijstwa GITA - wszystkie pliki i katalogi znajdujące się wewnątrz repozytorium są od tej pory bezpieczne - gdy popełnie błąd, jestem w stanie znacznie prosciej niż za pomocą sterty paczek z zipami, namierzyć miejsce gdzie powstał, porównać z poprzednią wersją, czy wykonać naniesienie zmian wykonanych przedwczoraj na te wykonane przed chwilą.

No ale dobrze, co stanie się teraz gdy stwierdzę, że mój wierszyk jednak lepiej brzmiał z błędem, rozmyśliłem się. Kraken ma wielkie jak byk przyciski undo i redo, pozwalające na szybkie podróżowanie po historii projektu, ale załóżmy że wacham się dalej, być może będę chciał rozwijać obydwie wersję. klikam więc prawym klawiszem na wybranym commicie, i tworzę tam nowego brancha.

Jest to sytuacja o tyle komforowa, że obydwa stany projektu współistnieją sobie, a korzystając z listy dosępnych branchy po prawej, mogę przerzucać się pomiędzy nimi - trwa to ułamek sekundy dla lokalnych branchy blisko siebie, ale nawet jeśli zmodyfikowałem kilkaset plików, nie powinno trwać więej niż kilka sekund - i wszystkie pliki w moim katalogu roboczym będą wyglądać dokładnie tak samo jak w momencie ostatniego commita danego brancha. Postanowiłem porozwijać chwilę obie wersje mojego wiersza, w jednym dodająć linijkę o papudze, a w drugim idąć radykalnie w błędy ortograficzne i robiąc kolejne dwa. stan widoczny przez okno krakena wygląda mniej więcej tak

W typowej konwencji pion oznacza chronologię, widać tu ciekawą sytuację - jestem na branchu master, tym bez błędu, ale commit na branchu KUT został wykoany później, więc git daje mi do zrozumienia że wersja nad którą pracuje może nie być najbardziej aktualną. oczywiście w tym wypadku nie ma to znaczenia

Ok, i teraz zaczyna dopiero robić się ciekawie. Pomimo tego, że readme nie istniało już na moim dysku od pięciu commitów, plik był już dawno w koszu, ale świadomie omijałem go podczas fazy stage - akcja polegająca na usunięciu pliku nie była wpuszczana na peron. I teraz, gdy mamy już dwie rozdzielne historie projektu, postanowiłem zatwierdzić usunięcie w commicie wykonanym na branchu master (powiedzmy że poprawny wiersz nie wymaga komentarza), przerzuciłem się na branch eksperymentalny KUT, i zamiast przeprowadzać stage tej zmiany, zrobiłem jej reset. Plik został przywrócony - zmiana nie była bowiem w tym branchu jeszcze scommitowana. Dopisałem więc linijkę komentarza o idei artystycznej przyświecającej pisaniu tekstu z błędami, i scommitowałem tą zmianę w readme. Sytuacja jaką mamy teraz jest prawie magiczna - gdy dwuklikam na brancha kod, plik readme.md pojawia się w katalogu, po czym znika gdy przerzucam się na brancha master. Jest to samo w sobie pewnego rodzaju cudem -zmiany odbywają się bowiem fizycznie na moim dysku - program w którym edytuje pliki tekstowe i git nie wiedzą o swoim istnieniu absolutnie nic, ale mimo to cały projekt automagicznie przeskakuje do innego stanu. To jednak nie koniec cudów.

Załóżmy że kiedyś, w dalekiej przyszłośći, gdy obie wersje mają już po wiele stron, postanowię skleić je z powrotem w jeden projekt, czyli wykonać tak zwany merge. W sytuacjach gdy w różnych branchach pracowałem nad różnymi plikami, merge przebiega automatycznie - git weźmie nowsze wersje każdego pliku i sprawa jest załatwiona - tu jednak istnieje konflikt - w jednej wersji doszła linijka, w drugiej treść pozostałych uległa zmianie - git nie jest pewien o co dokładnie mi chodzi, ale mergowanie branchy jest w zasdzie jednym momentem że coś może pójść nie tak - git po wykryciu konfliktu wchodzi z projektem w tzw conflicted state -

Po otwarciu konfliktu możemy (a nawet musimy zanim przejdziemy dalej) przejść przez wszystkie skonfikotowane pliki i wskazać rozwiązanie które mnie interesuje. Taki widok dostajemy po wybraniu pliku readme.md - w jednym branchu plik został dawno skasowany, a w drugim został zmodyfikowany. git daje mi więc trzy opcje - może plik skasować, zostawić zmodyfikowany, albo przywrócić ostatnią wspólną (w tym wypadku bazową) wersję, a więc nie tylko cofnie modyfikacje, ale też przywróci wersję dawno skasowaną, którą zawierał wyłącznie pierwszy, automatyczny commit tego repozytorium. Postanawiam zapisac zmodyfikowana wersje

Nieco bardziej skomplikowana sytuacja jest w pliku ala. Dopóki konflikty nie zostaną rozwiązaneW tym stanie pliki gdzie wystąpił konflikt nie nadają się do użycia - zawierają bowiem linijki z obydwu wersji. Kraken (niestety tylko w wersji pro) pozwala mi przejść przez konflikty, i wybrać wersję z dwóch commitów które próbuję mergować przy każdej linijce. Być może wolę zatrzymać błąd tylko w pierwszej linijce, a w drugiej przywrócić wersję bez błędu

Jeszcze więcej możliwości daje nam użycie zewnętrznego narzędzia do mergowania, np. potężnego choć brzydkeigo jak noc KDIFF, który wyciąga z repozytorium nie tylko wersje z mergowanych commitów ale także wersję bazową, pozwalając kształtować ostateczny kształt wynikowego pliku z jeszcze większą precyzją.

Po wykonaniu merge na naszym wykresie widzimy po raz pierwszy jeden z przyjemniejszych widoków jakie ogląda programista na swoim ekranie - dwie odrębne gałęzie projektu z powrotem sklejone w jedną doskonalszą całość. Rezutlaty merge trzeba oczywiście jeszcze scommitować (tzn utworzyć nowego commita zawieającego snapshot po merge, bo nie wolno nam modyfikowac już istniejących commitów - nie ma takiej operacji - wolno zmienić commit message, ale ponieważ na istnieniu danego commita mogą już polegać kolejne operacja, zwłaszcza jeżeli zmiany zostały pushniete to zmiany commitów wstecz w historii nie są zasadniczo mozliwe (chyba że mamy już wizard level i nie boimy się zagrzebać w wariacjach commandlinowego, surowego gita))

I teraz, robię sobie ten przykład na jednym komputerze, pracując na dwóch lokalnych branchach, ale częstszym use case są różni ludzie pracujący na różnych branchach - i wtedy możliwa jest sytuacja, w której ja siedzę dalej na swoim branchu KUT, jeszcze lśniącym połyskiem dopiero co odbytego merge, ale w tym czasie ktoś zmodyfikował brancha master, i teraz zawiera on zmianę której w moim branchu nie ma (i brardzo dobrze, bo mogłaby ona coś psuć w strukturze mojego projektu). taki stan widzimy mniej więcej tak


Tym razem jednak, ponieważ zmiana dotyczyła pliku który na branchu KUT nie był modyfikowany, merge przebieg całkowicie automatycznie - brach master ma od tej pory zestaw zmian wykonanych na nim, wraz ze zmianami których doknałem podczas merge na branchu KUT, który w tej chwili jednak pozostaje do tyłu względem HEAD, tzn nie zawiera nowych zmian. Na tym etapię mogę uznać, że branch KUT nie jest mi już potrzebny, ponieważ master zawiera wsystkie zmiany których chciałem, i po prostu go usunąć (przejść na stałe na branch master)

Mogę także, jeśli chcę, zmergować zmiany z brancha master do brancha KUT (i wprowadzić dalsze zmiany, np. zmienić alę na janka), i będzie to wyglądać tak:

I tak dalej, i tak dalej, taki mniej więcej jest rytm GITa. Dlaczego commity uciekają sobie do góry i muszą się gonić? Aby to zrozumieć wystarczy odejść od mojej hipotetycznej sytuacji. W tej chwili pracowałem tylko i wyłącznie na lokalnym repozytorium, przez cały czas pisania tego tekstu nie wysłałem w sieć ani jedneo pakietu. Przy pisaniu czegoś w parę osób, z repozytorium dostępnym online, do całej zabawy dochodzą jeszcze dwie operacje - PULL i PUSH. Push, prawdopodobnie najważniejsza operacja w ramach GIT, powoduje wypchnięcie twojego ostatniego comita do repozytorium ustawionego jako twój ORIGIN - można traktowąć to jako repozytorium nadrzędne, choć nie będzie to do końca słuszna metafora, w każdym razie w momencie wykonania pusha (o ile masz do niego prawa zapisu) twoje lokalne commity stają się częśćią stanu danego brancha w zewnętrznym repozytorium (REMOTE). Zanim jednak git pozwoli ci na pusha, musi upewnić się że stan danego brancha nie uległ w międzyczasie zmianie - jeżeli tak, to musisz wykonać najpierw operację PULL, tzn pobrać z serwera comitty innych ludzi które stały się od tego czasu 'oficjalne'. Jeżeli stefan w międzyczasie zmienił psa na hipototama, i jego push znalazł się na serwerze wcześniej, to nie mogę tego po prostu zignorować (tzn mogę, robiąć Force Push, ale może mieć to negatywne konsekwencje dla innych ludzi, którzy w mieczyasie wykonali merge hipototama - ich praca zostanie wtedy utracona), unikamy więc robienia Force Push, zamiast tego najpierw wykonujemy PULLA. Pull powoduje pobranie z serwera historii commitów któe wydarzyły się odkąd ostatni raz wykonywaliśmy tą operację, i odtworzenie ich z playbacku na moim lokalnym repozytorium. Powoduje to zmianę stanów moich lokalnych plików. Jeżeli żaden z tych plików nie był modyfikowany przeze mnie, pliki te znajdą się po prostu w Unstaged, mogę je zignorować i wypchnąć moje zmiany, jeżeli jednak zmiany które są już na REMOTE są w konflikcje z tymi które zrobiłem ja, mam do wyboru albo przeprowadzić merge w ramach swojego lokalnego repozytorium, albo jeżeli nie chcę tego robić, utworzenie nowego brancha (który będzie moim lokalnym stanem, ale przestanie synchronizować się ze zmianami w innych branchach.

Jeżeli kiedykolwiek pobieraliscie cokolwiek z GitHuba, a na pewno tak, to z pewnością zauważyliscie że oprócz DOWNLOAD jest tam przycisk CLONE. To w zasadzie esencja popularności gita - mogę pobwiem sklonować repozytorium z REMOTE (w tym wypadku z githuba), dokonać lokalnych zmian, i jeżęli uważam że zmiany te poprawiają projekt, mogę zrobić ze swoim repo mniej więcej trzy podstawowe czynności - jeżeli mam uprawnienia zapisu do danego REPO, mogę je po prostu tam wysłać, za pomocą operacji PUSH. Jeżeli nie, mogę zrobić tak zwany pull request, tzn wysłać zmiany autorowi jako propozycje - jeżeli sposobają się autorowi, może on wykonać merge do swojej wersji (co dla niego jest znacznie prostsze niż przeklejanie fragmentów poprawek wysłanych mailem). Jeżeli autor nie chcę pullować moich zmian, albo jeżeli chcę ten projekt pociągnąc z zupełnie inną stronę, wystarczy że zmienie adres origin na inny, nowy, tworząc w ten sposób tak zwanego FORKA, i mam nowe, niezależne od poprzedniego repozytorium, do któego już sam przyznaje uprawnienia zapisu, rozważam pull requesty itp. Jeżeli chcę zrobić swoją wersję jakiegoś projektu - czy będzie to mikroskopijny GITST mrugający ledem zawierajacy pojedynczy commit, czy cały np dotnet/corefx który zawiera w tym momencie ponad 24k commitów, o ile licencja na to pozwala mogę takie repo sklonować, puschnąć gdzie indziej i mieć swoejgo forka jako anonimowy typek z polski, na równych prawach z wielkimi korporacjami. Jest to ekstremalnie demokratyczna idea, prawie że uskrzydaljąca.

Okej, poszedłem z tym tekstem dużo dalej niż chciałem (nie pierwszy raz), tak naprawdę chciałem poukładać sobie sam to wszystko w głowie podczas pisania, ale jeżeli dotarłeś do końca to widocznie dostrzegasz w tym dla siebie pewien pożytek. Najważniejszym takeawayem z zabawy jest to, że stan w którym robsiz COMMIT wchodzi do gitowej zamrażarki, i już zawsze możesz do niego wrócić - nie jest to pełna kopia projektu a jedynie snapchot zmian, polegający na poprzednich snapshotach (dlatego nie wolno ich modyfikować), dzięki czemu nawet dla dużych projektów GIT nie zwiększa znacząco objętości projektu, lokalne commity są bardzo tanią operacją, i w zasadzie możesz je robić po napisaniu dowolnie małego fragmentu kodu - a potem podróżować po historii projektu jak tylko jest ci wygodnie, szukajać miejsca gdzie cos przestało, albo zaczęło działać, czego sobie i wam życzę.


 
 
05:07:2017 Unreally todo:prma#324

Kolejny kwiatek z unreala

Unreal raczył mi wysłać BWNa, bardzo ważną wiadomość, pojawiło się okienko z notyfikacjami, ale oprócz stada błędów z buildowaniem świateł pokazało się (1) przy Localisation services. Pomyślałem, w sumie ciekawe co tam jest.

Tak, dziękuję bardzo, wiem że nie ma w tym projekcie lokalizacji, nie pada żadne słowo nawet, jest ok, chill out, Unreal, fajnie byłoby dostawać tego typu ostrzeżenia wtedy kiedy naprawdę coś się dzieje, jak na przykład inna sytuacja z dzisiaj, kiedy nastąpił crash edytora podczas applyowania baked lightmap, zakończone stanem w którym scenę główną dało się otworzyć około trzech razy zanim wchodziła w stan corrupted, crasujący edytor, i wymagała rekonstrukcji od nowa z przeniesieniem zaimportowanych obiektów na czystą scenę, zanim i ona ulegała korupcji, i tak około siedmiu razy zanim znaleźliśmy przyczynę, pomyślałem, z pewną sympatią do programistów spoglądając na ten komunikat, i rozmyślając o tym jak różne rzeczy mogą być ważne dla różny ch ludzi przy tego rodzaju projekcie.

Wtedy zwróciło moją uwagę, aż pięć (5) BWNów w sekcji Source Control. Jako że w tym projekcie source control za bardzo nie ma, mogłem się spodziewać następującego komunikatu, ale mimo wszystko wywołał na mojej twarzy uśmiech

czasami sobie myślę, że

Ten cały Unreal to jest jeden wielki Easter Egg.




ps. gdyby kogoś interesowało, co zawierają pozostałe BWNy, oto ich treść

oraz

Czyli ogólnie nic ciekawego, dzień jak codzień


 
 
15:06:2017 UnitySnippets todo:prma#323
Użytkownicy VSCode często instalują sobie (i słusznie) różne pomagiery do kodu. Jeden z nich jednak, UnitySnippets od Ycleptic Studios ma brzydką cechę, podczas zatwierdzania jego sugestii dodaje dodatkowo napoczęty blok komentarza i niezakończoną kopię deklaracji metody (np. void funkcja /*koment*/ void funkcja() { }, co potrafi być bardzo wkurzające.

Na pomoc przychodzi jednak z odsieczą Iionize ze swoją modyfikacją tego dodatku która nie ma takiego zchowania

A swoją drogą instalacja VSCode tak, aby działał w nim Omnisharp/Intelisense na nowej instalce OSX 10.9 to jakiś koszmar - nie udało mi się to dziś.


 
 
12:06:2017 UNREAL todo:prma#322
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.


 
 
29:05:2017 UNREAL todo:prma#321
UNREAL

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


 
 
18:05:2017 Vscode todo:prma#320

VSCODE ma minimapę!

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)


 
 
33:04:2017 Unity3D todo:prma#319

Unity 3D - wybór IDE

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. 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


 
 
22:04:2017 todo:prma#318

[ShowOnly]

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.


 
 
21:04:2017 todo:prma#317

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


 
 
20:04:2017 todo:prma#316
Unity 3D - Rainbow Folders/h>

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.


 
 
10:04:2017 todo:prma#315

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.


 
 
09:04:2017 todo:prma#314

 
 
3:01:2017 todo:prma#313

Setup zambara

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.


 
 
20:20:2016 todo:prma#312
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.
 
 
18:04:2016 todo:prma#311

 
 
16:04:2016 todo:prma#310

 
 
14:04:2016 todo:prma#309
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.
 
 
28:03:2016 todo:prma#308

 
 
26:03:2016 todo:prma#307

 
 
30:01:2016 todo:prma#306
Soundcheck Session podczas Karanawałowej Domówki Na Pełnej
 
(226-245)   (246-265)   (266-285)   (286-305)   (306-325) 
 
  2D Guestbook::2DGB   (cc) 1982 19861998 2000-2013 2014 2018 2024 by zambari@gmail.com  
  

Creative Commons License