DE60006845T2

DE60006845T2 - Verfahren und vorrichtung zur zusammenarbeit bei multimediaerzeugung über einem netzwerk

Info

Publication number: DE60006845T2
Application number: DE60006845T
Authority: DE
Inventors: D. Matthew MOLLER; Graham Lyus; Michael Franke
Original assignee: Avid Technology Inc
Current assignee: Avid Technology Inc
Priority date: 1999-09-23
Filing date: 2000-09-22
Publication date: 2004-11-11
Anticipated expiration: 2020-09-23
Also published as: HK1047340B; DE60006845D1; AU7602200A; WO2001022398A1; US20040054725A1; US6598074B1; CA2384894A1; ATE255264T1; AU757950B2; EP1224658B1; JP2003510642A; US20030028598A1; EP1224658A1; CA2384894C; US7069296B2; HK1047340A1; WO2001022398A9

Description

HINTERGRUND DER ERFINDUNG Bereich der Erfindung
Die Erfindung betrifft das gemeinsame Benutzen von Daten, und insbesondere das gemeinsame Benutzen von Multimediadaten innerhalb eines Netzwerkes.
In zunehmendem Maße wird von Musikern und Multimedia-Produktionsspezialisten Computertechnologie eingesetzt, um den kreativen Prozess zu unterstützen. Musiker verwenden beispielsweise als "Sequenzer" oder "DAWs" (Digital-Audio-Workstations) konfiugurierte Computer, um Multimedia-Quellmaterial, wie Digital-Audio-, Digital-Video-, und Musikalische-Instrument-Digital-Schnittstellen- (MIDI, "Musical Instrument Digital Interface") Daten aufzuzeichnen. Sequenzer und DAWs erzeugen dann Sequenzdaten, um es dem Anwender zu ermöglichen, verschiedene Abschnitte der aufgezeichneten Daten auszuwählen und zu editieren, um ein fertiges Produkt zu erzeugen.
Sequenzersoftware wird oft verwendet, üblicherweise in Form von Mehrspur-Aufnahmen individueller, in einem Aufnahmestudio versammelter Instrumente, wenn mehrere Künstler in einem Projekt zusammenarbeiten. Ein Produktionsspezialist verwendet dann die Sequenzersoftware zum Editieren der verschiedenen Spuren, sowohl einzeln als auch in Gruppen, um das endgültige Arrangement für das Produkt zu erzeugen. Oft werden in einer Aufnahmesitzung mehrere Aufnahmeversionen des gleichen Musikabschnitts aufgezeichnet, wodurch dem Produktionsspezialisten ermöglicht wird, die besten Abschnitte von verschiedenen Aufnahmeversionen auswählen. Soweit notwendig, können während der Sitzung weitere Aufnahmeversionen angefertigt werden.
Eine solche Zusammenarbeit ist selbstverständlich dann am bequemsten, wenn alle Künstler zur gleichen Zeit am gleichen Ort anwesend sind. Allerdings ist dies oft nicht möglich. Beispielsweise kann ein Orchester in einem Aufnahmestudio in Los Angeles zusammenkommen, aber der Vokalist kann sich in New York oder London befinden und daher nicht in der Lage sein, persönlich an der Sitzung teilzunehmen. Selbstverständlich könnte der Vokalist von einem entfernten, mit dem Hauptstudio durch Breitband-High-Fidelity-Kommunikationskanäle verbundenem Studio aus teilnehmen. Dies ist allerdings häufig unerschwinglich teuer, wenn nicht unmöglich.
Im Stand der Technik sind verschiedene Verfahren zum Überwinden dieses Problems bekannt. Beispielsweise ermöglicht es das "Res Rocket" System von Rocket Networks, Inc. es geographisch getrennten Anwendern, MIDI-Daten über das Internet gemeinsam zu benutzen. Allerdings verwenden professionelle Multimedia-Produktionsspezialisten im Allgemeinen eine kleine Zahl weitbekannter professioneller Sequenzer-Softwarepakete. Da sie eingehende Erfahrung in der Verwendung der Schnittstellen eines speziellen Softwarepaketes haben, sind sie häufig nicht bereit, die Vorzüge dieser Erfahrung aufzugeben, um einen nicht geläufigen Sequenzer anzunehmen.
Es ist daher wünschenswert, ein System und ein Verfahren für professionelle Künstler und Multimedia-Produktionsspezialisten bereitzustellen, um von geographisch getrennten Orten aus und unter Verwendung vertrauter Anwenderschnittstellen existierender Sequenzersoftware zusammenzuarbeiten.
ZUSAMMENFASSUNG DER ERFINDUNG
Merkmale und Vorteile der Erfindung werden in der folgenden Beschreibung erklärt und werden teilweise aus der Beschreibung offensichtlich oder können durch Ausführen der Erfindung gelernt werden. Die Ziele und weitere Vorteile der Erfindung werden insbesondere durch die in der vorliegenden schriftlichen Beschreibung und den vorliegenden Ansprüchen aufgezeigten Systemen und Verfahren, sowie die beiliegenden Zeichnungen verwirklicht und erreicht.
Gemäß dem Zweck der Erfindung, wie ausgeführt und in Breite beschrieben, weist die Erfindung eine Vorrichtung zum gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation und wenigstens einer entfernten Sequenzerstation über ein Netzwerk mittels eines Servers auf, wobei die Sequenzdaten audiovisuelle Ereignisse darstellen, von welchen jedes beschreibende Merkmale und Zeitmerkmale hat. Die Vorrichtung weist ein erstes Schnittstellenmodul zum Empfangen von Befehlen von einer lokalen Sequenzerstation auf, und ein mit dem ersten Schnittstellenmodul verbundenes Datenverpackungsmodul ("data packaging module"). Das Datenverpackungsmodul reagiert auf die empfangenen Befehle durch Einkapseln von Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten, unter Beibehaltung der beschreibenden Merkmale und Zeitbeziehungen der Sequenzdaten. Das Datenverpackungsmodul extrahiert ferner Sequenzdaten aus vom Server zum Zugriff durch das lokale Sequenzerendgerät empfangenen Sendedateneinheiten. Die Vorrichtung weist ferner einen mit dem ersten Schnittstellenmodul und dem Datenverpackungsmodul verbundenen Sendungsbehandler auf.
Der Sendungsbehandler verarbeitet über das erste Schnittstellenmodul empfangene Befehle. Die Vorrichtung weist ferner ein Serverkommunikationsmodul auf, welches auf vom Sendungsbehandler verarbeitete Befehle durch Übertragen von Sendedateneinheiten zu dem Server zum Verteilen an wenigstens eine entfernte Sequenzerstation antwortet, wobei das Serverkommunikationsmodul auch Daten-Verfügbar-Nachrichten und Sendedateneinheiten vom Server empfängt. Die Vorrichtung weist ferner einen mit dem Serverkommunikationsmodul gekoppelten Mitteilungswarteschlangen-Behandler auf, welcher auf den Empfang von Daten-Verfügbar-Nachrichten und Sendedateneinheiten vom Server antwortet, um Mitteilungen an die erste Schnittstelle zum Zugriff durch das lokale Sequenzerendgerät herauszugeben.
In einem weiteren Aspekt stellt die Erfindung ein Verfahren zum gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation und wenigstens einer entfernten Sequenzerstation mittels eines Servers über ein Netzwerk bereit, wobei die Sequenzdaten audiovisuelle Ereignisse darstellen, von denen jedes beschreibende Eigenschaften und Zeitmerkmale aufweist. Das Verfahren weist auf: Empfangen von Befehlen mittels einer Client-Anwendungskomponente von einem Benutzer an einer lokalen Sequenzerstation; Antworten auf der empfangenen Befehle durch Einkapseln von Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten, unter Beibehaltung der beschreibenden Merkmale und Zeitbeziehungen der Sequenzdaten und Übertragen von Sendedateneinheiten zum Server zum Verteilen an wenigstens eine entfernte Sequenzerstation; Empfangen von Daten-Verfügbar-Nachrichten vom Server; Antworten auf den Empfang von Daten-Verfügbar-Nachrichten vom Server zum Übertragen. von Mitteilungen an die Client-Anwendungskomponente; Antworten auf von der Client-Anwendungskomponente empfangenen Befehlen zum Anfordern des Herunterladens von Sendedateneinheiten vom Server, und Empfangen von Sendedateneinheiten von dem Server und Extrahieren von Sequenzdaten von den empfangenen Sendedateneinheiten zum Zugriff durch die Client-Anwendungskomponente.
Es ist zu bemerken, dass sowohl die oben angegebene allgemeine Beschreibung, als auch die folgende detaillierte Beschreibung exemplarisch und erklärend sind und darauf zielen, ein weiteres Verständnis der Erfindung, wie sie beansprucht ist, zu geben.
Die begleitenden Zeichnungen sind zum weiteren Verständnis der Erfindung beigefügt. Sie sind in die Beschreibung aufgenommen und stellen ein Teil von ihr dar, um Ausführungsformen der Erfindung zu erläutern, und dienen gemeinsam mit der Beschreibung dazu, die Prinzipien der Erfindung zu erklären.
Kurzbeschreibung der Zeichnungen
Die begleitenden Zeichnungen, welche in die Beschreibung aufgenommen sind und ein Teil von ihr darstellen, erläutern Ausführungsformen der Erfindung und dienen zusammen mit der Beschreibung dazu, die Ziele, Vorteile und Prinzipien der Erfindung zu erläutern.
In den Zeichnungen ist:
1 ein Blockdiagramm, welches ein System gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt;
2 ein Blockdiagramm, welches Module der Dienstekomponente von 1 zeigt;
3 ein Diagramm, welches die hierarchische Beziehung von Sendedateneinheiten des Systems von 1 zeigt;
4 ein Diagramm, welches die Beziehung zwischen Arrangement-Objekten und Spurobjekten des Systems von 1 zeigt;
5 ein Diagramm, welches die Beziehung zwischen Spurobjekten und Ereignisobjekten des Systems von 1 zeigt;
6 ein Diagramm, welches die Beziehung zwischen Bestandobjekten und Rendering-Objekten des Systems von 1 zeigt;
7 ein Diagramm, welches die Beziehung zwischen Clipobjekten und Bestandobjekten des Systems von 1 zeigt;
8 ein Diagramm, welches die Beziehung zwischen Ereignisobjekten, Clip-Ereignisobjekten, Clipobjekten und Bestandobjekten des Systems von 1 zeigt;
9 ein Diagramm, welches die Beziehung zwischen Ereignisobjekten, Rahmenereignisobjekten und Zeitgeradeobjekten des Systems von 1 zeigt;
10 ein Diagramm, welches die Beziehung zwischen Projektobjekten und Kundenspezifikations-Objekten des Systems von 1 zeigt; und
11 ein Diagramm, welches die Beziehung zwischen Rocket-Objekten, Kundenspezifikations- und Erweiterbar-Objekten des Systems von 1 zeigt.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Computer Anwendungen für Musiker und Multimedia-Produktionsspezialisten (üblicherweise Sequenzer und DAWs) sind dazu eingerichtet, es Anwendern zu erlauben, Multimediadaten aufzunehmen und zu editieren, um ein Multimedia-Projekt zu erzeugen. Solche Anwendungen sind inhärent Einzel-Zweck-, Einzel-Anwender- Anwendungen. Die vorliegende Erfindung erlaubt es geographisch getrennten Personen, welche individuelle Sequenzer und DAWs bedienen, zusammenzuarbeiten.
Das grundlegende Paradigma der vorliegenden Erfindung ist das eines "virtuellen Studios". Dieses ist, wie ein reales Studio, ein "Platz", wo sich Menschen "treffen" und zusammen an Multimedia-Projekten arbeiten. Allerdings können sich die Menschen, mit denen ein einzelner Anwender in diesem virtuellen Studio zusammenarbeitet, irgendwo auf der Welt befinden, verbunden durch ein Computernetzwerk.
1 zeigt ein System 10 gemäß der vorliegenden Erfindung. System 10 weist einen Server 12 auf, eine lokale Sequenzerstation 14, und ein Mehrzahl von entfernten Sequenzerstationen 16, alle durch ein Netzwerk 18 verbunden. Netzwerk 18 kann das Internet sein, oder ein privates Netzwerk.
Lokale und entfernte Sequenzerstationen 14 und 16 sind bevorzugterweise Personal-Computer, wie Apple PowerMacintosh-Computer oder Pentium-basierte Personal-Computer, welche unter einer Version des Windows-Betriebssystems betrieben werden.
Lokale und entfernte Sequenzerstationen 14 und 16 weisen eine Client-Anwendungskomponente 20 auf, welche bevorzugterweise ein Sequenzer-Softwarepaket, oder "Sequenzer", aufweist. Wie oben angegeben, erzeugen Sequenzer Sequenzdaten, welche Multimediadaten repräsentieren, welche ihrerseits audiovisuelle Ereignisse repräsentieren, die jeweils beschreibende Eigenschaften und Zeitmerkmale aufweisen. Sequenzer ermöglichen es ferner einem Anwender, die Sequenzdaten zu manipulieren und zu editieren, um Multimedia-Produkte zu erzeugen. Beispiele von geeigneten Sequenzern enthalten: Logic Audio von Emagic Inc. aus Grass Valley, Kalifornien; Cubase von Steinberg Soft- und Hardware GmbH aus Hamburg, Deutschland; und ProTools von Digidesign, Inc. aus Palo Alto, Kalifornien.
Die lokale Sequenzerstation 14 und entfernte Sequenzer Stationen 16 können, müssen aber nicht, identisch sein, und weisen üblicherweise Anzeige-Hardware, wie einen Bildschirm und eine Soundkarte (nicht dargestellt) auf, um Audio- und Video-Ausgabe bereitzustellen. Die lokale Sequenzerstation 14 weist außerdem eine Verbindungssteuerungskomponente 22 auf, welche es einem Anwender an der lokalen Sequenzerstation 14 erlaubt, sich an Server 12'' einzuwählen", zu einem virtuellen Studio zu navigieren, andere Kooperationspartner an entfernten Sequenzerstationen 16 zu finden, und mit diesen Kooperationspartnern zu kommunizieren. Jede Client-Anwendungskomponente 20 an lokalen oder entfernten Sequenzerstationen 14 oder 16 ist in der Lage, ein in dem virtuellen Studio gespeichertes Projekt zu laden, weitgehend so, als wäre es von der Client-Anwendungskomponente an dieser Station erzeugt worden, aber mit einigen wichtigen Abweichungen.
Client-Anwendungskomponenten 20 stellen üblicherweise ein "Arrangement-" Fenster auf einem Bildschirm dar, welches eine Mehrzahl von "Spuren" aufweist, die jeweils eine(n) Spurnamen, Aufnahmestatus, Kanalzuordnung und andere, ähnliche Informationen anzeigen. Gemäß der vorliegenden Erfindung zeigt das Arrangement-Fenster auch eine neue Einzelheit: Anwendername. Der Anwendername ist der Name des Individuums, dem die betreffende Spur "gehört", nachdem sie auf seiner lokalen Sequenzerstation erzeugt worden ist. Dieses neue Konzept zeigt an, dass mehr als eine Person zu der derzeit bearbeiteten Sitzung beiträgt. Spuren in dem Arrangement-Fenster sind bevorzugterweise entsprechend dem Anwender sortiert und farbkodiert.
Verbindungssteuerungskomponente 22 ist auch auf dem Bildschirm des lokalen Anwenders sichtbar, und stellt (unter anderem) zwei Fenster bereit: eingehende Unterhaltung und ausgehende Unterhaltung. Der lokale Anwender kann Text von anderen Anwendern an entfernten Sequenzerstationen 16 durchlaufen sehen, und der lokale Anwender an der lokalen Sequenzerstation 14 ist in der Lage, Nachrichten an andere Anwender zu schreiben.
In Antwort auf einen Befehl eines entfernten Anwenders, kann eine neue Spur auf dem Bildschirm des lokalen Anwenders erscheinen, und spezielle musikalische Beiträge beginnen sich hierin zu zeigen. Wenn der lokale Anwender auf seinem Bildschirm "abspielen" auswählt, kommt Musik aus Lautsprechern der lokalen Sequenzerstation. Mit anderen Worten, während der lokale Anwender an seinen Spuren gearbeitet hat, haben andere, entfernte Anwender ihre eigenen Beiträge erzeugt.
Während der lokale Anwender arbeitet, "unterhält" er sich mit anderen Anwendern mittels Verbindungssteuerungskomponente 22, und empfängt von entfernten Anwendern deren Veränderungen an deren Spuren, sobald sie diese senden, oder "Posten". Der lokale Anwender kann also seine Bemühungen durch Aufnehmen neuen Materials und Durchführen von Veränderungen beisteuern. Wenn er fertig ist, betätigt der lokale Anwender eine "Post-" Schaltfläche der Client-Anwendungskomponente 20 auf seinem Bildschirm, und alle entfernten Anwender in dem virtuellen Studio können hören, was der lokale Anwender hört- live.
Wie in 1 dargestellt, weist die lokale Sequenzerstation 14 ferner eine Dienstekomponente 24 auf, welche Dienste bereitstellt, um der lokalen Sequenzerstation 14, das gemeinsame Verwenden von Sequenzdaten mit entfernten Sequenzerstationen 16 über ein Netzwerk 18 mittels Server 12, inklusive Serverkommunikationen und lokalem Daten-Management zu ermöglichen. Dieses gemeinsame Benutzen wird erreicht durch Einkapseln von Einheiten von Sequenzdaten in Sendedateneinheiten zum Übertragen zu Server 12.
Obwohl Server 12 hier als ein Einzel-Server gezeigt und beschrieben ist, werden Fachleute bemerken, dass die beschriebenen Server-Funktionen von einem oder mehreren individuellen Servern ausgeführt werden können. Beispielsweise kann es in gewissen Anwendungen wünschenswert sein, einen Server bereitszustellen, der für das Management von Sendedateneinheiten verantwortlich ist, und einen separaten Server, welcher für andere Server-Funktionen, wie das Zugangsmanagement oder die Verwaltung des Unterhaltens verantwortlich ist.
2 zeigt die Unter-Systeme von Dienstekomponente 24, inklusive einem ersten Schnittstellenmodul 26, einem Datenverpackungsmodul 28, einem Sendungsbehandler 30, einem Serverkommunikationsmodul 32 und einem Mitteilungswarteschlangen-Behandler 34. Dienstekomponente 24 weist ferner ein Rendering-Modul 36 und ein Zwischenspeichermodul 38 auf. Von diesen Unter-Systemen, ist nur das erste Schnittstellenmodul 26 für die Software der Client-Anwendungskomponente 20 zugänglich. Das erste Schnittstellenmodul 26 empfängt Befehle von der Client-Anwendungskomponente 20 der lokalen Sequenzerstation 14 und reicht diese weiter zu Sendungsbehandler 30 und zum Datenverpackungsmodul 28. Datenverpackungsmodul 28 antwortet auf die empfangenen Befehle durch Einkapseln von Sequenzdaten von der lokalen Sequenzerstation 14 in Sendedateneinheiten, unter Beibehaltung der beschreibenden Merkmale und Zeitbeziehungen der Sequenzdaten. Datenverpackungsmodul 28 extrahiert zum Zugriff durch Client-Anwendungskomponente 20 ferner Sequenzdaten aus von Server 12 empfangenen Sendedateneinheiten.
Serverkommunikationsmodul 32 antwortet auf von dem Sendungsbehandler verarbeitete Befehle mit Übertragen von Sendedateneinheiten an Server 12 zum Verteilen an wenigstens eine entfernte Sequenzerstation 16. Serverkommunikationsmodul 32 empfängt ferner Daten-Verfügbar-Nachrichten von Server 12, und mittels Server 12 Sendedateneinheiten von einer oder mehreren entfernten Sequenzerstationen 16 und reicht die empfangenen Sendedateneinheiten an das Datenverpackungsmodul 28 weiter. Insbesondere empfängt das Serverkommunikationsmodul Daten-Verfügbar-Nachrichten von Server 12, dass eine Sendedateneinheit (von entfernten Sequenzerstationen 16) am Server verfügbar ist. Wenn die verfügbare Sendedateneinheit von einem Nicht-Medien-Typ ist, wie unten im Detail beschrieben, beantragt das Serverkommunikationsmodul, dass die Sendedateneinheit von Server 12 heruntergeladen wird. Wenn die verfügbare Sendedateneinheit von einem Medien-Typ ist, beantragt das Serverkommunikationsmodul, dass die Sendedateneinheit vom Server 12 erst nach Empfang eines Herunterlade-Befehls von der Client-Anwendungskomponente 20 heruntergeladen wird.
Mitteilungswarteschlangenbehandler 34 ist an das Serverkommunikationsmodul 32 gekoppelt und antwortet auf den Empfang von Daten-Verfügbar-Nachrichten vom Server 12 durch Übertragen von Mitteilungen an das erste Schnittstellenmodul 26 zum Zugriff durch die Client-Anwendungskomponente 20 des lokalen Sequenzerendgerätes 14.
Üblicherweise wird ein Anwender an der beispielsweise lokalen Sequenzerstation 14 ein Projekt durch Aufnahme von Multimediadaten beginnen. Dies kann durch die Verwendung eines Mikrofons und einer Videokamera zum Aufnehmen von Audio- und/oder visuellen Darbietungen in Form von Digital-Quelle-Audio-Daten und auf einem Massenspeicher der lokalen Sequenzerstation 14 gespeicherten Digital-Quelle-Audio-Daten erreicht werden. Alternativ hierzu können Quelldaten durch Abspielen eines an die lokale Sequenzerstation 14 gekoppelten MIDI-Instrumentes und Speichern der Darbietung in Form von MIDI-Daten erzeugt werden. Es können auch andere Arten von Multimediadaten aufgezeichnet werden.
Sobald die Daten aufgezeichnet sind, können sie in einem "Arrangement"-Fenster auf dem Bildschirm der lokalen Sequenzerstation 14 von der Client-Anwendungskomponente 20, üblicherweise einem Sequenzerprogramm, dargestellt werden. In einer wohlbekannten Weise kann der Anwender mehrere aufgezeichnete Spuren entweder vollständig oder in Abschnitten auswählen und kombinieren, um ein Arrangement zu erzeugen. Die Client-Anwendungskomponente 20 repräsentiert daher dieses Arrangement in Form von Sequenzdaten, welche die Zeitmerkmale und beschreibenden Merkmale der aufgezeichneten Quell-Daten beibehalten.
Wenn der Anwender mit anderen Anwendern an entfernten Sequenzerstationen 16 zusammenzuarbeiten wünscht, verbindet er sich mit Verbindungssteuerungskomponente 22. Der Anwender gibt Befehle an die Verbindungssteuerungskomponente 22, um eine Einwahl-Prozedur auszuführen, in welcher die Verbindungssteuerungskomponente 22 mittels der Dienstekomponente 24 durch das Internet 18 eine Verbindung zu Server 12 errichtet. Unter Verwendung gut bekannter Verfahren zur Einwahl-Registrierung mittels Passwörtern, kann sich der Anwender entweder in ein existierendes virtuelles Studio auf Server 12 einwählen, oder ein neues Studio einrichten. Virtuelle Studios auf Server 12 enthalten von Sequenzerstationen erzeugte Sendedateneinheiten in Form von Arrangements enthaltenden Projekten, wie im Detail unten beschrieben.
Im Folgenden wird ein Verfahren gemäß der vorliegenden Erfindung beschrieben. Das Verfahren ermöglicht mittels Server 12 über Netzwerk 18 das gemeinsame Verwenden von Sequenzdaten zwischen der lokalen Sequenzerstation 14 und wenigstens einer entfernten Sequenzerstation 16. Wie oben angegeben, stellen die Sequenzdaten audiovisuelle Ereignisse dar, die jeweils beschreibende Eigenschaften und Zeitmerkmale aufweisen.
Wenn der Anwender an seiner Sequenzerstation erzeugte Sequenzdaten zu entweder einem neuen oder einem existierenden virtuellen Studio beisteuern möchte, aktiviert der Anwender eine POST-Schaltfläche auf seinem Bildschirm, was die Client-Anwendungskomponente 20 veranlasst, Befehle an die Dienstekomponente 24 zu senden. Ein Verfahren gemäß der vorliegenden Erfindung beinhaltet ein Empfangen von Befehlen von Dienstekomponente 24, welche von einem Anwender an der lokalen Sequenzerstation 14 stammen und mittels Client-Anwendungskomponente 20 übertragen werden. Der Sendungsbehandler 30 der Dienstekomponente 24 antwortet auf die empfangenen Befehle durch Einkapseln von Sequenzdaten von der lokalen Sequenzerstation 14 in Sendedateneinheiten, unter Beibehalten der beschreibenden Merkmale und Zeitbeziehungen der Sequenzdaten. Der Sendungsbehandler 30 verarbeitet empfangene Befehle durch Übertragen von Sendedateneinheiten mittels des Serverkommunikationsmoduls 32 an Server 12 zum Verteilen an entfernte Sequenzerstationen 16. Das Serverkommunikationsmodul 32 empfängt Daten-Verfügbar-Nachrichten von Server 12 und übermittelt Mitteilungen an die Client-Anwendungskomponente 20. Das Serverkommunikationsmodul 32 antwortet auf von der Client-Anwendungskomponente 20 empfangene Befehle zum Anfragen des Herunterladens von Sendedateneinheiten von Server 12. Das Serverkommunikationsmodul 32 empfängt Sendedateneinheiten mittels des Servers von der wenigstens einen entfernten Sequenzerstation. Das Datenverpackungsmodul 28 extrahiert dann zum Zugriff durch Client-Anwendungskomponente 20 Sequenzdaten aus von Server 12 empfangenen Sendedateneinheiten.
Wenn ein Anwender in einem virtuellen Studio an einem Projekt arbeitet, bearbeitet er eigentlich Sätze von Sendedaten, welche von Server 12 verwaltet, und auf ihm gepflegt werden. In der bevorzugten Ausführungsform verwendet Dienstekomponente 24 zum Darstellen der Sendedaten ein objektorientiertes Daten-Modell, welches vom Datenverpackungsmodul 28 verwaltet und bearbeitet wird. Durch Verwenden von Sendedateneinheiten in Form von durch Dienstekomponente 24 aus Sequenzdaten erzeugten Objekten, können Anwender eine Hierarchie definieren und gegenseitige Abhängigkeiten von Sequenzdaten in dem Projekt abbilden.
3 zeigt die Hohe-Ebene-Kapselungs-Hierarchie für Sendedateneinheiten bildende Objekte gemäß der bevorzugten Ausführungsform. Jedes Sendeobjekt stellt einen Satz von Schnittstellen bereit, um die Attribute des Objektes zu beeinflussen, und Vorgänge an dem Objekt auszuführen. Dienstekomponente 24 hält Kopien von allen Sendeobjekten.
Sendeobjekte werden in einer der beiden folgenden Weisen erzeugt:

