для чего необходим канал osc

Модули оптического канала контроля и управления

Модули OSCM предназначены для организации двунаправленного канала контроля и управления OSC между элементами оптической сети и обеспечивают передачу трафика системы управления сетью.

Модули используются в активных узлах, в которых применяются выходные оптические усилители OPT-BST. В состав плат OPT-BST входят оптические мультиплексоры/демультиплексоры канала OSC.

Сигнал канала контроля и управления OSC представлен в формате STM-1 и передается вне основной полосы на выделенной несущей с длиной волны 1510 нм.

Канал контроля и управления OSC поддерживает следующие функции:

— обмен управляющей информацией между элементами сети;

— перенос сигналов тактовой сетевой синхронизации;

— перенос сообщений SSM;

— перенос данных канала пользователя UDC со скоростью передачи до 100 Мбит/с.

Структурная схема модуля OSCM показана на рис. 2.7.

Рис. 2.7. Структурная схема модуля OSCM

В состав модуля входят следующие компоненты:

— интерфейс канала пользователя UDC;

— оптический приемопередатчик STM-1;

На передаче в модуле осуществляются следующие преобразования сигналов. Кадры Fast Ethernet канала пользователя UDC поступают на вход интерфейса FE и после восстановления в нем передаются в процессор EoS, где они размещаются в циклах виртуальных контейнеров VC-4. В процессоре STM-1 виртуальные контейнеры VC-4 вводятся в циклы STM-1. Кроме того в процессоре STM-1 формируется и вводится секционный заголовок STM-1. В результате сигнал заголовка оптического транспортного модуля OOS, поступающий с платы ТСС2Р, вводится в соответствующие байты секционного заголовка STM-1. Сформированный в процессоре STM-1 электрический сигнал STM-1 во внутреннем формате поступает на оптический передатчик и преобразуется в оптический линейный сигнал канала OSC. Таким образом, оптический приемопередатчик STM-1 выполняет функции интерфейса канала OSC. Для обеспечения большой длины регенерационных секций модули OSCM оборудуются передатчиками с повышенной мощностью выходного сигнала.

Уровень мощности в оптическом канале OSC программно регулируется с помощью управляемого оптического аттенюатора VOA. Диапазон регулирования аттенюатора составляет 30 дБ.

Параметры интерфейса STM-1 приведены в табл. 2. 1.

Параметры приемопередатчика STM-1 Таблица 2.1

Бюджет участка регенерации составляет 40 дБ и обеспечивает длину регенерационной секции около 150 км при затухании ОВ 0,25 дБ/км.

Общий вид модуля OSCM показан на рис.2.8. Они могут устанавливаться в слотах 8 и 10.

Рис. 2.8. Модули OSC-CSM и OSCM – общий вид

Лицевая панель модуля OSCM показана на рис. 2.9.а. На лицевую панель модуля выведены следующие светодиодные индикаторы:

• красный светодиод Fail:

— включается периодически при загрузке системы после включения питания или рестарта;

— включен постоянно при неисправности модуля.

• зеленый светодиодACT:

— индицирует о том, что модуль поддерживает трафик;

• желтый светодиод SF индицирует:

— о сбое сигнала или обнаружении состояния LOS, LOF или большого коэффициента ошибок в порту STM-1 модуля;

— о некорректном подсоединении оптических волокон на передаче и приеме, после правильного подключения ОВ и работе линии, светодиод SF выключается.

Модули OSC-CSM используются в пассивных сетевых элементах, не оборудованных платами выходных усилителей OPT-BST. Поэтому модули OSC-CSM в отличие от модулей OSCМ дополнительно содержат мультиплексор /демультиплексор (Combiner/Separator) канала OSC.

Структурная схема мультиплексора /демультиплексора канала OSC показана на рис 2.10.

Полоса пропускания фильтра передачи 1500…1520 нм, а фильтра приема – 1529…1562 нм. Входные потери для транзитных каналов составляют 2,2 дБ.

Рис. 2.10. Структурная схема мультиплексора /демультиплексора канала OSC

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

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Синхронизация. Новый уровень шоу. V2. NETWORK. Как работает OSC (Open Sound Control)

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

Для передачи данных OSC использует транспортный протокол UDP и TCP. Поэтому при передаче и приеме сообщений мы должны указывать порт данных и IP-адрес клиента и сервера.
OSC очень похожи на MSC-сообщения. Отличие в том, что сами сообщения и адрес клиента не регламентируются протоколом, как в MSC. В OSC регламентируется лишь правило описания адреса и сообщения. Любой производитель и программист может придумать свои наборы сообщений и передать их через OSC.

