DE69403915T2

DE69403915T2 - Objektorientiertes videosystem

Info

Publication number: DE69403915T2
Application number: DE69403915T
Authority: DE
Inventors: Steven H. Palo Alto Ca 94301 Milne; James Michael La Honda Ca 94020 Tindell
Original assignee: Taligent Inc
Current assignee: Object Technology Licensing Corp
Priority date: 1993-09-13
Filing date: 1994-01-06
Publication date: 1998-01-15
Anticipated expiration: 2014-01-07
Also published as: AU6121094A; CA2153965C; US5936643A; US6377962B1; EP0714531B1; WO1995008149A1; EP0714531A1; JPH09503081A; CN1125490A; JP3770616B2; CA2153965A1; DE69403915D1

Description

Gebiet der Erfindung

Diese Erfindung betrifft im allgemeinen Verbesserungen bei Camputersystemen und insbesondere bei einem System für die Übertragung von Videoinformationen zwischen Multimedia- Komponenten.

Hintergrund der Erfindung

Multimedia ist vielleicht die am schnellsten wachsende Anwendung für Computersysteme. In zunehmendem Maße verwenden Anwender ihre Computer dazu, Graphik-, Ton- und Bildinformationen für Endanwender darzustellen. Anwender fordern in zunehmendem Maße ergonomische Schnittstellen für die Verwaltung von Multimedia-Präsentationen. In der Vergangenheit wurden ein Zeitraster und eine Programmiersprache verwendet, um eine Multimedia-Präsentation zu implementieren. Es war jedoch nicht möglich, beim Start einer Multimedia-Präsentation ein flexibles Mischpult zu simulieren, um die Präsentation von Musik oder Ton mit der Darstellung von Informationen zu ermöglichen.
Beispiele für aktuelle Multimedia-Systeme, welche nicht über die Fähigkeiten der vorliegenden Erfindung verfügen, wären Quicktime von Apple und Video für Windows von Microsoft, wie sie in der März-Ausgabe von NEWMEDIA, "It's Showtime", Seiten 36-42 (1993) beschrieben sind. Die Wichtigkeit der Lösung des Übertragungsproblems, welches sich in den Lösungen des Standes der Technik präsentiert, wird in der März-Ausgabe im IEEE Spectrum, "Interactive Multimedia", Seiten 22-31 (1993) und in "The Technology Framework", IEEE Spectrum, Seiten 32-39 (1993) diskutiert.
Diese Artikel heben die Wichtigkeit einer ästhetischen Schnittstelle zur Steuerung von Multimedia-Produktionen hervor.

Zusammenfassung der Erfindung

Dementsprechend ist es eine Hauptaufgabe der vorliegenden Erfindung gemäß den angehängten Ansprüchen, ein System und ein Verfahren für den Anschluß, das Übertragen und das Filtern von Video-Multimediadaten im Zuge des gesamten Verlaufes einer Multimedia-Präsentation mit Hilfe eines Computers mit einem Speicher und einer Anzeigevorrichtung zu schaffen. Ein im System befindlicher Prozessor verfügt über einen daran angeschlossenen Speicher und eine angeschlossene Anzeigevorrichtung, welche vom Prozessor gesteuert werden. Eine Mehrzahl an Multimedia-Objekten wird im Speicher erzeugt und an der Anzeigevorrichtung dargestellt. Ein Verbindungsobjekt wird ebenfalls im Speicher erzeugt und an der Anzeige dargestellt, um Multimedia- Objekte mit einem Videoobjekt zu verbinden. Schließlich werden die Informationen über das Verbindungsobjekt zwischen dem Multimedia-Objekt und dem Video-Objekt übertragen.

Kurze Bebchreibung der Zeichnungen

Figur 1 ist ein Blockdiagramm eines Personal-Computersystems gemäß einer bevorzugten Ausführungsform;
Figur 2 zeigt ein einfaches Heimstudio des Standes der Technik mit einem Kassettenlaufwerk, einem Mischer, einer Halleinheit, einem Paar Mikrophonen und einem Paar Lautsprecher;
Figur 3 ist eine Darstellung einer Mediakomponente gemäß einer bevorzugten Ausführungsform;
Figur 4 ist eine Darstellung einer Audiospielerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 5 ist eine Darstellung der Eingangs- und Ausgangsfächerungsanschlüsse gemäß einer bevorzugten Ausführungsform;
Figur 6 ist eine Darstellung eine Audiokomponente mit null oder mehreren Audioeingangsanschlüssen und null oder mehreren Audioausgangsanschlüssen gemäß einer bevorzugten Ausführungsform;
Figur 7 ist eine Darstellung einer Stimmaufzeichnungsanwendung, welche ein Audioabspielgerät verwendet, um Stimmauf zeichnungen gemäß einer bevorzugten Ausführungsform aufzunehmen und abzuspielen;
Figur 8 ist eine Darstellung einer Voice Mail/Telefonanrufbeantworteranwendung gemäß einer bevorzugten Ausführungsform;
Figur 9 ist eine Darstellung eines Multimedia-Abspielgerätes, das extern mit einem Haupttaktgeber gemäß einer bevorzugten Ausführungsform synchronisiert wird;
Figur 10 ist eine Darstellung von drei Klängen, einer für Musik, einer für Klangeffekte, und einer für Sprachaufnahme, welche zusammengemischt und durch ein Ausgabegerät wie zum Beispiel einen Lautsprecher gemäß einer bevorzugten Ausführungsform geführt werden;
Figur 11 ist eine Darstellung einiger der Audiotypen, welche gemäß einer bevorzugten Ausführungsform unterstützt werden;
Figur 12 ist eine Darstellung eines Umwandlungsprozesses, um eine Umwandlung von einem Audiotyp in einen anderen gemäß einer bevorzugten Ausführungsform durchzuführen;
Figur 13 ist eine Darstellung eines Fernprozeduraufrufes gemäß einer bevorzugten Ausführungsform;
Figur 14 ist eine Darstellung einer Audioprozessorarchitektur mit einer zugeordneten Run()-Elementefunktion, welche Daten aus ihrem Eingabepuffer liest, diese verarbeitet und das Ergebnis in ihren Ausgabepuffer gemäß einer bevorzugten Ausführungsform schreibt;
Figur 15 ist eine Darstellung eines Audioprozessors gemäß einer bevorzugten Ausführungsform;
Figur 16 zeigt, wie die Verarbeitung für das in Figur dargestellte Netzwerk gemäß einer bevorzugten Ausführungsform durchgeführt wird;
Figur 17 zeigt einen Audioanschluß gemäß einer bevorzugten Ausführungsform;
Figur 18 ist eine Darstellung eines Audioprozessors, wie zum Beispiel eines Abspielgerätes, gemäß einer bevorzugten Ausführungsform;
Figur 19 ist ein Flußdiagramm der rekursiven Logik, welche mit dem Aktivieren eines Audioprozessors gemäß einer bevorzugten Ausführungsform im Zusammenhang steht;
Figur 20 ist ein Flußdiagramm, welches die detaillierte Logik zeigt, die mit dem Deaktivieren des Audioprozessors gemäß einer bevorzugten Ausführungsform im Zusammenhang steht;
Figur 21 ist ein Flußdiagramm, welches die mit dem Betrieb eines Audioprozessors im Zusammenhang stehende Logik gemäß einer bevorzugten Ausführungsform zeigt;
Figur 22 ist ein Beispiel für das Einfügen einer Videodigitalisierkomponente in eine Betrachterkomponente zur Darstellung auf einem Computerbildschirm gemäß einer bevorzugten Ausführungsform;
Figur 23 ist ein Beispiel für das Mischen von zwei Bildern aus zwei Videoobjekten in einem Effekteprozessor und das Darstellen des Ergebnisses auf einem Computerbildschirm gemäß einer bevorzugten Ausführungsform;
Figur 24 zeigt, wie graphische Anschlüsse gemäß einer bevorzugten Ausführungsform verwendet werden;
Figur 25 ist ein Flußdiagramm, welches die mit einer Write(Schreib)-Elementefunktion eines Ausgangsanschlusses im Zusammenhang stehende Logik gemäß einer bevorzugten Ausführungsform darstellt;
Figur 26 ist eine Darstellung einer Leseverarbeitung eines Eingangsanschlusses gemäß einer bevorzugten Ausführungsform;
Figur 27 zeigt die Nächste-Elementeverarbeitung eines Eingangsanschlusses gemäß einer bevorzugten Ausführungsform;
Figur 28 zeigt, wie gemäß einer bevorzugten Ausführungsform zwei Komponenten, ein MIDI-Spieler 2800 und eine MIDI-Schnittstelle 2810, verwendet werden können, um einen Musiksynthesizer zu spielen, der am Computer angeschlossen ist;
Figur 29 zeigt, wie MIDI-Daten von einem externen Musiksynthesizer gemäß einer bevorzugten Ausführungsform aufgezeichnet und abgespielt werden können;
Figur 30 zeigt, wie MIDI-Daten gemäß einer bevorzugten Ausführungsform abgespielt werden können;
Figur 31 zeigt eine Mediakomponente gemäß einer bevorzugten Ausführungsform, welche sowohl MIDI- als auch Audioanschlüsse umfaßt;
Figur 32 zeigt die detaillierten Systemmeldungen, unterteilt in Allgemein-, Echtzeit- und Exklusivmitteilungen gemäß einer bevorzugten Ausführungsform;
Figur 33 ist eine Darstellung einiger der Formate von MIDI-Mitteilungen gemäß einer bevorzugten Ausführungsform;
Figur 34 ist eine Darstellung eines MIDI-Paketobjektes, welches MIDI-Mitteilungstypen und -strukturen, ein Statusbyte und einen Zeitstempel gemäß einer bevorzugten Ausführungsform einkapselt;
Figur 35 zeigt ein Beispiel eines Fächerungsvorganges gemäß einer bevorzugten Ausführungsform;
Figur 36 ist eine Darstellung einer Write()-Elementefunktion eines MIDI-Ausgangsanschlusses gemäß einer bevorzugten Ausführungsform;
Figur 37 ist eine Darstellung einer Read()-Elementefunktion eines MIDI-Eingangsanschlusses gemäß einer bevorzugten Ausführungsform;
Figur 38 zeigt eine Mediakomponente mit einem einzigen Eingangsanschluß und zwei Ausgangsanschlüssen gemäß einer bevorzugten Ausführungsform;
Figur 39 zeigt ein Beispiel für eine Mediakomponente, welche zeitbasierte Mediasequenzen gemäß einer bevorzugten Ausführungsform abspielen kann,
Figur 40 zeigt einen Audiospieler für eine Audiokomponente zum Abspielen und Aufzeichnen von Audiodaten gemäß einer bevorzugten Ausführungsform;
Figur 41 zeigt ein Beispiel einer Lautsprecherkomponente gemäß einer bevorzugten Ausführungsform;
Figur 42 zeigt eine Mikrophonkomponente gemäß einer bevorzugten Ausführungsform;
Figur 43 zeigt ein Beispiel einer Mischerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 44 zeigt ein Beispiel einer Verteilerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 45 zeigt ein Beispiel einer Verstärkungskomponente gemäß einer bevorzugten Ausführungsform;
Figur 46 zeigt eine Echokomponente gemäß einer bevorzugten Ausführungsform;
Figur 47 zeigt eine Verzerrkomponente gemäß einer bevorzugten Ausführungsform;
Figur 48 zeigt ein Beispiel eines Audiotypumwandlers gemäß einer bevorzugten Ausführungsform;
Figur 49 zeigt einen Audio-Multiumwandler gemäß einer bevorzugten Ausführungs form;
Figur 50 zeigt eine Klangkomponente gemäß einer bevorzugten Ausführungsform;
Figur 51 zeigt die gemäß einer bevorzugten Ausführungsform in einer Klangkomponente eingebetteten Komponenten;
Figur 52 zeigt eine physikalische Lautsprecherkomponente gemäß einer bevorzugten Ausführungsform;
Figur 53 zeigt eine physikalische Mikrophonkomponente gemäß einer bevorzugten Ausführungsform;
Figur 54 zeigt eine Graphik-Spielerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 55 zeigt eine Graphik-Betrachterkomponente gemäß einer bevorzugten Ausführungsform;
Figur 56 zeigt eine Videodigitalisierkomponente gemäß einer bevorzugten Ausführungsform;
Figur 57 zeigt eine MIDI-Spielerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 58 zeigt eine MIDI-Schnittstellenkomponente gemäß einer bevorzugten Ausführungsform;
Figur 59 zeigt eine MIDI-Filterkomponente gemäß einer bevorzugten Ausführungsform;
Figur 60 zeigt eine MIDI-Zuordnerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 61 zeigt eine MIDI-Programmzuordnerkomponente gemäß einer bevorzugten Ausführungsform;
Figur 62 zeigt eine MIDI-Notenzuordnerkomponente gemäß einer bevorzugten Ausführungsform; und
Figur 63 zeigt eine MIDI-Kanalzuordnerkomponente gemäß einer bevorzugten Ausführungsform

