Protokół OSC, MIDI czy MQTT: co wybrać do instalacji?

Decyduje też o tym, jak szybko system zareaguje na ruch widza, czy parametry dźwięku będą dostatecznie precyzyjne, jak łatwo połączyć kilka komputerów oraz co stanie się z całością po zerwaniu połączenia sieciowego.

Dlatego pytanie „protokół OSC czy MIDI w sztuce interaktywnej?” nie ma jednej uniwersalnej odpowiedzi. MIDI nadal świetnie sprawdza się przy sterowaniu instrumentami i oprogramowaniem muzycznym. OSC daje większą swobodę w przesyłaniu złożonych danych między aplikacjami. MQTT z kolei jest naturalnym wyborem dla rozproszonych czujników, urządzeń IoT i systemów, które muszą działać przez wspólną infrastrukturę sieciową.

Różnica nie sprowadza się więc do tego, który standard jest nowszy. Chodzi o dopasowanie sposobu komunikacji do rytmu instalacji, topologii systemu i rodzaju danych.

MIDI: prostota, która nadal ma sens

MIDI pojawiło się w 1983 roku i przez dekady stało się podstawowym językiem komunikacji między klawiaturami, syntezatorami, automatami perkusyjnymi, kontrolerami i programami typu DAW. W instalacjach artystycznych jego największą zaletą nie jest nowoczesność, lecz przewidywalność.

Typowy komunikat MIDI jest niewielki i ma jasno określoną funkcję. Może informować o naciśnięciu klawisza, zmianie programu, poziomie kontrolera lub pozycji koła modulacji. Taki model dobrze pasuje do sytuacji, w której instalacja ma reagować na konkretne gesty i sterować parametrami muzycznymi.

Tradycyjne MIDI wykorzystuje 7-bitowe wartości całkowite w zakresie od 0 do 127. W przypadku prostego włączania dźwięku, wyboru presetu czy sterowania podstawowym parametrem taka rozdzielczość często jest wystarczająca. Ograniczenie staje się bardziej widoczne przy płynnym sterowaniu światłem, ruchem obiektu, przestrzenią dźwięku albo filtrem, gdy niewielkie skoki wartości mogą być słyszalne lub widoczne.

MIDI ma kilka praktycznych przewag:

• nie wymaga projektowania własnej struktury adresów ani tematów komunikatów;
• jest obsługiwane przez dużą liczbę instrumentów, kontrolerów i programów;
• dobrze nadaje się do lokalnego sterowania o jasno zdefiniowanym przebiegu;
• może działać bez rozbudowanej sieci komputerowej;
• łatwo je zrozumieć osobom pracującym na co dzień z muzyką elektroniczną.

Jego ograniczenia wynikają z tej samej prostoty. MIDI nie zostało zaprojektowane jako uniwersalny język dla współczesnej instalacji, w której dane płyną z kamer, czujników głębi, systemów śledzenia ruchu, silników grafiki czasu rzeczywistego i paneli sterujących. Da się je do takich zadań wykorzystać, ale często wymaga to mapowania wielu parametrów na skromny zestaw komunikatów.

Kiedy MIDI jest rozsądnym wyborem?

MIDI warto wybrać wtedy, gdy centrum instalacji stanowi sprzęt muzyczny albo oprogramowanie, a komunikaty mają charakter sterujący. Przykładowo: ruch widza zmienia wysokość dźwięku, przyciski aktywują sceny, a kontroler fizyczny wybiera warstwy kompozycji.

W takim układzie dodatkowe możliwości OSC mogą nie przynieść realnej korzyści. Jeśli odbiornik i tak rozumie wyłącznie komunikaty MIDI, rozbudowywanie architektury o kolejny protokół zwiększy liczbę punktów, w których coś może zostać źle skonfigurowane.

Nie należy też traktować tradycyjnego MIDI jako rozwiązania przestarzałego tylko dlatego, że ma ograniczoną rozdzielczość. W instalacji o prostych zależnościach najważniejsza bywa właśnie jego ograniczona liczba reguł. Im mniej warstw pośrednich, tym łatwiej znaleźć przyczynę problemu podczas montażu lub występu.

OSC: więcej danych, większa odpowiedzialność