Итак, мы хотим с одного компьютера через OSC отправить сообщение на другой компьютер. Для этого нужно указать в сообщении IP-адрес получателя и его порт. Обозначение этих параметров зависит от каждого софта отдельно.

Хорошо, OSC-сообщение мы доставили в нужный порт, и программа клиента прочитала это сообщение. Но как же программе понять, к чему применить это сообщение? Для этого OSC-сообщение содержит адрес назначения внутри программы клиента. Это очень похоже на параметр назначения MSC-сообщения, как CueList или Cue. Только, как я уже сказал выше, OSC не имеет жесткой привязки к синтаксису адреса, как в MSC, но тем не менее мы должны соблюдать правила описания адреса, которое использует OSC, а именно URL (Uniform Resource Locator).
Эту схему описания адреса пути вы применяете каждый раз, когда пользуетесь интернет-браузером, чтобы попасть в конкретное место на сайте.

Эти пути назначения сообщения могут быть разными – в зависимости от функционала, который заложил конкретный производитель. Если вы хотите отправить OSC-сообщение на световую консоль ETC Eos, то его путь должен начинаться с “/eos”, далее нужно указать группу контролируемых параметров пульта (например, “/fader”), далее нужно указать номер фейдера “/1” – и в итоге мы получим полный путь к конкретному фейдеру, который будет выглядеть так: “/eos/fader/1/”. Так же мы можем указать путь к группам, к спискам сцен и другому содержимому пульта.

String
Передает строку, закодированную в формате ASCII. С помощью этого типа вы можете передать имя объекта или целое сообщение. Очень часто это используется в системах дистанционного управления по OSC. К примеру, пульт может передать по OSC информацию об имени кьюлиста, который назначен на конкретный фейдер.

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, который обязывает указывать IP-адрес и порт клиента. Что дает множество преимуществ. К примеру, мы можем на одном сетевом клиенте синхронизировать несколько приложений одновременно, используя один и тот же IP-адрес, но при этом разные порты. Это также позволяет нам настраивать сложные маршруты, делить OSC-сигнал или получать на один клиент сообщения из разных источников без использования дополнительного оборудования, так как этот функционал уже заложен в сетевых протоколах группы TCP/IP.

OSC не регламентирует адрес к управляемым параметрам, каждый производитель может создать свою индивидуальную схему, которая будет максимально удобна для управления конкретным функционалом. OSC регламентирует лишь правила описания этого пути, который базируется на URL-системе.
OSC позволяет передавать по заданному адресу аргумент, который может содержать разные параметры и типы данных, а также исходные байты данных для отправки в OSC-сообщении изображения, звука и видео.

Я считаю, что OSC – самый функциональный и современный протокол синхронизации. С его помощью можно построить сложнейшие системы генеративной синхронизации с большой скоростью передачи данных. При этом, как я уже говорил, благодаря тому, что данный протокол базируется на физическом интерфейсе Ethernet, OSC наследует все преимущества передачи данных по этому интерфейсу. Что делает его намного привлекательнее остальных протоколов синхронизации.

Источник

MIDI и OSC — основные протоколы взаимодействия музыкальных приложений

Часть 1. MIDI

1 Предпосылки

Необходимость в таком стандарте возникла примерно к концу 70-х годов. В то время синтезаторы управлялись напряжением с помощью интерфейса CV/Gate. Существовало несколько его видов, однако, наибольшую популярность получил вариант, предложенный фирмой Roland: в нем при увеличении напряжения на 1 В, частота генерируемого тона увеличивалась на одну октаву. Главным недостатком такого интерфейса является то, что с помощью него можно управлять только одним голосом полифонии. Для извлечения дополнительной ноты нужно добавлять еще один интерфейс CV/Gate. Кроме того, таким способом передается только сам факт нажатия клавиши и ее высота, чего однозначно мало для выразительной игры.

Другим недостатком синтезаторов того времени была сложность настройки. Для каждого нового звука музыкантам приходилось настраивать инструмент заново, что было очень не удобно на живых выступлениях. На концертах тех времен часто можно было увидеть целые стеллажи из синтезаторов — так музыканты выходили из ситуации. Со временем в инструменты были встроены мини-компьютеры, с помощью которых можно было сохранять положения ручек в пресеты.
Однако, есть еще один момент, который оказал большое влияние на разработку MIDI.

Несомненно, у каждого синтезатора свой характер звучания, каждый из них был силен в определенных типах звуков. Поэтому многие музыканты того времени практиковали игру сразу на двух инструментах, как бы используя лучшее из разных моделей. Наслоение звуков из различных синтезаторов стало исполнительским приемом, визитной карточкой многих музыкантов. [1]

