Protokół OSC w instalacjach artystycznych: od konfiguracji do synchronizacji

Własne skrypty sieciowe są elastyczne, lecz wymagają budowania całej warstwy komunikacji od zera. Wtedy pojawia się pomysł, żeby przejść na OSC — i rzeczywiście część problemów znika. W ich miejsce przychodzą jednak pytania o adresy, porty, typy danych, stabilność UDP oraz sposób synchronizowania kilku urządzeń.

OSC, czyli Open Sound Control, stał się jednym z najwygodniejszych sposobów wymiany danych sterujących w czasie rzeczywistym między środowiskami używanymi w sztuce cyfrowej. Nie dlatego, że jest idealny. Nie jest. Jego przewaga polega raczej na tym, że dobrze wypełnia przestrzeń między prostym MIDI a rozbudowanymi frameworkami sieciowymi. Pozwala przesyłać dane o różnych typach, porządkuje je za pomocą hierarchicznych adresów i działa między aplikacjami, które często nie mają ze sobą wiele wspólnego poza tym, że muszą reagować na siebie w czasie rzeczywistym.

W praktyce protokół OSC w instalacjach artystycznych wymaga połączenia kilku perspektyw. Sama konfiguracja adresu IP i portu nie wystarczy, jeśli nie ma spójnego nazewnictwa ścieżek. Z kolei dobrze zaprojektowane adresy nie pomogą, gdy sieć bezprzewodowa gubi pakiety albo firewall blokuje ruch. Stabilna komunikacja między urządzeniami w instalacji zaczyna się więc nie od kliknięcia jednego przełącznika, ale od decyzji architektonicznych podjętych jeszcze przed otwarciem projektu dla publiczności.

Geneza i przewaga OSC nad standardem MIDI w sztuce cyfrowej

OSC opracowano pod koniec lat 90. w centrum CNMAT — Center for New Music and Audio Technologies na Uniwersytecie Kalifornijskim w Berkeley. Za projektem stali Adrian Freed i Matt Wright. Punktem wyjścia była potrzeba wygodniejszego sterowania systemami muzycznymi i multimedialnymi niż to, na co pozwalał standard MIDI.

MIDI pozostaje użyteczne, szczególnie w świecie instrumentów sprzętowych. Jego zaletą jest przewidywalność, ogromna liczba kompatybilnych urządzeń i prosty model komunikacji. Problem pojawia się wtedy, gdy trzeba sterować nie tylko nutą, głośnością czy zmianą programu, lecz także złożonymi parametrami obrazu, ruchem obiektu, stanem czujnika albo wieloma wartościami opisującymi gest.

Podstawowy komunikat Control Change w MIDI składa się z bajtu statusu oraz dwóch bajtów danych. Jeden z nich określa numer kontrolera, drugi jego wartość. Sama wartość kontrolera ma zazwyczaj zakres od 0 do 127, czyli rozdzielczość 7-bitową. MIDI przewiduje również komunikaty o rozdzielczości 14-bitowej, budowane z par MSB i LSB, ale wymagają one uzgodnienia sposobu obsługi po obu stronach i nie zmieniają podstawowej, kanałowej logiki standardu.

OSC podchodzi do tego inaczej. Nie opisuje komunikatu jako numeru kontrolera na określonym kanale, tylko jako adresowaną wiadomość z jednym lub wieloma argumentami. Dzięki temu jeden pakiet może przenosić kilka powiązanych wartości, a odbiorca może rozróżniać je na podstawie ścieżki i typów danych.

Rozdzielczość danych

OSC często wykorzystuje 32-bitowe liczby zmiennoprzecinkowe. Nie oznacza to jednak, że każda liczba dziesiętna jest przechowywana dokładnie. W zapisie binarnym wiele wartości, które wyglądają prosto w systemie dziesiętnym — na przykład 0,728491 — jest reprezentowanych jako najbliższe przybliżenie możliwe do zapisania w danym formacie. Dla większości parametrów sterujących ta precyzja jest wystarczająca, ale nie należy opisywać jej jako nieskończonej ani zakładać, że każda cyfra po przecinku zostanie zachowana bez zmiany.