– Lokales Erzeugen von Objekten und Senden von ihnen an Server 12. Client-Anwendungskomponente 20 erzeugt Sendeobjekte lokal durch Aufruf von Erzeuge-Methoden ("Create-Methods")(im Detail im Anhang angegeben) von anderen Objekten der Hierarchie.
– Empfangen eines neuen Sendeobjektes von Server 12. Wenn ein Sendeobjekt an Server 12 gesendet ist, wird es auf dem Server zu einer Projekt-Datenbank zugefügt und an alle mit dem Projekt verbundenen entfernten Sequenzerstationen weitergesendet.

Die Dienstekomponente 24 verwendet ein Mitteilungssystem des Mitteilungswarteschlangen-Behandlers 34, um mit der Client-Anwendungskomponente 20 zu kommunizieren. Mitteilungen erlauben es der Dienstekomponente 24, der Client-Anwendung Änderungen in den Zuständen von Sendeobjekten mitzuteilen.
Client-Anwendungskomponente 20 ist häufig in einem Zustand, in dem die von ihr verwendeten Daten nicht geändert werden sollten. Wenn beispielsweise eine Sequenzer-Anwendung sich mitten im Abspielen einer Datensequenz von einer Datei befindet, kann es wichtig sein, dass sie das Abspielen beendet, bevor die Daten verändert werden. Um sicherzustellen, dass dies nicht geschieht, versendet der Mitteilungswarteschlangen-Behandler 34 von Dienstekomponente 24 Mitteilungen nur in Antwort auf eine Anforderung durch Client-Anwendungskomponente 20, was es der Client-Anwendungskomponente 20 ermöglicht, die Mitteilung zu behandeln, wenn dies sicher und zweckmäßig ist.
An der Spitze des Sendeobjektmodells des Datenverpackungsmoduls 28 steht Projekt, siehe 3. Ein Projektobjekt ist die Wurzel des Sendeobjektmodells, und stellt den primären Zusammenarbeits-Kontext bereit, wobei es alle Objekte enthält, auf die von innerhalb des Projektes aus zugegriffen werden muss. Das Projektobjekt kann man sich als Sätze oder "Pools" von Objekten enthaltend denken, die innerhalb des Projektobjektes als Kompositions-Elemente agieren. Das Arrangement-Objekt ist das Kompositions-Element der höchsten Ebene in dem Objekt-Modell.
Wie in 4 gezeigt, ist ein Arrangement-Objekt eine Sammlung von Spurobjekten. Diese Gruppierung von Spurobjekten dient zwei Zwecken:

1. Es ermöglicht es dem Arrangement, den Kompositions-Kontext der Spuren zu definieren.
2. Es ermöglicht es dem Arrangement, den Zeitkontext für diese Spuren zu setzen.

Spurobjekte (s. 5) sind die Behälter ("Container") der höchsten Ebene für Ereignisobjekte, und setzen deren Zeitkontext. Alle Ereignisobjekte in einem Spurobjekt beginnen zu einer Zeit mit Bezug auf den Beginn eines Spurobjektes. Spurobjekte sind ferner die am häufigsten verwendeten Eigentümer-Einheiten in einer Zusammenarbeits-Sitzung. Das Datenverpackungsmodul 28 kapselt daher die Sequenzdaten in Sendedateneinheiten, oder Objekte, inklusive einem Arrangement-Objekt, welches eine Zeit-Referenz errichtet, und wenigstens einem Spurobjekt mit einer zur Arrangement-Zeit-Referenz korrespondierenden Spurzeitreferenz. Jedes Spurobjekt hat wenigstens ein zugeordnetes Ereignisobjekt, welches ein audiovisuelles Ereignis zu einer bezüglich der zugeordneten Spur-Zeit-Referenz festgelegten Zeit repräsentiert.
Die von der Client-Anwendungskomponente 20 der lokalen Sequenzerstation 14 erzeugten Sequenzdaten enthalten Multimediadaten-Quelldateneinheiten, welche von aufgenommenen Daten abgeleitet sind. Typischerweise werden diese aufgenommenen Daten MIDI-Daten, digitale Audio-Daten oder digitale Video-Daten sein, obwohl jeder Datentyp aufgenommen und gespeichert werden kann. Diese in dem Projekt verwendeten Multimediadaten-Quelldateneinheiten werden durch einen Typ von Sendedateneinheiten repräsentiert, der als Bestandobjekt bekannt ist. Wie 6 zeigt, hat ein Bestandobjekt einen zugeordneten Satz von Rendering-Objekten. Bestandobjekte verwenden diese Rendering-Objekte, um verschiedene "Ansichten" ("views") eines bestimmten Medien-Teils zu repräsentieren. Daher werden Bestand- und Rendering-Objekte als Medien-Sendedateneinheiten bezeichnet. Alle von Bestand- und Rendering-Objekten abweichenden Sendedateneinheiten sind von einem als Nicht-Medien-Sendedateneinheiten bezeichneten Typ.
Jedes Bestandobjekt hat ein spezielles Rendering-Objekt, welches die Original-Quellaufnahme der Daten repräsentiert. Da digitale Mediendaten häufig sehr umfangreich sind, kann es sein, dass diese Original-Quelldaten niemals über das Netzwerk verteilt werden. Stattdessen werden komprimierte Versionen der Daten gesendet werden. Diese komprimierten Versionen werden von abweichenden Rendering-Objekten des Bestandobjektes repräsentiert.
Durch Definieren von Hohe-Ebene-Methoden (im Detail im Anhang angegeben) zum Setzen und Manipulieren dieser Rendering-Objekte, stellen Bestandobjekte ein Mittel zum Verwalten verschiedener Versionen von Quelldaten bereit, um sie als ein gemeinsames Kompositions-Element zu gruppieren. Das Datenverpackungsmodul 28 kapselt somit die Multimedia-Quelldatenobjekte in wenigstens einen Typ von Bestand-Rendering-Sendeobjekt, wobei jeder Bestand-Rendering-Objekttyp eine Version von Multimediadaten-Quelldaten mit einem unterschiedlichen Grad an Datenkompression spezifiziert.
Die von der Client-Anwendungskomponente 20 der lokalen Sequenzerstation 14 erzeugten Sequenzdateneinheiten enthalten Clipdateneinheiten, welche jeweils einen speziellen Abschnitt einer Multimediadaten-Quelldateneinheit repräsentieren. Datenverpackungsmodul 28 kapselt diese Sequenzdateneinheiten als Clipobjekte, welche verwendet werden, um einen Abschnitt eines Bestandobjektes zu referenzieren, wie in 7 gezeigt. Der Haupt-Zweck der Clipobjekte ist es, diejenigen Abschnitte des Bestandobjektes zu definieren, die kompositionsrelevant sind. Beispielsweise könnte ein Bestandobjekt, welches einen Trommel-Part repräsentiert, zwanzig Takte lang sein. Ein Clipobjekt könnte verwendet werden, um Vier-Takt-Abschnitte der Original-Aufnahme zu referenzieren. Diese Clipobjekte könnten dann als Schleifen verwendet werden, um den Trommel-Part neu zu arrangieren.
Clipobjekte sind unter Verwendung von Clip-Ereignisobjekten in Arrangement-Objekte aufgenommen. Wie in 8 gezeigt, ist ein Clip-Ereignisobjekt ein Typ eines Ereignisobjektes, der verwendet wird, um ein Clipobjekt zu referenzieren. Dies bedeutet: das Datenverpackungsmodul 28 kapselt Sequenzdateneinheiten in Sendedateneinheiten, welche als Clip-Ereignisobjekte bekannt sind, und jeweils einen spezifischen Abschnitt einer Multimediadaten-Quelldateneinheit repräsentieren, welcher zu einer festgelegten Zeit bezüglich einer zugeordneten Spurzeitreferenz beginnt.
Es mag auf den ersten Blick zu kompliziert erscheinen, zwei Verweisungs-Ebenen auf Bestandobjekte vorzusehen. Der Bedarf hierfür ist allerdings einfach: Kompositionen werden oft durch Wiederverwenden geläufiger Elemente aufgebaut. Diese Elemente beziehen sich typischerweise auf ein Bestandobjekt, verwenden aber nicht die gesamten aufgezeichneten Daten des Bestandobjektes. Die Clipobjekte identifizieren somit diejenigen Abschnitte von Bestandobjekten, die tatsächlich innerhalb der Komposition von Interesse sind.
Obwohl es viele Anwendungen gibt, die erfolgreich allein unter Verwendung von Arrangement-, Spur- und Clip-Ereignisobjekten arbeiten könnten, verlangen viele Client-Anwendungskomponenten auch, dass Kompositions-Elemente geschachtelt werden.
Beispielsweise könnte ein Trommel-Part mittels einer Sammlung von Spuren arrangiert werden, wobei jede Spur eine individuelle Trommel repräsentiert (d.h. Schnarrtrommel, Bass-Trommel und Zimbel). Obwohl ein Komponist einen Trommel-Part unter Verwendung dieser individuellen Trommel-Spuren aufbauen kann, denkt er sich den ganzen Trommel-Part als ein einzelnes Kompositions-Element und wird – nachdem er mit dem Editieren fertig ist – das ganze Trommel-Arrangement als einen einzelnen Part bearbeiten. Viele Client-Anwendungskomponenten erzeugen Ordner für diese Spuren, ein geschachtelter Part, der als eine einzige Einheit editiert und arrangiert werden kann.
Um dieses Schachteln zu ermöglichen, weist die Sende-Objekt Hierarchie von Datenverpackungsmodul 28 einen speziellen Typ von Ereignisobjekten auf, welcher Rahmenereignisobjekt genannt wird (s. 9).
Ein Rahmenereignisobjekt ist ein Typ von Ereignisobjekt, welcher ein oder mehrere Zeitgeradeobjekte enthält. Diese Zeitgeradeobjekte enthalten ihrerseits weitere Ereignisse, wodurch sie einen Schachtelungs-Mechanismus bereitstellen. Rahmenereignisobjekte sind daher sehr ähnlich zu Arrangement-Objekten: das Rahmenereignisobjekt setzt eine Start-Zeit (den Zeitkontext) für alle in ihm enthaltenen Zeitgeradeobjekte.
Zeitgeradeobjekte sind sehr ähnlich zu Spurobjekten, so dass in diesen Zeitgeradeobjekten enthaltene Ereignisobjekte sich alle auf die Start-Zeit des Rahmenereignisobjektes beziehen. Daher kapselt das Datenverpackungsmodul 28 Sequenzdateneinheiten in Rahmenereignis-Datenobjekte, die jeweils eine Rahmenereignis-Zeitreferenz haben, welche zu einer festgelegten Zeit mit Bezug zur zugeordneten Spurzeitreferenz errichtet wird. Jedes Rahmenereignisobjekt enthält wenigstens ein Zeitgeradeereignisobjekt, wobei jedes Zeitgeradeereignisobjekt eine Zeitgeradeereignis-Zeitreferenz aufweist, welche zu einer festgelegten Zeit mit Bezug zur zugeordneten Rahmenereignis-Zeitreferenz errichtet wird, und welche wenigstens ein Ereignisobjekt aufweist, welches ein audiovisuelles Ereignis zu einer festgelegten Zeit mit Bezug zur zugeordneten Zeitgeradeereigniszeitreferenz enthält.
Ein Projektobjekt enthält Null oder mehr Kundenspezifikations-Objekte (s. 10). Kundenspezifikations-Objekte stellen einen Mechanismus bereit, jegliche generischen Daten zu enthalten, die Client-Anwendungskomponente 20 möglicherweise verwenden will. Kundenspezifikations-Objekte werden vom Projektobjekt verwaltet, und können beliebig oft von anderen Sendeobjekten referenziert werden.
Das von Datenverpackungsmodul 28 implementierte Sendeobjektmodell enthält zwei spezielle Objekte: Rocket-Objekt und Erweiterbar. Alle Sendeobjekte sind von diesen Klassen abgeleitet, wie in 11 gezeigt.
Das Rocket-Objekt enthält Methoden und Attribute, die allen Objekten in der Hierarchie gemeinsam sind. (Beispielsweise haben alle Objekte in der Hierarchie ein Name-Attribut).
Erweiterbar-Objekte sind Objekte, die von Client-Anwendungskomponente 20 erweitert werden können. Wie in 11 gezeigt, stellen diese Objekte Standard-Sendedateneinheiten dar, welche die Hierarchie der Sequenzdaten ausdrücken, inklusive Projekt-, Arrangement-, Spur-, Ereignis-, Zeitgerade-, Bestand- und Rendering-Objekten. Die Erweiterbarkeit dieser Standard-Sendedateneinheiten erlaubt es Dritt-Entwicklern, spezialisierte Typen von Sendedateneinheiten zur eigenen Verwendung zu erzeugen. Beispielsweise könnte es die Client-Anwendungskomponente 20 dem Datenverpackungsmodul 28 erlauben, ein spezialisiertes, als Mischspur bezeichnetes, Objekt zu implementieren, welches alle Attribute des Standard-Spurobjektes enthält, und außerdem zusätzliche Attribute enthält. Client-Anwendungskomponente 20 errichtet das Mischspur-Objekt durch Erweitern des Spurobjektes mittels der Spur-Klasse.
Wie oben angegeben, können Erweiterbar-Sendedateneinheiten erweitert werden, um spezialisierte Datentypen zu unterstützen. Viele Client-Anwendungskomponenten 20 werden allerdings herkömmliche Datentypen zum Aufbau von Kompositionen verwenden. Beispielsweise werden Musik-Sequenzer-Anwendungen praktisch immer Digital-Audio- und MIDI-Datentypen verwenden.
Verbindungssteuerungskomponente 22 bietet dem Anwender Zugang zu Kommunikations- und Navigations-Diensten innerhalb der Virtuellstudio-Umgebung. Insbesondere antwortet Verbindungssteuerungskomponente 22 auf vom Anwender an der lokalen Sequenzerstation 14 empfangene Befehle zum Errichten eines Zugangs mittels Server 12 zu einer vorbestimmten Untermenge von auf dem Server 12 gespeicherten Sendedateneinheiten. Verbindungssteuerungskomponente 22 enthält die folgenden Haupt-Module:

1. Einen Einwahl-Dialog
2. Eine Weiterleit-Schnittstelle zu einem externen Web-Browser, welcher Zugang zu dem Ressourcen-Server 12 gibt.
3. Eine floating Schnittstelle zum Unterhalten.
4. Eine private Schnittstelle zum Unterhalten.
5. Audio-Kompressions Codec-Präferenzen.
6. Eine Schnittstelle für Client-spezifische Anwender-Präferenzen.

Der Einwahl-Dialog erlaubt es dem Anwender, ein neues Benutzerkonto an Server 12 anzulegen, oder sich in verschiedene, auf Server 12 unterhaltene virtuelle Studios durch Eingeben eines vorher registrierten Anwendernamens und eines registrierten Passwortes einzuwählen.
Verbindungssteuerungskomponente 22 verbindet den Anwender mit Server 12 und errichtet eine Web-Brower-Verbindung.
Sobald eine Verbindung errichtet ist, kann der Anwender verfügbare virtuelle Studios auf Server 12 durchsuchen, ein Studio zum "Eintreten" auswählen, und Unterhalte-Nachrichten mit anderen Anwendern an entfernten Sequenzerstationen 16 durch ein Unterhalte-Fenster austauschen.
Insbesondere reicht Verbindungssteuerungskomponente 22 Befehle an Dienstekomponente 24 weiter, welche mittels Serverkommunikationsmodul 32 Nachrichten mit Server 12 austauscht. Bevorzugterweise werden Unterhalte-Nachrichten mittels eines Mehrfach-Anwender-Bereich objektorientierten Protokolls (MOO, "Multi User Domain, Object Oriented Protocol") implementiert.
Serverkommunikationsmodul 32 empfängt Daten von anderen Modulen der Dienstekomponente 24 zum Übertragen an Server 12, und empfängt ferner Daten von Server 12 zum Verarbeiten durch Client-Anwendungskomponente 20 und Verbindungssteuerungskomponente 22. Diese Kommunikation erfolgt in Form von Nachrichten zum Unterstützen von Transaktionen, d.h. von Nachrichten-Stapeln, welche zu Server 12 und von Server 12 gesendet werden, um eine spezielle Funktion zu erreichen. Die von Serverkommunikationsmodul 32 ausgeführten Funktionen enthalten: Herunterladen eines Einzel-Objektes, Herunterladen eines Objektes und seiner Kinder, Herunterladen von Medien-Daten, Herraufladen von Sendedateneinheiten zu Server 12, Einwählen in Server 12 zum Auswählen eines Studios, Einwählen in Server 12 zum Zugreifen auf Daten und zum Lokalisieren eines Studios.
Diese Funktionen werden von einer Mehrzahl von unten beschriebenen Nachrichten-Typen erreicht:
ACK
Dies ist eine Einzel-Empfangs-Bestätigung
NACK
Diese Nachricht ist ein Nicht-Bestätigen und enthält einen Fehler-Code.
Anfrage Einzel-Objekt
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt und identifiziert die Objekt-Klasse.
Anfrage Objekt und Kind-Objekte
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das gemeinsam mit seinen Kind-Objekten herunterzuladende Objekt, und identifiziert die Objekt-Klasse.
Senden Start
Diese Nachricht identifiziert das Studio und identifiziert das gesendete Projekt.
Senden Erzeuge
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das erzeugte Objekt und enthält die Objekt-Daten.
Senden Modifiziere
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das modifizierte Objekt und enthält die Objekt-Daten.
Senden Lösche
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das gelöschte Objekt und identifiziert die Klasse des aktualisierten Objektes.
Senden Beende
Diese Nachricht identifiziert das Studio und identifiziert das gesendete Projekt.
Transaktion rückgängig machen
Diese Nachricht bricht die derzeitig aktive Transaktion ab.
Beginn Objekt-Herunterladen
Diese Nachricht identifiziert das mit dieser Nachricht heruntergeladene Objekt, identifiziert die Objekt-Klasse, identifiziert das übergeordnete Objekt des Objektes und enthält die Objekt-Daten.
Einzel-Objekt-Herunterladen
Diese Nachricht identifiziert das heruntergeladene Objekt, identifiziert die Objekt-Klasse, und enthält die Objekt-Daten.
Anfrage Medien-Herunterladen
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das den herunterzuladenen Medien zugeordnete Rendering-Objekt und identifiziert die Objekt-Klasse(immer Rendering).
Sende Medium
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltene Projekt, identifiziert das herauf zuladende Medien-Objekt, identifiziert die Objektklasse (immer Medien), identifiziert das übergeordnete Rendering-Objekt der Medien und enthält Medien-Daten.
Medium-Herunterladen
Diese Nachricht identifiziert das den herunterzuladenden Medien zugeordnete Rendering-Objekt, identifiziert die Objekt-Klasse (immer Rendering) und enthält die Medien-Daten.
Anfrage Zeitstempel
Diese Nachricht erfragt einen Zeitstempel.
Antwort Zeitstempel
Diese Nachricht enthält einen Zeitstempel im Format JJJJMMTTHHMMSSMMM (Jahr, Monat, Tag im Monat, Stunde, Minute, Sekunde, Millisekunden).
Anfrage Einwahl
Diese Nachricht identifiziert den Name eines Anwenders, der versucht sich einzuwählen, und stellt aus Sicherheitsgründen einen MD5-Digest bereit.
Antwort SSS Einwahl
Diese Nachricht zeigt an, ob ein Anwender eine registrierte 'Pro-' Version besitzt, und stellt einen Sitzungs-Token, eine URL für die Web-Seite des Servers, einen Datenserver-Port und die Adresse des Datenservers bereit.
Anfrage Studio-Ort
Diese Nachricht identifiziert das Studio, dessen Ort angefragt wird, und die Namen der Gemeinschaft und des Studios.
Antwort Studio-Ort
Diese Nachricht identifiziert das Studio, den Port für das MOO und die Adresse des MOO.
Anfrage Einzel-Objekt
Diese Nachricht identifiziert das Studio, identifiziert das das Objekt enthaltende Projekt, identifiziert das herunterzuladende Objekt und identifiziert die Objekt-Klasse.
Beende Objekt-Herunterladen
Diese Nachricht identifiziert das Objekt, dessen Herunterladen beendet wurde, identifiziert die Objekt-Klasse und identifiziert das übergeordnete Objekt des Objektes.
Die Client-Anwendungskomponente 20 erhält durch einen Satz von Schnittstellen-Klassen, welche das erste Schnittstellenmodul 26 definieren, und welche in einer Klassenbibliothek enthalten sind, Zugriff auf die Dienstekomponente 24. In der bevorzugten Ausführungsform sind diese Klassen in einfachem, plattformübergreifendem C++ implementiert, und benötigen keine speziellen Kenntnisse von COM oder anderen Inter-Prozess-Kommunikations-Technologien.
Ein Sequenzer-Hersteller integriert eine Client-Anwendungskomponente 20 in die Dienstekomponente 24 durch Zusammenbinden der Klassenbibliothek mit Quell-Code der Client-Anwendungskomponente 20 in gut bekannter Weise, beispielsweise durch Verwenden von Visual C++ für Windows-Anwendungen oder Metroworks Codewarrier (Pro Release 4) für Macintosh Anwendungen.
Ausnahmebehandlung wird ermöglicht durch:

– Hinzufügen von Initialisierungs- und Beendigungs-Eintrittspunkten zu der Client-Anwendungskomponente 20 (Engl.: _initialize und _terminate für "_initialisiere" und "_beendige"),
– Hinzufügen der "MSL RuntimePPC++.DLL" zu der Client-Anwendungskomponente 20, und
– Hinzufügen der "MSL AppRuntime.Lib" zu der Client-Anwendungskomponente 20
– Sobald diese Pfade einmal spezifiziert sind, werden bei Bedarf einfach Header-Dateien von der Dienstekomponente 24 in Quelltext-Dateien aufgenommen.

Eine ausführliche Beschreibung der zum Implementieren des erfindungsgemäßen Systems notwendigen Klassen der Klassenbibliothek ist im Anhang angegeben.
Für die Client-Anwendungskomponente 24 ist CrktServices die grundlegendste Klasse in dem ersten Schnittstellenmodul 26. Sie stellt Methoden zur Durchführung der folgenden Funktionen bereit:

– Initialisieren der Dienstekomponente 24.
– Herunterfahren der Dienstekomponente 24.
– Empfangen von Mitteilungen von der Dienstekomponente 24.
– Erzeugen von Projektobjekten.
– Behandeln des Sendens von Objekten zu Server 12 mittels Dienstekomponente 24.
– Anfragen nach anderen Sendeobjekt-Schnittstellen.

Jede Implementierung, welche die Dienstekomponente 24 verwendet, ist einzigartig. Der erste Schritt ist daher, eine Dienstekomponente 24 -Klasse zu erzeugen. Hierzu erzeugt ein Anwender einfach eine neue, von CRktservices abgeleitete Klasse:
Eine Anwendung verbindet sich mit Dienstekomponente 24 mittels Erzeugens einer Instanz ihrer
Klasse und Aufrufens von
führt automatisch alle notwendigen Operationen aus, um die Kommunikation mit der Dienstekomponente 24 für die Client-Anwendungskomponente 20 zu initiieren.
Client-Anwendungskomponente 20 trennt sich durch Löschen der
-Instanz von der Dienstekomponente 24 ab:
Die Dienstekomponente 24 wird automatisch nur diejenigen Kundenspezifikations-Datenobjekte herunterladen, die von der Client-Anwendung registriert worden sind.
stellt eine Schnittstelle hierfür bereit:
Wie
weisen alle Sendeobjekte im ersten Schnittstellenmodul 26 zugeordnete -Schnittstellen-Implementations-Klassen auf. Mittels dieser
Schnittstellen-Klassen werden Sendeobjekte erzeugt und manipuliert.
Sendeobjekte werden in einer von zweierlei Weisen erzeugt:

– Lokales Erzeugen von Objekten und Senden dieser Objekte zum Server.
– Empfangen neuer Objekte vom Server.

Es gibt einen dreistufigen Prozess zum lokalen Erzeugen von Objekten:

1. Die Client-Anwendungskomponente erzeugt Sendeobjekte durch Aufrufen der zugehörigen
-Methoden ihres Behälter-Objektes("container object").
2. Die Client-Anwendungskomponente ruft
auf, um eine Schnittstelle zu diesem Objekt zu erhalten.
3. Die Clent-Anwendungskomponente ruft
auf, um den Server mit diesen neuen Objekten zu aktualisieren.

Sendeobjekte haben
-Methoden für jede Art von Objekt, das sie enthalten. Diese
-Methoden erzeugen das Sendeobjekt in der Dienstekomponente 24 und geben die ID des Objektes zurück.
Beispielsweise weist
-Methoden zum Erzeugen eines Projektes auf.
Der folgende Code würde mit diesem Verfahren ein Projekt erzeugen:
Zum Erzeugen einer Spur ruft die Client-Anwendungskomponente 20 die
-Methode des Arrangement-Objektes auf. Jedes übergeordnete Sendeobjekt hat Methode(n) seines spezifischen Typs von abgeleiteten Sendeobjekten.
Es ist nicht notwendig (und nicht wünschenswert)
unmittelbar nach Erzeugen neuer Sendeobjekte aufzurufen. Das Senden wird bevorzugterweise von der Anwender-Schnittstelle der Client-Anwendungskomponente 20 gestartet. (Beispielsweise, sobald der Anwender eine "Sende-" Schaltfläche betätigt).
Da die Dienstekomponente 24 alle geänderten Sendeobjekte beaufsichtigt und verwaltet, kann die Client-Anwendungskomponente 20 sich das Daten-Management der Dienstekomponente 24 zu Nutze machen, während sie gleichzeitig Anwendern die Wahl ermöglicht, wann sie ihre Beiträge und Änderungen mit anderen, in dem Projekt verbundenen Anwendern teilen wollen.
Es ist zu beachten, dass (anders als
) die Schnittstellen-Objekte des Datenmodells nicht direkt erzeugt werden. Sie müssen mittels der Erzeuge-Methoden oder der übergeordneten Objekte erzeugt werden.
Client-Anwendungskomponente 20 kann jederzeit
Schnittstellen-Objekte erhalten. Diese Objekte werden erst dann vom Datenverpackungsmodul 28 gelöscht, wenn die
-Methode erfolgreich ausgeführt worden ist. Client-Anwendungskomponente 20 greift wie folgt auf ein Sendeobjekt zu:
Die
Template-Klasse wird verwendet, um Auto-Pointer-Objekte zu erzeugen. Dies ist nützlich, um Schnittstellen-Objekte zu erzeugen, die automatisch zerstört werden, sobald
seinen Gültigkeitsbereich verliert.
Zum Modifizieren der Attribute eines Sendeobjekts ruft Client-Anwendungskomponente 20 die für das Attribut der korrespondierenden
Schnittstellen- Klasse definierten Zugriff-Methoden auf:
Jedes Sendeobjekt hat einen zugeordneten Editierer, welcher der einzige Anwender ist, dem es erlaubt ist, das Objekt zu modifizieren. Wenn ein Objekt erzeugt wird, wird als Voreinstellung derjenige Anwender, der das Objekt erzeugt hat, sein Editierer.
Vor Modifizieren eines Objektes stellt Dienstekomponente 24 sicher, dass der derzeitige Anwender der Editierer des Objektes ist. Wenn der Anwender keine Erlaubnis zum Modifizieren des Objektes hat, oder wenn das Objekt gerade zum Server gesendet wird, wird die Operation fehlschlagen.
Einmal erzeugt, ist die Client-Anwendungskomponente 20 verantwortlich für das Löschen des Schnittstellen-Objektes:
Löschen von
Schnittstellen-Klassen darf nicht mit Entfernen des Objektes aus dem Datenmodell verwechselt werden. Um ein Objekt aus dem Datenmodell zu entfernen, wird die
-Methode des Objektes aufgerufen:
Schnittstellen-Objekte sind "Referenz-gezählt". Obwohl der Aufruf von
das Objekt effektiv aus dem Datenmodell entfernen wird, wird er nicht die Schnittstellen zu ihm wieder freigeben. Der Code zum ordnungsgemäßen Entfernen eines Objektes aus dem Datenmodell ist:
oder unter Verwendung des
-Templates
Wie bei dem Erzeuge-Prozess, werden Objekte solange nicht global gelöscht, bis die
-Methode aufgerufen wird.
Hat der Anwender keine Erlaubnis, das Objekt zu modifizieren, oder findet gerade ein Senden statt, wird die Operation fehlschlagen, unter Auswerfen einer Ausnahmemeldung.
Sendeobjekte werden erst dann an Server 12 gesendet oder ihm anvertraut, wenn die
-Schnittstellen-Methode aufgerufen wird. Dies erlaubt es Anwendern, lokal Änderungen durchzuführen, bevor sie dem Server oder anderen Anwendern anvertraut werden. Der Sendeprozess ist eine asynchrone Operation. Dies erlaubt es Client-Anwendungskomponente 20, sogar dann fortzufahren, wenn Daten im Hochladen begriffen sind.
Um sicherzustellen, dass seine Datenbank während des Sendevorganges konsistent bleibt, erlaubt es Dienstekomponente 24 keinen Objekten, modifiziert zu werden, während gerade ein Senden fortschreitet. Wenn alle geänderten Objekte an den Server gesendet worden sind, wird eine
-Mitteilung an die Client-Anwendungskomponente gesendet werden.
Client-Anwendungskomponente 20 kann durch Aufrufen von
vor ihrem Anvertrauen an den Server 12 beliebige von ihr an dem Datenmodell ausgeführte Änderungen rückgängig machen. Bei Aufruf dieser Operation kehren die Objekte zu dem Zustand zurück, in dem sie sich vor dem letzten Senden befunden hatten. (Diese Operation ist nicht auf Medien-Daten anwendbar).
ist eine synchrone Methode.
Die Client-Anwendungskomponente 20 kann ein im Fortschreiten begriffenes Senden durch Aufruf von
abbrechen. Dieser Prozess läßt alle Objekte in den Zustand zurückkehren, in dem sie sich auf der sendenden Maschiene befinden. Dies beinhaltet alle Objekte, die vor dem Aufruf von
gesendet worden waren.
ist eine synchrone Methode.
Mitteilungen sind der primäre Mechanismus, den Dienstekomponente 24 verwendet, um mit Client-Anwendungskomponente 20 zu kommunizieren. Wenn eine Sendedateneinheit zu Server 12 gesendet wird, wird sie der Projekt-Datenbank auf Server 12 zugefügt und es wird eine Daten-Verfügbar-Nachricht erneut an alle anderen mit dem Projekt verbundenen Sequenzerstationen gesendet. Die Dienstekomponente 24 von anderen Sequenzerstationen erzeugen eine Mitteilung für ihre zugehörigen Client-Anwendungskomponenten 20. Bei Nicht-Medien-Sendedateneinheiten fragen die anderen Sequenzerstationen ebenfalls unmittelbar das Herunterladen der verfügbaren Sendedateneinheiten an. Für Medien-Sendedateneinheiten muß ein Befehl der zugehörigen Client-Anwendungskomponente 20 empfangen worden sein, bevor eine Anfrage zum Herunterladen der verfügbaren Sendedateneinheiten erzeugt wird.
Auf Empfang einer neuen Sendedateneinheit hin erzeugt die Dienstekomponente 24 eine Mitteilung für die Client-Anwendungskomponente 20. Beispielsweise würde, wenn ein Bestandobjekt empfangen worden wäre, die
-Mitteilung erzeugt werden.
Alle Mitteilungen werden von der
-Instanz behandelt und sind als virtuelle Funktionen des
-Objektes implementiert.
Um eine Mitteilung zu behandeln, überlädt die Client-Anwendungskomponente 20 die korrespondierende virtuelle Funktion in ihrer
-Klasse.
Beispielsweise:
Wenn die Client-Anwendungskomponente 20 mittels des Mitteilungswarteschlangen-Behandlers 28 Mitteilungen empfängt, werden diese überladenen Methoden aufgerufen:
Sequenzer sind oft in Zuständen, in denen die Daten, die sie verwenden, nicht geändert werden sollten. Wenn beispielsweise Client-Anwendungskomponente 20 sich mitten in einem Abspielen einer Datensequenz aus einer Datei befindet, kann es wichtig sein, dass sie das Abspielen beendet, bevor die Daten verändert werden.
Um Datenintegrität sicherzustellen, werden alle Mitteilungs-Übertragungen bei Client-Anwendungskomponente 20 angefordert, was es ihr erlaubt, die Mitteilung innerhalb ihres eigenen Threads zu behandeln. Wenn eine Mitteilung verfügbar ist, wird eine Nachricht an die Client-Anwendungskomponente 20 gesendet.
Bei unter Windows betriebenen Sequenzerstationen hat diese Mitteilung die Form einer Windows-Message. Um diese Mitteilung zu empfangen, müssen das Rückmeldungs-Fenster und die Mitteilungs-Nachricht gesetzt werden.
Dies wird mit der
Methode vorgenommen:
Dieses Fenster wird dann die
-Nachricht empfangen, sobald es Mitteilungen in der Ereigniswarteschlange des Warteschleifenbehandlermoduls 34 gibt.
Die Client-Anwendungskomponente 20 würde dann
aufrufen, um die Dienstekomponente 24 anzuweisen, Mitteilungen für die nächste Mitteilung über anliegende Daten zu senden:
veranlaßt Dienstekomponente 24, die Mitteilung von der Warteschlange zu entfernen, und den korrespondierend Mitteilungs-Behandler aufzurufen, den Client-Anwendungskomponente 20 in ihrer Implementierung von
überladen hatte.
Bei einer Macintosh-Sequenzerstation, plaziert Client-Anwendungskomponente 20 einen
-Aufruf
Wie oben in dem Windows-Abschnitt beschrieben, veranlaßt
die Dienstekomponente 24, die Mitteilung von der Warteschlange zu entfernen und den korrespondierenden Mitteilungs-Behandler aufzurufen, den Client-Anwendungskomponente 20 in ihrer Implementierung von
überladen hatte.
Da Mitteilungen nur dann behandelt werden, wenn die Client-Anwendungskomponente 20 sie anfordert, verwendet der Mitteilungswarteschlangen-Behandler der Dienstekomponente 24 ein "intelligentes Warteschlangen-"System, um anliegende Mitteilungen zu behandeln.
Der Zweck hiervon ist zweifach:

1. Um redundante Nachrichten zu entfernen.
2. Um sicherzustellen, dass bei Löschen eines Objektes alle Nachrichten von Kind-Objekten von der Warteschlange entfernt werden.

Dieser Prozess hilft Datenintegriät sicherzustellen, wenn der Fall eintritt, dass Mitteilungen eintreffen, bevor Client-Anwendungskomponente 20 alle Mitteilungen von der Warteschlange behandelt hat.
Das System aus l ermöglicht es auszuwählen, ob Mitteilungen für Objekte, welche innerhalb von anderen Objekten enthalten sind, gesendet werden sollen oder nicht. Wenn ein Wert von
bei einer Start-Mitteilung zurückgegeben wird, werden alle Mitteilungen für in dem Objekt enthaltene Objekte gesendet werden. Wenn
zurückgegeben wird, werden keine Mitteilungen für enthaltene Objekte gesendet werden. Die
-Mitteilung zeigt an, dass das Objekt und alle Kind-Objekte erzeugt worden sind.
Wenn beispielsweise die Client-Anwendungskomponente 20 sicherstellen wollte, dass sie nie Mitteilungen von irgendwelchen Ereignissen erhält, die innerhalb von Spuren enthalten sind, würde sie die
-Methode überladen, und würde sie zurückgeben lassen:
Und würde in der
Mitteilung die von der Spur enthaltenen Objekte parsen:
In der bevorzugten Ausführungsform werden, wenn immer dies möglich ist, vordefinierte Sendeobjekte verwendet. Hierdurch wird ein gemeinsamer Austausch-Standard unterstützt. Die meissten Client-Anwendungskomponenten 20 werden in der Lage sein, ausführlichen Gebrauch von den vordefinierten Objekten des Sendeobjektmodells zu machen. Es gibt allerdings Zeiten, in denen eine Client-Anwendungskomponente 20 Objekte auf ihren eigenen Bedarf zuzuschneiden hat.
Das beschriebene System stellt zwei primäre Methoden zum Erzeugen von Kundenspezifikations- und Erweiterungs- Objekten bereit. Wenn die Client-Anwendungskomponente 20 ein Objekt aufweist, welches eine Variation von einem der Objekte des Sendeobjektmodells ist, kann sie wählen, das Sendeobjekt zu erweitern. Dies erlaubt ein Beibehalten aller Attribute, Methoden und Enthalten-Sein-Eigenschaften des Sendeobjektes, während es auf eine spezifische Anwendung zugeschnitten wird. wenn beispielsweise die Client-Anwendungskomponente 20 einen Spur-Typ mit Misch-Information aufweist, kann sie das Spurobjekt dahingehend erweitern, dass es Attribute beinhaltet, welche sich auf Misch-Spur-Implementierung beziehen. Alle vordefinierten Sendeobjekt-Datentypen in der vorliegenden Erfindung (Audio, MIDI, MIDI-Trommel, Tempo) sind unter Verwendung dieses Erweiterungs-Mechanismus implementiert.
Der erste Schritt bei der Erweiterung eines Sendeobjektes ist es, ein global einzigartiges
zu definieren:
Diese ID wird zum Markieren des Daten-Typs des Objektes verwendet. Sie erlaubt der Dienstekomponente 20 die Kenntnis des im Sendeobjekt enthaltenen Datentyps. Der nächste Schritt ist das Erzeugen einer Attribut-Struktur, welche die erweiterte Attribut-Daten des Objektes enthält:
Um ein erweitertes Objekt zu initialisieren, setzt die Client-Anwendungskomponente 20 die Datentyp-ID, die Datengröße, und die Daten:
Wenn eine Mitteilung für ein Objekt des erweiterten Typs empfangen wird, wird angenommen, dass dieses initialisiert worden ist. Die Client-Anwendungskomponente 20 fragt einfach seine Attribut-Struktur von der
Schnittstelle ab und verwendet ihre Werte nach Bedarf.
Kundenspezifikations-Objekte werden verwendet, um private Objekte zu erzeugen, welche sich nicht direkt Objekten in dem Sendeobjekt-Model des Datenverpackungsmoduls 28 zuordnen lassen. Ein Kundenspezifikations-Datenobjekt ist ein Sendeobjekt, welches willkürliche Binär-Daten enthält. Kundenspezifikations-Datenobjekte weisen ebenfalls Attribute auf, die den von dem Objekt enthaltenen Datentyp spezifizieren, so dass Anwendungen das Datenobjekt identifizieren können. Die Dienstekomponente 24 stellt für Kundenspezifikations-Datenbeschreiber alle normalen Dienste bereit, die mit Sendeobjekten assoziiert sind: Methoden zum Erzeugen, Löschen, Modifizieren, und Mitteilungen.
Der erste Schritt zum Erzeugen eines neuen Typs von Kundenspezifikations-Daten ist, eine einzigartige ID zu erzeugen, welche den Datentyp (oder Klasse) des Objektes repräsentiert:
Es muss sichergestellt sein, dass diese ID einzigartig ist, da diese ID dazu verwendet wird, den Typ von zu sendenden Daten festzulegen, wenn Kundenspezifikations-Daten-Mitteilungen empfangen werden. Der nächste Schritt ist daher, eine Struktur zum Halten der Attribute und der Daten für das Kundenspezifikations-Datenobjekt zu definieren.
kann aufgerufen werden, um ein neues Kundenspezifikations-Objekt zu erzeugen, den Daten-Typ des Datenbeschreiber-Objektes zu setzen, und die Attribut-Struktur des Objektes zu setzen:
Wenn die Client-Anwendungskomponente 20 die Mitteilung für das Objekt empfängt, überprüft sie einfach den Datentyp und behandelt es in der notwendigen Weise:
Alle Kundenspezifikations-Datentypen müssen bei der Dienstekomponente 24 (während der Initialisierung der Dienstekomponente 24) registriert werden. Die Dienstekomponente 24 wird das Erzeugen und Empfangen nur von solchen Kundenspezifikations-Objekten erlauben, welche registriert wurden. Einmal registriert, werden die Daten automatisch heruntergeladen.
Wenn ein Anwender eine musikalische Komposition erzeugt, arrangiert er oder sie Daten-Clips, welche auf aufgezeichnete Medien Bezug nehmen. Diese aufgezeichneten Medien werden in dem Sendeobjektmodell der Daten-Verpackungs-Komponente 32 als ein Bestandobjekt wiedergegeben. Ein Bestandobjekt ist dazu vorgesehen, ein aufgezeichnetes Kompositions-Element zu repräsentieren. Es sind diese Bestandobjekte, die von Clips referenziert werden, um Arrangements zu bilden.
Obwohl jedes Bestandobjekt ein einzelnes Element repräsentiert, kann es mehrere Versionen von tatsächlich aufgezeichneten Medien für das Objekt geben. Dies erlaubt es Anwendern, verschiedene Versionen des Bestandes zu erzeugen. Innerhalb des Bestandes wird jede dieser Versionen von einem Rendering-Objekt repräsentiert.
Bestand-Daten sind häufig sehr umfangreich, und es ist für Anwender in hohem Maße wünschenswert, komprimierte Versionen von Bestand-Daten zu versenden. Da diese komprimierten Daten häufig verschlechterte Versionen der Original-Aufnahme darstellen, kann ein Bestand nicht einfach die Original-Medien-Daten durch komprimierten Daten ersetzen.
Bestandobjekte stellen einen Mechanismus zum Nachverfolgen jeder Daten-Version und zu ihrem Zuordnen zu den Original-Quell-Daten, sowie zum Festlegen der zu Server 12 zu sendenden Version(en) bereit. Dies wird durch Rendering-Objekte ausgeführt.
Jedes Bestandobjekt hat eine Liste von einem oder mehreren Rendering-Objekten, wie in 6 dargestellt. Für jedes Bestandobjekt gibt es ein Quell-Rendering-Objekt, welches die ursprünglichen, Bit-genauen Daten repräsentiert. Abweichende Rendering-Objekte sind von diesen Original-Quell-Daten abgeleitet.
Die Daten für jedes Rendering-Objekt werden nur dann zu Server 12 gesendet, wenn dies von der Client-Anwendungskomponente 20 festgelegt wird. In gleicher Weise werden Rendering-Objekt-Daten nur dann vom Server 12 heruntergeladen, wenn Client-Anwendungskomponente 20 hierum ersucht.
Jedes Rendering-Objekt agiert daher als ein Platzhalter für alle potentiellen Versionen eines Bestandobjektes, die der Anwender erhalten kann und beschreibt alle Attribute der dargestellten Daten. Basierend auf dem Verhältnis von Qualität zu Datenumfang wählen Anwendungen aus, für welche Rendering-Objekte auf Server 12 die Daten herunterladen werden.
Rendering-Objekte agieren in dem Sendeobjektmodell als Dateilokalisier-Objekte. Bestände sind in gewissem Sinn abstrakte Elemente. Es sind die Rendering-Objekte, die tatsächlich die Daten enthalten.
Renderings weisen zwei Methoden zum Daten-Speichern auf:

– In RAM als ein Datenblock.
– Auf Platte als eine Datei.

Die Verwendung von RAM oder Platte basiert zum größten Teil auf dem Umfang und dem Typ der zu speichernden Daten. Üblicherweise sind beispielsweise MIDI Daten RAM-gestützt, und Audio-Daten Datei-gestützt.
Von allen Objekten des Sendeobjektmodells werden nur Rendering-Objekte von dem Zwischenspeichermodul 36 zwischengespeichert. Da Rendering-Objekte vom Server 12 auf einer Nur-bei-Anfrage-Basis gesendet werden, kann die Dienstekomponente 24 überprüfen, ob das Rendering-Objekt von der lokalen Sequenzer Station 14 vor dem Senden der Daten-Anforderung auf Platte gespeichert worden ist.
In der bevorzugten Ausführungsform sind Bestand-Rendering-Objekte auf drei spezielle Typen beschränkt:
Quelle: Spezifiziert die Original-Quell-Aufnahme- stellt buchstäblich eine Bit-genaue Wiedergabe der Original-aufgezeichneten Datei dar.
Standard: Spezifiziert das Standard-Rendering der zu verwendenden Datei, im Allgemeinen eine moderat komprimierte Version der Original-Quell-Daten.
Preview: Spezifiziert das Rendering, welches heruntergeladen werden soll, um ein Preview über die Medien zu erhalten. Dies ist im Allgemeinen eine hoch-komprimierte Version der Original-Quell-Daten.
Jeder der im Anhang angegebenen Bestand-Aufrufe auf hoher Ebene verwendet ein Flag, welches angibt, welche der drei Rendering-Objekt-Typen von dem Aufruf referenziert wird.
Üblicherweise wird der Typ des ausgewählten Rendering-Objektes auf dem in dem Bestand enthaltenen Datentyp basieren. Einfache Datentypen – wie MIDI – werden keine Kompression oder alternative Renderings verwenden. Komplexere Datentypen – wie Audio oder Video – verwenden eine Anzahl verschiedener Rendering-Objekte, um eine effiziente Bandbreiten-Ausnutzung zu ermöglichen.
Ein erstes Beispiel der Anwendung von Bestandobjekten wird unter Verwendung von MIDI-Daten erklärt. Da der Daten-Umfang verhältnismäßig klein ist, wird nur das Quell-Rendering-Objekt gesendet, ohne Komprimierung und ohne alternative Renderings-Typen.
Der Sender erzeugt ein neues Bestandobjekt, setzt seine Daten, und sendet es an den Server 12.
Schritt 1
Erzeugen eines Bestandobjekt
Der erste Schritt für Client-Anwendungskomponente 20 ist das Erzeugen eines Bestandobjektes. Dies wird in der normalen Weise durchgeführt:
Schritt 2
Setzen der Bestand-Daten und der Daten-Art
Der nächste Schritt ist das Setzen der Daten und der Daten-Art für das Objekt. In diesem Fall werden, weil der gesendete Daten-Umfang klein ist, nur die Quell-Daten gesetzt:
Der
-Aufruf wird verwendet, um die Daten des Quell-Renderings zu setzen.
Die Daten-Art der Daten wird auf
gesetzt, um zu signalisieren, dass die Daten im Standard-MIDI Dateiformat vorliegen.
Schritt 3
Setzen der Bestand-Flags
Der dritte Schritt ist das Setzen der Flags für den Bestand. Diese Flags legen fest, welche Dastellung des Bestandes beim nächsten Aufruf von
zum Server 12 hochgeladen wird. Im vorliegenden Fall sind nur die Quell-Daten notwendig.
Setzen des
-Flags spezifiziert, dass das Quell-Rendering für das Objekt hochgeladen werden muss.
Schritt 4
Senden
Der letzte Schritt ist das Senden. Dies geschieht in normaler Weise, in Antwort auf einen vom Anwender erzeugten Befehl:
Um einen Bestand zu empfangen, behandelt die Client-Anwendungskomponente 20 der lokalen Sequenzerstation 14 die Neuer-Bestand-Mitteilung und fragt nach den Bestand-Daten nach. Wenn die
-Mitteilung empfangen wird, wurde das Bestandobjekt vom Datenverpackungsmodul 28 erzeugt. Client-Anwendungskomponente 20 erzeugt eine Schnittstelle zu dem Bestandobjekt und erfragt seine Attribute und verfügbaren Renderings:
Daten müssen immer von der lokalen Sequenzerstation 12 für Bestände angefragt werden. Dies erlaubt Flexibilität beim Empfangen von großen Daten-Mengen. Hierzu initiiert die Client-Anwendungskomponente 20 einfach das Herunterladen:
Wenn die Daten erfolgreich heruntergeladen worden sind, wird die
-Mitteilung gesendet. An diesem Punkt sind die Daten lokal verfügbar, und die Client-Anwendungskomponente 20 ruft
auf, um eine Kopie der Daten zu erhalten:
In einem zweiten Beispiel wird ein Audiodaten-Bestand erzeugt. Die Client-Anwendungskomponente 20 setzt die Audiodaten und von der Dienstekomponente 24 wird automatisch ein komprimiertes Preview-Rendering erzeugt.
In diesem Szenario ist der Datenumfang relativ groß, so dass die Daten in einer Datei gespeichert werden.
Der Sender verfolgt viele der Schritte des einfachen MIDI-Falls von oben. Diesmal werden allerdings die Daten in einer Datei gespeichert, und es wird ein anderes Sende-Flag verwendet:
Da
spezifiziert worden war, wird die Dienstekomponente 24 automatisch das Preview-Rendering aus dem spezifizierten Quell-Rendering erzeugen, und die Flags für sein Heraufladen beim nächsten Aufruf von
setzen.
Alternativ hierzu könnte das Preview durch Aufruf von
explizit erzeugt werden:
In diesem Beispiel war
nicht gesetzt. Dies bedeutet, dass das Quell-Rendering nicht zum Heraufladen markiert wurde und nicht zum Server 12 heraufgeladen werden wird.
Das Quell-Rendering könnte zum späteren Heraufladen beigefügt werden durch Aufruf von:
Wenn ein Bestand von einer entfernten Sequenzerstation 16 erzeugt und gesendet wird, erzeugt der Mitteilungswarteschlangenbehandler 28 eine
-Mitteilung. Die Client-Anwendungskomponente sucht nach dem Bestandobjekt, im Allgemeinen mittels eines ID-Nachschlagens ("lookup") innerhalb ihres eigenen Datenmodells:
Wie oben würden die Daten angefordert:
spezifiziert die Klassifikation der herunterzuladenden Rendering-Daten und des Verzeichnisses, in das die heruntergelade Datei geschrieben werden soll.
Wenn die Daten erfolgreich heruntergeladen worden sind, wird die
Mitteilung gesendet.
Jetzt sind die komprimierten Daten verfügbar, aber sie müssen dekomprimiert werden:
Wenn die Daten erfolgreich dekomprimiert worden sind, wird die
Mitteilung gesendet:
Die Dienstekomponente 24 verfolgt nach, welche Dateien sie auf Platte geschrieben hat. Die Client- Anwendungskomponente 20 kann dann diese Dateien überprüfen, um festzustellen, welche Dateien während eines Daten-Anfragens heruntergeladen werden müssen. Dateien, die bereits verfügbar sind, müssen nicht heruntergeladen werden. Aufrufe an
zeigen an, ob Medien bereits heruntergeladen worden sind.
Dienstekomponente 24 verwendet Daten-Lokalisier-Dateien, um Daten für Rendering-Objekte nachzuverfolgen und diese zwischenzuspeichern. Jede Daten-Lokalisier-Datei wird identifiziert anhand der ID des zugehörigen Renderings, der Zeit der letzten Änderung des Renderings und einem Präfix, welcher anzeigt, ob die zwischengespeicherten Daten vorverarbeitet (komprimiert) oder nachgearbeitet (dekomprimiert) worden sind.
Für Datei-basierte Rendering-Objekte werden Dateien an von der Client-Anwendung festgelegten Stellen geschrieben. Dies erlaubt es, Medien-Dateien projektweise in Ordner zu gruppieren. Es bedeutet auch, dass die Client-Anwendungskomponente 20 ein Datei-Organisations-Schema ihrer Wahl verwenden kann.
Jedes Projektobjekt weist einen korrespondierenden Ordner in dem Zwischenspeicher-Verzeichnis auf. Wie bei den Daten-Lokalisierern, sind die Verzeichnisse mit der ID des zugehörigen Projektes bezeichnet. Daten-Lokalisier-Objekte werden innerhalb des Ordners des sie enthaltenden Projektes gespeichert.
Da Medien-Dateien recht großen Platten-Speicherplatz beanspruchen können, ist es wichtig, dass nicht verwendete Dateien gelöscht werden. Dies ist insbesondere gegeben, wenn die derzeitige Rendering-Datei durch eine Datei höherer Qualität ersetzt wird. Beispielsweise kann ein Anwender für eine Weile mit der Preview-Version eines Bestandes arbeiten und sich dann später entscheiden, das Quell-Rendering herunterzuladen. Jetzt ist das Preview- Rendering redundant.
stellt eine Methode zum Löschen dieser redundanten Daten zur Verfügung:
Dieser Aufruf löscht die Rendering-Datei vom Zwischenspeicher und löscht die Datei von der Platte oder vom RAM.
Für Fachleute ist offensichtlich, dass verschiedene Modifikationen und Veränderungen an den erfindungsgemäßen Verfahren und Systemen durchgeführt werden können, ohne vom Gültigkeitsbereich der Erfindung abzuweichen. Wenn beispielsweise alle in der oben beschriebenen Erfindung vorhandenen Konstanten mit der gleichen Konstante multipliziert würden, wäre das Ergebnis eine skalierte Version der vorliegenden Erfindung, und wäre funktionell äquivalent. Der wahre Bereich der Ansprüche ist durch die folgenden Ansprüche definiert.

Claims

