VST
(Virtual Studio Technology)
– формат звуковых плагинов, внедрённый фирмой Steinberg. Формат распространён довольно широко и многие знают, что это такое и с чем его едят… Но до сих пор на форумах вижу посты типа: «Что такое VST?» или «Я установил VST инструмент, а он не работает. Даже ярлыка на рабочем столе и exe’шника у неё нету…» и т.д Итак, в двух словах: что это такое и как работает.
Что такое Vst инструменты (VSTi).
Источник звука, управляемый по midi. Это может быть Синтезатор, Сэмплер или Ромплер. Для того, чтобы Vst плагин функционировал, нужна хост программа, с помощью которой вы получите доступ к нему.
Всё просто: сначала устанавливаете хост программу (например: Sonar или Cubase, Nuendo, Fruity Loops, Logic и т.д. и т.п.). Затем, устанавливаете сам Vst инструмент, после его инсталляции, запускаете хост программу и пользуетесь.
Немного о содержании самих плагинов.
Как правило, основа VST плагина - это *.dll (не exe!
) файл, который, после инсталляции инструмента, размещается в папке с вашими VST Plugins.
Например, если вы работаете в Cubase, то путь будет таким:
C:\Program Files\Steinberg\Vstplugins
Если в Sonarе, то таким:
C:\Program Files\Cakewalk\VstPlugins
Аналогично для других программ. То есть, если вы впервые устанавливаете Vst плагин и он не виден в (хост программе), первым делом проверьте наличие dll’ок в этой папке.
Другой момент. Если dll файлы присутствуют в директории VST Plugins, но плагин всё равно не виден в системе, возможно вашей DAW нужно просканировать папку, чтобы найти новые плагины, как это нужно сделать, например, если вы работаете в Sonar (кнопка Re-Scan Plugin’s).
Standalone.
Это самостоятельные версии плагинов, не требующие хост-программы. Вот у них – совсем всё просто: после инсталляции появляется и экзэшник (exe файл), и ярлык на рабочем столе. Запустил и работай. Один недостаток. Вы можете легко играть звуками установленного инструмента, но чтобы записать то, что играете – всё равно потребуется хост программа
Vst эффекты.
Как я уже говорил. ВСТ инструменты – это источники звука. Vst эффекты звуков не издают, они обрабатывают входящий звуковой поток. Всё остальное справедливо из написанного выше.
Dx, Dxi
Dxi инструменты и эффекты – альтернатива VST, формат разработанный Microsoft. Кардинальных отличий никаких, форматы идентичны по многим параметрам. Многие программы в равной степени поддерживают как ВСТ, так и Dxi плагины, кроме того, есть Vst адаптеры, легко адаптирующие их для работы в Dxi совместимых хост-программах…
Также, в оболочке при инсталляции многих плагинов есть меню, в котором вы можете выбирать, в каком именно формате устанавливать Plugin.
Нужно сделать standalone приложение, которое бы содержало в себе движок браузера. Собственно всю логику планируется написать на JS , и можно было бы банально выложить в инет, но нужна связь с другим приложением, работающим параллельно.
Первое предложение - использовать компоненту IE и не парится. Но возможно что-то можно сделать на движке FF , но я не представляю как. Что-то слышал про XUL Runner, но это несколько не то.
Если кто объяснит в кратце, кинет ссылок - буду крайне признателен. Ну и мнения о реальности и осмысленности таких заморочек тоже нужны)
Александр aka Efreeti[досье]
полной кроссплатформенности не получится.
точных ссылок дать не могу - так как первого не знаю, а за информацией по второму сам хожу в поиск на майкрософтский сайт
Rumata[досье]
Кроссплатформенность и не стоит как приоритет, хочу использовать FF из "идеологических" соображений;)
Собственно вопрос и был задан сведующим по XUL, а HTA - это не то. Если уж юзать IE , будет С++ приложение.
Давид Мзареулян[досье]
А как потом это приложение связать с другим? Я что-то не нашёл на сайте инфы об внешнем API.
XULRunner (исходя из собственного опыта) более чем пригоден для быстрой разработки "толстых клиентов" и standalone приложений. Включая простое взаимодействие с базой данных SQLite. В смысле связи с другими проложениями - либо TCP / IP , либо консольные врапперы (в последнем случае есть недостаток, через nsIProcess нельзя получить доступ к stdout). Поскольку специфика задачи непонятна, подробнее ответить сложно.
Kirill[досье]
, Давид Мзареулян[досье]
Мне нужно сделать программу с встроенным браузером (без вперёд/назад и прочего), которая при этом могла бы передавать данные из сторонней программы JavaScript"у, который крутится в этом самом браузере.
Самый очевидный вариант (для меня) - движок IE , и самописная ActiveX компонента, которая даёт доступ к той, другой проге.
Но хочется FF (ну или не IE). Я спрашиваю о вариантах, как это можно сделать (и целесообразно ли это делать).
Александр aka Efreeti[досье]
Я не сторонник или приверженец определенных ОС.
Но для вашего случая лучше подходит именно JScript и "движок" МСИЕ.
вопрос и был задан сведующим по XUL
Тогда ваш вопрос звучит несколько по другому.
Кросс-платформенные технологии обеспечивают совместную эксплуатацию различных аппаратных и программных платформ в интересах организаций-потребителей.
Такими могут быть, как правило, сервисные программы, системные утилиты , текстовые и графические редакторы, компиляторы, достаточно простые корпоративные программы. Развитая корпоративная информационная система, как правило, не может состоять из отдельных, не связанных между собой компонентов.
Эта архитектура получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре "клиент-сервер" программное обеспечение разделено на две части -клиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web -технологии (клиент-браузер, сервер- Web -сервер), работа с распределенными СУБД (клиент - специальная программа, сервер - сервер базы данных). Развитие архитектуры "клиент-сервер", а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой "архитектура с толстым клиентом" .Здесь логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, когда сервером является СУБД ) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL .Однако необходимость установки " толстых клиентов ", требующих значительного количества специальных библиотек и специальной настройки окружения, на большое число пользовательских компьютеров с различными операционными средами, как правило вызывает массу проблем. Как альтернатива поэтому возникла также двухзвенная архитектура "с тонким клиентом" .При этом в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале клиентом является просто интернет-браузер, который имеется в стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т.п. К сожалению, такая схема тоже не свободна от недостатков, хотя бы уже потому, что серверу приходится брать на себя иногда не свойственные для него функции реализации бизнес-логики приложения (например, серверу СУБД приходится выполнять расчеты!)
Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено еще в рамках технологии "клиент/сервер". В них наряду с клиентской частью приложения и сервером баз данных появились серверы приложений (Application Servers) .В идеале:
Программа-клиент, таким образом, может быть "тонкой". Преимущества такой архитектуры очевидны:
Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.
Основной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре , является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. Даже если ограничиться UNIX- ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC ,в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы, и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся обратные преобразования. Таким образом, если система реализована на основе стандартного пакета RPC ,она может быть легко перенесена в любую открытую среду .
CORBA (Common Object Request Broker Architecture) - это набор открытых спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и платформо-независимого манипулирования объектами. Разработчиками данных интерфейсов являются OMG и X/Open .
Object Management Group, Inc. (OMG) - это интернациональная организация, основана в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем, разработчиков программного обеспечения и пользователей. OMG продвигает теорию и практику объектно-ориентированной технологии в область практической разработки программного обеспечения. Этот процесс включает в себя разработку промышленных стандартов и спецификаций управления объектами с целью создания общей базы для разработки программного обеспечения. Первоочередными задачами являются: повторное использование, переносимость и интероперабельность объектно-ориентированного программного обеспечения в распределенных, гетерогенных средах. Поддержка данных стандартов создает возможность разрабатывать гетерогенные приложения, работающие на всех основных платформах и операционных системах.
X/Open - независимая всемирная открытая организация, поддерживаемая большинством крупнейших поставщиков информационных систем, пользовательских организаций и компаний-производителей программного обеспечения. X/Open разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и интегрированное системное окружение - Common Applications Environment (CAE) .Компоненты CAE определены в стандартах X/Open CAE .Основная цель CAE - создание пакетов программных интерфейсов (API) которые могут применяться на практике с сохранением максимальной переносимости на уровне исходных кодов программ. API также повышают уровень взаимодействия приложений при помощи предоставления определений и ссылок на протоколы и их профили.
Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование присваивается X/Open trademark (XPG brand) ,лицензированная X/Open .
Концептуальной инфраструктурой, на которой базируются все спецификации OMG ,является Object Management Architecture (OMA) .В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities) ,язык определения интерфейсов распределенных объектов ,стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модель CORBA .
Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими продуктами.
CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) - программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее
Тем самым ORB является связующим звеном между распределенными частями основанной на технологии CORBA системы, позволяя одной части системы не заботиться о физическом расположении других частей (объектов) системы. На рынке представлены ORB разных производителей (например, VisiBroker, WebLogic) ,но все они соответствуют единой спецификации CORBA . Поэтому в принципе CORBA позволяет строить распределенные системы, одновременно используя ORB разных производителей, и строя систему одновременно на различных платформах и различных сетевых протоколах (это в терминологии CORBA называется интероперабельностью - interoperability) .В архитектуре CORBA каждый объект, методы которого доступны другим объектам (обычно его называют CORBA -объектом) имеет уникальную по всей доступной сети Объектную Ссылку (IOR - Interoperable Object Reference) ,по которой к нему можно обратиться. Искать CORBA -объекты можно как по IOR , так и по символическим именам, если они зарегистрированы (обычно при создании) в специальном сервисе имен (NameService) .Для обращения к методам CORBA -объекта последний имеет открытый для всех остальных CORBA -объектов интерфейс. Интерфейсы CORBA -объектов принято описывать на специальном, определенном спецификацией CORBA языке IDL (Interface Definition Language) . Производители ORB поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов CORBA -объектов в конструкции соответствующих языков программирования.
Основой интероперабельности является протокол GIOP - General inter-ORB Protocol ,предназначенный для связи между объектами и ORB в сети. Стандартизация коммуникационного протокола позволяет разработчикам различных частей корпоративной системы совершенно не заботиться об используемых ORBах в других частях ( ORB доменах)
системы. Почти все современные ORBbi строятся на основе IIOP - Internet inter-ORB Protocol (это версия общего протокола GIOP ,предусматривающая использование в качестве транспортного протокола TCP/IP) .
Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities) . Сервисы представляют собой обычные CORBA -объекты со стандартизованными (и написанными на IDL ) интерфейсами. К таким сервисам относится, например, уже упомянутый сервис имен NameService ,сервис сообщений, позволяющий CORBA -объектам обмениваться сообщениями, сервис транзакций, позволяющий CORBA -объектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов.
Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBA -объекты со стандартизованными интерфейсами. Common Facilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области). Например, разработаны Common Facilities для медицинских организаций, для ряда производств и т.п.
