Programowanie obiektowe. MaxMSP / PD. protokoły komunikacyjne. Paweł Janicki (.com.net.org) 7-9 maja 2010 r.

Transkrypt

1 Programowanie obiektowe MaxMSP / PD protokoły komunikacyjne Paweł Janicki (.com.net.org) 7-9 maja 2010 r.

2 WST ĘP Istniejące aplikacje, języki programowania i środowiska służące budowaniu medialnych performances i instalacji czy obiektów często same w sobie bazują na paradygmacie obiektowym (modularnym), jednak nawet w takim przypadku pozostają one w pewien sposób zamkniętymi systemami. Dopiero umiejętność zestawiania ze sobą systemów złożonych z różnych środowisk i aplikacji pozwala na ominięcie ograniczeń stawianych przez poszczególne składowe. Warto więc spojrzeć na aparatus twórcy medialnego (dotyczy to zarówno komponentów sprzętowych, jak i oprogramowania) jak na zaawansowany system o strukturze modułowej, przy czym poszczególne moduły połączone są stosownymi dla nich protokołami komunikacyjnymi. Tego rodzaju podejście pozwala na swobodną grę strategiami interaktywności i technologiami. Spośród dostępnych (tj. implementowanych przez większość aplikacji i środowisk) protokołów komunikacyjnych w pierwszym rzędzie należy wymienić OpenSound Control (OSC) i MIDI oba protokoły mają zresztą podobną genezę i początkowo służyły do komunikacji pomiędzy urządzeniami generującymi i przetwarzającymi dźwięk. Z czasem okazały się na tyle uniwersalne, że znalazły zastosowanie także w innych dziedzinach. Trzeci przydatny protokół to DMX, służący do sterowania oświetleniem scenicznym, jakkolwiek możliwy do wykorzystania także do kontroli i dystrybucji zasilania do w zasadzie dowolnych urządzeń (istnieją tu jednakże pewne zastrzeżenia, np. urządzenia takie nie powinny poborem mocy przekraczać maksymalnego dopuszczalnego obciążenia dystrybutorów zasilania kontrolowanych przez DMX). Niemniej warsztat, dla którego podstawę stanowi niniejszy dokument będzie koncentrował się głównie wokół MIDI i OSC Kolejną istotną kwestią jest zestaw łączonych ze sobą (traktowanych jako moduły większego zestawu) aplikacji choć punktem wyjścia będzie tu MaxMSP, to w ramach ćwiczeń będzie on spinany z zewnętrznymi aplikacjami i urządzeniami realizującymi rozmaite specjalizowane zadania (generowanie dźwięku, systemy śledzenia ruchu, itp. - lista kilku interesujących programów posługujących się MIDI i OSC znajduje się w dalszej części tekstu). Protokoły komunikacyjne są w oczywisty sposób sednem opisanej wyżej koncepcji. Znajomość zasad posługiwania się protokołami komunikacyjnymi i pewien poziom doświadczenia w pracy z nimi jest podstawowym warunkiem, umożliwiającym wyzwolenie możliwości tkwiących w potraktowaniu całego zasobu pozostających do naszej dyspozycji 2

3 technologii jako meta-obiektowe modularne środowisko. Naturalnie protokoły komunikacyjne nie funkcjonują w próżni: posługiwanie się nimi musi być poprzedzone praktyką w posługiwaniu się aplikacjami, które zamierzamy spiąć za pomocą protokołu komunikacyjnego. Podczas warsztatu zajmiemy się głównie komutowaniem komunikatów pomiędzy uruchomionymi na kilku komputerach instancjami środowiska MaxMSP, lub będziemy przesyłać informacje pomiędzy MaxMSP a innymi aplikacjami dlatego znajomość podstaw pracy z tym środowiskiem w zakresie objętym programem poprzedniego warsztatu i skryptem MaxMSP/PureData (+ Jitter + GEM): wprowadzenie będzie nam niezbędna (skrypt z pierwszej części warsztatów będzie zresztą w dalszym ciągu przydatny, ponieważ zawarte w nim informacje dotyczą również drugiej części warsztatu). Niniejszy dokument ma nieco inną strukturę, niż wspomniany przed chwilą MaxMSP/PureData (+ Jitter + GEM): wprowadzenie nie jest on serią prostych ćwiczeń i omówień podstawowych struktur danych, typów obiektów i technik programistycznych. Jest za to zestawem kilku aplikacji dwóch protokołów komunikacyjnych (OSC i MIDI) umieszczonych w kontekstach, zarówno typowych dla współczesnych zastosowań tych technologii, jak i generujących problemy, z którymi uczestnicy warsztatów zetkną się realizując samodzielne projekty. O ile pierwsza część warsztatu polegała więc na przeprowadzeniu uczestników przez podstawy pracy z obiektowymi językami programowania, o tyle celem drugiej części będzie nauczenie samodzielnego planowania i realizacji aplikacji w oparciu o takie środowiska. Częścią zawartości tego dokumentu są też informacje dotyczące innych, zewnętrznych w stosunku do MaxMSP środowiskach, programach i technologiach mogących z nim współpracować i poszerzyć jego funkcjonalność lub skrócić czas potrzebny na uzyskanie poszukiwanego rezultatu. Innymi słowy: MaxMSP/PureData (+ Jitter + GEM): wprowadzenie stanowił rodzaj instrukcji obsługi, MaxMSP / PD: protokoły komunikacyjne to w dennetowskim sensie dźwignia wyobraźni. 3

4 STRUKTURA I FUNKCJE PRZYKŁADOWEGO ŚRODOWISKA NA POTRZEBY INSTALACJI INTERAKTYWNEJ LUB PERFORMANCE kamera kamera kamera pracująca w paśmie kamera pracująca w paśmie podczerwieni podczerwieni ekran ekran ekran do tylnej projekcji ekran do tylnej projekcji oświetlenie podczerwienią oświetlenie podczerwienią reflektory podczerwieni reflektorykamerze podczerwieni potrzebne potrzebne kamerze projektor wideo projektor wideo projektor podłączony do projektor podłączony do stacji generującej stacji generującej monitorowana przestrzeń monitorowana przestrzeń pole działań performera pole działań performera monitorowane przez mocap monitorowane przez mocap nagłośnienie nagłośnienie stereofoniczny zestaw stereofoniczny zestaw ilustracja 1: elementy i budowa środowiska Typowe środowisko mogące być podstawą medialnej instalacji lub performance przedstawia ilustracja 1. Jest to przestrzeń mieszana fizyczna i wirtualna uzupełniona infrastrukturą składają się z systemu śledzenia ruchu (złożonego z kamery i reflektorów pracujących w paśmie podczerwieni oraz sprzężonego z kamerą oprogramowania uruchomionego na przeznaczonej do tego celu stacji roboczej [PC lub MAC]); projektor i ekran do tylnej projekcji umożliwiające uzupełnienie środowiska o interaktywnie sterowane (np. kontrolowane gesturalnie) projekcje wideo (źródłem danych dla projektora jest kolejna stacja robocza) oraz stereofonicznego zestawu nagłośnieniowego i stacji roboczej z oprogramowaniem do samplingu i syntezy dźwięku umożliwiającego generowanie również sterowanego interaktywnie komponentu dźwiękowego (ponadto, opcjonalnie, istnieje możliwość wyposażenia naszego hipotetycznego stanowiska w system analizy sygnału audio zebranego np. przez mikrofon). Stacje robocze obsługujące poszczególne komponenty systemu komunikują się ze sobą za pomocą protokołu OSC, którego komunikaty 4