W instalacji wizualnej różnica między siedmioma bitami a 32-bitową liczbą zmiennoprzecinkową nadal jest praktycznie odczuwalna. Płynniej można sterować pozycją obiektu, intensywnością światła, częstotliwością filtra czy parametrem symulacji. Nie chodzi przy tym o samą liczbę miejsc po przecinku. Chodzi o to, że dane można przekazywać w formie bliższej temu, jak parametry są faktycznie reprezentowane w środowiskach takich jak TouchDesigner, Max/MSP, Pure Data czy Processing.

Hierarchiczna przestrzeń adresowa

MIDI korzysta z kanałów i numerów kontrolerów. OSC wykorzystuje ścieżki przypominające adresy:

• /Visuals/Layer3/Opacity
• /Audio/Filter/Frequency
• /Kinect/Skeleton/Joint/Hand/PositionX

Adres może opisywać nie tylko pojedynczy parametr, ale również miejsce tego parametru w większej strukturze projektu. To szczególnie przydatne wtedy, gdy instalacja ma wiele scen, warstw obrazu albo źródeł danych. Dobrze zaprojektowane nazwy pozwalają rozpoznać pochodzenie wiadomości bez zaglądania do dodatkowej dokumentacji.

Ta swoboda ma jednak swoją cenę. OSC nie narzuca jednego obowiązującego systemu nazewnictwa. Jeśli jedna osoba używa /Visuals/Speed, druga /visual/speed, a trzecia /Layer_1/Rate, po pewnym czasie sama elastyczność protokołu zaczyna utrudniać pracę. Adresy warto ustalić przed rozpoczęciem implementacji i zapisać w krótkiej dokumentacji projektu.

Więcej niż jeden argument

W MIDI sterowanie czterema parametrami oznacza zwykle wysłanie czterech osobnych komunikatów Control Change. Każdy z nich zajmuje trzy bajty: jeden statusu i dwa danych. W OSC jedna wiadomość może zawierać kilka argumentów różnych typów — na przykład liczbę zmiennoprzecinkową, liczbę całkowitą i tekst — pod jednym adresem.

Nie zawsze będzie to najlepszy wybór. Zbyt szerokie wiadomości utrudniają debugowanie, a łączenie przypadkowych parametrów w jednym pakiecie nie tworzy automatycznie sensownej struktury. Gdy jednak kilka wartości opisuje ten sam stan, przekazanie ich razem może uprościć komunikację i ograniczyć ryzyko chwilowej niespójności.

OSC nie jest „lepszym MIDI”. To inna logika komunikacji: MIDI porządkuje sterowanie wokół kanałów i komunikatów, a OSC wokół znaczących adresów oraz typów danych.

OSC i MIDI obok siebie

W instalacji nie trzeba wybierać jednego standardu dla wszystkiego. MIDI może obsługiwać syntezator, klawiaturę albo kontroler sprzętowy, a OSC może przenosić informacje między aplikacją wizualną, czujnikami i systemem dźwiękowym. W takim układzie warto wyraźnie rozdzielić role obu protokołów, zamiast próbować tłumaczyć każdy rodzaj danych na każdy inny.

Architektura komunikacji: adresy, porty i pakiety danych

Żeby poprawnie skonfigurować OSC, trzeba rozdzielić trzy rzeczy, które w praktyce często się mieszają: adres IP urządzenia, port oraz adres OSC wewnątrz wiadomości.

Adres IP wskazuje urządzenie w sieci. Port wskazuje usługę, do której ma trafić pakiet. Adres OSC opisuje parametr lub zdarzenie przenoszone przez ten pakiet. Jeśli jeden z tych poziomów jest niezgodny, wiadomość może nie dotrzeć albo dotrzeć do aplikacji, która nie wie, co z nią zrobić.

Struktura wiadomości OSC