Genaue Bebchreibung der Erfindung

Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem ausgeführt, das sich auf einem Personal-Computer, wie zum Beispiel dem IBM PS/2 oder dem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine typische Hardware-Konfiguration einer Workstation gemäß der vorliegenden Erfindung darstellt und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A- Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel Disketteneinheiten 20, am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß eines Anzeigegerätes 38 am Bus. Typischerweise befindet sich auf der Workstation ein Betriebssystems, wie zum Beispiel das Apple System/7 - Betriebssystem.
In einer bevorzugten Ausführungsform wird die Erfindung in der Programmiersprache C++ mit Hilfe von objektorientierten Programmiertechniken implementiert. Ein Fachmann wird verstehen, daß es sich bei objektorientierten Programmierobjekten (OOP-Objekte) um Softwareeinheiten handelt, welche Datenstrukturen umfassen sowie Operationen, die auf die Daten wirken. Gemeinsam werden Objekte durch die Elemente dazu befähigt, nahezu jede Echtwelteinheit bezüglich deren Eigenschaften, welche durch deren Datenelemente dargestellt werden, zu modellieren, und deren Verhalten wird durch deren Datenmanipulationsfunktionen dargestellt. Auf diese Weise können Objekte konkrete Dinge wie zum Beispiel Personen und Computer modellieren, und sie können abstrakte Konzepte, wie zum Beispiel Zahlen oder geometrische Konzepte, modellieren. Die Vorteile der Objekttechnologie ergeben sich aus drei Grundprinzipien: Einkapselung, Polymorphismus und Vererbung.
Objekte verstecken die internen Strukturen ihrer Daten und die Algorithmen, nach denen ihre Funktionen arbeiten, bzw. kapseln diese ein. Anstatt diese Implementierungsdetails offenzulegen, präsentieren Objekte Schnittstellen, welche deren Abstraktionen säuberlich ohne unwesentliche Informationen darstellen. Polymorphismus ist eine weitere Stufe der Einkapselung. Der Gedanke, der dahintersteckt, ist: viele Formen, eine Schnittstelle. Eine Softwarekomponente kann eine Anforderung an eine andere Komponente stellen, ohne genau zu wissen, worum es sich bei dieser Komponente handelt. Die Komponente, welche die Anforderung erhält, interpretiert diese und berechnet aufgrund ihrer Variablen und Daten, wie die Anforderung auszuführen sei.
Das dritte Prinzip ist die Vererbung, welche es Entwicklern ermöglicht, bereits bestehende Konstruktionen und Codes wieder zu verwenden. Durch diese Fähigkeit müssen Entwickler eine Software nicht immer von Grund auf neu erstellen. Stattdessen können Entwickler durch die Vererbung Subklassen ableiten, welche die Verhaltensweisen erben, die dann vom Entwickler den jeweiligen besonderen Anforderungen angepaßt werden.
Ein Ansatz des Standes der Technik besteht darin, Objekte und Klassenbibliotheken in einer prozeduralen Umgebung zu schichten. Viele am Markt befindliche Anwendungsrahmenwerke verwenden diesen Konstruktionsansatz. In dieser Konstruktion befinden sich ein oder mehrere Objektschichten an der Spitze eines monolithischen Betriebssystems. Wenngleich dieser Ansatz alle Prinzipien der Einkapselung, des Polymorphismus und der Vererbung in der Objektschicht verwendet und eine wesentliche Verbesserung gegenüber den prozeduralen Programmiertechniken darstellt, weist dieser Ansatz auch gewisse Einschränkungen auf. Diese Probleme ergeben sich aus der Tatsache, daß es für einen Entwickler zwar einfach ist, seine eigenen Objekte wiederzuverwenden, aber schwierig ist, Objekte aus anderen Systemen zu verwenden, und der Entwickler daher immer noch gezwungen ist, mit prozeduralen Betriebssystemaufrufen (OS- Aufrufe) in tiefere Nichtobjekt-Schichten einzugreifen.
Ein weiterer Aspekt des objektorientierten Programmierens ist ein Rahmenwerkansatz für die Anwendungsentwicklung. Eine der besten rationalen Definitionen für Rahmenwerke stammt von Ralph E. Johnson von der Universität von Illinois und Vincent F. Russo von Purdue. In ihrem 1991 veröffentlichten Papier mit dem Titel 'Reusing Object- Oriented Designs' (Wiederverwendung von obj ektorientierten Designs), Technischer Bericht UIUCDCS91-1696 von der Universität in Illinois, bieten sie folgende Definition an: "Eine abstrakte Klasse ist eine Konstruktion einer Reihe von Objekten, welche zusammenarbeiten, um eine Reihe von Pflichten auszuüben. Somit stellt ein Rahmenwerk eine Reihe von Objektklassen dar, welche zusammenarbeiten, um festgelegte Gruppen von Berechnungspflichten auszuführen." Vom Standpunkt des Programmierens her betrachtet handelt es sich bei Rahmenwerken im wesentlichen um Gruppen miteinander verbundener Objektklassen, welche eine vorgefertigte Struktur einer Arbeitsanwendung bieten. So könnte zum Beispiel ein Anwenderschnittstellenrahmenwerk die Unterstützung und das "Standard"-Verhalten zum Zeichnen von Fenstern, Rollbalken, Menüs usw. bieten. Da Rahmenwerke auf Objekttechnologie basieren, kann dieses Verhalten vererbt und außer Kraft gesetzt werden, damit Entwickler das Rahmenwerk erweitern und maßgeschneiderte Lösungen auf einem speziellen Wissensgebiet erstellen können. Dies ist ein wichtiger Vorteil gegenüber der herkömmlichen Programmierung, da der Programmierer nicht den ursprünglichen Code verändert, sondern stattdessen die Software erweitert. Darüberhinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine strukturelle Führung und Modellierung bietet, zur selben Zeit aber auch den Entwickler befreit, um dann die spezifischen Maßnahmen, die für den jeweiligen Problembereich einzigartig sind, treffen zu können.
Von einer geschäftlichen Perspektive betrachtet können Rahmenwerke als eine Möglichkeit angesehen werden, Expertenwissen in einem bestimmten Wissensbereich einzukapseln oder aufzunehmen. Firmeneigene Entwicklungsorganisationen, Unabhängige Softwareverkäufer (ISV) und Systemintegratoren haben Fachwissen in bestimmten Bereichen erworben, wie zum Beispiel bei der Herstellung, Buchhaltung oder bei Währungsumwandlungen. Dieses Fachwissen wird in ihren Code aufgenommen. Rahmenwerke ermöglichen es diesen Entwicklungsorganisationen, die allgemeinen Merkmale dieses Fachwissens durch Aufnahme in den Code der Organisation festzulegen und zu verpacken. Zum ersten erhalten Entwickler dadurch die Möglichkeit, eine Anwendung, welche das Fachwissen verwendet, zu erstellen oder zu erweitern, wodurch das Problem einmal gelöst wird und die Geschäftsregeln und die Konstruktion verstärkt und auf konsistente Weise angewendet werden. Ebenso sind Rahmenwerke und das in den Rahmenwerken steckende Fachwissen auch von strategischem Wert für jene Organisationen, die sich Fachwissen in vertikalen Märkten erarbeitet haben, wie zum Beispiel in der Fertigung, der Buchhaltung oder der Biotechnologie, und somit einen Verteilungsmechanismus für die Verpackung, den Wiederverkauf und die Ausnutzung ihres Fachwissens und den weiteren Fortschritt und die Ausbreitung der Technologie gefunden haben.
Historisch gesehen haben sich die Rahmenwerke erst in jüngster Zeit als ein Hauptströmungskonzept auf Computerplattformen entwickelt. Diese Migration wurde durch die Verfügbarkeit objektorientierter Sprachen wie zum Beispiel C++ unterstützt. Traditionellerweise wurde C++ am häufigsten auf UNIX-Systemen und den Workstations von Forschern verwendet, und kaum auf Computern in kommerziellen Umgebungen. Sprachen wie C++ und andere objektorientierte Sprachen, wie zum Beispiel Smalltalk und andere, haben einer Reihe von Universitäts- und Forschungsprojekten geholfen, die Vorläufer der heutigen kommerziellen Rahmenwerke und Klassenbibliotheken zu schaffen. Einige Beispiele dafür wären InterViews von der Stanford-Universität, der Andrew- Befehlssatz von der Carnegie-Mellon Universität und das ET++-Rahmenwerk von der Zürich-Universität.
Es gibt, je nach Niveau des Systems und der Art des Problems, viele Arten von Rahmenwerken. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken, die bei der Entwicklung von Anwenderschnittstellen helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwaredienste wie zum Beispiel Kommunikation, Drukken, Ablagesystemunterstützung, Graphik usw. bieten. Kommerzielle Beispiele von Anwendungsrahmenwerken sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NeXT), und Smalltalk-80 MVC (ParcPlace). Das Programmieren mit Rahmenwerken erfordert von den Entwicklern, die an andere Systemarten gewöhnt sind, eine neue Art des Denkens. Tatsächlich handelt es sich hierbei nicht mehr um das "Programmieren" im herkömmlichen Sinn. In älteren Betriebssystemen, wie zum Beispiel in DOS oder UNIX, schafft das eigene Programm des Entwicklers die gesamte Struktur. Das Betriebssystem bietet Dienstleistungen durch Systemaufrufe - das Programm des Entwicklers führt diese Aufrufe durch, wenn es die Dienstleistung benötigt, und die Kontrolle kehrt wieder zurück, nachdem die Dienstleistung zur Verfügung gestellt wurde. Die Programmstruktur basiert auf der Flußkontrolle, welche im Code enthalten ist, den der Entwickler schreibt.
Wenn Rahmenwerke verwendet werden, ist dies genau umgekehrt. Der Entwickler ist nicht mehr für die Flußkontrolle verantwortlich. Der Entwickler muß auf die Tendenz verzichten, die Programmieraufgaben in bezug auf den Fluß der Ausführung verstehen zu wollen. Stattdessen muß sich das Denken auf die Verantwortlichkeiten der Objekte richten, welche sich auf das Rahmenwerk verlassen müssen, um zu bestimmen, wann die Tasks ausgeführt werden sollten. Vom Entwickler geschriebene Routinen werden von einem Code aktiviert, den der Entwickler nicht geschrieben hat, und den der Entwickler niemals sieht. Dieser Flipflop-Vorgang im Kontrollfluß kann eine wesentliche psychologische Barriere für Entwickler darstellen, die nur über Erfahrungen im prozeduralen Programmieren verfügen. Wenn dies jedoch einmal begriffen wird, erfordert das Rahmenwerk-Programmieren wesentlich weniger Aufwand als andere Arten des Programmierens.
Ähnlich wie ein Anwendungsrahmenwerk dem Entwickler vorgefertigte Funktionalität bietet, übertragen Systemrahmenwerke, wie zum Beispiel jenes, das in einer bevorzugten Ausführungsform enthalten ist, dasselbe Konzept, indem sie Dienstleistungen auf Systemebene bieten, welche Entwickler, wie zum Beispiel Systemprogrammierer, verwenden, um Unterklassen zu bilden bzw. außer Kraft zu setzen, um maßgeschneiderte Lösungen zu schaffen. Man stelle sich zum Beispiel ein Multimedia-Rahmenwerk vor, welches die Grundlage für die Unterstützung von neuen und unterschiedlichen Geräten wie zum Beispiel Audio, Video, MIDI, Animationen, usw. bieten sollte. Der Entwickler, der eine neue Art von Gerät unterstützen soll, müßte einen Gerätetreiber schreiben. Um dies mit einem Rahmenwerk durchzuführen, muß der Entwickler nur die Eigenschaften und das Verhalten unterstützen, welches dem neuen Gerät eigentümlich ist.
Der Entwickler bietet in diesem Fall eine Implementierung für bestimmte Mitgliederfunktionen, die vom Multimedia-Rahmenwerk aufgerufen werden. Ein unmittelbarer Vorteil für den Entwickler ist die Tatsache, daß der generische Code, der für die einzelnen Gerätekategorien benötigt wird, bereits vom Multimedia-Rahmenwerk zur Verfügung gestellt wird. Dies bedeutet, daß der Entwickler des Gerätetreibers weniger Code schreiben, testen und weniger Fehler beseitigen muß. Ein weiteres Beispiel für die Anwendung des Systemrahmenwerkes wären getrennte E/A-Rahmenwerke für SCSI- Geräte, NuBus-Karten und graphische Geräte. Weil es in diesem Zusammenhang eine vererbte Funktionalität gibt, bietet jedes einzelne Rahmenwerk Unterstützung für allgemeine Funktionalitäten, die in seiner Gerätekategone enthalten sind. Andere Entwickler könnten dann von diesen konsistenten Schnittstellen zu allen Arten von Geräten Gebrauch machen.
Eine bevorzugte Ausführungsform übernimmt das Konzept der Rahmenwerke und wendet dieses im gesamten System an. Für den kommerziellen oder firmeninternen Entwickler, den Systemintegrator oder OEM bedeutet dies, daß all die Vorteile, die für ein Rahmenwerk wie zum Beispiel MacApp dargestellt wurden, nicht nur auf die Anwendungsebene für solche Dinge wie Text und Anwenderschnittstellen übertragen werden können, sondern auch auf die Systemebene, für Dienstleistungen wie zum Beispiel Graphiken, Multimedia, Dateisysteme, E/A, Testdurchführung, usw.
Die Anwendungserstellung in der Architektur einer bevorzugten Ausführungsform ist im wesentlichen gleich wie das Schreiben bereichsspezifischer Puzzleteilchen, die dem Rahmenwerkprotokoll unterstellt sind. Auf diese Weise ändert sich das gesamte Konzept des Programmierens. Anstelle des Schreibens einer Codezeile nach der anderen, welche mehrfache API-Hierarchien aufrufen, wird Software nunmehr entwickelt, indem Klassen von bereits bestehenden Rahmenwerken innerhalb dieser Umgebung abgeleitet werden, und indem danach je nach Bedarf neues Verhalten hinzugefügt und/oder vererbtes Verhalten außer Kraft gesetzt wird.
Somit wird die Anwendung des Entwicklers zu einer Sammlung von Code, der geschrieben und von allen anderen Rahmenwerkanwendungen gleichermaßen benutzt wird. Dies stellt ein sehr mächtiges Konzept dar, weil Entwickler dadurch in der Lage sind, auf der Arbeit anderer aufzubauen. Dies gibt dem Entwickler auch die Flexibilität, ein Programm je nach Bedarf mehr oder weniger maßzuschneidern. Manche Rahmenwerke werden genau so verwendet werden, wie sie sind. In manchen Fällen wird das Ausmaß der maßgeschneiderten Anpassung minimal sein, so daß das Puzzleteilchen, das der Entwickler einfügt, ein kleines ist. In anderen Fällen kann der Entwickler sehr großzügige Veränderungen durchführen und etwas völlig Neues schaffen.
In einer bevorzugten Ausführungsform, wie sie zum Beispiel in Figur 1 dargestellt ist, verwaltet ein Multimedia- Datenübertragungssystem den Weg von Multimedia-Informationen durch das Computersystem hindurch, während mehrere Media-Komponenten, die sich im RAM 14 und unter der Kontrolle der CPU 10 befinden oder extern über den Bus 12 oder den Kommunikationsadapter 34 angeschlossen sind, für die Darstellung der Multimedia-Informationen verantwortlich sind. Zum Koordinieren oder Verwalten der gesamten Verarbeitung des Systems ist kein zentraler Spieler verantwortlich. Diese Architektur bietet Flexibilität ermöglicht eine erhöhte Erweiterbarkeit, wenn neue Media-Typen hinzugefügt werden. Das System verwendet eine Vielzahl an Multimedia- Objekten, von denen einige als Verbindungsobjekte verwendet werden können. Die Verbindungsobjekte umfassen Verstärkung, Filter, Verstärker, Mischer, Spieler und andere Multimedia- Komponenten, die individuell als Objekte in einem objektorientierten Betriebssystem implementiert werden. Objekte, wie sie oben diskutiert wurden, umfassen eine Code- oder Verfahrenskomponente und eine Datenkomponente. Das System umfaßt eine Maus zur Durchführung von Iconoperationen wie zum Beispiel Ziehen&Fallenlassen (Drag&Drop), Doppelklikken, Starten durch Fallenlassen, Cursorpositionierung und andere typische Operationen.
In Video- und Audioproduktionsstudios verwenden Medien wie zum Beispiel Klang, MIDI und Video physikalische Steckschnüre, um Signale zwischen Quellen, Effektprozessoren und Empfängern zu übertragen. Signalverarbeitungsalgorithmen werden auch oft als Netzwerke von Quellen, Empfängern und Prozessoren dargestellt. Beide diese Modelle können als gerichtete Objektgraphen dargestellt werden, die miteinander verbunden sind. Eine bevorzugte Ausführungsform macht es möglich, daß dieses Modell - die Verknüpfung von Objekten - auf einem Computersystem realisiert wird. Figur 2 zeigt ein einfaches Heimstudio des Standes der Technik mit einem Kassettenlaufwerk, einem Mischer, einer Halleinheit, einem Paar Mikrophonen und einem Paar Lautsprechern. Da die Mikrophone am Kassettenlaufwerk angeschlossen sind, wird die Klangeingabe vom Mikrophon zum Kassettenlaufwerk übertragen, wo sie aufgezeichnet werden kann. Wenn das Kassettenlaufwerk die Aufzeichnung abspielt, wird das Signal aufgrund der Verbindung vom Kassettenlaufwerk mit dem Mischer zum Mischer übertragen. Auf ähnliche Weise sind die Halleinheit und die Lautsprecher an einem Verstärker angeschlossen, der am Mischer angeschlossen ist.
Eine bevorzugte Ausführungsform verwendet objektorientierte Technologie zur Darstellung eines Verbindungsmodells. Multimedia-Objekte können miteinander verbunden werden und somit gerichtete Datenflußgraphen erstellen. Darüberhinaus wird im System ein Standardsatz an Multimedia-Objekten definiert. Diese Objekte können miteinander verbunden werden, um einen Multimedia-Datenfluß von Objekt zu Objekt zu ermöglichen. Die Verbindungsoperationen können durch das Verbinden von Multimedia-Objekten über eine geometrische Figur, wie zum Beispiel eine Linie, ein Liniensegment oder eine andere geeignete Geometrie erfolgen. Die unten diskutierten Figuren zeigen Beispiele verschiedener Multimedia-Objekte, einschließlich Verbindungsobjekte und geometrische Figuren, die verwendet werden, um die internen Datenstrukturen und die Logikverbindung der Multimedia-Objekte zu beschreiben.