Open Sound Control, czyli OSC, powstał w 1997 roku w CNMAT na Uniwersytecie Kalifornijskim w Berkeley. Za jego opracowanie odpowiadali Matthew Wright i Adrian Freed, a specyfikację OSC 1.0 opublikowano w marcu 2002 roku.

OSC zaprojektowano z myślą o komunikacji między aplikacjami muzycznymi i multimedialnymi. W praktyce protokół szybko znalazł zastosowanie w instalacjach, systemach wizualnych, śledzeniu ruchu oraz sterowaniu silnikami czasu rzeczywistego. Jego najważniejszą przewagą nad tradycyjnym MIDI jest swoboda opisywania danych.

OSC może przenosić między innymi:

• 32-bitowe liczby zmiennoprzecinkowe;
• liczby całkowite;
• ciągi znaków;
• struktury binarne;
• zestawy argumentów przypisane do jednego komunikatu.

Dzięki temu można przesłać nie tylko informację, że parametr ma wartość 74, lecz także bardziej precyzyjną wartość zmiennoprzecinkową, nazwę sceny, współrzędne obiektu albo kilka powiązanych danych w jednym komunikacie.

Wiadomości OSC korzystają z hierarchicznego schematu adresowania przypominającego adresy URL. Ścieżka może mieć postać na przykład /synth/filter/frequency albo /tuio/2Dcur. Taki zapis porządkuje komunikację. Odbiornik może od razu rozpoznać, czy wiadomość dotyczy filtra, pozycji obiektu, gestu czy parametrów konkretnej warstwy wizualnej.

To szczególnie przydatne w systemach, w których jeden komputer analizuje obraz, drugi generuje dźwięk, trzeci renderuje grafikę, a jeszcze inne urządzenie zarządza światłem. OSC pozwala opisać dane w sposób bliższy strukturze samego projektu niż tradycyjny zestaw numerowanych kontrolerów.

OSC daje instalacji język dopasowany do jej logiki, ale nie zwalnia twórcy z zaprojektowania tej logiki.

OSC a opóźnienia

W instalacjach artystycznych OSC jest zwykle przesyłane przez UDP/IP, najczęściej w lokalnej sieci. Taki model dobrze pasuje do częstych aktualizacji danych, gdy liczy się płynność reakcji, a pojedyncze zgubienie pakietu nie powinno zatrzymać całego systemu.

Jeśli czujnik wysyła pozycję dłoni wiele razy w ciągu sekundy, utrata jednej próbki może być mniej problematyczna niż oczekiwanie na jej ponowne dostarczenie. Kolejna aktualizacja szybko zastąpi poprzednią. Z tego powodu OSC często pojawia się w instalacjach z grafiką czasu rzeczywistego, śledzeniem ruchu i sterowaniem sceną w silnikach takich jak Unreal Engine 5.

Nie oznacza to jednak, że OSC automatycznie gwarantuje określone opóźnienie. Rzeczywista reakcja zależy od konfiguracji sieci, obciążenia komputerów, sposobu przetwarzania danych, jakości punktów dostępowych i architektury aplikacji. Sam wybór UDP nie rozwiązuje problemu źle zaprojektowanej sieci.

W przypadku instalacji działającej na żywo bezprzewodowe OSC przez Wi-Fi wymaga ostrożności. Zakłócenia, przeciążenie sieci lub zmiana warunków radiowych mogą powodować niestabilność. Przy krytycznych połączeniach przewodowy Ethernet albo MIDI bywa bezpieczniejszy. Nie jest to kwestia elegancji technicznej, tylko tego, czy instalacja ma działać niezawodnie przez wiele godzin, również wtedy, gdy w przestrzeni pojawi się dużo urządzeń i publiczności.

Adresowanie OSC: miejsce, w którym projekt wygrywa albo przegrywa

Swoboda OSC jest użyteczna tylko wtedy, gdy twórca od początku ustali porządek komunikacji. Protokół nie jest rozwiązaniem typu podłącz i zapomnij. Trzeba skonfigurować adresy IP, porty oraz ścieżki adresowe po stronie nadawcy i odbiornika.

W małej instalacji można zacząć od prostego układu:

• czujnik wysyła pozycję widza;
• aplikacja pośrednia przelicza ją na parametry artystyczne;
• program dźwiękowy odbiera wartości dotyczące wysokości i głośności;
• silnik wizualny wykorzystuje tę samą informację do sterowania ruchem obiektów.

Przy większej liczbie elementów warto rozdzielić ścieżki według funkcji, a nie według przypadkowej kolejności urządzeń. Adresy opisujące funkcję są czytelniejsze podczas debugowania. Gdy po kilku tygodniach trzeba sprawdzić, dlaczego nie działa światło, ścieżka związana z oświetleniem daje więcej informacji niż numer kontrolera, którego przeznaczenia nikt już nie pamięta.

Dobrze zaprojektowana przestrzeń adresowa powinna odpowiadać na kilka pytań:

• czy dana wartość opisuje surowy pomiar, czy już przetworzoną reakcję;
• czy komunikat pochodzi z konkretnego czujnika, czy z warstwy logiki;
• które dane są chwilowe, a które zmieniają stan instalacji;
• jak odbiornik ma rozpoznać wersję komunikatu;
• co ma się wydarzyć po braku kolejnych wiadomości.

Ten ostatni punkt jest często pomijany. Jeśli instalacja steruje ruchem mechanicznym, światłem lub dźwiękiem, odbiornik powinien mieć określoną reakcję na ciszę w sieci. Może zatrzymać efekt, utrzymać ostatnią wartość albo przejść do trybu bezpiecznego. Protokół przekazuje dane, ale nie definiuje za twórcę zachowania całego systemu.

UDP i TCP: różne założenia, nie prosty ranking

Porównując OSC i MQTT, łatwo wpaść w pułapkę zestawiania UDP z TCP jako dwóch wersji tego samego rozwiązania. To różne modele transportu, stworzone z innymi priorytetami.

OSC jest najczęściej przesyłane przez UDP/IP. Nadawca wysyła pakiet bez konieczności ustanawiania połączenia, a odbiorca może go odczytać, jeśli pakiet dotrze do właściwego miejsca. UDP nie zapewnia sam z siebie dostarczenia, kolejności ani ponowienia transmisji.

W instalacji interaktywnej może to być zaletą. Dane o pozycji lub natężeniu ruchu szybko się dezaktualizują. Jeśli odbiornik otrzyma nowszą wartość, poprzednia często nie ma już znaczenia. Brak mechanizmu ponawiania ogranicza narzut komunikacyjny.

MQTT korzysta z TCP/IP. Zapewnia to połączenie z mechanizmem kontroli transmisji, ale za cenę większej liczby elementów pośrednich. MQTT działa w architekturze publikuj–subskrybuj i wykorzystuje centralny broker. Urządzenie publikuje wiadomość w określonym temacie, a zainteresowani odbiorcy subskrybują ten temat.

Taki układ zmienia sposób myślenia o instalacji. W OSC nadawca zazwyczaj kieruje komunikat do konkretnego adresu IP i portu. W MQTT urządzenie nie musi znać wszystkich odbiorców. Wystarczy, że połączy się z brokerem i opublikuje dane we właściwym temacie.

Tabela nie pokazuje zwycięzcy. Pokazuje, że każdy z tych protokołów rozwiązuje inny problem.

MQTT w sztuce: nie do każdej reakcji, ale do dobrej infrastruktury

MQTT nie jest protokołem dedykowanym do syntezy dźwięku ani do sterowania muzycznego w czasie rzeczywistym z gwarancją reakcji poniżej milisekundy. Jego siła leży gdzie indziej: w zarządzaniu komunikacją pomiędzy rozproszonymi urządzeniami.

W instalacji artystycznej może zbierać dane z czujników temperatury, wilgotności, obecności, otwarcia obudowy albo poziomu baterii. Te informacje mogą trafiać do serwera, panelu internetowego i systemu archiwizacji bez konieczności tworzenia osobnego połączenia między każdym urządzeniem a każdym odbiornikiem.

To praktyczne w wystawach działających przez wiele dni lub tygodni. Twórca może obserwować stan urządzeń, rejestrować zachowanie publiczności albo zmieniać konfigurację z poziomu panelu. Broker staje się centralnym punktem wymiany informacji, a kolejne odbiorniki można dodawać bez przebudowy wszystkich połączeń.