5 transmitowane są za pomocą sieci Ethernet lub Wireless-LAN. Wewnętrzna komunikacja pomiędzy aplikacjami uruchomionymi na każdej ze stacji roboczych może być realizowana za pomocą OSC lub MIDI, a w przypadku bardziej zaawansowanych konfiguracji również innych metod, np. gniazd XML. Oprogramowanie przetwarza informacje o ruchu obiektów w monitorowanej przestrzeni (parametry ruchu/gestykulacji) i analizuje (częstotliwość, poziom sygnału) sferę dźwiękową, następnie używa tych danych do kontroli mediów wyjściowych: projekcji i dźwięku. Kluczowymi czynnikami kontrolującymi środowisko są więc osoba performera (ewentualnie publiczność) czyli "miękki" biofeedback i algorytm sterujący interpretacją danych otrzymywanych z systemów śledzenia ruchu i analizy audio. Przez "miękki" biofeedback rozumiem sterowanie medialnymi komponentami środowiska przez głos i gesty performera śledzone za pomocą odpowiednich systemów, jednak bez stosowania technologii biometrycznych (np. śledzących zmiany ciśnienia krwi, pracę oka [eye-tracker], itp.) a więc bez sztywnego przyporządkowania reakcji komponentów medialnych do konkretnych stanów fizjologicznych. "Pomiędzy" technologiami środowiska i performerem (publicznością) istnieje sprzężenie zwrotne pozwalające na dokonywanie wyborów i kontrolowanie systemu. System taki może być rozpatrywany jako kombinacja 3 modułów funkcjonalnych (patrz ilustracja 2 na następnej stronie): dźwiękowego, wideo i realizującego motion/audio tracking. Moduły te działają w oparciu o 3 połączone w sieci stacje robocze (PC lub Mac) i generalnie przyporządkowane do tych stacji, jednakże (co zostanie przedstawione niżej) istnieją możliwości innego podziału mocy obliczeniowych stacji roboczych w niektórych przypadkach może to ułatwić pracę nad projektami. Ponadto wszystkie podsystemy mogą komunikować się za pomocą protokołu OSC, możliwe jest więc opracowanie wielokanałowej komunikacji ze sprzężeniami zwrotnymi lub wzbogacenie środowiska o dodatkowe interfejsy lub technologie (np. komunikacja przez internet i korzystanie z baz danych on-line, sieci mobilne, nietypowe interfejsy sprzętowe, itp. w praktyce dowolna technologia korzystająca z OSC może być w łatwy sposób włączona w środowisko). 5

6 motion tracking system śledzenia ruchu analizujący dane z kamery (monitorującej aktywność performera) i dystrybuujący je w podsystem wideo podsystem audio aplikacja odpowiedzialna za wyświetlanie obrazu (wideo, animacje, itd.) aplikacja generująca komponent dźwiękowy (opcjonalnie analizująca również sygnał audio z mikrofonu) OpenSoundControl komunikaty OSC transmitowane poprzez Ethernet lub Wireless-LAN ilustracja 2: podstawowe komponenty środowiska Moduł realizujący motion tracking (capture) oraz zestawienie odpowiednich protokołów komunikacyjnych zapewniających współpracę wszystkich komponentów systemu stanowią przynajmniej potencjalnie - najtrudniejszą do poprawnego wykonania część środowiska, natomiast komponenty wizualny i dźwiękowy (czyli media prezentacyjne) w zależności od projektu, w którym są użyte, mogą być zestawiane z różnych technologii, również stosunkowo prostych i łatwych do szybkiego opanowania - jednocześnie kształt tych komponentów w największym stopniu musi zostać dostosowany do wymagań konkretnych projektów.poszerzony schemat połączeń komunikacyjnych pomiędzy komponentami i światem zewnętrznym przedstawiono poniżej na ilustracji 3, natomiast ilustracja 4 przedstawia aranżację przestrzeni środowiska). Nasz system zawiera komponenty komponenty związane z kilkoma przynajmniej dziedzinami użytecznymi w konstruowaniu projektów interaktywnych: programowaniem, przetwarzaniem w czasie rzeczywistym dźwięku i obrazu, technologiami komunikacyjnymi, projektowaniem interfejsów. 6