Klassen für die Übertragung

Eine Basisklasse einer zeitbasierten Mediakomponente (im folgenden als eine Mediakomponente bezeichnet) ist eine zentrale Abstraktion, welche für die Übertragung verwendet wird. Eine Mediakomponente verfügt über null oder mehrere Eingangsanschlüsse und null oder mehrere Ausgangsanschlüsse. In Figur 3 verfügt die Mediakomponente zum Beispiel über einen einzigen Eingangsanschluß 300 und zwei Ausgangsanschlüsse 310 und 320. Die Anschlüsse 300, 310 und 320 werden als gefüllte Dreiecke dargestellt.
Subklassen von Mediakomponenten werden durch Verbindung ihrer Anschlüsse miteinander verbunden. Diese Verarbeitung ist analog zur Verwendung von Steckschnüren zum Verbinden von Audio- und Videokomponenten in einem Aufnahmestudio. In Figur 4 wird eine Subklasse einer Mediakomponente, nämlich ein Audiospielerkomponentenobjekt, an eine andere Mediakomponentensubklasse, nämlich ein Lautsprecherkomponentenobjekt, angeschlossen. Der Audiospieler verfügt über einen Ausgangsanschluß, und der Lautsprecher besitzt einen Eingangsanschluß Mediakomponenten werden mit Hilfe von Elementenfunktionsaufrufen gesteuert. Der Audiospieler in Figur 4 zum Beispiel verfügt über Elementefunktionen zum Abspielen von Audiodaten. Wenn die Elementefunktion Play() des Audiospielers aufgerufen wird, werden Audiodaten vom Audiospieler zum Lautsprecher zugeführt, der dafür sorgt, daß die Audioinformationen am Lautsprecher des Computers hörbar werden. Die Lautsprecherkomponente verfügt über keine Play()-Funktion, weil sie alles das abspielt, was ihr an Audiodaten übertragen wird. Mediakomponenten können vollständig in Software implementiert werden. Es ist jedoch fur eine Mediakomponente möglich, ein Stück physikalische Hardware zu repräsentieren. Zum Beispiel kann ein Lautsprecherobjekt dazu verwendet werden, die Abspielhardware eines Computers zu repräsentieren. Auf diese Weise können externe Mediageräte, wie zum Beispiel Videorecorder, Mischer und Effektprozessoren als Mediakomponenten repräsentiert und miteinander verbunden werden.

Anschließen von Mediakomponenten

Mediakomponenten werden durch Verbinden ihrer Anschlüsse miteinander verbunden. Um zu verhindern, daß Klientenobjekte und Komponenten Daten gleichzeitig an den selben Anschluß schreiben, was zu einer Beeinträchtigung der Datenintegrität führen wurde, dürfen Klienten nicht direkt auf die Anschlüsse zugreifen. Stattdessen führen Klienten Verbindungsoperationen an mehrpfadsicheren Aliasobjekten aus. In dieser Beschreibung bezeichnet der Begriff "Alias" eine spezialisierte Darstellung einer darunterliegenden Klasse, welche es ermöglicht, daß mehrere Klienten Beispiele der Klasse auf sichere Weise gemeinsam verwenden. Im Falle der Mediakomponenten ermöglichen Aliasanschlüsse eine begrenzte, indirekte Manipulation der aktuellen Anschlüsse. Jede Mediakomponente verfügt über Elementefunktionen, welche Aliasse für jeden ihrer Eingangs- und Ausgangsanschlüsse erzeugen. Diese Anschlußaliasse sind extrem leichte Objekte und sehr gut dazu geeignet, Adreßgrenzen zu überqueren, um somit eine Verbindung der Mediakomponenten zu erreichen, welche sich in unterschiedlichen Adreßräumen befinden.
Jedem Anschluß und jedem Anschlußalias ist ein Datentyp zugeordnet. Beispiele für diese Daten sind MIDI-Daten, 44 kHz 16 bit Audiodaten, 22 kHz 8 bit Audiodaten und graphische Daten für Video. Wenn zwei Anschlüsse aufgefordert werden, sich miteinander zu verbinden, stellt ein Typenverhandlungsprotokoll sicher, daß die Anschlüsse in der Lage sind, kompatible Datentypen zu unterstützen. Eine Ausnahme wird ausgegeben, wenn die Anschlüsse über keine gemeinsamen Typen verfügen.
Umwandlerobjekte können zwischen Objekte eingefügt werden, die über nicht kompatible Anschlußtypen verfügen. Bei Umwandlern handelt es sich um Komponenten, welche Daten eins Typs aufnehmen, um Daten eines unterschiedlichen Typs zu produzieren. Beispiele für Eingangs- und Ausgangsfächerungsanschlüsse werden in Figur 5 dargestellt. Spezifische Subklassen können die Entscheidung treffen, eine Eingangsfächerung und/oder Ausgangsfächerung zu untersagen. Audioanschlüsse zum Beispiel untersagen beides, und bei einem Versuch, einen Anschluß mit mehr als einem anderen Anschluß zu verbinden, wird eine Ausnahme ausgegeben. Eingangs- und Ausgangsfächerungseigentümer werden von den spezifischen Media-Subklassen verwaltet. Beim MIDI sendet die Ausgangsfächerung zum Beispiel dieselben Daten an mehrere Empfänger, und die Eingangsfächerung mischt Daten von mehreren Empfängern.
Zwei Mediakomponenten, A und B, werden miteinander verbunden durch:
1) Aufruf einer Elementefunktion von A zur Anforderung eines Ausgangsanschlußaliasses, Pa;
2) Aufruf einer Elementefunktion von B, um nach der von B zu fragen, um einen Eingangsanschlußalias, Pb, anzufordern;
3) Aufruf der Elementefunktion von Pa, ConnectTo, und Weiterleitung nach Pb als Argument.
Die Anschlüsse können durch Aufruf der Elementefunktion DisconnectFrom von Pa und durch Weiterleitung nach Pb als Argument voneinander getrennt werden. Die oben genannten Prozeduren werden aufgerufen, wenn beliebige Mediakomponenten miteinander verbunden oder voneinander getrennt werden, gleichgültig, ob es sich bei dem Anschluß um Audio, Graphik, MIDI oder irgend einen anderen Multimedia-Datentyp handelt. Wenn zwei Anschlüsse miteinander verbunden werden, wird keine Überprüfung der Kompilierungszeit durchgeführt. So gibt es zum Beispiel nichts, was einen Softwareentwickler davon abhält, einen Code zu schreiben, zu kompilieren und zu verknüpfen, der versucht, einen Audioanschluß mit einem MIDI-Anschluß zu verbinden. Stattdessen wird eine Ausnahme während der Laufzeit ausgegeben. Dieses Verhalten wurde explizit in das Übertragungssystem eingebaut, um eine polymorphe Verbindung von Mediaanschlüssen zu ermöglichen. Ein Einfügemodul könnte zum Beispiel Mediaanschlußpaare zu bestimmten Zeiten miteinander verbinden, ohne den unterschiedlichen Anschlußtypen eine besondere Behandlung zukommen lassen zu müssen. Audio-, Video- und MIDI-Anschlüsse würden dann auf exakt die selbe Art und Weise von einem Einfüger behandelt werden. Die Verbindung von Objekten kann auf visuelle Weise durch das Zeichnen eines Liniensegmentes zwischen Indizes repräsentiert werden, welche Multimedia- Objekte, wie zum Beispiel ein Icon, an der Anzeigevorrichtung darstellen.

Übertragung von Audiodaten