MQTT dobrze pasuje do zadań takich jak:

1. Zbieranie danych z wielu czujników. Każdy czujnik może publikować informacje w osobnym temacie, na przykład związanym z lokalizacją lub rodzajem pomiaru.

2. Przekazywanie stanu urządzeń. Instalacja może raportować temperaturę komputera, dostępność kontrolera, poziom baterii albo stan połączenia.

3. Zasilanie kilku paneli i aplikacji. Jeden komunikat może zostać odebrany przez serwer, interfejs dla kuratora i system zapisujący dane.

4. Obsługa systemów hybrydowych. MQTT może przenosić dane infrastrukturalne, podczas gdy OSC steruje warstwą audiowizualną wymagającą częstych aktualizacji.

5. Zdalne zarządzanie instalacją. Wiadomości mogą zmieniać tryb pracy urządzeń, uruchamiać sceny albo przekazywać polecenia serwisowe.

Największym błędem byłoby użycie MQTT do każdej wartości generowanej przez czujnik ruchu tylko dlatego, że protokół zapewnia uporządkowaną architekturę. W przypadku reakcji wizualnej lub dźwiękowej liczy się nie tylko dostarczenie komunikatu, ale także jego aktualność. Broker, połączenie TCP/IP i dodatkowe warstwy obsługi mogą być uzasadnione dla danych stanu, lecz niekoniecznie dla strumienia szybkich zmian sterujących.

MQTT porządkuje rozproszoną instalację, ale nie powinno udawać protokołu do każdej reakcji czasu rzeczywistego.

OSC kontra MQTT w systemie hybrydowym

W większej instalacji nie trzeba wybierać jednego protokołu dla całego projektu. Rozsądniejszy może być podział według funkcji.

Przykładowa architektura może wyglądać tak: czujnik ruchu przekazuje dane do komputera analizującego obraz. Ten komputer wysyła przez OSC aktualne pozycje i gesty do silnika wizualnego oraz programu dźwiękowego. Równolegle urządzenia techniczne publikują przez MQTT informacje o stanie, temperaturze i dostępności. Serwer zbiera te dane i udostępnia je panelowi nadzorczemu.

W takim układzie każdy protokół robi to, do czego pasuje najlepiej:

• OSC odpowiada za częste i precyzyjne aktualizacje parametrów artystycznych;
• MQTT przekazuje informacje o stanie infrastruktury;
• MIDI może sterować instrumentem, kontrolerem lub lokalnym modułem muzycznym;
• warstwa aplikacyjna tłumaczy dane między protokołami, jeśli instalacja tego wymaga.

Takie rozwiązanie zwiększa złożoność, ale niekoniecznie ją komplikuje. Złożoność i chaos to dwie różne rzeczy. Kilka protokołów z jasno rozdzielonymi zadaniami może być łatwiejsze do utrzymania niż jeden protokół używany wbrew jego założeniom.

Problem pojawia się wtedy, gdy nie ma wyraźnej granicy między warstwami. Jeżeli ten sam parametr jest jednocześnie publikowany w MQTT, wysyłany przez OSC i mapowany na MIDI, trzeba ustalić, który kanał jest źródłem prawdy. Bez tego system może reagować na sprzeczne wartości albo nadpisywać ustawienia w trudnej do wykrycia kolejności.

Warstwa danych a warstwa reakcji

Przy projektowaniu warto rozdzielić surowe pomiary od decyzji artystycznych. Czujnik może wykryć pozycję dłoni, ale nie powinien koniecznie decydować, czy ta pozycja zmieni kolor światła, głośność syntezatora czy ruch obiektu na ekranie.

Lepszy podział wygląda następująco:

• urządzenie pomiarowe dostarcza dane;
• aplikacja logiki interpretuje dane i nakłada ograniczenia;
• protokół komunikacyjny przenosi wynik do właściwych odbiorników;
• program artystyczny wykonuje reakcję.