7 kamera kamera (pracująca w paśmie podczerwieni) monitorująca przestrzeń, w której podejmują działania digitizer video oświetlenie w paśmie podczerwieni wejście audio opcjonalny mikrofon (stacjonarny lub bezprzewodowy) zbierający dźwięk z monitorowanej reflektory podczerwieni umożliwiające obserwację aktywnej przestrzeni za karta wideo współpracująca z zewnętrzną kamerą lub zewnętrzny digitizer inne wejścia / wyjścia dostępne poprzez OSC i MIDI (również via Internet i urządzenia mobilne) motion tracking synteza wideo synteza / analiza audio podsystem z oprogramowaniem analizującym obraz z kamery i dystrybuującym uzyskane podsystem z oprogramowaniem generującym komponent wizualny podsystem z oprogramowaniem generującym (opcjonalnie równieź analizującym sygnał projekcja wideo nagłośnienie projektor wideo, ekran, tylna projekcja system nagłośnieniowy stereo komunikaty OSC via Ethernet lub Wireless-LAN analogowy sygnał audio oświetlenie podczerwienią analogowy sygnał wideo sygnał wideo (VGA) połączenie USB, FireWire lub magistrala PCI ilustracja 3: poszerzony model połączeń komunikacyjnych 7

8 ilustracja 4: aranżacja przestrzeni 8

9 SYSTEMY ŚLEDZENIA RUCHU: teoria i wskazówki praktyczne Motion capture (MoCap) / motion tracking / video tracking są ogólnymi terminami określającymi systemy (sprzęt i oprogramowanie) umożliwiające analizę informacji dotyczących ruchu obiektów przemieszczających się w monitorowanej (za pomocą różnych typów sensorów - w tym kamer - lub z wykorzystaniem sensorów montowanych bezpośrednio na ruchomych obiektach) przestrzeni. Geneza tego rodzaju systemów jest dwojaka: z jednej strony pojawiły się jako efekt uboczny rozwijania technologii nadzoru przemysłowego; z drugiej: stosunkowo wcześnie artyści korzystający z technologii komputerowych rozpoznali możliwości tkwiące w analizie digitalizowanego obrazu (warto w tym miejscu przywołać nazwisko Myron W. Krueger ten amerykański artysta urodzony w 1942 r. jest pionierem w dziedzinie tworzenia i stosowania w sztuce systemów śledzenia ruchu) ilustracja 5: system śledzenia ruchu (EyesWeb) W przypadku użycia kamery system śledzenia ruchu pozwala na lokalizowanie ruchomego obiektu (lub obiektów) przemieszczających się w polu widzenia kamery. Algorytmy stosowane w tego rodzaju systemach analizują kolejne klatki obrazu, wychwytują różnice pomiędzy nimi i na tej podstawie generują dane opisujące parametry ruchu śledzonego obiektu lub obiektów. Typowe parametry ruchomych obiektów możliwe do przechwycenia za pomocą systtemów śledzenia ruchu to: wystąpienie ruchu w określonym sektorze monitorowanego pola, powierzchnia ruchomego obszaru, ilość ruchomych elementów (na ogół sprawność algorytmu zachowana jest dla ilości obiektów nie większej niż kilka). współrzędne środka ruchomego elementu (położenie) lub współrzędne wieloboku (typowo: prostokąta), w którym zawiera się ruchomy element. Możliwe jest też wykrywanie konturów obiektów, lub analiza szybkości i kierunków ich przemieszczania się. Osobnymi - wymagającymi większego doświadczenia - dziedzinami są śledzenie ruchu w przestrzeni 3D i analiza gestów: wykrywanie konkretnych gestów lub póz i wykorzystanie tego rodzaju danych do sterowania aplikacjami. wykrywanie konkretnych gestów lub póz i wykorzystanie tego rodzaju danych do sterowania aplikacjami. 9

10 Wśród ograniczeń dotyczących systemów śledzenia ruchu opartych o kamery warto zwrócić uwagę na związane z mocą obliczeniową i częstotliwością pobierania danych z kamery: jedno i drugie sprawia, że systemy tego rodzaju działają tym sprawniej im wyższa jest częstotliwość odświeżania i rozdzielczość obrazu, zarazem wymagając do tego większej mocy obliczeniowej. Koszt obliczeniowy algorytmów śledzenia ruchu jest też zależny od ilości śledzonych obiektów przebywających jednocześnie w monitorowanym polu (o ile algorytm implementuje śledzenie wielu obiektów jednocześnie). Inne ograniczenie jest związane z oświetleniem: ponieważ obraz widziany przez kamerę jest zależny od warunków oświetleniowych: przypadkowe zmiany oświetlenia zakłócają działanie algorytmu detekcji ruchu (podobnie zmiana położenia samej kamery nie może być poprawnie zinterpretowana). Częściowe przeciwdziałanie problemom z oświetleniem zapewnia praca w paśmie podczerwieni. Proste, ale względnie skuteczne i łatwe w zastosowaniu technologie umożliwiają spreparowanie systemów śledzenia ruchu realizujących kilka odmiennych funkcji: wysłanie sygnału o wystąpieniu ruchu w konkretnym miejscu monitorowanego pola (analogicznie jak alarm w systemach dozorowych); śledzenie jednego lub kilku ruchomych obiektów i pobieranie ich położenia (współrzędne X i Y); pobranie wielkości ruchomej plamy obrazu; pobranie współrzędnych prostokąta z ruchomą plamą obrazu (zwyczajowo współrzędne lewego górnego i prawego dolnego rogu); wygenerowanie wieloboku odpowiadającego w przybliżeniu konturom ruchomego obiektu. Przechwycone parametry są formatowane do zestawu komunikatów OSC, które mogą być następnie przetwarzane przez podsystemy audio i wideo. Źródłem sygnału wideo jest kamera pracująca w paśmie podczerwieni, umieszczona centralnie nad monitorowanym polem. Dodatkowe wyposażenie to reflektory podczerwieni zapewniające kamerze odpowiednią ilość promieniowania elektromagnetycznego w monitorowanym przez nią paśmie. 10

11 Zakres i składnia wysyłanych przez system komunikatów powinny być dostosowane do wymagań konkretnych projektów jest to związane m. in. z możliwością zastosowania kilku algorytmów śledzenia ruchu, dysponujących różnymi możliwościami. Możliwe do zastosowania w łatwy sposób algorytmy można podzielić na następujące grupy (często wybór konkretnego algorytmu i jego implementacji może pozbawić nas niektórych możliwości): dla jednego ruchomego obiektu w monitorowanym polu: wykrywanie współrzędnych X i Y geometrycznego środka ruchomego obiektu, pola powierzchni i współrzędnych opisującego ruchomy obiekt prostokąta; dla kilku ruchomych obiektów jednocześnie obecnych w monitorowanym polu: wykrywanie współrzędnych X i Y środka każdego ruchomego obiektu; bez określania ilości o obiektów: wykrywanie wystąpienia ruchu w określonym sektorze lub sektorach monitorowanego pola bez rozpoznawania ilości ruchomych obiektów; przybliżone wykrywanie konturów ruchomych obiektów (przekazanie wierzchołków wieloboku opisującego ruchomy obiekt); systemy śledzenia markerów algorytmy tego typu (chyba najpopularniejszy system śledzenia ruchu oparty o taki algorytm to użyty w słynnym projekcie Reactable program reactivision) śledzą przede wszystkim pojawiające się w polu widzenia markery (ściślej: obiekty z naniesionymi markerami rozpoznawalnymi przez system znacznikami umożliwiającymi identyfikację obiektu i jego położenia). Daje to dość interesujące możliwości, m. in. detekcji parametrów związanych z kątem obrotu danego obiektu w stosunku do założonego jako zerowy dzięki temu wykrywane obiekty mogą służyć np. jako pokrętła (knobs) i stanowić interesującą bazę dla nietypowych interfejsów użytkownika. Dodatkowo system śledzenia ruchu może wykonać i wysłać do pozostałych komponentów kilka dodatkowych obliczeń dotyczących kierunków, szybkości poruszania się, itp. w zależności od potrzeb w konkretnych projektach. W przypadku twórców radzących sobie z programowaniem możliwe jest rozszerzenie funkcjonalności systemu o funkcje wywoływane wysyłanymi do niego komendami OSC (np. generowanie zapytań o status konkretnych sektorów obrazu, itp.). 11

12 Ponadto ponieważ żadna implementacja algorytmów realizujących funkcję śledzenia ruchu nie działa w 100% bezbłędnie (błędy w wyliczeniach pojawiać się mogą np. za sprawą niestabilnego oświetlenia monitorowanego przez kamerą pola lub ze względu na ograniczoną rozdzielczość przetwarzanego obrazu) zarówno sam system śledzenia ruchu jak i korzystające z niego komponenty powinny być zdolne do korygowania pojawiających się błędów (np. poprzez odsiewanie danych statystycznie odbiegających od typowych). Osobnym i istotnym zagadnieniem jest metoda pracy algorytmu analizującego obraz z kamery (ilustracja 5). Generalnie algorytm ten pracuje porównując ze sobą kolejne klatki obrazu i wykrywając różnice między nimi - różnice te świadczą oczywiście o występowaniu ruchu w monitorowanym polu. W ramach tej metody istnieją dwie wersje algorytmu: zamrożenie w buforze klatki obrazu uchwyconej w momencie, kiedy w monitorowanym polu nie ma żadnych ruchomych obiektów i następnie potraktowanie tej klatki jako wzorca z którym porównywane są kolejne klatki; sekwencyjne porównywanie ze sobą klatek wziętych z dwóch strumieni wideo: pierwszego pobranego bezpośrednio z kamery i drugiego - również pobranego z kamery - opóźnionego o zadaną wielkość (w praktyce zwykle 50ms do 1s). ilustracja 6: wpływ algorytmu śledzenia ruchu na uzyskany efekt Pierwsza metoda jest bardziej wszechstronna: pozwala na przechwytywanie danych ze wszystkich wymienionych wyżej grup. Wymaga jednak precyzyjnych warunków oświetleniowych (przy najmniejszej zmianie obraz monitorowanego pola może różnić się na tyle, że system pomimo braku ruchu wykryje jakąś aktywność). Druga metoda ma bardziej 12

13 ograniczone zastosowanie i w praktyce pozwala przede wszystkim na wykrywanie samego wystąpienia ruchu w wybranych sektorach monitorowanego pola. Jednakże druga metoda jest mniej wrażliwa na zakłócenia, nie wymaga "zamrażania" wzorcowego bufora. Ponadto druga wersja wykrywa tylko obiekty poruszające się w określonym przedziale czasu: obiekt pozostający przez pewien czas w bezruchu staje się dla systemu "niewidzialny", ponieważ przy bezruchu trwającym dłużej, niż wartość opóźnienia strumienia wideo kolejne klatki stają się identyczne - jest to zarówno ograniczeniem, jak i specyficzną dyspozycją tej opcji. Niedogodnością związaną z użyciem kamery jest - mniej lub bardziej dotkliwa - latencja (opóźnienie) otrzymania wyniku kalkulacji wynikająca z występujących kolejno opóźnień generowanych przez system przesyłu obrazu z kamery do komputera (porty, sterowniki, ewentualnie - w przypadku kamer bez portów USB lub FireWire - digitizer) i opóźnień generowanych przez oprogramowanie realizujące system śledzenia ruchu. Jedne i drugie zależne są od mocy obliczeniowej, użytych standardów komunikacyjnych (USB, FireWire), konstrukcji portów I/O (w przypadku różnych producentów mogą występować różne wartości), ilości przetwarzanych danych (rozdzielczość, częstotliwość FPS, głębia barw) i wybranej metody procesowania sygnału wideo. Sam przesył danych (w przypadku użycia sieci lokalnych) nie generuje odczuwalnych opóźnień. HIPERŁĄCZA:

14 KOMPONENT WIZUALNY Potencjalne wizualne możliwości obiektowych środowisk interaktywnych obejmują wyświetlanie statycznych obrazów, wideo, obrazu syntetyzowanego, przetwarzanie w czasie rzeczywistym danych wizualnych z zewnętrznych źródeł, czy kreację i kontrolowanie form trójwymiarowych (również w połączeniu z pozostałymi możliwościami) oraz innych form wizualnych w formatach podlegających kontroli poprzez OSC (np. Flash, Director, PD, VVVV, Processing, itp.) lub MIDI. Zasadniczo podsystem wideo może być stworzony za pomocą MaxMSP (często wygodnie jest taki system stworzyć jako osobny projekt komunikujący się w jakiś sposób z pozostałymi segmentami projektu). Nie zawsze jest to jednak wygodne (być może inna aplikacja lub środowisko dysponuje jakąś szczególną opcją trudną do uzyskania w MaxMSP), ponadto w przypadku projektów kooperacyjnych możemy się spotkać z twórcami korzystającymi z innych środowisk i aplikacji nic nie stoi na przeszkodzie, by pomimo tej niedogodności pracować wspólnie. Podsystem wideo może być więc konfigurowany na różne sposoby, może być też integrowany z podsystemem audio (tzn. przedstawiona na schematach struktura jako środowiska wykorzystującego 3 stacje robocze może zostać uproszczona i realizowana przy wykorzystaniu mocy obliczeniowej 2 stacji) - w zależności od potrzeb projektu i umiejętności twórców. Zasadniczymi wymaganiami, które dowolna konfiguracja musi spełnić są sprawne działanie przy dostępnej mocy obliczeniowej oraz oczywiście komunikacja za pośrednictwem MIDI lub OSC. Jeśli z jakiegoś powodu zamierzamy skorzystać z zewnętrznego (w stosunku do MaxMSP/Jitter) środowiska procesowania obrazu, możemy, w zależności od platformy (Mac / PC) i specyfiki projektu skorzystać z wielu różnych aplikacji, środowisk i języków programowania. Np. przypadku, jeśli wizualna strona naszego projektu opiera się o zdigitalizowane klipy wideo i prostą formę interakcji lub generatywności (wyzwalanie i miksowanie klipów sterowane poprzez MIDI) możemy bezpłatnej aplikacji MidiVid (lub MidiVid GPU korzystający z mocy obliczeniowej procesora graficznego) jest to wideo-sampler pracujący na platformie Windows/PC, oferujący wyzwalanie i miksowanie w różnych trybach sekwencji wideo lub strumienia wideo pobieranego w czasie rzeczywistym z kamery podłączonej do komputera przez dowolny standardowy port, kontrolowanych 14

15 poprzez MIDI, a z pomocą dodatkowego oprogramowania również OSC. Bardziej rozbudowane możliwości, zwłaszcza w zakresie syntezy obrazu i animacji można uzyskać za pomocą programów Adobe Flash, bądź Adobe Director. Godna uwagi jest również udostępniana przez firmę Adobe na zasadach opensource platforma Flex SDK, umożliwiająca, pisanie i kompilację programów w języku ActionScript. lub innych niż MaxMSP systemów modularnych obsługujących OSC (Pure-Data, EyesWeb, Impromptu, VVVV, QuartzComposer, itp.). Ponadto aktualnie wiele programów do VJingu obsługuje OSC, więc istnieje możliwość doboru bardziej zaawansowanych wideosamplerów (komercyjnych i bezpłatnych) w zależności od upodobań i potrzeb twórców realizujących konkretny projekt. Natomiast użycie opartych o timeline i typowe narzędzia graficzne i animacyjne komercyjnych narzędzi (np. wspomnianych Flash i Director) pozwala na budowanie struktur zawierających np. interaktywne udźwiękowione animacje, zaś w przypadku w przypadku wykorzystania wizualnych języków programowania istnieje możliwość organizacji materiału wizualnego w sposób obiektowy, charakterystyczny dla tych programów. Kolejną możliwością jest wykorzystanie języków programowania implementujących OSC np. Processing lub OpenFrameworks i profilowanych pod kątem zastosowań graficznych lub języków programowania ogólnego zastosowania. Dośinteresujące może być również wykorzystanie jako platformy generowania obrazu wybranego engine'u gry komputerowej 3D (Unreal, Quake, itp.) lub engine'u czasu rzeczywistego dostępnego poprzez wybraną aplikację do modelowania 3D w tym wypadku szczególnie polecić można Blender, jako aplikację dystrybuowaną na licencji opensource, a ponadto dysponującą dobrej jakości modułem renderującym w czasie rzeczywistym, a przy tym doskonale nadajacym się do sterowania z z poziomu zewnętrznych aplikacji poprzez skrypty języka Python. HIPERŁĄCZA:

16 KOMPONENT AUDIO Podobnie jak podsystem wideo, również podsystem audio nie posiada z góry ustalonej architektury i może być zbudowany z komponentów, jakie najbardziej odpowiadają konkretnemu projektowi. Naturalnie, powinien posiadać możliwość komunikowania się z pozostałymi komponentami poprzez OSC lub MIDI i pracować sprawnie w ramach dostępnej mocy obliczeniowej, ale poza tym nie podlega istotnym ograniczeniom innym niż kompetencyjne. Spośród możliwych do implementowania modeli architektury komponentu audio cztery wydają się najbardziej funkcjonalne i przejrzyste: zastosowanie architektury typowej dla tradycyjnych komercyjnych i darmowych aplikacji muzycznych, czyli wykorzystanie aplikacji bazowej - sequencer audio/midi lub jedynie host dla wybranego formatu pluginów - i zestawu tychże pluginów (w zależności od platformy sprzętowej, systemu operacyjnego i aplikacji bazowej mogą być to pluginy w formacie: VST/VSTi, DirectX, LADSPA, AU, itp.) pracujących pod kontrolą tej aplikacji (ponieważ technologie muzyczne pozwalają w łatwy sposób mieszać rozwiązania sprzętowe i programowe istnieje możliwość zastosowania sprzętowego sequencera i/lub sprzętowych urządzeń MIDI: instrumentów, procesorów efektowych, kontrolerów, itp.) - w tym przypadku sequencer (host) może być sprzężony z pozostałymi komponentami systemu dzięki konwersji komunikatów sterujących pomiędzy standardami MIDI i OSC; zastosowanie wybranego wizualnego języka programowania (np. MaxMSP, Pure-Data, OSW, itd.) dającego możliwość wykreowania własnej aplikacji przetwarzającej lub generującej środowisko dźwiękowe; klasyczne programowanie za pomocą profilowanego na potrzeby tworzenia aplikacji dźwiękowych języka programowania (np. Octave, ChucK, CyberSound, Impromptu, SuperCollider, itp.) lub wykorzystanie języków programowania ogólnego zastosowania; zastosowanie, podobnie jak w przyapdku komponentu wizualnego, któregoś z narzędzi służących do kompleksowego budowania aplikacji medialnych (np. Adobe Flash, Adobe Director) i wykorzystanie jedynie ich dźwiękowych możliwości, lub 16

17 integracja komponentów wizualnego i dźwiękowego w ramach jednej aplikacji zbudowanej przy wykorzystaniu wspomnianych narzędzi. Naturalnie istnieją też inne jeszcze możliwości kreacji komponentu dźwiękowego - cztery powyższe architektury to najbardziej wyraziste przykłady możliwości zastosowania różnych technologii i koncepcji w zależności od potrzeb. W przypadku komponentu dźwiękowego znacznie prostsza - niż w przypadku wizualizacji - jest synchronizacja z pozostałymi komponentami: stosunkowo łatwo jest dokonać specjalizowanymi aplikacjami konwersji pomiędzy komunikatami OSC i MIDI, a ten ostatni protokół komunikacyjny jest uznanym standardem w aplikacjach muzycznych. Oprócz generowania (syntezy) dźwięku istnieje możliwość wykorzystania w informacji opisujących parametry sygnału audio pobranego z wejścia mikrofonowego. Ze względu na ryzyko sprzężeń analiza sygnału audio nie powinna prowadzić do prostego multiplikowania i przesyłania na wyjście sygnału pobranego przez mikrofon. Metody analizy są oczywiście zależne od wykorzystanego w komponencie audio oprogramowania. Najprościej uzyskiwalne parametry sygnału to częstotliwość i poziom oraz dane pobierane dzięki analizie spektralnej. * Osoby zamierzające budować zaawansowane struktury dźwiękowe powinny rozważyć naukę któregoś z języków programowania profilowanego pod kątem zastosowań muzycznych będzie to znakomite uzupełnienie możliwości języka obiektowego, jakim jest MaxMSP, który jak wszystkie języki oparte o paradygmat obiektowy posiada, oprócz niewątpliwych zalet, również realne ograniczenia związane z trudnościami w graficznym przedstawieniu i manipulowaniu np. niektórymi dynamicznie tworzonymi strukturami danych, czy skomplikowanymi instrukcjami warunkowymi. Bez wątpienia najlepiej rozwiniętymi i uniwersalnymi środowiskami programistycznymi wykreowanymi jako narzędzia pracy z dźwiękiem są CSound i SuperCollider środowiska o długiej tradycji, dostępne na wiele platform i dystrybuowane na licencji opensource. SuperCollider, jako narzędzie od początku swego istnienia implementujące techniki programowania on-the-fly, jest niemalże synonimem języka programowania operującego w domenie live coding (programowanie w czasie rzeczywistym, podobne możliwości implementuje coraz więcej nowych języków, np. Impromptu). Natomiast CSound to praktycznie najdłużej rozwijany język programowania zorientowany na pracę z dźwiękiem, 17

18 stąd dysponuje procedurami i komponentami umożliwiającymi realizację dowolnego istniejącego algorytmu generowania lub przetwarzania sygnału dźwiękowego lub prototypowanie zupełnie nowych koncepcji, HIPERŁĄCZA: OPROGRAMOWANIE: NIE TYLKO MAXMSP Komponenty audio i wideo oraz systemy interaktywne (takie, jak stanowiące główny poligon interakcji w niniejszym warsztacie, systemy śledzenia ruchu), mogą być konstruowane przy wykorzystaniu bardzo różnorodnych narzędzi (temat ten został obszernie omówiony powyżej w rozdziałach poświęconych komponentom audio i wideo). O ile wybór narzędzi zależy od preferencji i celów jakie chcą osiągnąć uczestnicy projektu, o tyle istnieje pewien zasób programów, urządzeń i języków programowania (wizualnych i tradycyjnych), na które warto zwrócić uwagę, jako na szczególnie dobrze nadające się do zastosowania bezpośrednio w projektach interaktywnych i multimedialnych, a w szerszej perspektywie również w innych aplikacjach związanych z kreacją interaktywnych struktur na potrzeby performances i instalacji. Narzędzia takie od rozbudowanych systemów mogących służyć jako samodzielne środowiska realizujące większość zadań związanych z reżyserią interakcji po proste programy pomocnicze realizujące jedno lub kilka zadań warto poznać przynajmniej w podstawowym zakresie, by móc właściwie dobierać komponenty na własne potrzeby. Spośród oprogramowania rekomendowanego do wykorzystania warto wspomnieć o następujących aplikacjach: 18

19 Pure-Data ( Pure-Data (PD) można uznać za następcę MaxMSP (autorem programu jest Miller Smith Puckette, który stworzył również pierwsze wersje Max). W odróżnieniu od swego poprzednika jest aplikacją bezpłatną i dostarczaną wraz z kodem źródłowym, oraz rozwijaną jako Wolne Oprogramowanie przez międzynarodowy zespół developerów-wolontariuszy. PD jest wieloplatformowy, istnieją skompilowane wersje nie tylko dla Windows, Linuxa, czy MacOS, ale też wersje dla systemów palmtopowych. Pure-Data już w tej chwili dysponuje potężnymi możliwościami, a przy tym rozwija się bardzo dynamicznie z całą pewnością jest to oprogramowanie "z przyszłością", zaś częściowa kompatybilność z MaxMSP jest również wielką zaletą. PD doczekał się też doskonałego zestawu wtyczek do pracy z mediami wizualnymi (GEM), nie gorszymi od Jitter dla MaxMSP. VVVV ( Program VVVV firmy Meso jest modularnym syntezatorem wideo. Istnieje ciągle w wersji beta, jednak posiada potężne możliwości pracy z animacją komputerową w czasie rzeczywistym. Szczególnie unikalne możliwości w zakresie modelowania animacji 3D stawiają VVVV w rzędzie najlepszych aplikacji tego rodzaju. Autorzy programu używali go z powodzeniem do prac tak różnych jak przygotowanie video-clipów, VJ-ing i wizualizacje architektoniczne, poprzez różnego rodzaju prezentacje, aplikacje i instalacje interaktywne. VVVV jest dystrybuowany na specyficznej licencji, umożliwiającej jego darmowe wykorzystanie w niekomercyjnych zastosowaniach. EyesWeb ( EyesWeb jest darmową aplikacją dostępną na platformę PC/Win opracowaną przez InfoMus Lab (Laboratorio di Informatica Musicale / DIST - University of Genova) jako część prowadzonego przez UE projektu MEGA (Multisensory Expressive Gesture Applications) związanego z sensorycznym rozpoznawaniem ruchu i gestów. Z całą pewnością nie jest programem zapewniającym tak spektakularne efekty wizualne jak CSoundAV, czy VVVV w przypadku wykorzystania go jako narzędzia do pracy z wideo w czasie rzeczywistym, a podobnie ma się rzecz z dźwiękiem. Doskonała dokumentacja i tzw. SDK (Software Development Kit), czyli komponenty pozwalające na samodzielne programowanie rozszerzeń dla aplikacji (wymagana jest do tego znajomość C++) pozwalają wykorzystać EyesWeb jako narzędzie pomocne zwłaszcza w pracach eksperymentalnych. 19

20 CSound ( CyberSound (lub CSound) jest językiem programowania opracowanym w MIT i skoncentrowanym początkowo na obróbce dźwięku (ze względu na zaawansowane możliwości i wysoką konsumpcję mocy obliczeniowej początkowo nie był to system czasu rzeczywistego, którym jest obecnie), aktualnie uzupełniany o elementy graficznego interface'u użytkownika i możliwości pracy z wideo i animacją 3D (głównie w CsoundAV autorstwa kompozytora i programisty Gabriela Maldonado). CSound - pomimo, że jest aplikacją dystrybuowaną jako Wolne Oprogramowanie - jest swego rodzaju przemysłowym i laboratoryjnym standardem opisu algorytmów generowania i przetwarzania dźwięku wiele nowych technik syntezy czy przekształcania dźwięku znajduje swoje piewsze implementacje właśnie w CSound, zanim zostaną - lub nie - wykorzystane w komercyjnych aplikacjach i sprzęcie. CSound jest implementowany na wszystkich ważnych platformach sprzętowych i software'owych. W przeciwieństwie do innych opisanych tu programów CSound jest językiem programowania, nie graficznym środowiskiem (jakkolwiek istnieją graficzne nakładki i rozmaite programy ułatwiające pracę z CSound). Warto jednak pamiętać, że CSound jest programem o bodaj największych możliwościach generowania i obróbki dźwięku oraz wideo i animacji 3D w kontekście ich związków z dźwiękiem. Również mnogość implementacji (w tym jako wtyczki VST, PD, MaxMSP) nie pozostaje bez znaczenia. Processing ( Processing jest dystrybuowanym jako środowisko opensource językiem programowania opartym na Javie i korzystającym z większości jej możliwości: jest implementowany na wielu platformach sprzętowych (również mobilnych), doskonale integruje się z technologiami sieciowymi (m.in. programy napisane w Processingu mogą być łatwo uruchamiane z poziomu browsera WWW). To co - z punktu widzenia użytkownika - odróżnia Processing od Javy to specjalne środowisko stworzone na potrzeby edycji, testowania i publikowania projektów napisanych w tym języku - jest ono o wiele prostsze, niż standardowe implementacje Javy, dodatkowo Processing zawiera biblioteki ułatwiające projektowanie sprzętowych interfejsów współpracujących z tym językiem programowania. Inne dostępne biblioteki umożliwiają konstruowanie w Processingu m.in. systemów śledzenia ruchu. MidiVid ( jest to prosty, darmowy sampler wideo dostępny na platformę Windows - może zostać w łatwy sposób skonfigurowany jako odtwarzacz 20

21 pętli wideo wyzwalanych poprzez komunikaty MIDI. MidiVid dysponuje kilkoma trybami nakładania obrazu, a dzięki prostocie budowy i interfejsu może być wykorzystany przez niezaawansowanych użytkowników. ROB ( ROB jest prostą, darmową aplikacją napisaną w Javie umożliwiającą komunikację za pomocą OSC pomiędzy urządzeniami mobilnymi (wspierającymi Javę i wyposażonymi w Bluetooth), a tradycyjnymi, stacjonarnymi platformami (Mac i PC). vsthost ( jest prostym, darmowym w zastosowaniaqch niekomercyjnych modularnym hostem VST umożliwiającym uruchamianie pluginów w tym standardzie. Działa na platformie Windows. Dzięki modularnej i otwartej architekturze umożliwia bardzo swobodne konfigurowanie własnego środowiska dźwiękowego. airrack ( prosty dostępny w podstawowej wersji jako darmowa aplikacja host VST na platformie Windows, ale symulujący klasyczny układ urządzeń montowanych w statywach typu rack. FLOSC ( FLOSC jest darmową technologią (stworzoną w Javie) umożliwiającą komunikację pomiędzy projektami stworzonymi we Flashu z oprogramowaniem i urządzeniami wykorzystującymi protokół OSC. FLOSC konwertuje dane pomiędzy komunikatami OSC i XML Socket (ten ostatni standard wspiera Flash). MidiYoke, MIDI-OX ( darmowe aplikacje na platformę Windows pozwalające na łatwy routing sygnałów MIDI pomiędzy aplikacjami muzycznymi uruchomionymi na komputerze. Pozwalają m.in. na komunikowanie się ze sobą aplikacji muzycznych (i innych, korzystających z MIDI) uruchomionych równolegle (również takich, które nie wspierają standardu VST i DirectX. Analogiczne funkcje są dostępne na platformie Mac z poziomu systemu operacyjnego. MID2NET, NET2MID, VST2NET, NET2VST ( zestaw prostych aplikacji pracujących na platformie Windows (analogiczne możliwości dostępne są - jako standardowa funkcja systemu operacyjnego - również na platformie Mac), umożliwiających przesyłanie komunikatów MIDI przy 21

22 wykorzystaniu protokołu TCP/IP (a więc przy wykorzystaniu Ethernetu lub WirelessLAN). Wymienione aplikacje są darmowe (dostępne jako część większego pakietu również darmowego - wtyczek VST). Powyższe zestawienie, choć dość obszerne, nie wyczerpuje tematu i możliwości uzupełniania o kolejne technologie. Jakkolwiek poznanie wszystkich wymienionych aplikacji nie jest możliwe w krótkim czasie, to z pewnością powyższy spis ukazuje spore możliwości i elastyczność w doborze własnych komponentów i narzędzi. Spośród innych, nie wymienionych wyżej, komercyjnych i niekomercyjnych narzędzi i standardów warto wymienić m. in.: Octave ( EyeCon ( Isadora ( AudioMulch ( CPS ( FreeFrame ( SuperCollider ( we wcześniejszym rozdziale poświęcam SC kilka słów; i wiele innych... Wyszukiwanie potrzebnych aplikacji i technologii waro rozpocząć od portali tematycznych zbierających zarówno ogólne informacje, jak i linki do konkretnych projektów programistycznych, np

23 PROTOKOŁY KOMUNIKACYJNE: OpenSound Control (OSC) Podstawowe informacje o pochodzeniu i metodach stosowania OSC znajdują się w skrypcie do pierwszej części warsztatu. Warto jednak uzupełnić dane techniczne o kilka uwag bardziej ogólnej natury. OSC zastępuje przestarzały, niespełniający współczesnych wymagań, standard MIDI (opracowany w latach '80). Ponieważ OSC bazuje na technologiach sieciowych pozwala instrumentom muzycznym, kontrolerom, interfejsom i innym urządzeniom komunikować się za pośrednictwem domowych lub montowanych w studiach sieci (TCP/IP, Ethernet), lub poprzez Internet. OSC wykorzystuje przepustowości łączy szerokopasmowych pozwalając - przynajmniej potencjalnie - na realizowanie schematów interakcji niemożliwych do uzyskania za pomocą MIDI. Pozwala poza tym na o wiele większą swobodę w konstruowaniu architektury połączeń i samej struktury przesyłanych komunikatów (OSC wspiera komunikaty tekstowe, numeryczne, oraz przesyłanie pakietów komunikatów lub komunikatów o różnej ilości parametrów. Pozwala też na samodzielne nadawanie komunikatom identyfikatorów). OSC może być łatwo wykorzystany w zastosowaniach audio i wideo, zwłaszcza real-time. W szczególności często bywa stosowany do komunikacji pomiędzy gesturalnymi (i innymi niestandardowymi) interfejsami a kontrolowanymi za ich pośrednictwem aplikacjami. Ponadto sieciowa natura umożliwia wykorzystanie OSC do konstruowania instalacji/performances rozproszonych. W przeciwieństwie do MIDI, OSC nie określa definiuje fizycznej i elektrycznej strony standardu, ani postulowanego znaczenia komunikatów, a jest jedynie formułą przesyłania abstrakcyjnych danych poprzez zdefiniowane w osobnych standardach łącza sieciowe - interpretacja danych jest zależna od komunikujących się aplikacji. Szczególną wersją OSC jest protokół TUIO jest to niejako podzbiór OSC skompilowany jako standard komunikacji z technologiami wykrywania markerów (patrz: rozdział o systemach śledzenia ruchu). HIPERŁĄCZA:

24 PROTOKOŁY KOMUNIKACYJNE: MIDI Podobnie jak omówiony powyżej OpenSound Control, także protokół MIDI został już wprowadzony w pierwszej części warsztatów, ale i w tym przypadku warto przyswoić sobie kilka dodatkowych informacji. MIDI (Musical Instrument Digital Interface) to opracowany w 1983 powszechny przemysłowy (i studyjny) standard komunikacyjny umożliwiający współpracę elektronicznych instrumentów muzycznych, komputerów i innych urządzeń korzystających z tego protokołu (np. technologii oświetleniowych na potrzeby sceniczne, klawiaturom sterującym lub innego rodzaju sterownikom, sequencerom, urządzeniom synchronizującym ze sprzętem wideo). W zamierzeniu MIDI miało umożliwić prostą współpracę instrumentów i innych urządzeń konstruowanych przez różne firmy. Dodatkowo miało zastąpić wcześniej używany standard CV (sterowanie napięciowe) - prosty, ale niewygodny i o niewielkich możliwościach. Poza samym standardem komunikacyjnym (i definicjami formatów elektrycznych, oraz standardów gniazd) akronimu MIDI używa się w kontekście m.in. formatów plików zawierających dane przesyłane za pośrednictwem MIDI rozumianego jako protokół komunikacyjny (SMF0, SMF1, KAR), ustandaryzowanego rozkładu brzmień zawartych w instrumentach elektronicznych (General MIDI, Extended General MIDI), format kodu czasowego i kilku innych znaczeniach powiązanych z wąskopasmową transmisją danych w zastosowaniach muzycznych i medialnych. Tak więc MIDI jest również zespołem standardów i technologii umożliwiających współpracę pomiędzy różnego rodzaju sprzętem i oprogramowaniem implementującym te technologie i standardy. MIDI - ze względu na wąską przepustowość - nie transmituje sygnałów audio (ani wideo), a jedynie komunikaty kontrolne (np. informacje o wysokości lub głośności dźwięku, kontrolery ustawiające vibrato lub pozycję w panoramie stereofonicznej, itp.) oraz sygnał synchronizujący (zależny od tempa utworu) i komunikaty sterujące odtwarzaniem (start, stop, itd.) - tak więc np. przesłany do instrumentu poprzez MIDI komunikat o włączeniu wybranej nuty może wygenerować różne dźwięki w zależności od parametrów i ustawień instrumentu. SPECYFIKACJA: MIDI Manufacturers Association (MMA) Los Angeles, California, USA ( Japan, the MIDI Committee of the Association of Musical Electronic Industry (AMEI) in Tokyo ( 24

25 ZAAWANSOWANE MOŻLIWOŚCI KOMUNIKACYJNE Jak zostało uwidocznione na schematach, nasze modułowe środowisko jest z definicji otwarte imoże być w łatwy sposób rozbudowywane o dodatkowe elementy, w szczególności interfejsy i źródła danych. Zwłaszcza umiejętność programowania w Processing, ActionScript lub innym języku otwiera nowe możliwości: danych w formacie XML, nie tylko z zapisanych na lokalnych nośnikach plików, ale również pobieranych strumieniowo. Dzięki temu projekty mogą przetwarzać informacje pobrane przez Internet ze źródeł dystrybuujących różnego rodzaju informacje sformatowane do XML ( informacji uzyskanych z zapytań kierowanych do internetowych serwisów wyszukiwawczych ( danych z innych źródeł, takich jak publicznie dostępne kamery internetowe, bazy danych SQL i inne ( nietypowych interfejsów sprzętowych, zarówno adaptowanych konstrukcji przemysłowych, jak i samodzielnie budowanych ( Spoglądając w szerszej (choć zorientowanej technicznie ) perspektywie na jakąkolwiek interaktywną instalację lub performance, można założyć, że jest to zespół protokołów komunikacyjnych łączących wymienne i konfigurowalne w zależności od potrzeb komponenty (ilustracja 7 przedstawia schemat hipotetycznej instalacji rozpatrywany jako modularny zespół technologii komunikacyjnych łączących poszczególne elementy). Dlatego właśnie poszukiwania w obszarze okołokomunikacyjnym - a więc skupianie się na tym, co dzieje się niejako "pomiędzy" poszczególnymi komponentami - określają kierunek rozwoju wielu zaawansowanych projektów. 25

26 oświetlenie w paśmie digitizer lub karta wideo kamera pracująca w inne wejścia / wyjścia dostępne poprzez OSC i MIDI (również via Internet i urządzenia mobilne) wejście audio (mikrofon) kontrolery MIDI/OSC, stacja (PC lub Mac) obsługująca system detekcji ruchu (motion tracking) analiza wideo konwersja danych do komunikatów OSC komunikacja - poprzez OSC - z pozostałymi podsystemami edrome i opcjonalne przetwarzanie danych z zewnętrznych stacja (PC lub Mac) generująca komponent dźwiękowy synteza audio opcjonalna konwersja danych opcjonalna analiza zewnętrznego algorytm sterujący funkcjonowaniem komunikacja - poprzez OSC - z pozostałymi podsystemami edrome i opcjonalne przetwarzanie danych z zewnętrznych stacja (PC lub Mac) sterująca projekcją synteza wideo opcjonalna konwersja danych pomocniczy podsystem algorytm sterujący funkcjonowaniem projekcja wideo zewnętrzne urządzenia MIDI komunikacja - poprzez OSC - z pozostałymi podsystemami edrome i opcjonalne przetwarzanie danych z zewnętrznych mixer audio nagłośnienie komunikaty OSC via Ethernet lub Wireless-LAN sygnał wideo (VGA) analogowy sygnał audio analogowy sygnał wideo oświetlenie podczerwienią inne protokoły i technologie komunikacyjne połączenie USB, FireWire lub magistrala PCI połączenia MIDI ilustracja 7: zaawansowane możliwości komunikacyjne 26

27 POLECANE LEKTURY Poza informacjami stricte technicznymi, które w praktyce najlepiej czerpać poprzez WWW (niniejszy dokument zawiera oczywiście komplet najistotniejszych odsyłaczy przyporządkowanych poszczególnym tematom i technologiom), chciałbym zaproponować wybrane pozycje teoretyczne i krytyczne, lokujące działania i eksperymenty medialne w szerszym kontekście sztuki współczesnej tego rodzaju lektura, choć niebezpośrednio związana z techniczną stroną omawianych podczas warsztatu zagadnień pomóc może w zrozumieniu recepcji technologii medialnych przez korzystających z nich twórców, oraz unaocznić pewne kierunki poszukiwań w ramach rzeczywistości kreowanej przez te technologie. W MediaArtHistories [red. Olivier Grau, MIT Press, Cambridge, Massachusetts, London, 2007] znaleźć można przede wszystkim artykuły omawiające relacje pomiędzy technologiami komunikacyjnymi a zagadnieniami kluczowymi dla zrozumienia badań nad współczesną kulturą. Istotne informacje dotyczące praktyki wystawienniczej w relacji do mediów elektronicznych oraz w pewnym stopniu historycznej perspektywy w sztuce mediów korzystającej lub bazującej na cyfrowych technologiach komunikacyjnych proponuję wyszukiwać przede wszystkim w publikacjach dużych centrów wystawienniczych zajmujących się tego rodzaju sztuką. Jako publikacje referencyjne polecam katalog vision.ruhr (Kunst Medien Interaktion aud der Zeche Zollern II/IV Dortmund) [vision.ruhr, Dortmund 2004] oraz net_condition_ art and global media [red. Peter Weibel i Timothy Druckrey, MIT Press, Cambridge, Massachusetts / ZKM Karlsruhe 2001]. Kolejną publikacją omawiającą wzajemne relacje pomiędzy technologią a kulturą jest Engineering Culture [red. Geoff Cox i Joasia Krysa, Autonomedia, Brooklyn NY 2005] w szczególności w tej publikacji znaleźć można ważne informacje i teorie dotyczące tego, w jaki sposób działalność na polu technologii potraktować można jako kulturotwórczą. Na koniec ulokowawszy już przedmiot naszych zainteresowań w szerokim kontekście krytyki i teorii kultury proponuję wrócić do zagadnień bezpośrednio związanych z praxis: Programming Interactivity: A Designer's Guide to Processing, Arduino, and openframeworks [Joshua Noble, O'Reilly 2009] i Making Things Talk: Practical Methods for Connecting Physical Objects [Tom Igoe, O'Reilly 2007] omawiają koncepcje i praktyczne implementacje algorytmów związanych z protokołami i procesami komunikacyjnymi. Jakkolwiek autorzy obu pozycji skupiają się na rozwiązaniach i technikach implementowanych za pomocą klasycznego, polegającego na pisaniu kodu programowaniu, to same koncepcje są uniwersalne i możliwe do przeniesienia na dowolną technologię. 27