Sync a New Level of Show

• MSC сообщении есть информация, к какому объекту в принимающем устройстве применить команду – Q Number, Q List, Q Path.

Эти возможности во много раз расширяют функционал MSC перед простыми звуковыми MIDI сообщениями. Это позволяет быстро запрограммировать команды на главном контроллере для синхронизации шоу. При этом нет необходимости в сложных настройках на световых консолях и других принимающих устройствах. Всю необходимую информацию они получают по протоколу управления.

Теперь снова вернемся к истории. MSC v1.0 стал настолько популярным, что позже была разработана новая усовершенствованная версия MSC v1.1. Основное его отличие заключалось в том, что эта версия MSC теперь подразумевало обратную связь между сервером и клиентом. Применение новой версии протокола было нацелено на опасные системы, такие, как, к примеру, механика сцены

В новой идеологии протокола клиент перед тем, как получить данные с сервера, должен отправить ответ серверу о возможности выполнения действия, и после получения команды он также должен сообщить серверу, удалось ли выполнить команду или нет. Такая система подтверждения команд рассчитана на то, чтобы повысить безопасность управления сложными системами. Но кроме явных преимуществ обратной связи с сервером был один недостаток, заключался он в скорости синхронизации. Сервер не мог отправить новую команду до тех пор, пока не был получен ответ о выполнении предыдущей команды. К сожалению, усложненная версия MSC v1.1 так и не получила широкого применения в шоу-индустрии. А вот MSC v1.0 был долгое время очень популярен, пока на его смену не пришли новые протоколы, основанные на современных технологиях передачи данных.

MCC (MIDI Machine Control)

Использование MMC для синхронизации в шоу-индустрии применяется довольно редко. Но мы тем не менее еще можем встретить оборудование, которое может генерировать и принимать MMC сообщения. Этот протокол был разработан для того, чтобы дистанционно управлять профессиональными многодорожечными видео и аудио рекордерами на студиях. Основное назначение MMC команд – передача сообщений разных режимов воспроизведений и записи.

Команды MMC находятся в группе SysEx сообщений. MMC сообщения так же, как и MIDI Show Control, несут в себе информацию о номере устройства Device ID и команду. Все команды, которые можно передать в MMC сообщении, находятся ниже в таблице.

Как мы видим, некоторые команды могут нести дополнительную информацию. Как, например, команда Goto, которая передает также время, на которое необходимо перейти устройству. Мы не будем подробно разбирать этот протокол, так как он уже устарел и для синхронизации практически не используется. Но мы все равно его затронули, потому что некоторые профессиональные таймкод генераторы поддерживают этот тип сообщений для настройки и старта генерации времени.

OSC (Open Sound Control)

Время идет и технологии не стоят на месте. Протоколу MIDI уже почти сорок лет! И конечно же, ему на замену пришла более современная альтернатива Open Sound Control. Как понятно по названию, и этот интерфейс пришел из мира музыки. Но как и следовало ожидать, другие направления шоу-индустрии быстро его освоили. Сейчас этот протокол настолько популярен в разных направлениях шоу технологий, что позже сами создатели дали ему второе название: Open System Control. Что же в нем особенного? Давайте разберемся.

Этот протокол был разработан в компании CNMAT (Center for New Music and Audio Technologies) программистами Adrian Freed и Matt Wright еще в 1997 году. У них появилась идея создать новый протокол на базе широко используемого интерфейса Ethernet. Главное преимущество его в том, что для работы с этим протоколом не нужно никакого специального оборудования и коммутации, как в случае с другими интерфейсами и протоколами синхронизации. Также, Ethernet – это отдельное направление, которое развивается и поддерживается разными компаниями и институтами. Сейчас технологии позволяют передавать сигнал по Ethernet, по воздуху и оптическому каналу на многие километры. А скорость передачи по сравнению с MIDI в тысячи раз быстрее, при этом соединение надежнее. Все эти преимущества автоматически унаследует протокол OSC. Но кроме ряда преимуществ есть и недостатки. Он стал сложнее, а как следствие, специалисту необходимо иметь больше знаний об этом протоколе для работы с ним. Как раз цель этой главы – дать вам знания для комфортной и уверенной работы с протоколом синхронизации OSC.

Концепт построения сетей

Так как OSC базируется на сетевом интерфейсе Ethernet, то прежде чем работать с этим проколом, необходимо настроить сеть. Я уверен, что вы и так прекрасно ориентируетесь в этом вопросе, и то, что вы прочитаете ниже, для вас будет не ново, тем не менее я рекомендую освежить свои знания в этом направлении.