Audio kann auf einem Computer- digitalisiert, gespeichert, verarbeitet und abgespielt werden. Ein Computer kann auch dazu verwendet werden, Audioinformationen zu synthetisieren und abzuspielen. Ein Analog-Digital-Umwandler (ADC) wird verwendet, um ein analoges, elektrisches Audiosignal in eine Reihe von Zahlen umzuwandeln, die als digitale Audiomuster bezeichnet werden. Die Audiomformationen werden typischerweise mit einer Geschwindigkeit von 8000 Abtastungen pro Sekunde für Telephonqualität bis zu 44100 Abtastungen pro Sekunde für Compact Disc-Qualität (CD- Qualität) und 48000 Abtastungen pro Sekunde für Digital Audio Tape (DAT) abgetastet. Wenn sie einmal in numerischer Form vorhanden sind, können die Audiomformationen vom Computer gespeichert und verarbeitet werden. Die digitalen Audioabtastungen werden von einem Digital-Analog-Umwandler (DAC) wieder in analoge elektrische Audiosignale zurückverwandelt. Eine bevorzugte Ausführungsform definiert Subklassen von Anschlußobjekten, die als Audioanschlüsse bezeichnet werden, welche dazu verwendet werden, um digitale Audiodaten zwischen Mediakomponenten zu übertragen. Audioausgangsanschlüsse können mit Audioeingangsanschlüssen verbunden werden, um Audiodaten zu übertragen. Wenn eine Mediakomponente über mindestens einen Audioanschluß verfügt, wird sie als Audiokomponente bezeichnet. Alle Audiokomponenten sind Subklassen von Mediakomponenten-Basisklassen. Eine Audiokomponente verfügt über null oder mehrere Audioeingangsanschlüsse und null oder mehrere Audioausgangsanschlüsse, wie dies in Figur 6 dargestellt ist. Audiokomponenten können durch Verbinden ihrer Anschlüsse miteinander verbunden werden. Dies ist analog zur Verwendung von Steckschnüren zum Verbinden von Stereokomponenten miteinander unter Verwendung von Hardware.
Eine bevorzugte Ausführungsform ermöglicht die Verbindung von Audiokomponenten zur Erstellung einer Vielzahl an interessanten Anwendungen. Figur 7, 8, 9 und 10 zeigen einige Beispielanwendungen, die mit Hilfe von Audiokomponenten konstruiert werden können. Figur 7 zeigt, wie eine Stimmaufzeichnungsanwendung mit Hilfe eines Audiospielers zum Aufzeichnen und Abspielen von Sprachaufzeichnungen geschrieben werden kann. Ein Telephonapparat wird für die Eingabe und die Ausgabe verwendet. Figur 8 zeigt, wie eine Voice Mail/Telefonanrufbeantworteranwendung konstruiert werden kann. Ein Audiospieler spielt eine Begrüßung über die Telefonleitung ab, während ein anderer Audiospieler eine einlangende Mitteilung aufzeichnet. Figur 9 zeigt eine Musikanwendung. Echo, ein Spezialeffekt, wird dem Klang eines Musikinstrumentes hinzugefügt und durch einen Lautsprecher abgespielt. Figur 10 zeigt, wie drei Klänge, einer für Musik, einer für Klangeffekte und einer für Sprachaufzeichnung, miteinander gemischt und einem Ausgabegerät, wie zum Beispiel einem Lautsprecher, zugeführt werden können.
Wie alle Mediakomponenten werden Audiokomponenten durch Verbinden ihrer Anschlüsse miteinander verbunden. Dieser Vorgang wird ausgeführt, indem ein Audiokomponentenanschluß ausgewählt wird, eine geometrische Figur, wie zum Beispiel eine Linie, vom Komponentenanschluß zum Anschluß einer anderen Multimedia-Komponente verlängert wird, und eine Datenstruktur erzeugt wird, welche die graphisch an der Anzeigevorrichtung dargestellte Verknüpfung im Gedächtnis behält. Jede Audiokomponente verfügt über Elementefunktionen, welche Aliasse für ihre Eingangs- und Ausgangsanschlüsse erzeugen. Klienten führen Verbindungsoperationen durch, indem sie Eingabe- und/oder Ausgabeanschlußaliasse von den einzelnen Komponenten anfordern und danach die von den Aliasobjekten zur Verfügung gestellten Elementefunktionen nutzen, um die aktuellen Eingabeanschlüsse mit den aktuellen Ausgabeanschlüssen zu verbinden. Jedem Audioanschluß und jedem Anschlußalias ist ein Audiotyp zugeordnet. Figur 11 führt einige der Audiotypen an, die von einer bevorzugten Ausführungsform unterstützt werden.
Eine Verbindung, die vom Verknüpfungsliniensegment an der Anzeigevorrichtung repräsentiert wird, stellt einen einzelnen Audiokanal dar. Stereo wird von zwei Verbindungen ermöglicht, wobei eine für den linken Kanal und eine für den rechten Kanal zur Verfügung steht. Wenn zwei Anschlüsse aufgefordert werden, sich miteinander zu verbinden, stellt ein Typverhandlungsprotokoll sicher, daß die Anschlüsse in der Lage sind, kompatible Datentypen zu unterstützen. Eine Ausnahme wird ausgegeben, wenn die Anschlüsse über keine gemeinsamen Typen verfügen. Wenn dies geschieht, kann ein Audiotypenumwandler zwischen die zwei Anschlüsse eingefügt werden, um die Daten von einem Typ in einen anderen umzuwandeln, wie dies in Figur 12 dargestellt ist. In einem Netzwerk von Audiokomponenten sind keine Schleifen (Zyklen) erlaubt. Jeder Versuch, eine Verbindung herzustellen, welche zu einer Schleife führen würde, verursacht die Ausgabe einer Ausnahme. Der Vorgang des Verbindens von Audiokomponenten wird an der Anzeigevorrichtung graphisch durch das Verlängern einer geometrischen Figur, wie zum Beispiel eines Liniensegmentes, zwischen Icons, wie zum Beispiel Figuren, dargestellt, welche die Audioeingabe- und -ausgabeanschlüsse von Indizes repräsentieren, die Multimedia-Objekte darstellen.

Implementierung von Audiokomponenten

Eine Architektur auf Chent-Server-Basis wird zur Implementierung von Audiokomponenten verwendet. Für jede Audiokomponente gibt es ein Audioprozessorobjekt, welches sich in einem Task befindet, der als Sound-Server bezeichnet wird. Das Audioprozessorobjekt ist für die Durchführung der eigentlichen Signalverarbeitung verantwortlich. Audiokomponenten-Subklassenersteller müssen sowohl eine Audiokomponente als auch eine Audioprozessorsubklasse schreiben. Ein Client-/Serveransatz wird verwendet, um die Leistung zu verbessern. Die nach Art einer Steckschnur erfolgende Übertragung von Audiodaten wird am effizientesten implementiert, wenn alle Datenbewegungen und Signalverarbeitungsvorgänge in einem einzigen Task ausgeführt werden. Dies verhindert unnotwendige Zwischenrechnerkommunikationsschaltungen (IPC - Interprocess Communication) und Kontextschaltungen. Ausgehend von der Annahme, daß Klienten in vielen unterschiedlichen Tasks vorhanden sind, muß ein Sound- Server die Verarbeitung in einem einzigen Task konzentrieren.
Es wurde auch eine alternative Implementierung erforscht, welche die Signalverarbeitung jeweils in einem getrennten Task pro Audiokomponente durchführt. Es wird hierbei kein Server für die Audioverarbeitung benötigt. Dies ist eine elegante Alternative mit vielen Vorteilen, aber leider weist sie auch einen Nachteil auf - sie ist mehr als eine Größenordnung langsamer als die in einer bevorzugten Ausführungsform der Erfindung dargestellte Methode. Bei Monoprozessoren würde dieses Verhältnis ziemlich konstant bleiben, selbst wenn Geräte mit erhöhter Verarbeitungsleistung gebaut würden.

Client- /Servermodell

Audiokomponenten erfordern Einrichtungen für die Kommunikation mit ihren entsprechenden Audioprozessoren. Eine Fernprozeduraufrufschnittstelle (RPC - remote procedure call) wird für diesen Zweck verwendet. Im allgemeinen rufen Elementefunktionen einer Audiokomponentensubklasse dezentral die "wirkliche" Elementefunktion am Audioprozessor auf. Figur 13 ist ein Blockdiagramm, welches einen Fernprozeduraufruf gemäß einer bevorzugten Ausführungsform der Erfindung darstellt.

Herstellen von Verbindungen

Im Gegensatz zu Audiokomponenten besitzen Audioprozessoren die Audioanschlüsse. Audiokomponenten besitzen die Audioanschlußaliasse. Wenn zwei Anschlußaliasse im Klientenadreßraum miteinander verbunden werden, werden die entsprechenden Audioanschlüsse im Sound-Serveradreßraum miteinander verbunden. Subklassenersteller werden nicht benötigt, um eine unterstützende Maßnahme auszuführen, sondem das Rahmenwerk führt dies für sie aus.

Verarbeitung von Audiomformationen

Verbindungen zwischen Audioanschlüssen werden mit Hilfe von Puffern von Audiodaten implementiert. Jeder Verbindung oder "Steckschnur" ist ein Puffer zugeordnet. Der Audioprozessor kann jeden seiner Audioanschlüsse nach der Adresse und der Größe dieses Puffers fragen. Figur 14 ist ein Blockdiagramm, welches eine Audioprozessorarchitektur mit einer zugeordneten Run()-Elementefunktion zeigt, welche Daten aus ihren Eingabepuffern ausliest und das Ergebnis in ihre Ausgabepuffer schreibt. Die Größe der Puffer ist veränderlich, aber die bevorzugte Größe liegt bei 5 Millisekunden für die Abtastung. Diese Größe ist erforderlich, um Klänge mit einer Latenz von maximal 10 ms starten und stoppen zu können.

Rahmenbasierte Verarbeitung

Der Sound-Server verwendet eine Technik, die als rahmenbasierte Verarbeitung bezeichnet wird, um die Klangabtastungen zu verarbeiten. Der grundlegende Vorgang wird unten dargestellt.
1) Reihe die Audioprozessoren, so daß Erzeuger vor Konsumenten kommen.
2) Rufe für jeden Audioprozessor seine Run()-Elementefunktion auf. Wiederhole diesen Schritt, sooft ein E/A-Gerät Daten benötigt.
Dies ist ein extrem effizienter Weg, um Audiodaten zu bearbeiten, denn wenn einmal die Laufreihenfolge festgelegt wurde, können Rahmen auf einfache Weise durch Aufruf von Run() produziert werden. Die Implementierung von Run() kann auf sehr effiziente Weise erfolgen, weil es Puffer mit festgelegter Größe verwendet, die in einem einzigen Rahmen vollständig verarbeitet werden können. Man betrachte in diesem Zusammenhang zum Beispiel Figur 15, welche ein Netzwerk an Audioprozessoren darstellt. Jeder einzelne Audioprozessor, oder Knoten, ist mit einem Buchstaben gekennzeichnet. Zur Erzeugung von Klängen führt der Sound- Server folgende Schritte durch:
1) Reihe die Audioprozessoren, so daß Erzeuger vor Konsumenten kommen; und
2) Führe sie aus, sooft ein Audio-E/A-Gerät, wie zum Beispiel der Lautsprecher, weitere Daten benötigt.
Figur 16 zeigt, wie diese Verarbeitung für das in Figur 15 dargestellte Netzwerk ausgeführt wird. Im ersten Block werden die Audioprozessoren gereiht, danach werden die Prozessoren in der festgelegten Reihenfolge ausgeführt. Parallel dazu werden Informationen für jeden einzelnen Prozessor erhalten. Kein Prozessor wird vor seiner Zeit ausgeführt; in anderen Worten geht der Prozessor solange in einen Wartezustand, bis die entsprechenden Informationen für den Prozessor verfügbar sind.

Reihung von Audioprozessoren