Vorrichtung zum gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation (14) und wenigstens einer entfernten Sequenzerstation (16) mittels eines Servers (12) über ein Netzwerk (18), wobei die Sequenzdaten audiovisuelle Ereignisse verkörpern, von welchen jedes beschreibende Eigenschaften und Zeiteigenschaften hat, wobei die Vorrichtung aufweist: ein erstes Schnittstellenmodul (26), welches Befehle von einer lokalen Sequenzerstation empfängt; ein Datenverpackungsmodul, welches mit dem ersten Schnittstellenmodul verbunden ist, wobei das Datenverpackungsmodul auf die empfangenen Befehle durch Einkapseln der Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten reagiert, welche die beschreibenden Eigenschaften und Zeitbeziehungen der Sequenzdaten beibehalten, ebenso extrahiert das Datenverpackungsmodul Sequenzdaten von Sendedateneinheiten, welche von dem Server zum Zugriff durch das lokale Sequenzerendgerät empfangen wurden; einen Sendungsbehandler (30), der mit dem ersten Schnittstellenmodul und dem Datenverpackungsmodul verbunden ist, wobei der Sendungsbehandler (30) über das erste Schnittstellenmodul empfangene Befehle verarbeitet; ein Serverkommunikationsmodul (32), welches auf durch den Sendungsbehandler verarbeitete Befehle antwortet durch Übertragen von Sendedateneinheiten zu dem Server zum Verteilen an wenigstens eine entfernte Sequenzerstation, wobei das Serverkommunikationsmodul auch Daten-verfügbar-Nachrichten und Sendedateneinheiten vom Server empfängt; und einen Mitteilungswarteschlangen-Behandler (34), welcher mit dem Serverkommunikationsmodul verbunden ist und für den Empfang von Daten-verfügbar-Nachrichten und Sendedateneinheiten von dem Server empfangen kann, zum Übertragen von Mitteilungen zu der ersten Schnittstelle zum Zugriff durch das lokale Sequenzerendgerät.
Vorrichtung gemäß Anspruch 1, wobei das Datenverpackungsmodul die Sequenzdaten in Sendedateneinheiten einkapselt, welche eine Anordnungsdateneinheit aufweisen, die eine Zeitreferenz bildet und wenigstens eine Spurdateneinheit, welche eine der Anordnungszeitreferenz entsprechende Spurzeitreferenz aufweist, wobei jede Spurdateneinheit wenigstens eine zugeordnete Ereignisdateneinheit aufweist, welche ein audiovisuelles Ereignis zu einer angegebenen Zeit mit Bezug auf den zugeordneten Spurzeitbezug darstellt.
Vorrichtung gemäß Anspruch 2, wobei die durch die lokale Sequenzerstation erzeugten Sequenzdaten Multimediadaten-Quelldateneinheiten aufweist und wobei das Datenverpackungsmodul die Multimedia-Quelldateneinheiten in wenigstens eine Art einer bestanddarstellenden Sendeeinheit einkapselt, wobei jede bestanddarstellende Sendeeinheitsart eine Version von Multimediadaten-Quelldaten angibt, welche einen unterschiedlichen Grad von Datenkompression zeigen.
Vorrichtung gemäß Anspruch 3, wobei das Serverkommunikationsmodul auf durch den Sendungsbehandler bearbeitete Befehle durch Übertragen von bestanddarstellenden Sendungseinheiten einer ausgewählten bestanddarstellenden Sendeeinheitsart zu dem Server zum Verteilen auf wenigstens eine entfernte Sequenzerstation antwortet.
Vorrichtung gemäß Anspruch 3, wobei die durch die lokale Sequenzerstation erzeugten Sequenzdateneinheiten Clipdateneinheiten aufweisen, wobei jede einen festgelegten Teil einer Multimediadaten-Quelldateneinheit darstellt und wobei das Datenverpackungsmodul die Clipdateneinheiten in Sendeclipdateneinheiten einkapselt.
Vorrichtung gemäß Anspruch 5, wobei das Datenverpackungsmodul Sequenzdateneinheiten in Sendeclipereignisdateneinheiten verpackt, wobei jedes einen festgelegten Anteil einer Multimediadaten-Quelldateneinheit darstellt, welche zu einer festgelegten Zeit in Bezug auf eine zugeordnete Spurzeitreferenz beginnt.
Vorrichtung gemäß Anspruch 6, wobei: das Datenverpackungsmodul Sequenzdateneinheiten in Rahmenereignisdateneinheiten einkapselt, von denen jedes eine Rahmenereigniszeitreferenz aufweist, welche zu einer festgelegten Zeit mit Bezug auf eine zugeordnete Spurzeitreferenz eingerichtet ist; jede Rahmenereignisdateneinheit weist wenigstens eine Zeitgeradenereignis-Dateneinheit auf, wobei jede Zeitgeradenereignis-Dateneinheit eine Zeitgeradenereignis-Zeitreferenz hat, welche zu einer festgelegten Zeit mit Bezug zu der zugeordneten Rahmenereignis-Zeitreferenz eingerichtet wurde und wenigstens eine Ereignisdateneinheit aufweist, welche ein audiovisuelles Ereignis zu einer festgelegten Zeit mit Bezug zu der zugeordneten Zeitgeradenereignis-Zeitreferenz darstellt.
Vorrichtung gemäß Anspruch 1, welche eine Verbindungssteuerungskomponente aufweist, welche in Antwort auf die Befehle, die von der lokalen Sequenzerstation empfangen wurden, zum Einrichten des Zugriffs über den Server zu einer vorgegebenen Untermenge von auf dem Server gespeicherten Sendedateneinheiten.
Vorrichtung gemäß Anspruch 8, wobei die Verbindungssteuerungskomponente von der lokalen Sequenzerstation Registrierungsdaten empfängt und den Zugriff herstellt zu einer vorgegebenen Untermenge von auf dem Server gespeicherten Sendedateneinheiten, in Übereinstimmung mit auf dem Server gespeicherten Berechtigungsdaten.
Vorrichtung gemäß Anspruch 1, wobei das Datenverpackungsmodul: Sequenzdaten in erste und zweite Arten von Sendedateneinheiten einkapselt; auf den Empfang einer Nachricht, welche die Verfügbarkeit der ersten Art von Sendedateneinheit am Server anzeigt durch Veranlassen des Serverkommunikationsmoduls zum Beginnen des Herunterladens der ersten Art von Sendedateneinheit antwortet, ohne die Autorisierung von der Client-Anwendungskomponente zu benötigen; und auf den Empfang einer Nachricht, welche die Verfügbarkeit der zweiten Art von Sendedateneinheit am Server anzeigt durch Veranlassen des Serverkommunikationsmoduls zum Beginnen des Herunterladens der zweiten Art von Sendedateneinheit nur nach Empfang eines Befehls zum Herunterladen von der Client-Anwendungskomponente antwortet.
Vorrichtung gemäß Anspruch 10, wobei die erste Art von Sendedateneinheit eine nichtmediale Sendedateneinheit aufweist und die zweite Art von Sendedateneinheit eine mediale Sendedateneinheit aufweist.
Vorrichtung zum Gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation (14) und wenigstens einer entfernten Sequenzerstation (16) mittels eines Servers (12) über ein Netzwerk (18), wobei die Sequenzdaten audiovisuelle Ereignisse verkörpern, wobei jedes beschreibende Eigenschaften und Zeiteigenschaften hat und Multimediadaten-Quelldateneinheiten aufweist, wobei die Vorrichtung aufweist: ein erstes Schnittstellenmodul (26), welches Befehle von einer lokalen Sequenzerstation empfängt; ein Datenverpackungsmodul (28), welches mit dem ersten Schnittstellenmodul verbunden ist, wobei das Datenverpackungsmodul auf die empfangenen Befehle durch Einkapseln der Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten reagiert, welche die beschreibenden Eigenschaften und Zeitbeziehungen der Sequenzdaten beibehalten, das Datenverpackungsmodul kapselt die Multimedia-Quelldateneinheiten in wenigstens eine Art von bestanddarstellender Sendungseinheit ein, wobei jede darstellende Sendungseinheitsart eine Version von Multimediadaten-Quelldaten festlegt, welche einen unterschiedlichen Grad von Datenkompression zeigt, das Datenverpackungsmodul extrahiert auch Sequenzdaten von Sendedateneinheiten, welche von dem Server empfangen wurden; einen Sendungsbehandler (30), der mit dem ersten Schnittstellenmodul und dem Datenverpackungsmodul verbunden ist, wobei der Sendungsbehandler (30) über das erste Schnittstellenmodul empfangene Befehle verarbeitet; ein Serverkommunikationsmodul (32), welches auf durch den Sendungsbehandler verarbeitete Befehle durch Übermittlung von Sendedateneinheiten zu dem Server zum Verteilen an wenigstens eine entfernte Sequenzerstation antwortet, wobei das Serverkommunikationsmodul auch Sendedateneinheiten von wenigstens einer entfernten Sequenzerstation empfängt; und
Vorrichtung zum Gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation (14) und wenigstens einer entfernten Sequenzerstation (16) mittels eines Servers (12) über ein Netzwerk (18), wobei die Sequenzdaten audiovisuelle Ereignisse verkörpern, wobei jedes beschreibende Eigenschaften und Zeiteigenschaften hat, wobei die Vorrichtung aufweist: ein erstes Schnittstellenmodul (26), welches Befehle von einer lokalen Sequenzerstation empfängt; ein Datenverpackungsmodul (28), welches mit dem ersten Schnittstellenmodul verbunden ist, wobei das Datenverpackungsmodul auf die empfangenen Befehle durch Einkapseln der Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten reagiert, welche die beschreibenden Eigenschaften und Zeitbeziehungen der Sequenzdaten beibehalten, die Sendedateneinheiten weisen kundenspezifische Sendedateneinheiten auf, Standard-Sendedateneinheiten, welche die Hierarchie von Sequenzdaten ausdrücken und spezialisierte Sendedateneinheiten, welche alle Attribute von Standard-Sendedateneinheiten plus zusätzliche Attribute aufweisen, das Datenverpackungsmodul extrahiert auch Sequenzdaten von Sendedateneinheiten, welche von dem Server empfangen wurden; einen Sendungsbehandler (30), der mit dem ersten Schnittstellenmodul und dem Datenverpackungsmodul verbunden ist, wobei der Sendungsbehandler (30) über das erste Schnittstellenmodul empfangene Befehle bearbeitet; ein Serverkommunikationsmodul (32), welches auf durch den Sendungsbehandler bearbeitete Befehle durch Übermitteln von Sendedateneinheiten zu dem Server zum Verteilen an wenigstens eine entfernte Sequenzerstation antwortet, wobei das Serverkommunikationsmodul auch Sendedateneinheiten über den Server von wenigstens einer entfernten Sequenzerstation empfängt und die empfangenen Sendedateneinheiten zu dem Datenverpackungsmodul weitersendet.
Verfahren zum Gemeinsamen Benutzen von Sequenzdaten zwischen einer lokalen Sequenzerstation (14) und wenigstens einer entfernten Sequenzerstation (16) mittels eines Servers (12) über ein Netzwerk (18), wobei die Sequenzdaten audiovisuelle Ereignisse darstellen, von denen jedes beschreibende Eigenschaften und Zeiteigenschaften hat, wobei das Verfahren aufweist: Empfangen von Befehlen über eine Client-Anwendungskomponente (20) von einem Benutzer an einer lokalen Sequenzerstation; Antworten auf die empfangenen Befehle durch Einkapseln von Sequenzdaten von der lokalen Sequenzerstation in Sendedateneinheiten, welche die beschreibenden Eigenschaften und Zeitbeziehungen der Sequenzdaten beibehalten und Übertragen von Sendedateneinheiten zu dem Server zum Verteilen an wenigstens eine entfernte Sequenzerstation; Empfangen von Daten-verfügbar-Nachrichten von dem Server; Antworten auf den Empfang von Daten-verfügbar-Nachrichten von dem Server zum Übertragen von Benachrichtigungen zu der Client-Anwendungskomponente; Antworten auf von der Client-Anwendungskomponente empfangenen Befehle zum Anfordern des Herunterladens von Sendedateneinheiten von dem Server; und Empfangen von Sendedateneinheiten von dem Server und Extrahieren von Sequenzdaten von den empfangenen Sendedateneinheiten zum Zugriff durch die Client-Anwendungskomponente.