В этом разделе описывается то, над чем мы сейчас работаем. А так как разработка ведётся быстро, информация может быть устаревшей. Чтобы узнать о последних планах, проверяйте список файла TODO и список рассылки. Не забывайте о том, что вы тоже можете принять участие в разработке. Это черновик, в котором описано, как новые технологии внедряются в &arts;. Вот какие темы здесь упомянуты: Как работает интерфейс. Кодеки - декодирование потоков mp3 или wav для того, чтобы использовать их как данные. Видео. Многопоточность. Синхронизация. Динамическое расширение. Динамическое построение. &GUI; &MIDI; Над этим мы сейчас работаем. Если вы хотите увидеть технологию в &arts;, начните с этого. Вы получите общее представление о решающихся проблемах. Вы можете и исправить эту информацию. То, что будет использоваться совместно с &arts; (поэтому координируйте свои действия, пожалуйста): KPhone (передача речи по протоколу IP) &noatun; (видео- и аудиопроигрыватель) &artscontrol; (программа управления звуковым сервером, для осциллографов) Brahms (музыкальный синтезатор) Kaiman (&kde;2 медиа-проигрыватель, совместим с kmedia2) mpglib/kmpg (mpg - технология воспроизведения аудио и видео) SDL (обращение к мульитмедиа-данным напрямую, для игр, ещё не реализовано) electric ears (автор со мной связался - статус неизвестен) Интерфейсы &MCOP; - основа идеи &arts;. Они эквивалентны классам в C++. Когда возможно, ориентируйтесь на интерфейсы. Они состоят из четырёх частей: Синхронные потоки Асинхронные потоки Методы Атрибуты Их можно смешивать как угодно. Новые технологии должны быть определены в терминах интерфейсов. Прочитайте разделы о синхронных и асинхронных потоках, а также об интерфейсах KMedia2, которые являются замечательными примерами работы интерфейсов. Интерфейсы определены в коде .idl и компилируются mcopidl. Вы создаёте производный класс Interfacename_impl и используете функцию REGISTER_IMPLEMENTATION(Interfacename_impl), чтобы встроить ваши объктные реализации в систему объектов &MCOP;. Интерфейсы kmedia2 позволяют игнорировать файлы wav, mp3 и всё, что состоит из потоков данных. Вместо этого вы описываете методы их воспроизведения. Поэтому вы можете написать программу загрузки файлов wave таким образом, чтобы она пригрывала их (как PlayObject), но никто другой, кроме вас, не сможет использовать код. Альтернативой являются асинхронные потоки. Вы определяете интерфейс, который позволяет передавать блоки данных. В &MCOP; это выглядит так: interface Codec { in async byte stream indata; out async byte stream outdata; }; Конечно, кодеки могут снабжаться атрибутами для получения дополнительной информации, к примеру, о формате. interface ByteAudioCodec { in async byte stream indata; out async byte stream outdata; readonly attribute samplingRate, bits, channels; }; Этот ByteAudioCodec, например, может быть подключен к объекту ByteStreamToAudio для создания настоящего аудио потока. Конечно, в других типах кодеков видео воспроизводится напрямую, например interface VideoCodec { in async byte stream indata; out video stream outdata; /* note: видеопотоки ещё не используются */ }; Кодек не должен разрабатываться по принципу вы знаете, как воспроизводить, а я - нет, как, например, WavPlayObject. И всё же кто-то должен сидеть и тестировать его до завершения API. Я хочу сделать видео асинхронными потоками некоторых встроенных типов данных &MCOP;, содержащих изображения. Сейчас идёт работа над этим типом данных. Тогдга модули, работающие с видео изображениями могут быть подключены так же, как и модули, работающие со звуком. Есть ещё несколько вещей, которые обязательно нужно иметь в виду: Цветовые пространства RGB и YUV Формат должен каким-то образом добавляться к потоку. Очень важна синхронизация. Также я хочу оставить возможность переопределить класс VideoFrame, чтобы он мог хранить данные в разделённой памяти. Тогда будут возможны видео потоки между различными процессами без особых проблем. Как обычно, вся обработка видео, от декодирования до отображения на экране, должна производиться в одном процессе. Я сделал прототип реализации видеопотоков, который вы можете скачать отсюда. Его нужно будет интегрировать в &MCOP; после тестирования. Компонент визуализации должен поддерживать XMITSHM (с RGB и YUV), Мартин Вогт (Martin Vogt) сказал, что работает над этим. Сейчас &MCOP; не поддерживает работу с несколькими потоками обработки данных. Возможно, мы не сможем избежать многопоточности при работе с видео. Но есть вещи, с которыми нужно обращаться аккуратно: SmartWrappers - их использование с многопоточностью небезопасно из-за незащищенного механизма подсчета ссылок и т. д. Диспетчер ввода-вывода тоже небезопасен. Однако я мечтаю сделать эти модули безопасными для синхронных и асинхронных потоков. Тогда можно будет посылать сигнал на несколько процессоров. Кроме того, это можно использовать при воспроизведении аудио на многопроцессорных системах. Как это будет работать: Система управления потоками решает, что должны обрабатывать модули (и какие), т. е.: видеокадры (метод process_indata) синхронные аудиопотоки (calculateBlock) другие асинхронные потоки, в основном байтовые Модули могут обрабатывать эти вещи и в собственных потоках. В аудио можно использовать потоки повторно (т. е. использование 4 потоков на 4 процессорах, даже если запущено 100 модулей). Для видео и декомпрессии будет удобно использование блокирующего средства во внутреннем потоке, которое синхронизировано с остальной частью &MCOP; системой управления потоками. Модули могут не использовать средства &MCOP; (такие, как удалённый вызов) во время работы в потоке. Видео и &MIDI; (и аудио) могут требовать синхронизации. Это могут быть маркеры времени. Я хочу использовать их в асинхронным потокам, добавляя эти маркеры к каждому пакету. Если вы посылаете два видеокадра, сделайте их пвкетами (всё равно они большие), чтобы у вас были два разных маркера. Т. к. аудио - синхронный поток, временные метки здесь тоже подразумеваются. Нужно сделать так, чтобы можно было сказать: эффект FX состоит из этих простых модулей. FX должен выглядеть как обычный модуль &MCOP;, но состоять из других модулей. Это необходимо для &arts-builder;. Все компоненты &GUI; будут модулями &MCOP;. У них должны быть такие атрибуты, как размер, метка, цвет, ... &arts-builder; должен уметь составлять их визуально. Должна быть возможность сохранять графический интерфейс, сохраняя атрибуты. &MIDI; будет реализован с помощью асинхронных потоков. Есть два варианта: использовать обычные структуры &MCOP; для описания типа или вводить новые стандартные типы. Думаю, обычных структур будет достаточно: struct MidiEvent { byte b1,b2,b3; sequence<byte> sysex; } Асинхронные потоки должны поддерживать обычные типы потоков.