Audioprozessoren werden mit einem Verfahren gereiht, das als simulierter Datenfluß bezeichnet wird. Die meisten Subklassenersteller müssen sich nicht um die Festlegung einer Reihenfolge kümmern, weil die Reihenfolge in den meisten Fällen automatisch von einem Rahmenwerk festgelegt wird. Der simulierte Datenfluß durchläuft zyklisch das Netzwerk in topologischer Reihenfolge, so als ob Daten von einem Prozessor zum nächsten weitergegeben würden. Dies geschieht, um zu sehen, welcher Audioprozessor laufen kann und welcher Audioprozessor nicht laufen kann. Audioprozessoren, die laufen, werden auf die Laufliste gesetzt und während der Laufphase wiederholt verwendet.
Ein Audioprozessorknoten kann laufen, wenn:
#1: an seinen Eingangsanschlüssen Daten zur Verfügung stehen, UND
#2: an seinen Ausgangsanschlüssen freie Plätze zur Verfügung stehen, um die Daten dorthin zu geben.
Jeder Audioprozessor verfügt über eine CanRun()-Elementefunktion, welche WAHR zurückgibt, wenn der Knoten laufen kann. Die Standardimplementierung von CanRun() verwendet die oben angeführten Regeln, so daß ein Subklassenersteller nur CanRun() überschreiben muß, wenn der Audioprozessor eine Regel überschreiben muß. Wenn ein Audioprozessor laufen kann, simuliert er den Fluß der Daten aus allen Ausgangsanschlüssen heraus. Fire() dreht sich eigentlich nur um und ruft eine andere Fire()-Elementefunktion an jedem einzelnen Ausgangsanschluß auf. Das Abfeuern eines Ausgangsanschlusses simuliert den Datenfluß aus dem Anschluß, wodurch die simulierten Daten am Eingangsanschluß an der anderen Seite verfügbar gemacht werden. Die Eingangsanschlüsse verfügen über eine IsAvailable()-Elementefunktion, welche WAHR zurückgibt, wenn am Anschluß simulierte Daten zur Verfügung stehen. Figur 17 zeigt einen Audioanschluß gemäß einer bevorzugten Ausführungsform.
Verzögerungen müssen Priorität gegenüber CanRun() haben, weil der Eingang in eine Verzögerung schweigend vor sich geht. Daher muß die Verzögerung immer noch eine Ausgabe erzeugen, bis die Verzögerung ausgelaufen ist. Der Eingangsanschluß hat keine Daten mehr zur Verfügung, aber der Audioprozessor muß noch immer laufen. CanRun() muß entsprechend modifiziert werden, um WAHR zurückzugeben, wenn kein Eingang verfügbar ist und immer noch Daten in der Verzögerung stehen, die ausgegeben werden müssen. Spieler müssen ebenfalls CanRun() übersteuern, denn wenn ein Spieler gestoppt wird, kann ein Spieler nicht laufen, selbst wenn die Datenflußkriterien erfüllt werden. Spieler müssen die Regeln modifizieren, so daß CanRun() immer FALSCH zurückgibt, wenn der Spieler gestoppt wird, und zwar unabhängig davon, ob die Datenflußkriterien erfüllt werden oder nicht. Ein Audioprozessor kann seinen Audioausgangsanschluß bezüglich der Verzögerung zwischen dem Schreiben der Daten in den Puffer des Anschlusses bis zum Zeitpunkt, an dem der Anwender die Audioinformationen tatsächlich hört, abfragen. Dadurch sind Audioprozessoren in der Lage, sich auf willkürliche Zeitbasen zu synchronisieren. Figur 18, 19 und 20 sind Flußdiagramme, welche die mit Audioprozessoren zusammenhängende Logik zeigen. Ein Audioprozessor, wie zum Beispiel ein Spieler, bestimmt, daß eine Ausführung erforderlich ist, und ruft RequestOrder auf, welche in Figur 18 dargestellt ist.
Figur 18 ist ein Flußdiagramm, welches die detaillierte Logik zum Aufruf einer Reihungsanforderung gemäß einer bevorzugten Ausführungsform darstellt. Die Verarbeitung beginnt am Punkt 1800 und geht sofort weiter zum Funktionsblock 1810, um die Laufliste als ungültig zu kennzeichnen. Die Laufliste kann als ungültig gekennzeichnet werden, indem ein Multimedia-Objekt durch Fallenlassen gestartet wird, indem auf ein Multimedia-Objekt doppelgeklickt wird oder indem irgendeine andere Iconoperation verwendet wird, um den Beginn einer Operation mitzuteilen. Danach wird am Entscheidungsblock 1820 ein Test durchgeführt, um zu bestimmen, ob der Audioprozessor laufen kann. Wenn dies der Fall ist, wird am Funktionsblock 1830 der Audioprozessor deaktiviert, und die Kontrolle wird zum Punkt 1850 weitergeleitet. Wenn der Audioprozessor jedoch nicht laufen kann, wird der Audioprozessor im Funktionsblock 1840 aktiviert, und die Kontrolle wird zum Punkt 1850 weitergeleitet.
Figur 19 ist ein Flußdiagramm der rekursiven Logik, welche mit dem Aktivieren eines Audioprozessors gemäß einer bevorzugten Ausführungsform im Zusammenhang steht. Die Verarbeitung beginnt am Punkt 1900, wo die Kontrolle vom Funktionsblock 1840 weitergeleitet wird oder ein rekursiver Aufruf vom Punkt 1990 ausgeführt wird. In beiden Fällen wird die Kontrolle sofort zum Funktionsblock 1910 weitergeleitet, wo der Index i gleich Null gesetzt wird und der Zähler N gleich der Anzahl der Audioprozessorausgangsanschlüsse gesetzt wird. Danach wird am Entscheidungsblock 1920 ein Test durchgeführt, um zu bestimmen, ob der Zähler i = N ist. Wenn dies der Fall ist, wird die Kontrolle zum Punkt 1930 zurückgegeben. Wenn dies nicht der Fall ist, wird der Ausgangsanschluß i am Funktionsblock 1940 abgefeuert, der Ausgangsanschluß wird am Funktionsblock 1950 als abgefeuert gekennzeichnet, der mit dem Ausgangsanschluß verbundene Audioprozessor wird am Funktionsblock 1960 erhalten, der Zähler i wird am Funktionsblock 1970 hochgezählt, und ein Test wird am Entscheidungsblock 1980 durchgeführt, um zu bestimmen, ob der Audioprozessor laufen kann. Wenn der Audioprozessor laufen kann, wird über den Punkt 1900 ein rekursiver Aufruf an die Logik in Figur 19 ausgegeben. Wenn nicht, wird die Kontrolle zum Entscheidungsblock 1920 weitergegeben, um mit der Verarbeitung fortzufahren.
Figur 20 ist ein Flußdiagramm, welches die mit dem Deaktivieren des Audioprozessors im Zusammenhang stehende detaillierte Logik zeigt. Die Verarbeitung beginnt am Punkt 2000, von wo die Kontrolle zum Funktionsblock 1830 weitergegeben wird, oder es wird ein rekursiver Aufruf vom Punkt 2018 oder 2080 durchgeführt. In beiden Fällen wird die Kontrolle sofort zum Funktionsblock 2004 weitergeleitet, wo der Index i gleich Null gesetzt wird, und der Zähler N gleich der Anzahl der Audioprozessor-Ausgangsanschlüsse gesetzt wird. Danach wird ein Test am Entscheidungsblock 1920 durchgeführt, um zu bestimmen, ob der Zähler i = N ist. Wenn dies der Fall ist, wird die Kontrolle zum Funktionsblock 2020 weitergeleitet, um den Index und den Zähler erneut zu initialisieren. Danach wird am Entscheidungsblock 2024 ein Test durchgeführt, um zu bestimmen, ob i = N ist. Wenn dies nicht der Fall ist, wird der Eingangsanschluß i so gekennzeichnet, daß er am Funktionsblock 2040 nicht abgefeuert hat, der mit dem Eingangsanschluß verbundene Audioprozessor wird am Funktionsblock 2050 erhalten, der Zähler wird am Funktionsblock 2060 hochgezählt, und ein Test wird am Entscheidungsblock 2070 durchgeführt, um zu bestimmen, ob der Audioprozessor laufen kann. Wenn dies der Fall ist, wird die Kontrolle am Punkt 2024 zurückgegeben. Wenn der Audioprozessor nicht laufen kann, wird über den Punkt 2080 ein rekursiver Aufruf an die Logik in Figur 20 ausgeführt. Wenn der Audioprozessor laufen kann, wird die Kontrolle zum Entscheidungsblock 2024 weitergegeben, um den Index erneut zu überprüfen.
Wenn der Index i am Entscheidungsblock 2006 nicht gleich N ist, wird der Ausgangsanschluß i so gekennzeichnet, daß er NICHT am Funktionsblock 2008 abgefeuert hat, der mit dem Ausgangsanschluß verbundene Audioprozessor wird am Funktionsblock 2010 erhalten, der Zähler i wird am Funktionsblock 2012 hochgezählt, und ein Test wird am Entscheidungsblock 2014 durchgeführt, um zu bestimmen, ob der Audioprozessor laufen kann. Wenn der Audioprozessor nicht laufen kann, wird über den Punkt 2018 ein rekursiver Aufruf an die Logik in Figur 20 ausgegeben. Wenn nicht, wird die Kontrolle zum Entscheidungsblock 2006 weitergeleitet, um den Index wiederum zu überprüfen und mit der Bearbeitung fortzufahren.
Figur 21 ist ein Flußdiagramm, welches die mit der Ausführung eines Audioprozessors gemäß einer bevorzugten Ausführungsform im Zusammenhang stehende Logik darstellt. Die Verarbeitung beginnt am Punkt 2100 und wird sofort zum Entscheidungsblock 2104 weitergegeben, um zu bestimmen, ob die Laufliste gültig ist. Wenn die Laufliste nicht gültig ist, wird eine topologische Reihung im Funktionsblock 2106 durchgeführt, um die Audioprozessoren in abgefeuerter Reihenfolge zu sortieren. Danach wird im Funktionsblock 2110 die gereihte Liste als gültig gekennzeichnet, und die Kontrolle geht zum Funktionsblock 2120 weiter. Wenn die Laufliste am Entscheidungsblock 2104 nicht gültig war, geht die Kontrolle zum Funktionsblock 2120 weiter, um den Index i zurückzusetzen und den Zähler N zu initialisieren. Danach wird am Entscheidungsblock 2122 ein Test durchgeführt, um zu bestimmen, ob der Zähler i den Wert N erreicht hat. Wenn dies der Fall ist, wird die Bearbeitung abgeschlossen, und die Kontrolle geht zum Punkt 2130 weiter. Wenn dies nicht der Fall ist, wird der Audioprozessor i wie im Funktionsblock 2124 dargestellt ausgeführt, und der Index i wird wie im Funktionsblock 2126 dargestellt hochgezählt

Übertragen von Video- und Graphikdaten

Videoinformationen können von einem Computer digitalisiert, gespeichert, verarbeitet und abgespielt werden. Ein Videodigitalisierer wird verwendet, um ein analoges elektrisches Videosignal in eine Reihe digitaler Bilder umzuwandeln, was als Rahmen bezeichnet wird. Die Anzahl der pro Sekunde digitalisierten Rahmen wird als Rahmengeschwindigkeit bezeichnet. Fünfzehn bis dreißig Rahmen pro Sekunde sind typische Rahmengeschwindigkeiten. Wenn die Videoinformationen einmal in digitaler Form vorliegen, können sie vom Computer gespeichert und verarbeitet werden. Das Video kann abgespielt werden, indem die digitalen Bilder der Reihe nach mit der ursprünglichen Rahmengeschwindigkeit auf einem Computerbildschirm dargestellt werden.
Bei einem Graphikobjekt handelt es sich um eine Basisklasse, die verwendet wird, um ein beliebiges Objekt zu repräsentieren, welches auf einem Computerbildschirm dargestellt werden kann. Unterklassen von Graphikobjekten umfassen unter anderem Polygone, Kurven und digitale Bilder. Jeder Rahmen eines digitalisierten Videos ist ein digitales Bild und kann somit von einem Graphikobjekt dargestellt werden.
Graphische Eingangs- und Ausgangsanschlüsse werden verwendet, um graphische Objekte von einer Mediakomponente zu einer anderen zu übertragen. Ein digitales Video kann auf diese Weise übertragen werden, da es sich bei jedem Videorahmen um ein graphisches Objekt handelt. Animationsdaten können auch mit graphischen Anschlüssen übertragen werden, da graphische Anschlüsse jedes beliebige graphische Objekt übertragen können. Durch Verwendung von Mediakomponenten, welche graphische Anschlüsse enthalten, ist es möglich, Netzwerke von Videoobjekten zu erzeugen, zwischen denen Videoinformationen strömen. Auf diese Weise kann eine Vielzahl interessanter Anwendungen verwirklicht werden. Figur 22 zeigt ein Beispiel des Einfügens einer Videodigitalisierkomponente in eine Betrachterkomponente zur Darstellung auf einem Computerbildschirm gemäß einer bevorzugten Ausführungsform.
Figur 23 ist ein komplizierteres Beispiel des Mischens von Bildern von zwei Videoobjekten in einem Effekteprozessor und des Darstellens des Ergebnisses auf einem Computerbildschirm gemäß einer bevorzugten Ausführungsform. Graphikanschlüsse werden mit Hilfe von Graphikaliassen miteinander verbunden. Jede Videokomponente verfügt über Elementefunktionen, die Aliasse für deren Eingangs- und Ausgangsanschlüsse erzeugen. Klienten führen Verbindungsoperationen durch, indem sie Eingangs- und/oder Ausgangsanschlußaliasse von den einzelnen Komponenten anfordern. Danach verbinden Objekte unter Verwendung der vom Alias zur Verfügung gestellten Elementefunktionen die aktuellen Eingangsanschlüsse mit den aktuellen Ausgangsanschlüssen. Jedem Graphikanschluß und jedem Anschlußalias ist ein Graphiktyp zugeordnet. Wenn zwei Anschlüsse dazu aufgefordert werden, sich zu verbinden, stellt ein Typenverhandlungsprotokoll sicher, daß die Anschlüsse in der Lage sind, kompatible Datentypen zu unterstützen. Wenn die Anschlüsse über keine gemeinsamen Typen verfügen, wird eine Ausnahme ausgegeben.
Der Vorgang des Verbindens von Videokomponenten kann an der Anzeigevorrichtung graphisch durch das Verlängern einer geometrischen Figur, wie zum Beispiel eines Liniensegmentes, zwischen Indizes, welche Videoeingangs- und ausgangsanschlüsse darstellen, repräsentiert werden.

Daten übertragen

Graphikanschlüsse manipulieren graphische Daten, indem sie Zeiger zu graphischen Objekten lesen und schreiben. Die Anschlußimplementierung zum Schreiben ist synchron: Die Write()-Elementefunktion des graphischen Ausgabeanschlusses blockiert, bis der Empfänger mit dem Senden des graphischen Objektes fertig ist. Der Graphikanschluß verwendet aus Leistungsgründen keine Kopiersemantik. Das Kopieren von RGB-Bitmapbildern wird aufgrund des mit solchen Operationen verbundenen Prozessor- und Speicheraufwandes vermieden. Stattdessen wird ein Zeiger vom Graphikobjekt vom Graphikausgangsanschluß zum Graphikeingangsanschluß gesandt. Die synchrone Schnittstelle arbeitet über die Adreßgrenzen hinweg, wenn gemeinsam benutzter Speicher zum Speichern der geschriebenen oder gelesenen Graphikobjekte verwendet wird, oder wenn die Graphikobjekte über den Adreßraum eines Tasks hinaus kopiert werden. Blockierte Graphikanschlüsse werden freigegeben, wenn eine Verbindung abgebrochen wird.
Figur 24 zeigt, wie Graphikanschlüsse gemäß einer bevorzugten Ausführungsform verwendet werden. 1) Ein Task in der Ausgangsmediakomponente schreibt ein Graphikobjekt in den Ausgangsanschluß der Mediakomponente. 2) Ein Zeiger zum Graphikobjekt wird zum angeschlossenen Eingangsanschluß der Zielmediakomponente übertragen. 3) Ein Task in der Zielmediakomponente hat, nachdem er die Read()-Elementefunktion seines Eingangsanschlusses aufgerufen und blockiert hat, den graphischen Objektzeiger freigegeben und gelesen. 4) Wenn dieser Task mit der Verarbeitung des Graphikobjektes fertig ist, ruft er die Next()-Elementefunktion des Eingangsanschlusses der Zielmediakomponente auf. 5) Der Task der Quellmediakomponente deblockiert und kehrt vom Abfeuerungsaufruf zurück. Nun kann er das Graphikobjekt sicher abgeben, weil das Ziel damit fertig ist. Figur 25 ist ein Flußdiagramm, welches die mit der Schreib- (Write) Elementefunktion eines Ausgangsanschlusses im Zusammenhang stehende Logik darstellt. Ein Zeiger zu einem Graphikobjekt wird in diese Elementefunktion weitergegeben. Die Verarbeitung beginnt am Punkt 2500 und geht sofort zum Entscheidungsblock 2510 weiter, um zu bestimmen, ob der Anschluß verbunden ist. Wenn der Anschluß nicht verbunden ist, kommt es zu einer Ausnahme, wie dies am Punkt 2520 dargestellt ist. Wenn ein Anschluß verbunden ist, wird ein Test am Entscheidungsblock 2530 durchgeführt, um zu bestimmen, ob sich der verbundene Anschluß im selben Adreßraum befindet. Wenn sich der Anschluß nicht im selben Adreßraum befindet, wird am Funktionsblock 2540 das gesamte Graphikcbjekt in den gemeinsam genutzten Speicher kopiert. Wenn sich der Anschluß im selben Adreßraum befindet, wird ein Zeiger zum Graphikobjekt in den Speicher kopiert. In beiden Fällen besteht der nächste Schritt darin, eine Mitteilung zum Eingangsanschluß zu senden, wie dies am Funktionsblock 2560 dargestellt ist, den Task zu blockieren, bis der Eingangsanschluß den Anschluß darüber in Kenntnis setzt, daß die Verarbeitung beendet ist, wie dies am Funktionsblock 2570 dargestellt ist, und die Ausführung am Punkt 2580 zu beenden.
Figur 26 zeigt die Leseverarbeitung eines Eingangsanschlusses gemäß einer bevorzugten Ausführungsform. Die Verarbeitung beginnt am Punkt 2600 und geht sofort weiter zum Entscheidungsblock 2610, um zu bestimmen, ob der Anschluß verbunden ist. Wenn der Anschluß nicht verbunden ist, erzeugt das Rahmenwerk eine Ausnahme am Punkt 2620. Wenn der Anschluß verbunden ist, wird ein weiterer Test am Entscheidungsblock 2630 durchgeführt, um zu bestimmen, ob die Graphik fertig ist. Wenn nicht, wird solange ein Blokkierungstask verarbeitet, bis das Objekt fertig ist, wie dies im Funktionsblock 2640 dargestellt ist, und die Kontrolle wird zum Funktionsblock 2650 weitergegeben. Wenn die Graphik fertig ist, wird ein Zeiger zum Graphikobjekt im Funktionsblock 2650 zurückgegeben, und die Kontrolle wird über den Punkt 2660 zurückgegeben.
Figur 27 zeigt die 'Nächste'- (next)-Elementverarbeitung eines Eingangsanschlusses gemäß einer bevorzugten Ausführungsform. Die Verarbeitung beginnt am Punkt 2700 und geht sofort zum Entscheidungsblock 2710 weiter, um zu bestimmen, ob der Anschluß verbunden ist. Wenn der Anschluß nicht verbunden ist, wird eine Ausnahme am Punkt 2720 ausgegeben. Wenn der Anschluß verbunden ist, wird die entsprechende Mitteilung, wie im Funktionsblock 2730 dargestellt, übertragen, und ein anderer Test wird am Entscheidungsblock 2740 durchgeführt, um zu bestimmen, ob sich der verbundene Anschluß im selben Adreßraum befindet. Wenn sich der Anschluß im selben Adreßraum befindet, wird die Verarbeitung am Punkt 2760 abgeschlossen. Wenn sich der Anschluß nicht im selben Adreßraum befindet, wird eine Kopie des Graphikobjektes wie im Funktionsblock 2750 dargestellt gelöscht, und die Verarbeitung endet am Punkt 2760.