W uproszczeniu wiadomość OSC składa się z trzech elementów:

1. Wzorca adresu — ścieżki zaczynającej się od ukośnika, na przykład /Visuals/Background/Color/R.

2. Ciągu znaczników typów — informacji o tym, jakie typy mają kolejne argumenty. f oznacza liczbę zmiennoprzecinkową, i liczbę całkowitą, s tekst, a b dane binarne.

3. Argumentów — właściwych wartości przesyłanych do odbiorcy.

Wiadomość pod adresem /Visuals/Background/Color/R może zawierać wartość zmiennoprzecinkową 0,85. Odbiorca interpretuje ją jako zmianę składowej czerwonej koloru tła. Jeśli ten sam adres zostanie użyty raz dla liczby, a innym razem dla tekstu, część środowisk może zareagować nieprzewidywalnie. Typ danych powinien być stały dla danego parametru, chyba że projekt świadomie przewiduje konwersję.

Nadawca, odbiorca i porty

W codziennej pracy często mówi się o kliencie i serwerze, choć w OSC te role mogą zależeć od kierunku komunikacji. Tablet z TouchOSC może wysyłać dane do komputera z TouchDesignerem, ale ten sam komputer może jednocześnie odsyłać komunikaty do tabletu albo do kolejnego systemu.

Najważniejsze parametry konfiguracji to:

• Adres IP odbiorcy — 127.0.0.1, gdy nadawca i odbiorca działają na tej samej maszynie, albo adres urządzenia w lokalnej sieci.
• Port docelowy — port, na którym nasłuchuje aplikacja odbierająca dane.
• Port lokalny — port, z którego aplikacja wysyła albo na którym oczekuje komunikatów zwrotnych.
• Protokół transportowy — najczęściej UDP, czasem TCP, zależnie od aplikacji i wymagań projektu.

W TouchOSC często spotyka się konfigurację z portem 8888 dla wysyłania i 7777 dla odbioru, ale konkretne wartości zależą od wersji aplikacji, wybranego profilu i ustawień projektu. Najważniejsze nie jest użycie określonego numeru, lecz zgodność portu wysyłania z portem nasłuchiwania po drugiej stronie.

Warto także unikać automatycznego przyjmowania, że port „odbioru” oznacza to samo w każdym programie. Jedna aplikacja może opisywać go z perspektywy nadawcy, inna z perspektywy odbiorcy. Przy diagnozowaniu problemu najlepiej rozpisać kierunek komunikacji: kto wysyła, na jaki adres IP i port oraz który komponent ma na tym porcie nasłuchiwać.

Konfiguracja środowiska: od TouchOSC do TouchDesigner

Najprostszy scenariusz wygląda znajomo: suwak na tablecie zmienia parametr wizualny w TouchDesignerze. Żeby jednak taki układ działał podczas wystawy, trzeba sprawdzić więcej niż samo pojawienie się pierwszego komunikatu.

Przygotowanie sieci

Tablet i komputer powinny znajdować się w tej samej sieci lokalnej. W przypadku instalacji dobrze sprawdza się router używany wyłącznie przez system wystawienniczy, bez przypadkowych urządzeń podłączających się do niego w trakcie działania. Komputer odpowiedzialny za projekcję warto połączyć z routerem przewodowo. Kontroler mobilny może pozostać w sieci Wi-Fi, ale główna maszyna nie musi wtedy dzielić bezprzewodowego kanału z resztą systemu.

Trzeba też sprawdzić, czy sieć nie izoluje klientów bezprzewodowych od urządzeń przewodowych. Niektóre routery mają tryb, w którym urządzenia Wi-Fi mogą korzystać z internetu, ale nie mogą komunikować się między sobą ani z komputerami podłączonymi przewodem. Dla OSC taki układ wygląda jak awaria aplikacji, choć problem znajduje się niżej — w konfiguracji sieci.

Konfiguracja TouchOSC

Po stronie TouchOSC należy wskazać:

• adres IP komputera odbierającego komunikaty,
• port, na którym nasłuchuje odbiorca,
• ewentualny port dla komunikatów zwrotnych,
• adresy przypisane do elementów interfejsu.

Suwak odpowiedzialny za prędkość animacji może wysyłać dane pod /Visuals/Speed, a pokrętło sterujące filtrem dźwięku pod /Audio/Filter/Frequency. Nazwa powinna mówić, co dana wartość oznacza, ale nie musi odzwierciedlać całej struktury programu. Lepiej utrzymać kilka konsekwentnych poziomów niż budować bardzo długie ścieżki, których nikt później nie chce wpisywać ani sprawdzać.

Warto od razu ustalić zakresy wartości. Interfejs może wysyłać liczby od 0 do 1, podczas gdy parametr w TouchDesignerze oczekuje zakresu od 0 do 100. Taka różnica nie jest błędem protokołu, ale wymaga jawnego przeskalowania po stronie odbiorcy. Ukryte konwersje są częstym źródłem sytuacji, w której komunikacja działa, lecz efekt wizualny wydaje się niewłaściwy.

Konfiguracja TouchDesigner

TouchDesigner udostępnia kilka operatorów przydatnych w pracy z OSC:

• OSC In CHOP odbiera dane i udostępnia je jako kanały, które można dalej przetwarzać lub podłączać do parametrów;
• OSC In DAT pokazuje odebrane wiadomości w formie tabeli, co ułatwia sprawdzanie adresów i wartości;
• OSC Out CHOP wysyła dane z TouchDesignera do innych aplikacji lub urządzeń.

Na początku lepiej użyć OSC In DAT do weryfikacji samego ruchu wiadomości. Dopiero gdy adresy i wartości pojawiają się poprawnie, można podłączać je do logiki wizualnej. Dzięki temu łatwiej rozdzielić problem sieciowy od problemu z mapowaniem parametrów.

Jeżeli OSC In CHOP odbiera wiadomość, ale nie steruje właściwym parametrem, przyczyną może być niezgodna nazwa kanału, inny zakres wartości albo dodatkowy poziom adresu, którego operator nie mapuje w oczekiwany sposób. Warto testować jedną ścieżkę naraz, zamiast uruchamiać cały system i szukać błędu w kilkudziesięciu komunikatach.

Konfiguracja OSC nie kończy się na wpisaniu adresu IP. Trzeba dopasować adres urządzenia, port, ścieżkę, typ danych i sposób mapowania wartości po obu stronach.

Weryfikacja przed podłączeniem wizualizacji

Najpierw należy sprawdzić, czy wiadomość dociera. Dopiero potem warto pytać, czy obiekt reaguje poprawnie. W TouchDesignerze można obserwować odebrane dane w OSC In DAT, podglądać kanały w OSC In CHOP i testować parametr za pomocą jednej kontrolki.

Jeśli wiadomość nie pojawia się w odbiorniku, najczęściej problem wynika z jednego z kilku powodów:

• port wysyłania nie odpowiada portowi nasłuchiwania;
• adres IP wskazuje nie tę maszynę;
• urządzenia znajdują się w różnych podsieciach;
• firewall blokuje ruch UDP;
• router izoluje klientów Wi-Fi;
• aplikacja nasłuchuje na innym interfejsie sieciowym;
• adres OSC jest poprawnie wysyłany, ale odbiornik oczekuje innej ścieżki.

Dobrą praktyką jest przygotowanie jednej testowej wiadomości, na przykład /Test/Ping, i sprawdzenie jej w całym łańcuchu. Dopiero po tym można dodawać adresy związane z projekcją, dźwiękiem czy czujnikami.

Wyzwania sieciowe: stabilność UDP i zarządzanie opóźnieniami

Najczęściej OSC korzysta z UDP. Ten transport nie gwarantuje dostarczenia każdego pakietu, nie zapewnia kolejności wiadomości i nie retransmituje danych, które zaginęły po drodze. To brzmi jak poważna wada, ale w instalacjach interaktywnych bywa świadomym kompromisem.