Dzięki temu zmiana czujnika nie wymusza przebudowy całej instalacji. Można zastąpić kamerę innym systemem śledzenia, pozostawiając bez zmian sposób sterowania sceną. To szczególnie ważne podczas pracy warsztatowej i na hackathonach, gdzie część sprzętu często zmienia się już po rozpoczęciu budowy prototypu.

Jak wybrać protokół do konkretnej instalacji?

Najpierw trzeba opisać nie sprzęt, lecz zachowanie systemu. Pytanie „czy urządzenie obsługuje OSC?” jest użyteczne, ale dopiero po ustaleniu, jakie informacje mają przepływać i co odbiornik ma z nimi zrobić.

Pomocne są następujące kryteria:

• Rodzaj danych. Czy są to pojedyncze wartości sterujące, współrzędne, teksty, komunikaty stanu czy większe struktury?
• Częstotliwość aktualizacji. Czy odbiornik potrzebuje każdej próbki, czy wystarczy mu ostatnia dostępna wartość?
• Znaczenie utraty wiadomości. Czy brak jednego pakietu tylko lekko zmieni efekt, czy może zatrzymać mechanizm?
• Liczba odbiorników. Czy komunikat trafia do jednego programu, czy ma być dostępny dla wielu niezależnych aplikacji?
• Topologia. Czy urządzenia działają w jednej lokalnej sieci, czy komunikacja ma przechodzić przez serwer i różne segmenty infrastruktury?
• Możliwość serwisowania. Czy osoba techniczna będzie w stanie szybko rozpoznać temat MQTT, ścieżkę OSC albo komunikat MIDI?
• Zgodność sprzętowa. Czy docelowy instrument lub kontroler ma natywne MIDI, czy wymaga dodatkowego mostu?
• Zachowanie po awarii. Czy instalacja ma zatrzymać efekt, utrzymać ostatnią wartość, czy przełączyć się w tryb awaryjny?

W praktyce można przyjąć kilka roboczych reguł.

Wybierz MIDI, gdy:

• instalacja jest bezpośrednio związana z instrumentami lub kontrolerami muzycznymi;
• liczba parametrów jest ograniczona;
• wartości 0–127 zapewniają wystarczającą kontrolę;
• najważniejsza jest zgodność z gotowym sprzętem;
• system ma działać lokalnie i nie potrzebuje rozbudowanej komunikacji sieciowej.

Wybierz OSC, gdy:

• dane płyną między aplikacjami audiowizualnymi;
• potrzebujesz wartości zmiennoprzecinkowych i większej precyzji;
• instalacja wykorzystuje śledzenie ruchu, systemy wizualne albo silnik czasu rzeczywistego;
• chcesz budować czytelną, hierarchiczną przestrzeń adresową;
• odbiornik ma reagować na częste aktualizacje w lokalnej sieci.

Wybierz MQTT, gdy:

• urządzenia są rozproszone i komunikują się przez brokera;
• trzeba zasilać dane dla serwera, panelu i kilku aplikacji;
• najważniejsze są stan urządzeń, telemetria i obsługa infrastruktury;
• instalacja ma wielu producentów danych i wielu odbiorców;
• projekt wymaga centralnego zarządzania tematami i połączeniami.

Stabilność sieci jest częścią projektu artystycznego

W dokumentacji protokołu łatwo skupić się na formacie komunikatu i zapomnieć o fizycznym środowisku, w którym instalacja będzie działać. Tymczasem sieć jest częścią dzieła tak samo jak projekt dźwięku, światła czy interakcji.

Instalacja przygotowana w pracowni może działać bez zarzutu, a po przeniesieniu do galerii zacząć gubić komunikaty. Powodem nie musi być błąd w kodzie. Wystarczy zatłoczone pasmo Wi-Fi, inna adresacja sieci, aktywna izolacja klientów bezprzewodowych albo brak dostępu do brokera MQTT.

Przy OSC używanym bezprzewodowo szczególnego znaczenia nabiera stabilność lokalnej sieci. Jeśli system reaguje na ruch widza, krótkie przerwy mogą być widoczne jako skoki animacji lub chwilowe zamrożenie parametrów. Przy sterowaniu mechanicznym konsekwencje mogą być poważniejsze, dlatego przewodowy Ethernet jest często rozsądniejszy niż wygoda Wi-Fi.