Übertragung von MIDI-Daten

Die 'digitale Schnittstelle für Musikinstrumente' (MIDI) definiert eine Schnittstelle zum Austausch von Informationen zwischen elektronischen Musikinstrumenten, Computern, Sequenzern, Beleuchtungsreglern, Mischern und Kassettenrekordern, wie dies in der Publikation der MIDI- Herstellervereinigung mit dem Titel MIDI 1.0 Detailed Specification (1990) diskutiert wird. MIDI wird sowohl im Aufnahmestudio als auch bei Live-Auftritten auf umfassende Weise verwendet und hat seit langem enorme Auswirkungen auf Studioaufnahmen und die automatisch gesteuerte Audio-Video- Produktion sowie auf die Komposition. Durch sich selbst und in Verbindung mit anderen Medien spielt MIDI eine integrale Rolle in der Anwendung von Computern für Multimedia-Anwendungen. Im Vergleich zu digitalem Audio nehmen MIDI-Dateien viel weniger Speicherplatz ein, und die Informationen sind symbolisch, um eine komfortable Manipulation und Betrachtung zu ermöglichen. Eine typische dreiminütige MIDI-Datei benötigt zum Beispiel vielleicht 30 bis 60 Kilobyte auf der Festplatte, wohingegen eine Stereo-Audiodatei in CD-Qualität ungefähr 200 Kilobyte pro Sekunde bzw. 36 Megabyte für drei Minuten benötigt. MIDI-Daten können als Musiknoten, graphische Pianorolle oder Mitteilungslisten dargestellt werden, die geeignet sind, um unterschiedliche Instrumente zu bearbeiten und sie zuzuordnen. In General MIDI sind Instrumente standardmäßig zugeordnet, um so den Produzenten von Multimedia-Titeln auf großartige Weise zu motivieren.
MIDI-Eingangs- und Ausgangsanschlüsse werden verwendet, um zeitgestempelte MIDI-Pakete von einer Mediakomponente zu einer anderen zu übertragen. MIDI-Anschlüsse dienen als Postfächer für die Kommunikation von MIDI-Paketen über Adreßräume hinweg. Viele interessante MIDI-Anwendungen können durch das Verbinden von Media-Komponenten geschaffen werden, welche MIDI-Anschlüsse enthalten. Figur 28 zeigt, wie zwei Komponenten, ein MIDI-Spieler 2800 und eine MIDI-Schnittstelle 2810, verwendet werden können, um einen am Computer angeschlossenen Musiksynthesizer zu spielen. Die MIDI-Schnittstelle wird verwendet, um externe Geräte, wie zum Beispiel einen Musiksynthesizer, anzuschließen. MIDI-Pakete werden vom MIDI-Spieler zur MIDI- Schnittstelle gesandt. Die MIDI-Schnittstelle 2810 wandelt die MIDI-Pakete in MIDI-Daten um, die zum Abspielen zum Musiksynthesizer gesandt werden.
Figur 29 zeigt, wie MIDI-Daten von einem externen Musiksynthesizer aufgezeichnet und abgespielt werden können. Die MIDI-Schnittstelle 2910 verfügt über einen MIDI-Ausgangsanschluß, der MIDI-Pakete auf der Basis der vom Musiksynthesizer empfangenen Daten produziert. Der MIDI-Spieler 2900 verfügt über einen MIDI-Eingangsanschluß, der diese Pakete liest und sie auf dem Computer speichert. Figur 30 zeigt, wie MIDI-Daten zurückgespielt 3000, gefiltert 3010 und zu einem externen Musiksynthesizer geschickt 3020 werden können. Ein Filter 3010 kann eine Operation an seinem Eingang 3000 durchführen und das Ergebnis zu seinem Ausgang 3010 weiterleiten. Spezifische Filter können geschrieben werden, um zum Beispiel zusätzliche Noten zur Erzeugung eines MIDI-Echos oder einer Verzögerung zu erzeugen oder um das Tonhöhenband zu beschneiden, um die Bandbreitenlast zu verringern.
Figur 31 zeigt eine Media-Komponente, welche sowohl MIDI- als auch Audioanschlüsse enthält. Ein auf Software basierender Musiksynthesizer liest die MIDI-Pakete von dessen Eingangsanschluß und gibt die digitalen Audioinformationen aus, welche die Noten repräsentieren und vom Eingangsanschluß abgelesen werden. MIDI-Anschlüsse sind mit Hilfe von Anschlußaliassen miteinander verbunden. Jede MIDI-Komponente verfügt über Elementefunktionen, die Aliasse für deren Eingangs- und Ausgangsanschlüsse erzeugen. Klienten führen Verbindungsoperationen durch, indem sie Eingangs- und/oder Ausgangsanschlußaliasse von den einzelnen Komponenten anfordern und danach die von den Aliasobjekten zur Verfügung gestellten Elementefunktionen benutzen, um die aktuellen Eingangsanschlüsse mit den aktuellen Ausgangsanschlüssen zu verbinden. Jedem MIDI- Anschluß und jedem Anschlußalias ist ein MIDI-Typ zugeordnet. Wenn zwei Anschlüsse aufgefordert werden, sich zu verbinden, stellt ein Typenverhandlungsprotokoll sicher, daß die Anschlüsse in der Lage sind, kompatible Datentypen zu unterstützen. Wenn die Anschlüsse über keine gemeinsamen Typen verfügen, wird eine Ausnahme ausgegeben.
Der Prozeß des Verbindens von MIDI-Komponenten kann graphisch auf einer Anzeigevorrichtung dargestellt werden, indem eine geometrische Figur, wie zum Beispiel ein Liniensegment, zwischen den Indizes verlängert wird, welche einen MIDI-Eingangs- und Ausgangsanschluß darstellen.

MIDI - Pakete

Geräte, welche MIDI unterstützen, kommunizieren miteinander durch das Senden und Empfangen von MIDI-Mitteilungen. Der MIDI-Standard definiert zwei Arten von Mitteilungen: Kanalmitteilungen und Systemmitteilungen. Kanalmitteilungen werden weiter unterteilt in Stimm- und Modusmitteilungen. Systemmitteilungen werden weiter unterteilt in Allgemein-, Echtzeit- und Exklusivmitteilungen, wie dies in Figur 32 dargestellt ist. Kanalstimmenmitteilungen enthalten eine Kanalnummer (0-15), der ein MIDI-Gerät zuhören kann. Kanalmodusmitteilungen werden am Basiskanal gesandt, um die Reaktion eines Instrumentes auf die Kanalstimmenmitteilungen zu bestimmen. System-Allgemein-Mitteilungen gehen an alle Empfänger, und System-Echtzeit-Mitteilungen tragen Synchronisierungsinformationen zu taktgeberbasierten Instrumenten. System-Exklusiv-Mitteilungen ermöglichen es Herstellern, MIDI-Unterstützung anzubieten, die über jene hinausgeht, welche vom Standard festgelegt wird. Alle Mitteilungen starten mit einem Statusbyte, außer konsekutive Mitteilungen derselben Art, die auf optionale Weise das Statusbyte ausfallen lassen können (laufender Status) Alle Mitteilungstypen außer System-Exklusiv besitzen null, ein oder zwei Datenbytes. System-Exklusiv-Mitteilungen bestehen aus einer beliebigen Anzahl an Datenbytes, die durch ein EOX-Byte beendet werden. Figur 33 zeigt Formate von MIDI-Mitteilungen gemäß einer bevorzugten Ausführungsform der Erfindung.

MIDI-Paket kapselt den Standard ein

Ein MIDI-Paketobjekt kapselt alle MIDI-Mitteilungstypen und Strukturen ein. Darüberhinaus besitzen alle MIDI- Paketobjekte ein Statusbyte und einen Zeitstempel, wie dies in Figur 34 dargestellt wird. Subklassen von MIDI-Paketen reflektieren das MIDI-Protokoll durch Definition von Mitteilungstypen mit geeigneten Konstruktoren und Zugriffselementefunktionen.

MIDI-Anschlüsse

MIDI-Anschlüsse werden verwendet, um MIDI-Pakete zwischen Media-Komponenten auszutauschen. Ein MIDI-Ausgangsanschluß kann ein MIDI-Paket schreiben, und ein MIDI-Eingangsanschluß kann ein MIDI-Paket lesen. Ein Ausgangsanschluß kann über einen Aliasanschluß mit einem Eingangsanschluß verbunden werden. Aliasanschlüsse können MIDI-Pakete weder lesen noch schreiben. Stattdessen handelt es sich dabei um passive Objekte, die nicht an andere Adreßräume weitergegeben werden können, um Verbindungen zu unterstützen. Elementefunktionen werden zur Verfügung gestellt, um eine oder viele Mitteilungen gleichzeitig an einen Ausgangsanschluß zu schreiben. Auf ähnliche Weise kann beim Lesen von einem Eingangsanschluß entweder die nächste Mitteilung oder ein Zähler aller gepufferten Mitteilungen angefordert werden. Das Lesen (Read) blockiert, bis der Puffer nicht leer ist, und ein blockierter Read-Aufruf kann von einem anderen Task abgebrochen werden. Eine Kopie des an einen Ausgangsanschluß geschriebenen Paketes wird vom Eingangsanschluß gelesen.
Pakete werden in der Reihenfolge ihres Einlangens gelesen und sind nicht mit einem Zeitstempel versehen. Wenn die nach Zeit gereihte Vermischung zweier Ströme erforderlich ist, wird ein Sortiermischobjekt benötigt. Um zu verstehen, warum ein Eingangsanschluß keine Reihung erstellt, denke man zuerst daran, daß Zeit sowohl vorwärts als auch rückwärts fließen kann. Man denke an ein bestimmtes Abspielszenario mit einer Sequenz mit Ereignissen bei 6, 8 und 10 Sekunden. Wenn die Zeit bei 5 beginnt, bis 11 geht, umkehrt und wieder zu 5 zurückgeht, sollte die Reihenfolge der Ereignisse lauten: 6, 8, 10, 10, 8, 6, und nicht 6, 6, 8, 8, 10, 10. Gerade weil die Zeit in beide Richtungen fließt, reicht eine Reihung nicht für die Pufferung der Pakete aus.
Die Eingangs- und Ausgangsfächerung von Verbindungen wird unterstützt. Die Fächerung bezieht sich auf die Fähigkeit eines MIDI-Ausgangsanschlusses, mit mehr als einem MIDI-Eingangsanschluß verbunden zu sein, und an einem MIDI- Eingangsanschluß können mehr als ein MIDI-Ausgangsanschluß verbunden sein. Figur 35 zeigt ein Beispiel für eine Fächerungsoperation gemäß einer bevorzugten Ausführungsform.

Implementierung von HIDI-Anschlüssen