Jeśli użytkownik przesuwa suwak, odbiorca nie musi otrzymać każdej pośredniej wartości. Najważniejsza jest najnowsza wartość. Gdy zaginie jeden pakiet opisujący pozycję obiektu, kolejny może szybko zastąpić poprzedni. Retransmisja starego pakietu mogłaby w takim przypadku przynieść więcej szkody niż pożytku, bo system na chwilę wróciłby do nieaktualnego stanu.

TCP działa inaczej. Zapewnia uporządkowany strumień i mechanizmy ponownego przesyłania, ale wprowadza dodatkową logikę połączenia oraz może powodować opóźnienia związane z oczekiwaniem na dane. Dlatego wybór między UDP a TCP nie sprowadza się do pytania, który protokół jest ogólnie lepszy. Trzeba ustalić, czy ważniejsza jest świeżość danych, czy pewność ich dostarczenia.

Parametry ciągłe i zdarzenia krytyczne

W przypadku parametrów ciągłych — pozycji, jasności, prędkości, skali czy częstotliwości — utrata pojedynczej wiadomości zwykle nie niszczy działania instalacji. Odbiorca zachowuje ostatnią znaną wartość albo czeka na następną.

Inaczej jest z komendami opisującymi zdarzenia:

• rozpoczęcie sekwencji;
• zmiana sceny;
• wyzwolenie nagrania;
• zapis stanu;
• uruchomienie urządzenia;
• przejście do kolejnego etapu performansu.

Jeśli taka wiadomość zaginie, sam fakt pojawienia się kolejnych pakietów nie musi naprawić sytuacji. W takim przypadku trzeba zaprojektować dodatkową logikę: potwierdzenie odbioru, ponowienie komendy, numer sekwencji albo cykliczne ogłaszanie aktualnego stanu. Można też użyć transportu zapewniającego dostarczenie, jeśli dane środowisko rzeczywiście go obsługuje.

Wi-Fi w warunkach wystawienniczych

Komunikacja OSC przez Wi-Fi może działać bardzo dobrze w małej, kontrolowanej sieci, ale studio nie jest galerią. W miejscu wystawy pojawiają się dodatkowe punkty dostępowe, telefony zwiedzających, ściany, urządzenia bezprzewodowe i zmieniające się obciążenie. Opóźnienie może być zmienne, a chwilowa utrata pakietów nie musi wystąpić podczas testu przy pustej sali.

Nie ma jednej wartości opóźnienia, którą można obiecać dla każdej instalacji. Zależy ono między innymi od topologii sieci, jakości routera, odległości od punktu dostępowego, zakłóceń oraz obciążenia urządzeń. Dlatego test powinien odbywać się w warunkach możliwie zbliżonych do docelowych.

Praktyczny test może obejmować:

1. uruchomienie wszystkich urządzeń, które będą pracować podczas wystawy;

2. przeprowadzenie ciągłego ruchu kontrolera przez dłuższy czas;

3. sprawdzenie reakcji przy kilku jednoczesnych źródłach danych;

4. odłączenie i ponowne podłączenie kontrolera;

5. obserwację zachowania po chwilowej utracie sieci;

6. sprawdzenie, czy połączenie wraca do właściwego stanu bez ręcznego restartu całej instalacji.

Strategie ograniczania skutków strat pakietów

W projektach opartych na przesyłaniu danych OSC przez sieć sprawdzają się różne strategie.

1. Ignorowanie pojedynczych strat przy parametrach ciągłych.

Dla pozycji, jasności czy prędkości najnowszy poprawnie odebrany stan często wystarcza. Nie ma sensu komplikować systemu tylko po to, żeby odzyskać każdą pośrednią wartość.

2. Cykliczne wysyłanie aktualnego stanu.

Kontroler może regularnie wysyłać bieżącą wartość, nawet gdy użytkownik jej nie zmienia. Dzięki temu odbiorca po chwilowej utracie pakietów szybciej wraca do właściwego stanu.

