Sync a New Level of Show
- -
- 100%
- +
Итак, для того чтобы клиент локальной сети имел доступ к глобальной сети интернет, в настройках сетевой карты должны быть указаны корректные адреса Router и DNS Server. В случае, когда активирована служба DHCP, эти адреса устанавливаются автоматически.
А теперь давайте познакомимся с волшебной службой DHCP (Dynamic Host Configuration Protocol). Это специальная служба, которая может автоматически всем компьютерам сети задать IP адреса и другие настройки сетевой карты так, чтобы все компьютеры были участниками одной подсети. Чтобы волшебство DHCP произошло, нужно соблюсти два условия.
Первое условие: на одном из участников сети должен быть создан и запущен DHCP сервер. Этот сервер можно поднять на Windows и на MAC OS, но очень часто такая служба присутствует на роутере. В этой службе указываются такие параметры как маска подсети и диапазон адресов, которые будут выдаваться новым клиентам сети.
Второе условие: необходимо, чтобы на сетевой карте вашего компьютера была активирована опция автоматического получения настроек сетевой карты от DHCP сервера. Как мы видим в MAC OS системе, эта функция называется Using DHCP. А в Windows – Obtain an IP address automatically и Obtain DNS server address automatically.
Включение функции получения настроек сетевой карты от DHCP сервера на MAC OS
Включение функции получение настроек сетевой карты от DHCP сервера на Windows
Дополнительная информация сетевой карты, где можно увидеть полученные настройки и IP DHCP сервера
Но зачастую, когда мы работаем с синхронизацией, где нам приходится указывать конкретные IP адреса клиентов, которые должны получать наши данные, как, например, в протоколе OSC, автоматическая конфигурация сети – не самый лучший выбор, так как наши устройства не привязываются жестко к IP адресам. У DHCP есть такой параметр, как время аренды IP адреса клиента, по истечению которого DHCP сервер выдает клиенту новый IP адрес, и он может отличаться от старого. Если такое происходит, то наша синхронизация по сети рушится, так как у клиента, которому мы хотим отправить сообщения, теперь новый IP адрес. При статических IP адресах на сетевых картах адрес перманентен, и только пользователь может его изменить. Такая жесткая привязка настроек сетевой карты намного надежнее, что необходимо при настройке синхронизации по сети.
Упомяну также о беспроводной сети Wi-Fi. Часто приходится использовать в синхронизации смартфоны и планшеты, к примеру, для управления сервером синхронизации, которые также должны быть участниками общей сети. В этом случае нам достаточно ввести в нашу сеть беспроводную точку доступа (Wi-Fi Access Point) или Wi-Fi роутер, в котором уже встроена точка доступа. Все настройки Wi-Fi сетевых карт абсолютно идентичны, единственное, что перед тем, как подключиться к беспроводной сети, нам необходимо авторизоваться в ней, введя логин и пароль Wi-Fi, которые заданы в беспроводной точке доступа.
Проверка сетевого подключения
Если все сетевое оборудование настроено правильно и все клиенты подключены к сети, то теперь все участники могут обмениваться данными между собой. Чтобы проверить, действительно ли устройства видят друг друга, можно сделать тест, отправив тестовые пакеты на конкретный IP адрес.
WINDOWS
Для этого в Windows системе необходимо открыть приложение командной строки. Чтобы это сделать, нажмите сочетание клавиш Win+R, в окне «выполнить» введите cmd, далее нажимаем кнопку OK. Перед вами откроется окно командной строки. Чтобы проверить подключение между вашим компьютером и другим клиентом, введите команду ping 192.168.1.202 и нажмите Enter. Соответственно, вам нужно вести тот IP адрес, связь с которым вы хотите проверить. Если все успешно, то в отчете пинга адреса вы увидите Received=4; Lost=0; В противном случае командная строка выдаст вам отчет, где либо частично, либо все пакеты были потеряны. Это означает, что клиент с этим IP адресом недоступен или имеет какие-то неисправности с сетью.
MAC
Чтобы сделать такую же проверку в операционной системе MAC OS, необходимо открыть приложение терминала. Для этого зайдите в папку с вашими установленными приложениями и откройте приложение Terminal. Для проверки соединения с клиентом введите команду ping -c4 192.168.1.201. По итогу вы также получите отчет о пинге адреса. Если все в порядке, то вы не потеряете ни одного пакета, и терминал выдаст сообщение 0.0% packet loss. Это означает, что соединение работает корректно.
Итак, после того как мы подключили все оборудование, проверили подключения между участниками сети и убедились в том, что все работает корректно, можно приступить к настройке OSC.
Как работает OSC
Основываясь на той информации, которую мы разобрали выше, теперь можно более подробно поговорить об OSC и его структуре. Для передачи данных OSC использует транспортный протокол UDP и TCP. Поэтому для передачи и приема сообщений мы должны указывать порт данных и IP адрес клиента и сервера.
OSC очень похоже на MSC сообщения. Отличие в том, что сами сообщения и адрес клиента не регламентируются протоколом, как в MSC. В OSC регламентируется лишь правило описания адреса и сообщения. Любой производитель и программист могут придумать свои наборы сообщений и передать их через OSC.
Итак, мы хотим с одного компьютера через OSC отправить сообщение на другой компьютер. Для этого нужно указать в сообщении IP адрес получателя и его порт. Указание этих параметров зависит от каждого софта отдельно. Позже мы с вами разберем особенности настройки OSC на разных шоу системах.
Хорошо, OSC сообщение мы доставили в нужный порт, и программа клиента прочитала это сообщение. Но как же программе понять, к чему применить это сообщение? Для этого OSC сообщение содержит адрес назначения внутри программы клиента. Это очень похоже на параметр назначения MSC сообщения, к примеру, как Cuelist или Cue. Только, как я уже сказал выше, OSC не имеет жесткой привязки к синтаксису адреса как в MSC, но тем не менее мы должны соблюдать правила описания адреса, которое использует OSC, а именно URL (Uniform Resource Locator). Эту схему описания адреса пути вы используете каждый раз, когда пользуетесь интернет браузером, чтобы попасть на конкретное место в интернет сайте.
Эти пути назначения сообщения могут быть разнообразны в зависимости от того, какой функционал заложил конкретный производитель. К примеру, если вы хотите отправить OSC сообщение на световую консоль ETC Eos, то путь вашего сообщения должен начинаться с /eos, далее нужно указать группу контролируемых параметров пульта, к примеру, /fader, дальше нужно указать номер фейдера /1, и по итогу мы получим полный путь к конкретному фейдеру, который будет выглядеть как: /eos/ fader/1/. Также мы можем указать путь к группам, к спискам сцен и другому содержимому пульта.
Идем дальше. Теперь по аналогии с MSC вы можете предположить, что дальше в сообщении OSC передается команда! Верно, но тут есть своя особенность: в OSC сообщении передается не команда, а аргумент. В чем же отличие команды от аргумента? Дело в том, что аргумент в OSC сообщении – это некий контейнер, который передает данные определенного типа. В последней версии OSC 1.1 вы можете использовать следующие типы данных:
Int32
Integer 32 bit, этот тип данных может хранить в себе натуральное число в диапазоне от -2 147 483 648 до 2 147 483 647. Этот тип используют, когда нужно передать целочисленный номер, как, например, для идентификации номера страницы или фейдера, так как в пульте не существует фейдеров и страниц с номером, к примеру, два с половиной или три целых четырнадцать сотых.
Float32
Float 32 bit, этот тип данных может хранить в себе действительное число c плавающей запятой в диапазоне от -3.4*1038 до +3.4*1038. Этот способ выражения действительного числа отличается от простого целочисленного типа. Но зато он позволяет закодировать более точные данные. Часто этим типом данных кодируют уровни фейдеров, вы можете определить диапазон фейдера от нуля до единицы, а вот точность позиционирования фейдера в этом диапазоне может быть огромной, но зачастую производители ограничиваются двумя знаками после запятой.
String
Этот тип данных передает строку, закодированную в формате ASCII. С помощью этого типа мы можем передать имя объекта или целое сообщение. Очень часто этот тип используется на системах дистанционного управления по OSC. К примеру, пульт может передать по OSC информацию об имени Cuelist, который назначен на конкретный фейдер.
Blob
Binary Large Object. Это тип данных, который передает оригинальный массив байтов. Очень часто его используют для передачи изображений, звука и видео.
Bool
Boolean – это логический тип данных, который может передать либо ложь, либо истину. Самое распространенное его использование – описание состояния переключателя, который может быть либо включенным (истина), либо выключенным (ложь). На самом деле, в типологии OSC этот тип данных разделен на две части, каждая из которых несет в себе конкретное состояние. Я объединил их воедино, дабы облегчить понимание этих типов.
Impulse
Это не совсем тип данных как таковой, так как он не несет в себе информации о состоянии аргумента, он инициализирует событие. В описании OSC протокола этот тип описывается как Bang. Частое его применение, когда вам нужно передать событие о действии, скажем, открытие страницы или любое другое событие без необходимости передачи конкретной информации в аргументе.
Null
Это пустой тип данных, который не содержит в себе ничего. Используется довольно редко, но как дополнительная опция присутствует.
Итак, давайте еще раз вспомним, из чего состоит OSC сообщение. Первая часть – это IP адрес клиента и номер его порта, на который нужно доставить OSC сообщение. Вторая его часть – это адрес. И третья часть – аргумент. Схематически это будет выглядеть следующим образом.
Как видно на схеме, чтобы передать состояние кнопки Flash фейдера номер один на световую консоль Eos, мы должны указать сетевой адрес и порт пульта 192.168.1.101:5004. Далее нужно указать адрес необходимой кнопки, состояние которой мы хотим передать, /eos/fader/1/flash и по итогу передать аргумент типа Boolean, если кнопка должна быть нажата, то аргумент равен True, если кнопка отпущена, то аргумент равен False.
Итак, резюмируем особенности OSC протокола.
• OSC протокол базируется на интерфейсе передачи данных Ethernet. А это дает сразу несколько преимуществ. Для передачи такого сигнала мы можем использовать стандартное сетевое оборудование, которое намного распространеннее и доступнее, чем специализированные карты синхронизаций. По Ethernet мы можем передать сигнал практически на неограниченное расстояние, используя при этом разные способы передачи сигнала, как по радиоканалу, по оптике, так и по витой паре.
• OSC использует протокол передачи данных UDP и TCP. Эти протоколы обязывают нас указывать IP адрес и порт клиента, что дает нам множество преимуществ. К примеру, мы можем на одном сетевом клиенте синхронизировать несколько приложений одновременно, используя один и тот же IP адрес, но при этом разные порты. Это также позволяет нам настраивать сложные маршруты, делить OSC сигнал или получать на одного клиента сообщения с разных источников без использование дополнительного оборудования, так как этот функционал уже заложен в сетевых протоколах группы TCP/IP.
• OSC не регламентирует адрес к управляемым параметрам, каждый производитель может создать свою индивидуальную схему, которая будет максимально удобна для управления конкретным функционалом. OSC регламентирует лишь правила описания этого пути, который базируется на URL системе.
• OSC позволяет передавать по заданному адресу аргумент, который может содержать разные параметры и типы данных. OSC также позволяет передать исходные байты данных для передачи в OSC сообщение изображения, звука и видео.
Я считаю, что OSC – самый функциональный и современный протокол синхронизации, с помощью него можно построить сложнейшие системы генеративной синхронизации с большой скоростью передачи данных. При этом, как я уже говорил, благодаря тому, что этот протокол базируется на физическом интерфейсе Ethernet, OSC наследует все преимущества передачи данных по этому интерфейсу. Что делает его намного привлекательнее перед остальными командными типами протоколов синхронизации.
ALTERNATIVE SYNC PROTOCOLS
В этой главе мы с вами познакомимся с различными протоколами, которые появились на фоне активного развития интерфейсов передачи данных. Некоторые из них базируются на уже хорошо нам известном протоколе MIDI, а некоторые были созданы с нуля для решения определенных задач синхронизации.
RTP-MIDI (Apple MIDI)
Благодаря тому, что интерфейс передачи MIDI полностью цифровой, то без особых изменений пакеты данных MIDI можно передавать через более современные и быстрые интерфейсы. Ассоциация MMA понимала, что MIDI стал довольно популярным стандартом для работы в разных индустриях, но при этом развитие этого стандарта упиралось в технические особенности физического серийного интерфейса, на котором базировался MIDI. И тогда MMA ассоциация начала смотреть в сторону других успешных технологий передачи данных, чтобы уйти от технических недостатков, которые накладывал старый интерфейс передачи данных. И по итогу на свет начали появляться новые технологии передачи MIDI.
RTP (Real-time Transport Protocol) – это протокол высокого уровня, который базируется на UDP, но при этом имеет свои преимущества, которые были специально разработаны для стриминга аудио и видео. Основная его особенность в том, что каждый пакет данных этого протокола имеет в заголовке абсолютное время отправки, которое может прочитать принимающее устройство и определить задержку и порядок доставки сообщений. Такие преимущества идеально подошли для MIDI, и в 2004 году на свет появилась первая версия протокола RTP-MIDI. Позже компания Apple включила этот протокол в состав своих операционных систем и активно дорабатывала его. И как следствие этого, протокол получил второе название Apple MIDI. Позже был написан отдельный драйвер для Windows и Linux, который также позволял использовать протокол в этих системах.
Так же, как и в случае с OSC, этот протокол базируется на физическом интерфейсе Ethernet, и как следствие, RTP-MIDI также наследует все преимущества этого интерфейса передачи данных. Соответственно, чтобы использовать протокол RTP-MIDI, так же как и с OSC, изначально необходимо поднять сеть, в которой будут находиться все наши сетевые клиенты. Как это сделать, мы уже узнали в главе «Концепт построения сетей».
Давайте теперь поговорим об идеологии этого протокола. В RTP- MIDI есть такое понятие, как «Сессия». «Сессия» – это виртуальная среда, к которой могут подключаться клиенты, для того чтобы обмениваться MIDI сообщениями. Для начала в сети должен быть тот, кто создаст эту сессию. Это может быть либо компьютер, либо другое устройство. Создатель сессии будет являться мастер устройством или, говоря терминологией RTP-MIDI, «Инициализатором сессии». После того как в сети будет создана сессия, другие клиенты могут к ней подключиться и стать участниками этой сессии. В сети может быть создано несколько сессий, и они могут работать независимо. Но при этом удобство заключается в том, что клиент сам может выбрать, к какой сессии ему необходимо подключиться. После того как клиент стал участником сессии, в операционной системе появляются виртуальные MIDI порты, которые могут использовать приложения для приема и передачи MIDI сигнала.
Одно из немаловажных преимуществ RTP-MIDI заключается в том, что на уровне этого протокола реализованы схемы разделения и смешивания MIDI сигналов (Split/Merge). Ниже представлена простейшая схема транспорта сообщений между разными участниками сессии, где видно, что устройство номер один является инициализатором сессии, к которому подключены другие участники сети. При отправлении MIDI сообщения с главного устройства (Device 1) это сообщение автоматически дублируется на все остальные клиенты. Но при этом, если сообщения отправят другие клиенты сессии (Device 2 и Device 3), то они будут получены только инициализатором сессии, т.е. устройством номер один. Эти сообщения автоматически будут соединены и направлены на его виртуальный MIDI IN порт.
Так как RTP-MIDI – это по сути лишь способ передачи MIDI через Ethernet, то все, что касается протокола MIDI, остается по-прежнему тем же самым, единственное, что отличается, это способ доставки MIDI сообщений. По этой причине предлагаю разобрать пример того, как создать RTP-MIDI сессию и как подключить к ней клиентов для обмена сообщениями. Чтобы в будущем вы сами для себя решали, использовать ли физические MIDI карты и коммутацию для работы и экспериментов или использовать сетевую альтернативу RTP-MIDI.
Ниже представлен список операционных систем и название программ, которые добавляют в систему возможность работы с протоколом RTP-MIDI.
Некоторые программисты, которые читают эту книгу, возможно, спросят, а где же Linux? Существуют библиотеки, которые позволяют интегрировать поддержку этого протокола во внутрь отдельной программы в момент разработки приложения программистами, эти библиотеки есть для всех операционных систем, в том числе и Linux. Приложения под Windows и Android были написаны программистами-энтузиастами, которые выложили свои программы в открытый доступ, за что им огромное спасибо.
Если вы пользователь устройств Apple, то вам ничего не нужно устанавливать, так как, как я уже говорил, RTP-MIDI уже интегрирован в системы MAC OS и iOS. А вот для других операционных систем нужно скачивать специальные драйверы и программное обеспечение.
Предлагаю создать сессию в системе MAC OS. Приложение для Windows выглядит абсолютно идентично с таким же интерфейсом и функционалом. Итак, чтобы открыть меню для работы с RTP-MIDI в MAC OS, зайдите в папку Applications и откройте приложение Audio MIDI Setup. Если перед вами откроется окно настроек аудио без окна MIDI, в панели меню откройте Window и в выпадающем меню нажмите на опцию Show MIDI Studio, и перед вами откроется окно, содержащее устройства MIDI.
Для работы с RTP-MIDI нам нужно нажать на иконку глобуса в верхнем правом углу. Давайте разберемся, что здесь к чему
Итак, чтобы создать новое подключение, необходимо:
1. Ниже раздела Sessions, с правой стороны окна настройки RTP-MIDI, необходимо указать номер порта, который будет использоваться для передачи и приема этого протокола. Как мы помним, RTP-MIDI использует низкоуровневый протокол UDP, а как следствие, для приема и передачи данных мы должны указать конкретный порт. По умолчанию RTP- MIDI использует порт 5004, но если этот порт уже занят каким-нибудь приложением, мы можем указать любой другой свободный порт.
2. Далее необходимо указать Local name, это имя виртуальной MIDI карты, которая будет использоваться в нашей системе. И также необходимо указать Bonjour name, это имя сессии, которую будут видеть клиенты в сети.
3. Теперь нужно активировать сессию, для этого необходимо поставить галочку напротив Enabled верхней части окна Session.
4. И также необходимо настроить правила безопасности, которые позволяют настроить права подключения к сессии. В нижней части окна настроек RTP-MIDI слева раскройте выпадающий список Who can connect to me: и выберите одну из опций. Так как клиенты сами могут подключаться в сессию, иногда нужно ограничить правила подключения.
5. Если необходимо добавить нового клиента, вручную нажмите кнопку ниже окна Directory и введите имя, адрес и порт клиента, который должен стать участником вашей сессии. В завершении, чтобы добавить клиентов в вашу сессию, выберите устройство в окне Directory и нажмите кнопку Connect. Если клиент успешно добавлен в сессию, он появится в окне Participants:
Список MIDI портов, сигнал с которых приложение RTP-MIDI может перенаправить в сессию
Хотел бы также упомянуть об очень удобной опции, которая позволяет перенаправить потоки MIDI c сессии на физическое устройство и наоборот. Для этого в правой нижней части программы, напротив Live routings, раскройте необходимый список оборудования на вход или выход и выберите MIDI порт, на который необходимо направить поток с сессии или, наоборот, отправить поток в сессию. В этом случае наш компьютер
выступает как конвертер, который преобразует между собой физический MIDI и сетевой RTP-MIDI.
Подводя итог всех особенностей протокола RTP-MIDI, можно сказать:
• Первая особенность, этот протокол абсолютно совместим со всеми MIDI протоколами, которые были разработаны для передачи через классический серийный интерфейс данных MIDI.
• Вторая, для работы с RTP-MIDI нет необходимости использовать MIDI карты для передачи сообщений MIDI, так как протокол был разработан для работы через локальную сеть, вам достаточно иметь любое устройство, которое имеет сетевую карту, для подключения к сети.
• Третья особенность вытекает из второй благодаря тому, что этот интерфейс работает через локальную сеть, он наследует все преимущества сетевых технологий передачи данных Ethernet, Wi-Fi и оптоволокна, одни из которых – дальность передачи и скорость сигнала, что является одним из недостатков классического интерфейса MIDI.
• И четвертая, в RTP-MIDI сессии уже реализована идеология соединения и разделения MIDI сигнала между клиентами, что также позволяет оказаться от использования специализированных MIDI сплиттеров и мерджеров.
BLE-MIDI
Bluetooth уже довольно взрослая беспроводная технология, которая активно используется в мобильных устройствах. А так как в мобильных устройствах всегда уделяли внимание экономии ресурсов батареи, то на свет появилась новая, более усовершенствованная версия Bluetooth, которая намного умнее использует ресурсы мобильного устройства. И по итогу новая версия стала называться Bluetooth Low Energy или, сокращенно, BLE, также у него есть и второе название – Bluetooth SMART. Так как новый стандарт стал более привлекателен, производители стали активно внедрять новую технологию в свои устройства. MMA (MIDI Manufacturers Association) не стало исключением, в 2014 разработав новый протокол BLE-MIDI, передаваемый через Bluetooth Low Energy. И как следовало ожидать, компания Apple не заставила себя долго ждать и в этом же году объявила о поддержке протокола BLE-MIDI в своих вновь вышедших релизах операционных систем iOS 8 и OS X 10.10. В течение года компания Apple исправляла ошибки и дорабатывала этот протокол. И в 2015 году ассоциация MMA приняла все их изменения и утвердила финальную версию BLE-MIDI.
Теперь поговорим об особенностях BLE-MIDI. В отличие от RTP- MIDI, он не настолько функционален. К примеру, по этой технологии вы можете настроить подключение только между шестнадцатью устройствами. По причине того, что скорость Bluetooth не настолько велика. В сравнении с RTP-MIDI мы можем создать практически неограниченное количество сессий в одной системе, количество зависит от скорости нашей сети и мощности системы, на которой поднимаются сессии. И также Bluetooth имеет ограниченный радиус действия, до 10 метров прямой видимости. Но есть и плюсы, так же как и с RTP-MIDI, BLE-MIDI отправляет пакеты данных с абсолютными маркерами времени, что также обеспечивает синхронность приема пакетов данных. Также отличие BLE-MIDI подключения от других Bluetooth соединений в том, что BLE-MIDI использует отличную от стандартного Bluetooth систему передачи данных по радиоканалу, которая обеспечивает минимальные задержки на кодирование данных, передачу их по радиоканалу и декодинг для обеспечения максимальной скорости передачи данных между устройствами.