Eine bevorzugte Ausführungsform verwendet eine Liste von verbunden Anschlüssen, um MIDI-Anschlußverbindungen und einen gemeinsam benutzten Puffer für das Senden und Empfangen von Paketen zu verfolgen. Jeder Anschluß führt eine Liste aller anderen Anschlüsse, mit denen er verbunden ist. Diese Liste wird von Connect- (Verbinden) und Disconnect(Trennen) Aufrufen aktualisiert und verwendet, wenn Anschlüsse zerstört werden, um alle Anschlüsse, die damit verbunden sind, darüber zu informieren, daß dieser Anschluß nicht mehr vorhanden ist. Diese Verarbeitung verhindert, daß ein Ausgangsanschluß einen Eingangsanschluß in der Liste hat und versucht, an diesen zu schreiben, während dieser Eingangsanschluß in Wirklichkeit bereits zerstört wurde. Somit führt ein Ausgangsanschluß eine Liste mit all jenen Eingangsanschlüssen, die er verwendet, um den Write- Aufruf (Schreiben-Aufruf) zu implementieren, und er schreibt an jeden einzelnen Anschluß, der in seiner Liste enthalten ist. Und ein Eingangsanschluß führt eine Liste mit all jenen Ausgangsanschlüssen, die mit diesem verbunden sind und die benachrichtigt werden müssen, wenn er weggeht. Ein gemeinsam benutzter Puffer unterstützt ein Produzenten- Konsumenten-Protokoll. Wenn der Puffer leer ist, kann ein Task blockieren, bis er nicht mehr leer ist. Ein weiterer Task, der in der Folge in seinen Puffer ablegt, kann den blockierten Task darüber informieren, daß er etwas hineingeschrieben hat. Alternativ dazu kann jedoch ein anderer Task die Blockierung aufheben, was zu einer anderen Art der Benachrichtigung führt.
Die Write()-Elementefunktion eines MIDI-Ausgangsanschlusses wird in Figur 36 dargestellt. Die Verarbeitung beginnt bei Punkt 3600 und geht sofort zum Funktionsblock 3610 weiter, um einen Zähler und einen Grenzwert für eine Schleife zu initialisieren. Danach wird am Entscheidungsblock 3620 ein Test durchgeführt, um zu bestimmen, ob der Zähler den Grenzwert erreicht hat. Wenn der Zähler diesen erreicht hat, wird die Verarbeitung am Punkt 3670 abgeschlossen. Wenn der Zähler diesen nicht erreicht hat, wird am Funktionsblock 3630 eine Kopie des Paketes in den Puffer eines Anschlusses eingefügt, und ein Test wird am Entscheidungsblock 3640 durchgeführt, um zu bestimmen, ob der Puffer eine Mitteilung besitzt. Wenn der Puffer nicht leer ist, wird eine entsprechende Mitteilung übertragen, wie dies im Funktionsblock 3650 dargestellt wird. Wenn nicht, wird keine Mitteilung gesandt. In beiden Fällen wird der Zähler am Funktionsblock 3660 erhöht, und die Kontrolle wird über den Punkt 3670 zurückgegeben.
Eine Read()-Elementefunktion eines MIDI-Eingabeanschlusses wird in Figur 37 dargestellt. Die Verarbeitung beginnt am Entscheidungsblock 3700, um zu bestimmen, ob der Puffer leer ist. Wenn dies der Fall ist, wird der Task blockiert, bis der Puffer Informationen enthält oder ein Abbruch am Funktionsblock 3710 erfolgt. Am Entscheidungsblock 3730 wird ein Test durchgeführt, um zu bestimmen, ob das Warten abgebrochen wurde. Wenn dies der Fall ist, tritt eine Ausnahme am Punkt 3750 auf. Wenn nicht, oder wenn der Puffer am Entscheidungsblock 3700 nicht leer war, wird ein Paket vom Puffer zum Aufrufer am Funktionsblock 3720 kopiert, und die Verarbeitung wird durch Rückgabe am Punkt 3740 abgeschlossen.

Abstrakte Multimedia-Komponenten Media - Komponente

Eine zeitbasierte Media-Komponente, welche als Mediakomponenten-Basisklasse bezeichnet wird, ist eine zentrale Abstraktion, die für die Übertragung verwendet wird. Eine Media-Komponente verfügt über null oder mehr Eingangsanschlüsse und null oder mehr Ausgangsanschlüsse In Figur 38 verfügt die Media-Komponente zum Beispiel über einen einzigen Eingangsanschluß und zwei Ausgangsanschlüsse.

Media-Sequenz

Eine Media-Sequenz ist eine abstrakte Basisklasse, welche den Media-Inhalt einschließlich Audiosequenzen repräsentiert. Subklassen von Media-Sequenzen werden verwendet, um Audio-, Video- und MIDI-Ausschnitte zu repräsentieren. Media-Sequenzen sind gekennzeichnet durch eine Dauer und eine Liste von Typen. Die Dauer, dargestellt durch einen Gleitkommawert, zeigt an, wie lange die Daten sind. Die Daten werden auch nach Typ unterschieden, um anzuzeigen, welcher Typ von Klang von den Daten repräsentiert wird, wie zum Beispiel Video, Audio, usw. Eine Subklasse kann mehrere Typen unterstützen. Zum Beispiel kann eine Audio-Subklasse Daten sowohl in linearer Form als auch in komprimierter Form zuführen. Aufgrund dieser Möglichkeit verfügt eine Media-Sequenz über eine Liste von Typen.

Spieler

Figur 39 zeigt ein Beispiel für eine zeitbasierte Media-Spieler-Basisklasse (Spieler). Dies ist eine Media- Komponente, welche zeitbasierte Media-Sequenzen (als Media- Sequenz bezeichnet) abspielen kann. Eine Media-Sequenz ist eine abstrakte Basisklasse, die verwendet werden kann, um einen Audio-, Video- oder Animationsausschnitt oder MIDI- Daten zu repräsentieren. Subklassen der zeitbasierten Media-Sequenz werden dazu verwendet, um Audio-, Video-, Animations- und MIDI-Sequenzen zu implementieren. Ein Spieler ist analog zu einem Kassettenrekorder, während eine Media-Sequenz analog zu einem Kassettenband ist. Ein Spieler besitzt eine Play()-Elementefunktion zum Abspielen der Media-Sequenz, eine Record()-Elementefunktion zum Aufnehmen der Sequenz, und eine Stop()-Elementefunktion, um das Abspielen und Aufzeichnen zu beenden. Er verfügt auch über eine Seek()-Elementefunktion (Suchen), um eine Position in der Sequenz zu suchen und um es Elementefunktionen zu ermöglichen, den Spieler mit anderen Spielern oder mit Software-Taktgebern zu synchronisieren. Durch das Trennen der Spieler von den Daten können Spieler auch wiederverwendet werden. Nach dem Abspielen einer Kassette kann der Spieler angewiesen werden, eine andere abzuspielen oder aufzunehmen.

Standard-Audiokomponenten Audio-Spieler

Figur 40 zeigt einen Audio-Spieler, dem eine abstrakte Basisklasse zugeordnet ist, damit eine Audiokomponente Audiodaten abspielen und aufzeichnen kann. Audiodaten werden in Objekten gespeichert, die als Audio-Sequenzen bezeichnet werden, welche Subklassen von Media-Sequenzen sind. Ein Audio-Spieler ist analog zu einem Kassettenrekorder, und die Audio-Sequenz ist analog zu einer Kassette. Ein Audio-Spieler ist eine Subklasse eines Spielers. Wie alle Spieler - Ton, Video oder MIDI - besitzt ein Audio- Spieler eine Play()-Elementefunktion, so daß der Ton abgehort werden kann, und eine Record()-Elementefunktion, so daß die Sequenz aufgezeichnet werden kann (wenn die Aufzeichnung erlaubt ist), und Stop(), um die Aufzeichnung oder das Abspielen zu stoppen. Er besitzt eine Seek()- Elementefunktion, um auf wahllose Weise auf einen Punkt im Ton zugreifen zu können. Er besitzt auch Elementefunktionen, um es einem Spieler zu ermöglichen, mit einem anderen Media-Spieler oder einem Sof tware-Taktgeber synchronisiert zu werden.

Lautsprecher

Figur 41 zeigt ein Beispiel einer Lautsprecherkomponente. Eine Lautsprecherkomponente ist eine abstrakte Basisklasse für ein Audioausgabegerät. An einem System können mehrere Tonausgabegeräte angeschlossen sein. Von einer Lautsprecherkomponente können Subklassen gebildet werden, um verschiedene Merkmale der Ausgabegeräte zu repräsentieren. Zum Beispiel existiert eine Subklasse einer Lautsprecherkomponente, um ein Abspielen über den Telefonapparat oder eine Telefonleitung zu ermöglichen. Eine Lautsprecherkomponente ist ein logisches Ausgabegerät - es können viele Beispiel von Lautsprecherkomponenten existieren -, alle werden zusammengemischt und über die physikalischen Lautsprecher des Computers ausgegeben. Stereoausgabegeräte würden von zwei Subklassen der Lautsprecherkomponente repräsentiert, und zwar eine für den linken Kanal, und eine für den rechten.

Mikrophon

Figur 42 zeigt eine Mikrophonkomponente gemäß einer bevorzugten Ausführungsform. Eine Mikrophonkomponente ist eine abstrakte Basisklasse, welche eine Toneingabequelle repräsentiert, wie zum Beispiel eine Mikrophon- oder eine Leitungseingabe. An einem System können mehrere Toneingabegeräte angeschlossen sein. Von einer Mikrophonkomponente können Subklassen abgeleitet werden, um diese Geräte zu repräsentieren. Zum Beispiel wird eine Subklasse der Mikrophonkomponente verwendet, um die Aufzeichnung vom Telefonapparat oder der Telefonleitung durchzuführen. Wie bei einer Lautsprecherkomponente handelt es sich auch bei der Mikrophonkomponente um ein logisches Gerät - mehrere Beispiele einer Mikrophonkomponente können vorhanden sein, alle Beispiele erzeugen identische Audiodaten, welche vom selben physikalischen Mikrophon stammen. Eine Mikrophonkomponente besitzt einen Ausgang. Weil eine Mikrophonkomponente eine Datenquelle ist, muß sie explizit durch Aufruf von Start() gestartet werden. Durch Aufruf von Stop() kann sie gestoppt werden. Stereoeingabegeräte werden durch zwei Subklassen von Mikrophonkomponenten repräsentiert, und zwar eine für den linken Kanal und eine für den rechten.

Mischer

Figur 43 zeigt ein Beispiel für eine Mischerkomponente. Eine Mischerkomponente ist eine abstrakte Basisklasse, die zwei oder mehrere Audioeingänge in einen einzigen Audioausgang summiert. Die Anzahl der Eingänge wird bestimmt vom Eingang in den Konstruktor.

Verteiler

Figur 44 zeigt ein Beispiel für eine Verteilerkomponente. Eine Verteilerkomponente ist eine abstrakte Basisklasse, welche einen Eingang nimmt und diesen in zwei oder mehrere Ausgänge aufteilt. Die Anzahl der Ausgänge wird bestimmt durch das, was zum Konstruktor weitergeleitet wird.

Verstärkung

Figur 45 zeigt ein Beispiel für eine Verstärkungskomponente. Eine Verstärkungskomponente ist eine abstrakte Basisklasse, welche die Amplitude(ngröße) eines Signals erhöhen oder verringern kann. Sie wird für die Lautstärkeregelung verwendet und besitzt SetGain()- (Verstärkung einstellen) und GetGain()- (Verstärkung holen) Funktionen. Mathematisch gesehen multipliziert eine Verstärkungskomponente jedes eingegebene Tonstück mit dem Verstärkungswert und führt das Ergebnis ihrem Ausgang zu. Ein Verstärkungswert von 1.0 verändert das Signal überhaupt nicht, während ein Verstärkungswert von 2.0 das Signal doppelt so laut macht. Der Verstärkungswert 0.5 verringert das Signal auf die halbe Lautstärke. Große Signalpegel werden beschnitten.

Echo

Figur 46 zeigt eine Echo-Komponente gemäß einer bevorzugten Ausführungsform. Eine Echo-Komponente ist eine abstrakte Basisklasse, welche ihrem Eingang ein Echo hinzufügt und das Ergebnis als ihren Ausgang produziert. Eine Echokomponente verfügt über drei einstellbare Parameter, nämlich Verzögerungslänge, Feedback und Mischverhältnis. Große Verzögerungslängen führen dazu, daß der Eingabeton so klingt, als wäre er in einer großen Schlucht, während kleine Verzögerungen einen Flanscheffekt erzeugen können, ähnlich wie das Vorbeizischen eines Düsenflugzeuges. Das Feedback bestimmt die Anzahl der hörbaren Echos. Das Mischverhältnis legt fest, wieviel des Echosignals wieder zurück hineingemischt wird.

Verzerrung

Figur 47 zeigt eine Verzerrungskomponente gemäß einer bevorzugten Ausführungsform. Eine Verzerrungskomponente ist eine abstrakte Basisklasse, welche einen Klang verzerrt.
Dieser Effekt wird am sinnvollsten bei Gitarrenklängen oder Klängen von einem Musikinstrument eingesetzt.

Audiotypumwandler

Figur 48 zeigt ein Beispiel für einen Audiotypumwandler. Eine Audiotypumwandlerkomponente ist eine abstrakte Basisklasse, welche eine Umwandlung von einem Audiotyp in einen anderen durchführt.

Audio-Multiumwandler

Figur 49 zeigt einen Audio-Multiumwandler gemäß einer bevorzugten Ausführungsform. Eine Audio-Multiumwandlerkomponente führt eine Umwandlung von mehreren Audiotypen in eine Mehrzahl anderer Audiotypen basierend auf einem bestimmten Abschnitt durch.

Klang

Figur 50 zeigt eine Klangkomponente gemäß einer bevorzugten Ausführungsform. Eine Klangkomponente ist ein Komfortgbjekt, daß sich für das Aufzeichnen und Abspielen von Klängen eignet. Figur 51 zeigt die Komponenten, welche in einer Klangkomponente eingebettet sind. Eine Klangkomponente 5100 enthält eine Mikrophonkomponente 5110, eine Verstärkungskomponente 5120 (zur Regelung des Eingangspegels), eine Audio-Spielerkomponente 5130, eine weitere Verstärkungskomponente 5140 (zur Regelung des Ausgangspegels) und eine Lautsprecherkomponente 5150. Bei einem gegebenen Klangdateinamen erzeugt eine Klangkomponente automatisch die richtige Audiosequenz und die erforderlichen Audiokomponenten zum Abspielen und Aufzeichnen der Datei.