3. Rozdzielenie danych sterujących i zdarzeń.

Parametry płynne mogą korzystać z szybkiego transportu bez potwierdzeń, a zdarzenia krytyczne powinny mieć własny mechanizm potwierdzania albo ponawiania.

4. Zachowanie bezpiecznej wartości domyślnej.

Gdy instalacja przestaje otrzymywać dane, powinna przejść w przewidywalny stan. Dotyczy to szczególnie napędów, intensywnego światła, głośności i urządzeń, które mogą kontynuować działanie bez udziału użytkownika.

5. Monitorowanie czasu od ostatniej wiadomości.

Odbiorca może sprawdzać, kiedy po raz ostatni otrzymał dane z konkretnego urządzenia. Jeśli przerwa trwa zbyt długo, system może wygasić reakcję, pokazać stan awaryjny albo przełączyć instalację w tryb autonomiczny.

Zaawansowane techniki przesyłu: bundles i typy danych

Gdy podstawowa komunikacja działa, warto przyjrzeć się możliwościom OSC, które pomagają porządkować bardziej złożone sytuacje. Nie wszystkie są konieczne w małym projekcie, ale w instalacji z kilkoma warstwami obrazu i dźwięku mogą ograniczyć liczbę trudnych do odtworzenia błędów.

Bundles i znaczniki czasu

Bundle OSC pozwala umieścić kilka wiadomości w jednej strukturze oraz przypisać jej znacznik czasu. To ważne, gdy wartości powinny zostać wykonane w odniesieniu do wspólnego momentu, a nie po prostu przetworzone w kolejności nadejścia.

Przykładowo, zmiana pozycji, koloru i skali obiektu może zostać przygotowana jako zestaw wiadomości należących do tego samego stanu sceny. Odbiornik, który obsługuje znaczniki czasu, może zaplanować ich wykonanie tak, aby ograniczyć różnice wynikające z kolejności przetwarzania.

Nie należy jednak traktować bundle jako gwarancji absolutnej atomowości ani jako sposobu na naprawienie zawodnej sieci. Bundle nadal jest pakietem transportowanym przez sieć. Jeśli zostanie utracony, odbiorca nie otrzyma zawartych w nim wiadomości. Jeśli jest zbyt duży, może również zwiększyć ryzyko problemów związanych z fragmentacją pakietów. Bundle porządkuje czas i strukturę komunikatów, ale nie zastępuje projektu odpornego na awarie.

Typy danych

OSC może przenosić między innymi liczby zmiennoprzecinkowe, liczby całkowite, tekst, wartości logiczne, znaczniki czasu oraz bloki danych binarnych. Wybór typu powinien wynikać z charakteru parametru.

• Liczba zmiennoprzecinkowa sprawdza się przy płynnym sterowaniu jasnością, pozycją czy częstotliwością.
• Liczba całkowita jest naturalna dla numeru sceny, indeksu warstwy albo liczby powtórzeń.
• Tekst może zawierać nazwę sceny, identyfikator obiektu albo komendę.
• Wartość logiczna nadaje się do prostych przełączników.
• Dane binarne mogą przenosić większe fragmenty informacji, ale trzeba ostrożnie ocenić ich rozmiar i częstotliwość wysyłania.

W praktyce liczby zmiennoprzecinkowe pokrywają dużą część typowych potrzeb instalacji, ale nie wszystkie. Komenda zmiany sceny nie musi być przesyłana jako wartość 0, 1, 2 lub 3, jeśli czytelniejszy będzie tekstowy identyfikator. Z drugiej strony przesyłanie tekstu dla każdego parametru animacji niepotrzebnie zwiększa złożoność i obciążenie systemu.

Wiele urządzeń i adresowanie źródeł

W instalacji z kilkoma kontrolerami każde urządzenie może wysyłać dane do tego samego komputera, lecz korzystać z własnej gałęzi adresów:

• /Tablet1/Gesture/X
• /Tablet2/Gesture/X
• /Kinect/Skeleton/Joint/Hand/PositionX
• /Arduino/Sensor/Light

Takie adresowanie pozwala odróżnić źródła bez tworzenia osobnego portu dla każdego urządzenia. Nie zawsze jednak jeden wspólny port jest najlepszym rozwiązaniem. Jeśli różne systemy mają odmienne wymagania dotyczące bezpieczeństwa, częstotliwości wiadomości albo sposobu restartu, rozdzielenie ich na osobne porty może ułatwić utrzymanie całości.

Trzeba również ustalić, co dzieje się w przypadku dwóch urządzeń wysyłających tę samą ścieżkę. Jeśli oba kontrolery używają /Visuals/Speed, odbiorca może nie wiedzieć, która wartość powinna obowiązywać. Jednoznaczne prefiksy źródła rozwiązują ten problem wcześniej, zanim stanie się on trudny do wykrycia.

Stabilność instalacji OSC wynika nie z samego protokołu, lecz z połączenia sensownego adresowania, właściwego transportu i planu na utratę danych.

Synchronizacja urządzeń w czasie rzeczywistym

Samo przesłanie wartości nie zawsze oznacza synchronizację. Jeśli projekcja, dźwięk i mechanizm fizyczny mają rozpocząć działanie w tym samym momencie, trzeba uwzględnić opóźnienia po obu stronach. Wiadomość może dotrzeć szybko, ale aplikacja może przetworzyć ją dopiero przy kolejnym cyklu renderowania albo po zakończeniu aktualnie wykonywanej operacji.

W prostym sterowaniu gestem opóźnienie jest zwykle mniej problematyczne niż w sytuacji, w której kilka urządzeń powinno wykonać precyzyjnie powiązane zdarzenie. W tym drugim przypadku warto przesyłać nie tylko polecenie, ale również informację o tym, kiedy ma zostać wykonane. Do tego właśnie przydają się znaczniki czasu w bundle’ach, o ile odbiornik i nadajnik interpretują je w zgodny sposób.

Pomaga również rozdzielenie dwóch poziomów:

• stan systemu — na przykład aktywna scena, pozycja obiektu i poziom jasności;
• zdarzenie — na przykład rozpoczęcie sceny albo wyzwolenie pojedynczego ruchu.

Stan można okresowo ogłaszać ponownie. Zdarzenie wymaga natomiast mechanizmu, który nie doprowadzi do jego przypadkowego wielokrotnego wykonania. Numerowanie zdarzeń, potwierdzenia i przechowywanie ostatniego przetworzonego identyfikatora są często bardziej użyteczne niż samo zwiększanie częstotliwości wysyłania.

OSC jako fundament, nie cel sam w sobie

Protokół OSC w instalacjach artystycznych daje dużą swobodę: pozwala łączyć różne środowiska, przesyłać dane o różnych typach i organizować komunikację za pomocą czytelnych adresów. Właśnie dlatego dobrze pasuje do projektów, w których spotykają się czujniki, obraz, dźwięk, sterowanie ruchem i interfejsy tworzone na potrzeby konkretnej wystawy.

Ta swoboda nie oznacza jednak, że OSC rozwiązuje problemy automatycznie. Trzeba świadomie ustalić strukturę adresów, zakresy wartości, kierunki komunikacji i role poszczególnych portów. Trzeba też rozdzielić parametry, dla których ważniejsza jest świeżość danych, od komend, których utrata może przerwać logikę instalacji.

Najlepsza konfiguracja OSC to taka, której publiczność nie zauważa. Zwiedzający nie powinien zastanawiać się, czy tablet wysłał wiadomość przez UDP, czy router nie zgubił pakietu i czy TouchDesigner rozpoznał właściwy typ danych. Powinien widzieć reakcję instalacji na własny gest. Żeby ten efekt był naturalny, warstwa techniczna musi być zaprojektowana z większą uwagą, niż sugerowałaby prostota pojedynczego suwaka i jednego adresu IP.