2 История появления

К началу 80-х большинство производителей осознали необходимость создания единого интерфейса. Задача стояла такая: разработать стандарт передачи действий исполнителя в цифровой форме между всеми типами электромузыкальных инструментов. [1]

3 Основы

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

Сам протокол состоит из трех частей [1]: спецификация формата данных, аппаратная спецификация интерфейса и спецификация хранения данных. В данной статье будет идти речь только о первой части.

MIDI сообщения делятся на два типа: сообщения канала (channel messages) и системные сообщения (system messages). Первые управляют звукообразованием, а вторые выполняют служебные функции, например, синхронизация.

Сообщение обычно состоит из двух или трех байт. Первый байт называется статус байтом. В нем задается тип сообщения и номер канала, к которому оно относится. Все последующие байты называются байтами данных. Статус-байт всегда начинается с единицы, а байт-данных с нуля — таким образом система их различает. Получается, что для MIDI информации остается только 7 бит, с помощью которых можно закодировать целые числа от 0 до 127, — вот откуда берется это «знаменитое» ограничение на количество нот и значения контроллеров.

Как видно из рисунка, информации о типе сообщений отводится всего 3 бита, в которых можно закодировать только 8 чисел. 7 из них отведены под наиболее часто используемые команды, а последнее используется для системных сообщений. Когда передается системное сообщение, последние 4 бита статус байта (в которых обычно передается номер канала) определяют тип системного сообщения.

Табл. 1. Сообщения канала.

Табл. 2. Системные сообщения

4 Недостатки

MIDI разрабатывался, как доступный и практичный стандарт для передачи жестов исполнителя между любыми MIDI-устройствами [2]. Не в последнюю очредь благодаря своей легковесности он и получил такое распространение. Что ни говори, со своим предназначением он справляется прекрасно, и это подтверждается временем.
Итак, наверное, самый известный недостаток — ограничение значений контроллеров на 128 значений. Конечно, есть возможность передавать их с помощью двух байтов данных (что дает 16 384 возможных значений), но для этого надо передать три сообщения Control Change, что очень сильно загрузит протокол, так как данные по нему передаются со скоростью 31 250 бит/с. Это очень мало. Для сравнения, 12-нотный аккорд передастся примерно за 10 мс. И это без других сообщений, например Clock и CC. В реальном перфомансе, когда одновременно передается много различных параметров, могут возникнуть проблемы с синхронизацией.

Часть 2. Open Sound Contol

«Open Sound Control — это новый, оптимизированный для современных сетевых технологий протокол для взаимодействия компьютеров, звуковых синтезаторов и других мультимедиа устройств» — так был представлен OSC на международной конференции по компьютерной музыке в 1997 году [3]. OSC не является протоколом в том виде, каким является MIDI, так как он не описывает требований к аппаратному обеспечиванию — спецификации описывают лишь формат передачи данных. В этом плане OSC больше схож с XML или JSON, нежели с MIDI [8].

Пока оставим технические подробности и начнем с самого начала, с истории.

1 История, области применения

Open Sound Control был создан в 1997 году Мэттью Райтом (Matthew Wright) и Эдрианом Фридом (Adrian Freed) в Университете Калифорнии в центре новой музыки и аудио технологий (CNMAT — Center of New Music and Audio Technologies). Разработчики хотели использовать высокоскоростные сетевые технологии в интерактивной компьютерной музыке [4]. OSC не важно, по какому протоколу передаваться, так как он представляет собой всего лишь формат данных (binary message format), хотя большинство реализаций используют TCP/IP или UDP. Другой причиной создания было то, что MIDI с его нотами, каналами и контроллерами логично не подходил к разрабатывающемуся в то время синтезатору CAST (CNMAT Additive Synthesis Tools), оно и понятно, ведь MIDI — это клавишно-ориентированный протокол, который разрабатывался для управления одним синтезатором с другого [1].

Слово «Open» в названии означает, что OSC не предопределяет, какие сообщения должны использоваться для определенных параметров — это решается разработчиком конкретного девайса. Кроме того, это слово имеет и другое значение: протокол открыт, его спецификации находятся на официальном сайте, где можно скачать исходники.

2 Особенности

3 Анатомия сообщений

Стоит отметить, что при использовании UDP, если сообщения передавались в разных пакетах, они не обязательно будут приходить в том порядке, в каком были переданы [6]. Допустим, были переданы сообщения:

/synth1/noteoff 54
/synth1/noteon 60

Фактически они могут прийти в обратном порядке:

/synth1/noteoff 60
/synth1/noteon 54

Это может привести к проблемам с управлением голосами в полифонии, например, в данном сообщении передается команда noteoff, которая выключает голос, а потом включает другую ноту. Если эти сообщения придут в обратном порядке, голос не освободится и новая нота не сможет запуститься.

Чтобы этого избежать, нужно передавать сообщения в одном пакете (bundle), либо использовать TCP/IP, он отличается от UDP тем, что гарантирует корректную доставку пакетов, передавая каждый из них до тех пор, пока он не передастся в изначальном виде. Нужно иметь ввиду, что ценой такому удобству будут большие в сравнении с UDP задержки, поэтому использование TCP/IP должно быть обосновано.

4 Pattern matching

дефис между двумя символами означает диапазон чисел в ASCII последовательности (дефис в конце строки не имеет специального значения);

Источник

Управляем самодельными железяками по воздуху при помощи Open Sound Control

В этом материале я постараюсь рассказать, каким образом можно с телефона или планшета на iOS и Android удалённо управлять вашим самодельным устройством подключенным к сети. Любой, хоть сколь-нибудь знакомый с темой, к этому моменту уже решил, что речь пойдёт об очередном веб-интрефейсе к вашим Arduino и mbed’ам — спешу перебить ваши мысли — не пойдёт. Способ, о котором я хочу рассказать, быстр, дёшев, имеет готовую обратную связь, удобные контролы и обладает наглядностью, которой позавидует самый вылизанный веб-интерфейс.

Чтобы материал не показался оторванным от реальной жизни, я покажу, как мы 4 месяца назад проделали этот фокус с нашим Лайтпаком. Эта ситуация немного отличается от сферического сценария применения протокола Open Sound Control (дальше OSC) в вакууме, но тем не менее, является хорошим примером того, как он может быть эффективно использован в быстром прототипировании.

Задача

В наличии мы имели open-source USB-устройтво подсветки, которое управляется кроссплатформенным софтом и имеет на стороне этого софта API для управления из внешних программ или плагинов. Мы хотели управлять этим устройством по сети с наших планшетов и смартфонов. Включать и выключать его, менять профили настроек, управлять яркостью, регулировать подсветку по каждому отдельному каналу и может быть даже запускать другие плагины.

В вашем случае ситуация может быть иной, не осложнённой посредником в виде полноценного ПК и какого-то API. Например, устройство на ARM/AVR периодически подключающееся к сети, или хотя бы Arduino c ethernet-шилдом, который 24/7 логирует для вас потребление электроэнергии за щитком в подъезде и шлёт данные прямиком в гуглодокумент.

Первое, что приходит в голову для решения такой задачи — веб-интерфейс. Казалось бы универсально: можно получить доступ с любой платформы. Но заставлять постоянно крутиться веб-сервер, каким бы микроскопическим он ни был, нам не хотелось. Да и хороших конструкторов веб-интерфейсов, которые бы имели подходящие нам контролы, мы сходу не нашли, рисовать свои не хотели и понимали, что результат всерьёз сможет работать лишь на десктопе и рядовой МК его не осилит в случае если в будущем нам придётся управлять standalone-устройством.

Однако, если к устройству можно подключиться через сеть (в нашем случае слать команды в API можно прямо через Telnet) можно было бы написать полноценное приложение для мобильной платформы, которое бы просто слало пакеты-сообщения, а сервер парсил их и таким образом управлял бы устройством. Не смотря на то, что мы за вечер собрали небольшой прототип для Android, который эксплуатировал этот способ, он всё-равно оставался “дорогим” даже в сравнении с веб-интерфесом.

Время шло, задача записалась где-то на подкорке и не вылезала оттуда до тех пор, пока я случайно не наткнулся на мобильное приложение TouchOSC, которое (практически) одинаково хорошо работает на iOS и Android.

После демонстрационных роликов и скриншотов пройти мимо не попробовав было попросту невозможно.)

Если коротко, то приложение TouchOSC (AppStore, Google Play) реализует на ваших мобильных девайсах интерфейсы протоколов OSC и MIDI, с которыми привыкли работать все специализированные синтезаторы, редакторы звука, программы для диджеев, студий звукозаписи и пр. При этом TouchOSC даёт возможность использовать не только предустановленные раскладки контролов (layouts) кнопок-слайдеров-ярлычков, но и очень просто и быстро рисовать свои собственные в специальном редакторе. Всё это добро работает через wi-fi, но может работать и по проводам при наличии специальных адаптеров.