Physikalische Lautsprecher

Figur 52 zeigt eine physikalische Lautsprecherkomponente gemäß einer bevorzugten Ausführungsform. Eine physikalische Lautsprecherkomponente ist ein Alias für den Ausgangsverstärker und den Lautsprecher des Computers. Sie wird verwendet, um die Lautstärke für den gesamten Computer zu regeln. Wenn der Computer über andere Klangausgabegeräte verfügt, würden entsprechende Subklassen eines physikalischen Lautsprechers vorhanden sein. Physikalische Lautsprecherkomponenten besitzen die Elementefunktionen SetVolume() (Lautstärke einstellen) und GetVolume() (Lautstärke holen), um den gesamten Lautstärkepegel einzustellen und zu holen.

Physikalisches Mikrophon

Figur 53 zeigt eine physikalische Mikrophonkomponente gemäß einer bevorzugten Ausführungsform Eine physikalische Mikrophonkomponente repräsentiert die aktuelle Hardware für einen Mikrophon- oder Leitungseingang. Der gesamte in den Computer eingehende Eingangspegel kann eingestellt werden

Standard-Videokomponenten Graphik-Spieler

Figur 54 zeigt eine Graphik-Spielerkomponente gemäß einer bevorzugten Ausführungsform Eine Graphik-Spielerkomponente ist eine abstrakte Basisklasse für eine Komponente, welche Zeitgraphikobjekte abspielen und aufzeichnen kann, bei denen es sich um Graphikobjekte handelt, die sich mit der Zeit verändern. Eine Graphik-Sequenz ist eine Subklasse der Zeitgraphik. Eine Graphik-Sequenz ist eine geordnete Folge von Graphikobjekten, wobei jedes einzelne Graphikobjekt über eine Dauer verfügt. Ein Graphik-Spieler ist analog zu einem Videorecorder, und die Graphik-Sequenz ist analog zu einer Videokassette. Ein Graphik-Spieler ist eine Subklasse eines Spielers. Wie alle Spieler - Ton, Video, oder MIDI - besitzt ein Graphik-Spieler eine Play()-Elementefunktion, so daß die Graphik-Objekte gesehen werden können, und eine Record()-Elementefunktion, so daß die Sequenz aufgezeichnet werden kann (falls die Aufzeichnung erlaubt ist), und eine Stop()-Funktion, um die Aufzeichnung und das Abspielen zu stoppen. Er besitzt eine Seek()-Elementefunktion, um auf wahllose Weise auf einen Punkt in der Sequenz zugreifen zu können. Er besitzt auch Elementefunktionen, mit deren Hilfe der Spieler mit einem anderen Media-Spieler oder einem Software-Taktgeber synchronisiert werden kann.

Graphik-Betrachter

Figur 55 zeigt eine Graphik-Betrachterkomponente gemäß einer bevorzugten Ausführungsform. Eine Graphik-Betrachterkomponente wird verwendet, um Graphikobjekte auf einer Computeranzeigevorrichtung darzustellen. Ein Graphik-Spieler muß an einem Graphik-Betrachter angeschlossen sein, um die abgespielten Graphikobjekte sehen zu können. Verwendet man eine Analogie zum Verbraucherelektronikvideo, so ist ein Graphik-Spieler wie der Videorecorder, während ein Graphik-Betrachter wie ein Videomonitor ist.

Videodigitalisier

Figur 56 zeigt eine Videodigitalisierkomponente gemäß einer bevorzugten Ausführungsform. Eine Videodigitalisierkomponente wandelt analoge Videomformationen durch einen am Computer angeschlossenen Hardware-Videodigitalisierer in graphische Objekte um. Ein Videodigitalisierer kann an einen Graphik-Spieler angeschlossen werden, um analoge Videomformationen aufzuzeichnen, die in den Computer eingegeben werden. Würde man eine Analogie zu einem Verbraucherelektronikvideo verwenden, so wäre der Videodigitalisierer analog zu einer Videokamera, während der Graphik- Spieler analog zu einem Videorecorder wäre.

Standard-MIDI-Komponenten MIDI-Spieler

Figur 57 zeigt eine MIDI-Spieler-Komponente gemäß einer bevorzugten Ausführungsform Eine MIDI-Spieler-Komponente ist eine abstrakte Basisklasse für eine Komponente, welche MIDI-Sequenzen abspielen und aufzeichnen kann. Eine MIDI-Sequenz ist eine Sammlung von MIDI-Spuren. Eine MIDI- Spur ist eine gereihte Folge von MIDI-Paketen. Ein MIDI- Spieler ist eine Subklasse eines Spielers. Wie alle Spieler - Ton, Video oder MIDI - besitzt ein MIDI-Spieler eine Play()-Elementefunktion, so daß MIDI-Pakete an einen externen Musiksynthesizer gesandt werden können, und eine Record()-Elementefunktion, so daß MIDI-Mitteilungen von einem externen Keyboard aufgezeichnet werden können (falls das Aufzeichnen erlaubt ist), und Stop(), um das Aufzeichnen oder Abspielen zu stoppen. Er besitzt eine Seek()- Elementefunktion, um auf zufällige Weise auf einen Punkt in der Sequenz zuzugreifen. Er besitzt auch Elementefunktionen, die es ermöglichen, daß der Spieler mit einem anderen Media-Spieler oder einem Software-Taktgeber synchronisiert werden kann.

HIDI-Schnittstelle

Figur 58 zeigt eine MIDI-Schnittstellenkomponente gemäß einer bevorzugten Ausführungsform. Eine MIDI-Schnittstellenkomponente sendet MIDI-Pakete an einen externen Musiksynthesizer und empfängt diese auch. Ein MIDI-Spieler muß an einer MIDI-Schnittstelle angeschlossen sein, um MIDI-Mitteilungen abspielen oder aufnehmen zu können.

MIDI-Filter

Figur 59 zeigt eine MIDI-Filterkomponente gemäß einer bevorzugten Ausführungsform. Eine MIDI-Filterkomponente ist eine abstrakte Basisklasse für ein Objekt, das einen MIDI- Eingangsanschluß und einen MIDI-Ausgangsanschluß besitzt. Subklassen bieten einen Umwandelalgorithmus, der die Eingangsdaten in Ausgangsdaten umwandelt.

MIDI-Zuordner

Figur 60 zeigt eine MIDI-Zuordnerkomponente gemäß einer bevorzugten Ausführungsform Die MIDI-Zuordnerkomponente ist eine Subklasse von MIDI-Filter, welche ein Wörterbuch verwendet, um Eingangs-MIDI-Pakete Ausgangs-MIDI- Paketen zuzuordnen. Jeder Eintrag im Wörterbuch besteht aus einem Paar MIDI-Paketen, einem Eingangspaket (als Schlüssel bezeichnet) und einem Ausgangspaket (als Wert bezeichnet). Eingangs-MIDI-Pakete, welche in den MIDI-Zuordner eintreten, werden als Suchschlüssel für das Wörterbuch verwendet. Das Ergebnis der Suche ist das Ausgangs-MIDI-Paket, welches in den Ausgangsanschluß geschrieben wird.

MIDI-Programmzuordner

Figur 61 zeigt eine MIDI-Programmzuordnerkomponente gemäß einer bevorzugten Ausführungsform. Eine MIDI-Programmzuordnerkomponente ist eine Subklasse des MIDI-Zuordners. Sie wandelt MIDI-Programmänderungsmitteilungen in andere MIDI-Programmänderungsmitteilungen um. Sie kann dazu verwendet werden, um jedes beliebige Instrument einem anderen zuzuordnen.

MIDI-Notenzuordner

Figur 62 zeigt eine MIDI-Notenzuordnerkomponente gemäß einer bevorzugten Ausführungsform. Eine MIDI-Notenzuordnerkomponente ist eine Subklasse des MIDI-Zuordners. Sie wandelt MIDI-Noten-Ein- und Noten-Aus-Mitteilungen um, wodurch Noten transponiert werden können

MIDI-Kanalzuordner

Figur 63 zeigt eine MIDI-Kanalzuordnerkomponente gemäß einer bevorzugten Ausführungsform Eine MIDI-Kanalzuordnerkomponente ist eine Subklasse des MIDI-Zuordners. Sie wandelt MIDI-Kanal-Stimmen- und -Modus-Mitteilungen um und kann für Kanaländerungen zu jedem Zweck verwendet werden.
Wenngleich die Erfindung im Hinblick auf eine bevorzugte Ausführungsform in einer spezifischen Systemumgebung beschrieben wurde, kann der Fachmann leicht erkennen, daß die Erfindung mit Modifizierungen in anderen und unterschiedlichen Hardware- und Softwareumgebungen in Geist und Umfang der angehängten Patentanmeldungen ausgeführt werden kann.

Claims

1. Ein System für Multmedia-Präsentationen, das einen Prozessor (10) aufweist sowie einen an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (16), eine an den Prozessor angeschlossene und von diesem gesteuerte Anzeigevorrichtung (38) und eine Vielzahl von Multimediaobjekten im Speicher und repräsentative Markierungen der Multimediaobjekte im Speicher, die auf der Anzeigevorrichtung angezeigt werden können,

gekennzeichnet durch:

(a) Multimediaobjekte, die für an den Prozessor angeschlossene und von diesem gesteuerte Multimediageräte repräsentativ sind (Fig. 12);

(b) ein Verbindungsobjekt (300, 310, 320), das im Speicher enthalten ist und auf der Anzeigevorrichtung angezeigt werden kann und zur Verbindung eines ersten der Multimediaobjekte mit einem Videoobjekt dient; und

(c) Mittel (2560, 2570, 2650) , die unter der Steuerung des Prozessors Informationen zwischen dem ersten der Multimediaobjekte und dem Videoobjekt über das Verbindungsobjekt weiterleiten.

2. Das System nach Anspruch 1 enthält wenigstens ein Anschlußmittel in den Multimediaobjekten zum Empfang von Videoinformation.

3. Das System nach Anspruch 1 enthält wenigstens ein Anschlußmittel in den Multimediaobjekten zum Senden von Videoinformation.

4. Das System nach Anspruch 2 enthält Mittel zur Unterstützung eines Video-Digitalisierers.

5. Das System nach Anspruch 1 enthält Mittel zur Aufzeichnung von Videoinformation.

6. Das System nach Anspruch 1 enthält Mittel für das Rückspielen von Videoinformation.

7. Das System nach Anspruch 1 enthält Mittel zum Umwandeln von einem Videotyp in einen anderen Mediatyp.

8. Das System nach Anspruch 1 enthält Mittel zum Umwandeln von einem Videotyp in eine Vielzahl von Mediatypen.

9. Das System nach Anspruch 1 enthält Mittel zum Verbinden eines Datentyps mit jedem Anschluß des Multimediaobjekts und zum polymorphen Verbinden von Multimediaobjekten.

10. Das System nach Anspruch 9 enthält Umwandlungsmittel zum Verbinden von Multimediaobjekten unterschiedlichen Typs.

11. Ein Verfahren zum Ermöglichen von Multmedia-Präsentationen auf einem Prozessor (10) mit einem an den Prozessor angeschlossenen und von diesem gesteuerten Speicher (16) und mit einer an den Prozessor angeschlossenen und von diesem gesteuerten Anzeigevorrichtung (38), und unter Verwendung einer Vielzahl von Multimediaobjekten im Speicher und repräsentativen Markierungen der Multimediaobjekte im Speicher, die auf der Anzeigevorrichtung angezeigt werden können,

gekennzeichnet durch die Schritte:

(a) Erzeugen einer Vielzahl von Multimediaobjekten, die für an den Prozessor angeschlossene und von diesem gesteuerte Multimediageräte repräsentativ sind (Fig. 12);

(b) Anzeigen eines in Schritt (a) erzeugten Multimediaobjekts;

(c) Anzeigen eines Videoobjekts auf der Anzeigevorrichtung;

(d) Verbinden der Multimediaobjekte mit dem Videoobjekt (Figur 24, 2550, 2540); und

(e) Weiterleiten von Information zwischen dem Multimediaobjekt und dem Videoobjekt zur Erzeugung einer Multmedia-Präsentation (2560, 2570, 2650).

12. Das Verfahren nach Anspruch 11 enthält den Schritt des Empfangs von Videoinformation an einem Multimediaobjekt- Anschluß.

13. Das Verfahren nach Anspruch 11 enthält den Schritt des Sendens von Videoinformation zu einem Multimediaobjekt- Anschluß.

14. Das Verfahren nach Anspruch 12 enthält den Schritt der Unterstützung eines Video-Digitalisierers.

15. Das Verfahren nach Anspruch 11 enthält den Schritt der Aufzeichnung von Videoinformation.

16. Das Verfahren nach Anspruch 11 enthält den Schritt des Rückspielens von Videoinformation.

17. Das Verfahren nach Anspruch 11 enthält den Schritt des Umwandelns von einem Videotyp in einen anderen Mediatyp.

18. Das Verfahren nach Anspruch 11 enthält den Schritt des Umwandelns von einem Videotyp in eine Vielzahl von Mediatypen.

19. Das Verfahren nach Anspruch 11 enthält den Schritt der Verbindung eines Datentyps mit jedem Anschluß des Multimediaobjekts und der polymorphen Verbindung von Multimediaobjekten.

20. Das Verfahren nach Anspruch 19 enthält den Schritt der Verbindung von Multimediaobjekten unterschiedlichen Typs.