MQTT wymaga dodatkowo zaplanowania brokera. Trzeba wiedzieć, gdzie działa, co stanie się po jego restarcie i jak urządzenia zachowają się po utracie połączenia. Centralny broker upraszcza dystrybucję danych, ale staje się też elementem krytycznym. Jeśli cała instalacja czeka na jego dostępność, awaria jednego komputera może odłączyć wiele pozornie niezależnych urządzeń.

MIDI także nie jest całkowicie wolne od problemów. Długie łańcuchy urządzeń, przejściówki, niejasne mapowanie komunikatów i różnice między implementacjami potrafią utrudnić pracę. Jego przewaga polega na tym, że obszar możliwych problemów jest zwykle węższy niż w rozbudowanej sieci aplikacji.

Najczęstszy błąd: wybór protokołu przed opisaniem komunikatów

Twórcy instalacji często zaczynają od pytania, który protokół jest najlepszy. Lepsze pytanie brzmi: jakie komunikaty będą przepływać przez system?

Jeśli chodzi o kilka przycisków, wybór MIDI może zamknąć temat bez zbędnych warstw. Jeśli system ma przenosić pozycję kilkunastu obiektów, informacje o gestach i parametry do kilku aplikacji, OSC będzie zwykle naturalniejsze. Jeśli najważniejsze są dane z wielu urządzeń działających w różnych miejscach oraz centralny monitoring, MQTT pokaże swoją przewagę.

Warto rozpisać komunikację przed zakupem sprzętu. Nie w formie technicznego dokumentu dla samego dokumentu, tylko jako mapę zależności:

1. Zapisz źródła danych. Kamera, czujnik nacisku, kontroler MIDI, mikrofon, panel operatora i moduł pomiarowy mogą mieć różne wymagania.

2. Oddziel dane szybkie od danych stanu. Pozycja dłoni i temperatura urządzenia nie muszą być przesyłane tym samym kanałem.

3. Określ odbiorców. Jeden program może potrzebować surowego pomiaru, a inny tylko wartości przeskalowanej do zakresu sterowania.

4. Zaprojektuj reakcję na ciszę. Każdy odbiornik powinien wiedzieć, co zrobić, gdy wiadomości przestaną przychodzić.

5. Zdecyduj, gdzie odbywa się konwersja. Mapowanie danych z OSC na MIDI lub z MQTT na OSC powinno mieć jedno jasno określone miejsce.

6. Przetestuj konfigurację poza sceną. Adresy IP, porty, ścieżki OSC i tematy MQTT trzeba sprawdzić w warunkach przypominających docelową instalację.

Ta praca nie jest dodatkiem do części kreatywnej. W instalacji interaktywnej sposób przesyłania danych wpływa na odczuwalny rytm dzieła. Opóźnienie, utrata komunikatu albo błędne mapowanie stają się częścią doświadczenia widza, nawet jeśli nie były planowane.

Werdykt: nie jeden protokół, lecz właściwy podział ról

MIDI, OSC i MQTT nie tworzą liniowego rankingu od najgorszego do najlepszego. MIDI jest zwarte i kompatybilne ze światem instrumentów. OSC daje precyzję oraz elastyczność potrzebną w komunikacji między aplikacjami. MQTT porządkuje rozproszone urządzenia i dobrze obsługuje warstwę IoT, monitoringu oraz zarządzania.

W instalacji muzycznej z kilkoma kontrolerami MIDI może być najrozsądniejszym rozwiązaniem. W systemie reagującym na ruch i sterującym jednocześnie dźwiękiem oraz obrazem naturalnym kandydatem będzie OSC. W wystawie z dziesiątkami czujników, panelem internetowym i serwerem zbierającym dane warto rozważyć MQTT. W bardziej złożonym projekcie najlepszy efekt przyniesie połączenie tych protokołów, pod warunkiem że każdy z nich otrzyma jasno określone zadanie.

Najpierw opisz więc dane, odbiorców i konsekwencje awarii. Dopiero potem wybierz standard. To prostsza droga do stabilnej instalacji niż próba dopasowania całego projektu do protokołu, który akurat wydaje się najbardziej nowoczesny.