Типичная раскладка из состава предустановленных выглядит примерно так. Уровень сложности: «Корейцы», что, впрочем не мешает вам повторить её в редакторе раскладок.

Поверхностный анализ показал, что это приложение не единственное и по желанию для iOS можно воспользоваться iOSC, OSCemote, Mrmr OSC controller, Remokon for OSC (для Android даже перечислять не буду — их ещё больше). Этот же анализ показал, что сам протокол используется в большом числе программ и устройств, а самое главное для нас то, что библиотеки и обёртки с его реализацией существуют для многих языков программирования и платформ (вот, например, варианты для Arduino и mbed). Неполный список есть на официальном сайте.

У нас появилась возможность нетипичным образом применить новый, интересный, на первый взгляд, инструментарий. Впереди был свободный выходной день, поэтому со словами “вызов приянт” timsat на одну половину монитора развернул Гугл, а на вторую Notepad++.

Протокол

Open Sound Control — это пакетный протокол передачи данных между мультимедийными устройствами (в первую очередь электронными музыкальными инструментами/ синтезаторами и ПК), который в последнее время всё чаше используется как замена MIDI. Основновной фичей протокола остаётся работа через сеть, но есть и другие особенности. Последняя версия спецификации доступна на сайте Центра Аудио-технологий университета Беркли (CNMAT).

Как я уже упоминал, на сегодняшний день типичное применение протокола — обеспечение интерфейса между устройствами ввода (синтезаторами, планшетами, игровыми контроллерами и пр.) и специализированными программами такими, как Super Collider, Traktor, REAPER и пр. OSC “из коробки” поддерживается такими потрясающими устройствами, как Lemur и Monome.

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

Вот пример сообщений, которыми обмениваются OSC-сервер и клиент:

В данном случае у нас имеется точный идентификатор контрола и /1/fader2 0.497120916843 означает, что со второго ползунка на первой вкладке (да, там можно использовать несколько вкладок в пределах одного лэйаута) к серверу приехало значение 0.49 и т.д. Z-message из этого примера можно включить по желанию и о нём я расскажу позже.

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

Реализация

Для работы с API Лайтпака мы используем собственную обёртку написанную на Python. Поэтому, а ещё потому, что для Питона существовала удовлетворяющая нас OSC-библиотека, мы решили написать небольшой скриптик, который фаткически являлся коннектором между API и сетевым устройством посылающим OSC-сообщения. Главные требования для такой реализации:

Для тех, кто, как и я, предпочитает картинки, наколхозил схему взаимодействия:

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

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

Честно говоря, не знаю, о чём тут можно написать подробнее. С точки зрения программирования задача примитивна. Исходный код этого “коннектора” по обыкновению лежит у нас в репозитории и доступен для всех.

Кстати, в TouchOSC реализованы некоторые довольно удобные дополнительные фичи: Во-первых, есть возможность использовать сообщение /ping которым обмениваются клиент с сервером для поддержки соединения даже когда сами данные не бегают. Во-вторых, поддерживается так называемый z-message — специальное сообщение, которое говорит серверу, что пользователь на клиенте наконец-то закончил возюкать пальцем по экрану (момент окончания ввода). Мы не использовали эту фичу, но не исключаю, что существуют ситуации в которых она окажется крайне полезной. В-третьих, как и большинство похожих приложений, TouchOSC умеет слать на сервер даные со встроенного в мобильный девайс акселерометра. Т.е. вы можете использовать свой смартфон или планшет как хитрое устройство ввода для ваших сетевых самоделок (крутить камерой на сервомашинках и пр.).

Подводные камни

Всё, что касается взаимодействия с приложением TouchOSC проходит гладко. Даже загрузка собственных лэйаутов осуществляется “по воздуху” нажатием одной кнопки. Единственный на сегодняшний день заметный недостаток — это невозможность загрузки собственных лэйаутов для версии под Android. В переписке с автором ему удалось убедить меня в том, что “уже вот-вот, готовлю к релизу”.

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

В целом, процесс создания такого машапа предельно интуитивен и не займёт много времени. Вот почему я бы посоветовал использовать OSC для быстрого прототипирования вместо полноценных клиент-серверных стеков с веб-интерфейсами. Тем более, если вы собираетесь презентовать этот прототип на мероприятии, или, скажем, заказчику, более наглядного варианта реализации сопровождающегося вау!-как-у-вас-такое-пропустили-в-эппстор вопросами я попросту не знаю.

Итак, ещё раз: Если вам необходимо быстро и дёшево реализовать простой способ наглядного управления самодельным сетевым устройством с обратной связью, то протокол OSC — интересный выбор.

Источник