Первое, с чем необходимо познакомиться, это с группой протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). Концепт работы со всеми протоколами описан уровнями (слоями), через которые должен пройти каждый пакет данных при отправке или получении.

TCP/IP Уровни (Layers)

Уровень 1. Физический уровень

Уровень 1 является физическим уровнем. Это оборудование интерфейсов, включая электронику и провода.

Уровень 2. Дата линк уровень

Уровень 2 тесно связан с оборудованием. Этот уровень занимается тем, что собирает данные в пакеты для отправки через Физический уровень. Также этот уровень отвечает за корректную передачу и прием данных и исправление ошибок. На этом уровне появляется такое понятие, как MAC адрес (Media Access Address[2 - Если коротко, то каждое сетевое оборудование имеет уникальный MAC адрес, предустановленный на заводе. MAC адрес для каждого устройства является уникальным. При помощи MAC адреса каждое устройство может идентифицировать себя в общей сети для передачи или приема данных. Пример MAC адреса – 98:5A:EB:C9:00:A8.]).

Уровень 3. Сетевой (Internet) уровень

Это Сетевой уровень, отвечающий за логическое направление данных через сеть.

В большой сети может быть множество логических маршрутов связи между устройствами, по которым пакеты данных могут передаваться. Этот уровень занимается анализом доступных возможностей в сети и выбором подходящего маршрута.

Уровень 4. Транспортный уровень

Этот уровень ответственен за обеспечение того, чтобы низкоуровневые пакеты данных были собраны в их оригинальной форме, правильном порядке и без ошибок.

Сетевой уровень может разбить пакет данных на несколько частей и отправить их разными маршрутами. Поэтому части одного пакета могут быть доставлены не по порядку. Транспортный уровень как раз и решает такие проблемы. Осуществляется это при помощи функционала двух протоколов TCP и UDP.

Уровень 5. Уровень приложения

Этот уровень отвечает уже за передачу «полезных» данных через сеть, с которыми непосредственно имеют дело приложения и программное обеспечение.

Итак, зачем же нам знать все эти уровни и их функционал? Дело в том, что если мы хотим передать что-то через сеть, то прежде нам необходимо выполнить определенные условия, которые регламентирует группа протоколов TCP/IP.

Одно из таких условий – это обязательное использование для каждого клиента сети IP адреса (Internet Protocol Address). Напрашивается резонный вопрос, зачем же использовать дополнительный параметр адреса, если каждое сетевое устройство уже имеет уникальный адрес MAC? Не будем углубляться во все особенности, скажу лишь только, что благодаря IP адресам в нашей сети появляется возможность ее организации, что очень важно, когда мы создаем сложную сеть с определенными правилами. К тому же в отличие от MAC адреса, одно устройство может иметь несколько адресов IP. Какие бывают IP адреса и как их настроить, мы разберем позже.

Кстати, существуют такие типы протоколов, которые используют для подключения только MAC адрес, к примеру, транспортный протокол NetBEUI. Это довольно быстрый протокол, но его главным недостатком является то, что он полностью не маршрутизируемый.

Следующее условие. Для передачи данных мы должны использовать UDP или TCP протокол. По сути, и первый, и второй тип протокола занимается тем, что обеспечивает корректную передачу данных. Но в чем же их отличие?

Принцип работы UDP основан на том, что при отправке данных сервер не беспокоится о том, получил ли клиент эти данные или нет. Он просто отправляет пакет за пакетом в сеть. Отличительная особенность UDP протокола в том, что он очень быстрый.

При использовании протокола TCP клиент сначала должен подключиться к серверу, создав виртуальное подключение. После этого сервер может передать данные клиенту. После получения данных клиентом он отвечает серверу, что пакет данных принят корректно, в противном случае сервер отправляет пакет данных повторно. После завершения сеанса связи клиент должен обязательно корректно отключиться от сервера. Эта схема занимает больше времени на передачу данных, но при этом она более надежна, так как сервер получает обратную связь от клиента.

Но как бы ни был надежен TCP протокол, UDP намного шире используется в шоу-индустрии. Самый яркий пример – это ArtNet протокол, который базируется на UDP. Световой консоли нет необходимости беспокоиться о том, получил ли необходимый пакет данных один из десятка артгейтов. Консоли более важно отправлять пакеты данных в реальном времени для всех участников. И если по какой-то причине один пакет был доставлен некорректно, то это будет менее заметно, чем если все артгейты будут ждать, пока один из клиентов получит корректный пакет. И последнее условие – это использование TCP или UDP портов для передачи или приема данных. Так как потоков данных для одного клиента может быть большое количество, то для того, чтобы эти потоки не перемешивались и были независимы, каждый поток использует свой входящий или исходящий порт, через которые идет обмен данными. Номер порта в UDP и TCP идентифицируется одним числом. Оно может быть в диапазоне от 1 до 65535. Приложение, которое хочет получить или отправить данные, обращается к необходимому TCP или UDP порту. Некоторые порты зарезервированы системой для служебного пользования, и программы пользователя не могут использовать эти порты. К примеру, протокол ArtNet использует порт 6454.

