&arts; entwickelt sich zu schnell, als das an dieser Stelle eine aktuelle Liste möglich wäre. Informationen zu Plänen finden Sie in der Datei TODO und in den Mailinglisten. Sie sind eingeladen, sich bei der weiteren Planung und Implementation zu beteiligen. Dieses in der Entwicklung befindliche Dokument versucht einen Überblick darüber zu geben, wie neue Technologien in &arts; integriert werden. Es behandelt folgende Themen: Wie Schnittstellen funktionieren. Codecs: Dekodierung von mp3-Strömen in eine Form, so dass sie als Daten verwendet werden können. Video. Threading. Synchronisation. Dynamische Erweiterung / Maskierung. Dynamische Komposition. &GUI; &MIDI; Dieses befindet sich in Arbeit. Es ist die Grundlage dafür, wie neue Technologien in &arts; integriert werden können. Man kann einen ungefähren Eindruck davon bekommen, wie solche Probleme gelöst werden. Sie können alles, was Sie hier sehen, korrigieren. Programme, die &arts;-Technologie verwenden (bitte: koordinieren Sie Ihre Anstrengungen): KPhone (Voice over IP) &noatun; (Video- / Audiospieler) &artscontrol; (Kontrollprogramm des Soundservers) Brahms (Musiksequencer) Kaiman (&kde;2-Medienspieler - kmedia2-kompatibel) mpglib/kmpg (mpg Audio- und Videowiedergabetechnologie) SDL (direkte Medienschicht für Spiele, noch nicht begonnen, aber wohl sinnvoll) electric ears (Der Autor hat mich kontaktiert - Status unbekannt) &MCOP;-Schnittstellen sind die Grundlage des Konzeptes von &arts;. Sie sind das netzwerktransparente Äquivalent zu C++-Klassen. Sie sollten Ihre Programmentwicklung mit Schnittstellen durchführen. Die Schnittstellen bestehen aus vier Teilen: Synchrone Ströme Asynchrone Ströme Methods Attributes Diese können beliebig kombiniert werden. Neue Technologien sollten als Schnittstellen definiert werden. Lesen Sie die Abschnitte über asynchrone Ströme und synchrone Ströme, sowie den über die KMedia2-Schnittstelle. Es sind gute Beispiele für ihre Funktionsweise Schnittstellen werden als .idl-Code spezifiziert und mit dem mcopidl-Compiler übersetzt. Sie leiten die Interfacename_impl-Klasse ab, um es zu implementieren und verwenden REGISTER_IMPLEMENTATION(Interfacename_impl), um Ihre Objekt-Implementation in das &MCOP;-Objektsystem einzufügen. Die kmedia2-Schnittstellen erlauben Ihnen zu ignorieren, dass wav-Dateien, mp3-Dateien und viele andere Formate aus Datenströmen bestehen. Stattdessen können Sie Methoden implementieren, um sie abzuspielen. Sie können eine Routine zum Laden von wav-Dateien schreiben, um wav-Dateien abzuspielen ( als PlayObject), aber niemand sonst kann Ihren Code verwenden. Asynchrone Ströme sind eine Alternative. Sie definieren eine Schnittstelle, die die Übergabe von Datenblöcken ermöglichen. So sieht das in &MCOP; aus: interface Codec { in async byte stream indata; out async byte stream outdata; }; Natürlich können Codecs Attribute verwenden, um zusätzliche Daten, wie Formatinformationen bereitzustellen. interface ByteAudioCodec { in async byte stream indata; out async byte stream outdata; readonly attribute samplingRate, bits, channels; }; Dieser ByteAudioCodec kann zum Beispiel mit einem ByteStreamToAudio-Objekt verbunden werden, um einen Audio-Strom zu formen. Andere Codec-Typen können stattdessen Video-Daten direkt ausgeben, wie interface VideoCodec { in async byte stream indata; out video stream outdata; /* note: video streams do not exist yet */ }; Meistens sollte ein Codec-Konzept verwendet werden anstatt einem Sie wissen, wie man es abspielt und ich nicht-Konzept, wie zum Beispiel WavPlayObject es praktiziert. Natürlich muss sich jemand hinsetzen und einige Versuche durchführen, bevor ein API festgeschrieben werden kann. Mein Vorschlag ist, Video als asynchronen Strom eines &MCOP;-Datentypen, der Bilder enthält, zu implementieren. Dieser Datentyp muss noch kreiert werden. Auf diese Weise könnten Plugins, die Video-Bilder verarbeiten in der gleichen Art wie Audio-Plugins verbunden werden. Auf einige Dinge muss dabei geachtet werden: Es gibt die Farbmodelle RGB und YUV. Das Format sollte dem Strom aufgeprägt werden. Synchronisation ist wichtig. Es sollte möglich sein, die VideoFrame-Klasse so zu reimplementieren, das Daten im gemeinsam genutzten Speicher gespeichert werden können. Damit würde auch Video-Streaming zwischen verschiedenen Prozessen ohne große Probleme möglich. Bisher befindet sich für Videodaten von der Dekodierung bis zum Rendern alles im gleichen Prozess. Ich habe einen Prototyp für ein Videostreaming-Programm implementiert, man kann ihn von hier herunterladen. Er muss nach einigen Experimenten in &MCOP; integriert werden. Eine Render-Komponente, die XMITSHM (mit RGB und YUV) unterstützt, sollte programmiert werden. Martin Vogt arbeitet derzeit an so etwas. Bisher ist &MCOP; Singel-Threaded. Für Video werden wir allerdings wohl nicht um Threading herum kommen. Dabei ist auf einige Dinge zu achten. SmartWrappers - sie sind nicht threadsicher wegen nicht abgesicherter Referenzzählung und ähnlichen Dingen. Dispatcher / I/O - nicht threadsicher. Ich könnte mir allerdings vorstellen, einzelne Modules sowohl für synchrones als auch asynchrone Streaming threadsicher zu machen. Auf diese Weise - mit einem threadtauglichen Flusssystem - könnte der Signalfluss auf zwei oder mehr Prozessoren verteilt werden. Damit wäre dem Audiosystem in Bezug auf Mehrprozessorsysteme erheblich geholfen. Wie es funktionieren könnte: Das Flusssystem entscheidet, welche Module was berechnen sollen - das sind: Video-Frames (mit der process_indata-Methode) Synchrone Audio-Ströme (calculateBlock) oder asynchrone Ströme, hauptsächlich Byte-Ströme Module können diese Dinge in eigenen Threads berechnen. Für Audio ist es sinnvoll, Threads wiederholt zu benutzen (z.B. rendern in vier Threads auf vier Prozessoren, unabhängig davon, ob 100 Module ausgeführt werden). Für Video und Byte-Dekomprimierung könnte es sinnvoll sein, eine blockierende Implementierung in einem eigenen Thread zu haben, der mit dem Rest das &MCOP;-Systems durch das Flusssystem synchronisiert wird. Module dürfen die Funktionen von &MCOP; (wie entfernte Aufrufe) während Thread-Operationen nicht verwenden Video und &MIDI; (und Audio) müssen möglicherweise synchronisiert werden. Das funktioniert über Zeitmarken. Zeitmarken könnten zu asynchronen Strömen hinzugefügt werden, indem jedes Paket mit einer Zeitmarke versehen wird. Zwei Video-Frames müssen also als zwei Pakete gesendet werden (sie sind sowieso recht groß), damit sie unterschiedliche Zeitmarken haben können. Audio sollte implizit Zeitmarken haben, da Audiodaten synchron wiedergegeben werden. Es sollte folgendes möglich sein: Ein FX-Effekt ist zusammengesetzt aus mehreren einfachen Modulen. Ein FX-Effekt sollte aussehen wie ein normales &MCOP;-Modul (siehe auch Maskierung (masquerading)), obwohl er aus anderen Modulen besteht. Das ist für &arts-builder; erforderlich. Alle &GUI;-Komponenten werden &MCOP;-Module sein. Sie sollten Attribute wie Größe (size), Name (label), Farbe (color), ... haben. Ein RAD-Builder (&arts-builder;) sollte in der Lage sein, sie visuell zusammenzusetzen. Das &GUI; sollte durch Sicherung der Attribute speicherbar sein. &MIDI; sollte als asynchroner Strom implementiert werden. Es sollte zwei Möglichkeiten geben, zum Einen die Verwendung von normalen &MCOP;-Strukturen für die Typen und zum Anderen die Einführung von weiteren angepassten Typen. Normale Strukturen sollten ausreichen, also etwas wie: struct MidiEvent { byte b1,b2,b3; sequence<byte> sysex; } Asynchrone Ströme sollten angepasste Typen unterstützen.