Теперь давайте немного пофантазируем и представим работу курьерской службы и вокзала. Это поможет нам более наглядно понять принцип работы TCP и UDP.

Вокзал имеет свой уникальный адрес местонахождения: город, улица, номер дома – как IP адрес компьютера. На этот вокзал постоянно приходят поезда, как пакеты данных, которые передаются по Ethernet. В поездах приезжают курьеры, работающие на конкретную компанию, которая в свою очередь имеет жесткий протокол отправления и доставки посылок, как протоколы TCP/IP.

В этом протоколе прописано, что каждый посыльный должен доставлять посылку в отделение своей компании и в конкретное окно приема посылок, каждое окно имеет свой номер, так же, как номер порта UDP или TCP. По итогу посыльный доставляет посылку в конкретное отделение и в конкретное окно с конкретным номером. В отделении этой компании много окон, так как заказчиков, которые хотят получить свои посылки, тоже немало. Когда заказчик хочет получить на руки свою посылку, он приходит в отделение компании и обращается в окно с конкретным номером, к которому он прикреплен. Также поступают и программы на компьютере, когда они хотят прочитать данные с конкретного UDP или TCP порта. Если в окне что-то есть для заказчика, то служащий выдает посылку.

Теперь, когда данные получены программой, наступает следующий этап. Расшифровка данных. Когда заказчик открывает посылку, он ожидает увидеть там, скажем, письмо, которое состоит из букв и знаков препинания, с помощью которых закодировано сообщение. Чтобы его прочитать, заказчик должен знать язык, на котором это письмо написано. Языки кодирования регламентируют протоколы высокого уровня, как, например, ArtNet, sACN, OSC, RTP-MIDI. Наш заказчик – англичанин, и если письмо написано на английском языке, то он сможет прочитать сообщение, написанное в письме. То же самое и с программным обеспечением: если программа понимает язык ArtNet, то, получив пакет данных, закодированных протоколом ArtNet, она сможет прочитать и извлечь данные о DMX уровнях.

Теперь давайте познакомимся с методами передачи данных, которые основываются на IP адресах.

Существует три распространенных метода, которые имеют место быть в шоу-индустрии: Unicast, Multicast и Broadcast.

Сразу уточню, методов больше и их принципы отличны. Но так как это уже более специализированное направление, которое не имеет точек соприкосновения с нашей индустрии, то информацию о них вы можете найти в более специализированной литературе.

Самый простой метод передачи. В этом методе пакеты данных передаются уникально, т.е. от клиента сети к клиенту. Такой пакет данных может быть передан только одному устройству. Сетевые свитчи (принцип, который мы разберем чуть позже), получая такой пакет данных, переправят его на физический порт конкретного устройства, которое должно получить эти данные.

Широковещательный метод передачи данных, где один пакет данных передается всем участникам сети (или подсети), в независимости от их адреса. По этому принципу очень часто работает протокол ArtNet. Для этого метода в каждом уровне диапазона сетей зарезервирован адрес 255.

Какие бывают подсети и как они ограничиваются, мы разберем чуть позже, когда будем знакомиться с таким понятием, как маска подсети, но уже сейчас я хочу привести пример широковещательных адресов для сети 10.0.0.0, для понимания идеи диапазона широковещания. Ниже я постараюсь избегать терминологии, с которой мы еще не познакомились.

Итак, если отправить пакет данных на адрес 10.0.0.255, его получат все устройства, чей адрес начинается на 10.0.0.x.

Если отправить пакет данных на адрес 10.0.255.255, его получат все устройства, чей адрес начинается на 10.0.x.x.

Если отправить пакет данных на адрес 10.255.255.255, его получат все устройства, чей адрес начинается на 10.x.x.x.

И последний, самый широковещательный адрес – это 255.255.255.255, пакет данных, отправленный на этот адрес, получат все устройства в сети.

Зачастую в консолях управления уже предустановлено системой, насколько широко может открываться вещание того или иного протокола. В частности, хорошо знакомого нам ArtNet.

Технология, которая реже используется в шоу-индустрии и обычно скрыта в управлении от пользователя.