DE69735054T2

DE69735054T2 - Verteiltes echtzeitkommunikationssystem

Info

Publication number: DE69735054T2
Application number: DE69735054T
Authority: DE
Inventors: Donaldson Matthew West Falmouth MOLLER
Original assignee: Avid Technology Inc
Current assignee: Avid Technology Inc
Priority date: 1996-04-01
Filing date: 1997-03-27
Publication date: 2006-09-14
Anticipated expiration: 2017-03-28
Also published as: AU2298597A; JP2000507715A; DE69735054D1; JP3685805B2; CA2250855C; AU730214B2; EP0891665B1; HK1018142A1; EP0891665A1; WO1997037476A1; CA2250855A1; ATE315301T1

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich auf die Echtzeit-Kommunikation zwischen verteilten Clients wie in einem Client-Server-Netz. Sie ist insbesondere, aber nicht ausschließlich, geeignet, um den Client-Anwendern zu ermöglichen, in Echtzeit miteinander Musik zu spielen.
Hintergrund der Erfindung
Ein Client-Server-Paradigma ist ein Computer-System, in dem verteilte Clients einen gemeinsamen Server für die Datenübertragung und -manipulation verwenden. In 1 ist ein schematisches Beispiel gezeigt, in dem ein Server 10 mit drei verteilten Client-Computern 12 kommuniziert. Der Server kann sowohl Programme ausführen als auch als ein einfacher "unintelligenter' Datenübertragungs-Hub wirken. Jeder Client kann Daten zu jedem anderen mit dem Server verbundenen Client senden, in dem er die Daten durch den Server sendet, der den Austausch der Informationen mit jedem der anderen Clients durch ein gemeinsames Datenübertragungssystem, wie z. B. ein Computer-Netz, erlaubt.
Die Client-Server-Technologie ist gut begründet und wird weit und breit verwendet, z. B. auf dem Gebiet der Finanzen, wo Broker Echtzeit-Datendienste verwenden, um mit den Bewegungen der Aktienpreise auf dem laufenden zu bleiben. Die in diesen Systemen empfangenen Informationen werden in Echtzeit wahrgenommen, weil jede Verzögerung minimal und unwichtig ist. Falls jedoch das Client-Server-Paradigma ausgenutzt wird, um mehreren verteilten Clients, angenommen in einer Anzahl verschiedener Länder, zu erlauben, zu kommunizieren, können ihre Zeitverzögerungen wichtig werden. Dies ist insbesondere der Fall, wo die Clients miteinander in Echtzeit zusammenarbeiten und in Wechselwirkung treten, wo die Aktionen jedes Clients die Reaktionen der anderen Clients bestimmen oder beeinflussen und diese Aktionen in hohem Grade zeitabhängig sind, z. B. wenn Musik in einem Ensemble gespielt wird. In derartigen Systemen machen die inhärenten Zeitverzögerungen, die auferlegt werden, eine unmittelbare, sofortige Reaktion unmöglich. Dies gilt insbesondere in modernen Computer-Netzen, in denen Verzögerungen von bis zu einigen Sekunden auftreten können. Diese Länge der Verzögerung würde das Spielen von Musik in Echtzeit zwischen verteilten Musikern unmöglich machen. Verzögerungen von selbst einigen Millisekunden können ästhetisch missfallend sein.
Ein Gruppensynchronisationsprotokoll ist in "Multimedia Group Synchronisation Protocols for Integrated Services Networks" (IEEE Journal on Selected Areas in Communications, Bd. 14, 1996) offenbart. Dieses Dokument beschäftigt sich mit den Problemen einer Synchronizität, des Verzögerungs-Jitters und der Drift des lokalen Taktgebers in verschiedenen Echtzeit-Multimedia-Verkehrssituationen. Ein Protokoll für die Gruppensynchronisation über Punkt-Mehrpunkt-, Punkt-Punkt-, Abruf- oder Gruppenkonfigurationen eines Netzes, wie z. B. eine Telekonferenz oder ein Teleorchester, wird erörtert, wo die durch den Verzögerungs-Jitter zwischen einem Sender und einem Empfänger in einem Netz und eine Drift des lokalen Taktgebers bei jedem Client im Netz verursachte Asynchronizität unter Verwendung eines dynamischen Periodeneinstellprotokolls kompensiert wird.
Es ist erwünscht, dass Musiker über Computer-Netze miteinander in Wechselwirkung treten können, um ihnen zu ermöglichen, an verteilten Orten in Echtzeit zusammen zu spielen. Es gibt jedoch keinen Weg, mehrere Clients zu veranlassen, Daten gleichzeitig zu senden und zu empfangen. Selbst in den schnellsten Netzen, die die Daten mit Lichtgeschwindigkeit übertragen, besitzt die transkontinentale Datenübertragung eine Verzögerung, die für viele Musiksituationen sowohl wahrnehmbar als auch unannehmbar ist.
Zusammenfassung der Erfindung
Die Erfindung schafft ein Verfahren zum Synchronisieren von Daten von mehreren Quellen über ein Client-Server-Netz, das die folgenden Schritte umfasst: Senden eines ersten Startbefehls von dem Server zu einem ersten Client, um bei dem ersten Client einen lokalen Taktgeber zu starten, Senden eines kontinuierlichen Datenstroms von dem ersten Client zu dem Server, Senden eines weiteren Startbefehls von dem Server zu mehreren weiteren Clients, um in jedem der weiteren Clients einen lokalen Taktgeber zu starten, wobei der weitere Startbefehl in Bezug auf den ersten Startbefehl verzögert ist, Senden einer Datenfolge von jedem der mehreren weiteren Clients zu dem Server, Senden des kontinuierlichen Datenstroms von dem Server zu jedem der mehreren weiteren Clients, Resynchronisieren des empfangenen kontinuierlichen Datenstroms bei jedem der mehreren weiteren Clients, Senden der Datenfolgen von dem Server zu jedem der mehreren weiteren Clients und zu dem ersten Client, wobei der Schritt des Sendens das Zurücksenden einer gegebenen Datenfolge zu einem entsprechenden weiteren Client, von dem aus sie gesendet wurde, entweder enthält oder nicht enthält, Resynchronisieren der empfangenen Datenfolgen bei jedem der Clients auf den lokalen Taktgeber und mehrfaches Wiederholen der empfangenen und lokal erzeugten Datenfolgen bei jedem der Clients.
Die Erfindung schafft außerdem ein computerlesbares Speichermedium, das so konfiguriert ist, dass es einen Computer dazu veranlasst, die folgenden Schritte auszuführen: Empfangen eines ersten Startbefehls von einem Server zu dem Computer, um einen lokalen Taktgeber in dem Computer zu starten, Senden eines kontinuierlichen Datenstroms von dem Computer zu dem Server, Empfangen mehrerer Datenfolgen von dem Server, Synchronisieren der empfangenen Folgen mit dem lokalen Taktgeber, mehrfaches Wiederholen der empfangenen Datenfolgen, um Ausgangsdaten zu erzeugen, Senden der Ausgangsdaten und des kontinuierlichen Datenstroms zu einem Ausgang.
Die Erfindung schafft ferner ein Computersystem, das umfasst: eine Zentraleinheit und einen zugeordneten Speicher, einen lokalen Taktgeber sowie eine Eingabevorrichtung zum Eingeben von Daten in das System, Mittel, um eine Datenfolge von der Eingabevorrichtung zu empfangen und um die eingegebene Folge mit dem lokalen Taktgeber zu synchronisieren, Mittel, um die Datenfolge an einen entfernten Server zu senden, Mittel, um mehrere weitere Datenfolgen, die in verschiedenen Computersystemen erzeugt werden, von dem Server zu empfangen, Mittel, um die empfangenen Folgen mit dem lokalen Taktgeber zu synchronisieren, Mittel, um die eingegebene Folge und jede empfangene Datenfolge mehrmals zu wiederholen, Mittel, um die mehreren wiederholten eingegebenen Folgen und empfangenen Folgen zu einer Ausgabevorrichtung zu senden, einen Puffer, Mittel, um einen kontinuierlichen Datenstrom in dem Puffer zu empfangen, Mittel, um den Datenstrom von dem Puffer mit dem lokalen Taktgeber zu synchronisieren, und Mittel, um den kontinuierlichen Datenstrom zu der Ausgabevorrichtung synchron mit den wiederholten Datenfolgen auszugeben.
Die Erfindung schafft noch ferner eine Vorrichtung zum Synchronisieren von Daten von mehreren Quellen über ein Client-Server-Netz, die umfasst: Mittel, um einen ersten Startbefehl von dem Server zu einem ersten Client zu senden, um bei dem ersten Client einen lokalen Taktgeber zu starten, Mittel, um einen kontinuierlichen Datenstrom von dem ersten Client zu dem Server zu senden, Mittel, um einen weiteren Startbefehl von dem Server zu mehreren weiteren Clients zu senden, um in jedem der weiteren Clients einen lokalen Taktgeber zu starten, wobei der weitere Startbefehl in Bezug auf den ersten Startbefehl verzögert ist, Mittel, um eine Datenfolge von jedem der mehreren weiteren Clients zu dem Server zu senden, Mittel, um den kontinuierlichen Datenstrom von dem Server zu jedem der mehreren weiteren Clients zu senden, Mittel, um den empfangenen kontinuierlichen Datenstrom bei jedem der mehreren weiteren Clients zu resynchronisieren, Mittel, um die Datenfolgen von dem Server zu jedem der mehreren weiteren Clients und zu dem ersten Client zu senden, Mittel, um die empfangenen Datenfolgen bei jedem der Clients auf den lokalen Taktgeber zu resynchronisieren, und Mittel, um die empfangenen Datenfolgen bei jedem der Clients mehrmals zu wiederholen.
Die Ausführungsformen der Erfindung besitzen den Vorteil, den Clients an verteilten Orten zu erlauben, in Echtzeit in Wechselwirkung zu treten.
Die Ausführungsformen der Erfindung besitzen den Vorteil, die zeitabhängigen Informationen von mehreren Quellen zu synchronisieren.
Die Ausführungsformen der Erfindung besitzen den Vorteil, mehreren Musikern zu erlauben, von verteilten Orten in Echtzeit zusammen zu spielen.
Die Ausführungsformen der Erfindung besitzen den Vorteil, den Clients zu erlauben, von verteilten Orten, an denen ein Client einen improvisierten, sich nicht wiederholenden Datenstrom bereitstellt, in Echtzeit in Wechselwirkung zu treten.
In einer bevorzugten Ausführungsform eines ersten Aspekts der Erfindung werden ein Verfahren und eine Vorrichtung geschaffen, um Daten von mehreren Quellen zu synchronisieren. Ein Datenstrom von einer ersten Quelle wird erzeugt und zu einem Server gesendet, wo er an alle teilnehmenden Clients verteilt wird. Jeder Client sendet seinen eigenen Datenstrom, der wiederum zu jedem Client zurückgeworfen wird. Die in jedem Client empfangenen Datenströme werden auf einen lokalen Taktgeber synchronisiert, wobei die Kontinuität aufrechterhalten wird, indem die Datenströme in einer Schleife durchlaufen werden, sodass jeder mehrmals wiederholt wird.
Diese Ausführungsform erlaubt, dass die interaktiven Kommunikationen, z. B. über ein Computer-Netz, ungeachtet der Unterschiede in den Zeitverzögerungen zwischen dem Server und den einzelnen Clients synchronisiert werden. Sie ist auf Medien, wie z. B. Musik, anwendbar, wo der Datenstrom jedes Clients einen musikalischen Part darstellt, wobei der Server das Ensemblespiel zu jedem Client zurückwirft. Der durch jedem Client erzeugte Datenstrom stellt eine musikalischen Folge dar. In einer bevorzugten Ausführungsform der Erfindung erzeugen einer oder mehrere der Clients eine Folge von Folgen oder eine Makro-Folge. Dies ermöglicht, dass musikalisch komplexere Muster gespielt werden, wobei auf diese Weise die Flexibilität und Nützlichkeit der Erfindung vergrößert werden.
Da sich der erste Aspekt der Erfindung darauf stützt, dass jeder Datenstrom in einer Schleife durchlaufen wird, um die Kontinuität zu erreichen und so das Echtzeit-Spiel auszuführen, schließt er notwendigerweise die Improvisation oder nicht sequentielle Daten von den Clients aus. Beim Spiel der Musik ist dies nachteilig, weil es die Kreativität und die Kunstfertigkeit, die durch jeden der Spieler ausgedrückt werden können, begrenzt.
Ein zweiter Aspekt der Erfindung schafft ein Verfahren und eine Vorrichtung, die erlauben, dass ein Datenstrom von einem der Clients ein nicht sequentieller, sich nicht wiederholender Strom ist, der nicht in einer Schleife durchlaufen wird und der eine improvisierte musikalische Linie darstellen kann.
In einer bevorzugten Ausführungsform des zweiten Aspekts der Erfindung beginnt der Client, der die improvisierte oder "Solo"-Linie schafft, das Senden seines Datenstroms zu dem Server vor den verbleibenden Clients. Der Server wirft diese Daten zu den Clients zurück, von denen sie jeder in einem lokalen Puffer hält und sie dann auf seinen eigenen lokalen Taktgeber synchronisiert. Die relative Synchronisation der verbleibenden Clients wird in derselben Weise wie der erste Aspekt der Erfindung gehandhabt. In dieser Weise werden alle Parts in allen Clients synchronisiert. Die Tatsache, daß die Nicht-Solo-Datenströme nach dem Beginn der Solo-Linie beim Solo-Client ankommen, macht nichts, da diese Linien sich wiederholend sind und einfach die Synchronisation auf den lokalen Taktgeber erfordern.
Vorzugsweise ist die Verzögerung zwischen dem Senden der Daten des Solo-Clients zum Taktgeber und dem Senden der verbleibenden Datenströme etwa gleich der längsten Verzögerung zwischen einem Client und dem Server.
Beschreibung der Zeichnung
Nun werden bevorzugte Ausführungsformen der Erfindung lediglich beispielhaft unter Bezugnahme auf die beigefügte Zeichnung beschrieben, worin:
1 eine schematische graphische Darstellung eines Client-Server-Paradigmas ist, das vorher erörtert worden ist;
2 eine schematische Ansicht eines Client-Endgeräts ist;
3 eine schematische graphische Darstellung ist, die die Schleifenbildung der Datenströme veranschaulicht und einen ersten Aspekt der Erfindung verkörpert;
4 eine schematische graphische Darstellung ist, die zeigt, wie mehrere Datenströme in einer Schleife durchlaufen werden können;
5 eine Darstellung einer Partitur mit vier Parts, die als Datenströme ausgedrückt sind, ist;
6 zeigt, wie die Partitur nach 5 klingen würde, wenn sie durch die Client-Software wiedergegeben wird;
7 zeigt, wie ein fünfter Part, der einen längeren Datenstrom besitzt, in die Partitur eingeführt werden kann;
8 ein Ablaufplan ist, der im Umriss die Operation des Servers zeigt;
9 ein Ablaufplan ist, der zeigt, wie in jedem Client ein lokaler Taktgeber verwendet wird;
10 unter Verwendung der herkömmlichen Notenschrift zeigt, wie ein Client eine Folge erzeugt und sie zum Server sendet, der sie dann zu jedem Client zurückwirft;
11 unter Verwendung der herkömmlichen Notenschrift zeigt, wie das System mit einer Folge umgeht, die zwei einzelne Folgen umfasst;
12 unter Verwendung der herkömmlichen Notenschrift die Folgen, die durch einen Client-Server empfangen werden würden, und ihre relativen Zeiten, wenn es vier Clients gibt, zeigt;
13 ein schematischer Überblick über das Verfahren und die Verarbeitungseinheiten ist, die in dem System nach den 1 bis 12 verwendet werden;
14 eine schematische graphische Darstellung ist, die zeigt, wie ein improvisierter Solo-Part zu dem Ensemble aus fünf Parts nach 7 hinzugefügt werden kann, und die einen zweiten Aspekt der Erfindung verkörpert;
15 veranschaulicht, wie der Solo-Part vor den verbleibenden Clients begonnen wird; und
16 ein zu 13 für den zweiten Aspekt der Erfindung ähnlicher Überblick ist.
Beschreibung der besten Art und Weise
Das früher dargestellte Problem war eines der Übertragungsgeschwindigkeit; die Gesetze der Physik schreiben vor, dass die maximale Übertragungsgeschwindigkeit die Lichtgeschwindigkeit ist, die ungenügend schnell ist, um die Clients an interkontinentalen Orten zu synchronisieren.
Es ist erkannt worden, dass dieses Problem vermieden werden kann, indem eine Linie von Informationen oder Daten bei jedem Client in einen oder mehrere Datenströme zerlegt wird und diese Ströme zum Server gesendet werden. Da der Server alle einzelnen Datenströme zu allen Clients, die vom sendenden Client verschieden sind, zurückwirft, empfängt jeder Client alle von den andern Clients erzeugten Datenströme. Die einzelnen Clients setzen dann die Daten wieder zusammen und halten die Ströme durch einen entsprechenden lokalen Taktgeber in Synchronisation miteinander.
Im verbleibenden Teil der Beschreibung werden die Datenströme in Form von musikalischen Parts erörtert. Es ist jedoch selbstverständlich, dass die Erfindung nicht auf die Synchronisation mehrerer musikalischer Parts eingeschränkt ist, sondern dass sie auf alle zeitabhängigen oder zeitlich geordneten Daten anwendbar ist, die digital dargestellt werden können und z. B. Audio und Video enthalten. Die Erfindung wird außerdem im Kontext jedes Clients beschrieben, der einen einzelnen Part erzeugt. Es gibt jedoch keinen Grund, warum ein gegebener Client nicht mehr als einen Part zum Ensemblespiel beitragen könnte.
Folglich werden die Musikinformationen als eine Kombination mehrerer musikalischer Elemente dargestellt, was zu einem Orchester analog ist, in dem eine Anzahl separater Instrumente separate Linien der Musik synchron spielt, um eine einzige Komposition zu spielen. In der vorliegenden Erfindung wird jeder Instrumentalpart durch einen Datenstrom dargestellt.
Bevor beschrieben wird, wie die Datenströme zusammengesetzt sind, ist es hilfreich, die Hardware-Anforderungen des Systems zu betrachten. In seiner einfachsten Form umfasst das Netz einen Server-Computer und mehrere Client-Computer, wie in 1 veranschaulicht ist.
Ein typischer Client ist in 2 veranschaulicht. Der Computer kann von irgendeinem Typ sein, z. B. ein PC oder ein MAC, der eine MIDI-Schnittstelle (digitale Schnittstelle für Musikinstrumente) 22 und ein Modem 24 besitzt. Die MIDI-Schnittstelle dient als ein Mittel, um Daten einzugeben. Der Client-Computer enthält eine CPU 23, die abgesehen von den anderen Aufgaben die von der MIDI, einer Festplatte 25 und einem Schreib-Lese-Speicher (RAM) 27 eingegebenen Daten lesen kann. Die Client-Software schafft und managt die Datenübertragung mit dem Server über das TCP/IP (Übertragungssteuerungsprotokoll/Internetprotokoll). Die Musikinformationen werden sowohl zum als auch vom Server gesendet. Die Client-Software erlaubt den Anwendern, Musikinformationen über die Standard-MIDI-Schnittstelle aufzuzeichnen.
Diese Informationen werden bezüglich eines lokal laufenden Taktgebers 26 mit einem Zeitstempel versehen und dann zum Server gesendet, damit sie zu jedem Client zurückgeworfen werden. Das Client-Endgerät enthält ein (nicht gezeigtes) Mittel, um den Taktgeber auf eine gewünschte Zählfrequenz einzustellen. In dem beschriebenen Beispiel wird ein MIDI-Eingang verwendet, wobei er bevorzugt ist, da die Daten kompakt und effizient zu senden sind, was ihn ideal für das Arbeiten innerhalb strenger Bandbreitenanforderungen macht. Es könnten jedoch andere Eingänge verwendet werden, wie z. B. ein digitaler Audio- oder Videoeingang.
Die Client-Software empfängt außerdem MIDI-Daten vom Server und gibt MIDI-Daten aus. Dies sind die Daten von allen Clients. Folglich können sie, ebenso wie sie in irgendeiner Standard-MIDI-Vorrichtung aufgezeichnet werden, außerdem auf irgendeiner Standard-MIDI-Vorrichtung wiedergegeben werden. Die MIDI-Ereignisse werden bezüglich des lokalen Taktgebers 26 synchronisiert und wiedergegeben. Abermals ist die MIDI-Vorrichtung nur ein bevorzugtes Wiedergabemedium.
Das Format der Daten, die durch jede Client-MIDI empfangen und mit einem Zeitstempel versehen werden, ist veränderlich. Jede Note kann z. B. durch vier Stücke der Informationen dargestellt sein: wann die Note gespielt worden ist (die relative Zeit), welche Note es gewesen ist (ihre Höhe), wie lange sie gespielt worden ist und wie laut die Note gespielt worden ist (ihre Amplitude). Höher entwickelte Datendarstellungen, wie z. B. digitales Audio, können verwendet werden, aber diese besitzen den Nachteil eines hohen Informationsgehalts, wobei sie in relativ kleinen Netzen ineffizient sind, die für die das Internet nutzenden Verbraucher verfügbar sind. Die wesentlichen identifizierenden Daten sind die relative Zeit der Note. Es können andere Parameter enthalten sein, wie z. B. das Vibrato, der Akzent, das Staccato usw.
Unter Bezugnahme auf die Struktur der Daten erzeugt jeder Client zeitabhängige Ströme der Musikinformationen, die einen Part angeben, wie z. B. eine Bass- oder eine Melodielinie, die lokal mit allen anderen Strömen synchronisiert werden müssen, die durch die anderen Clients erzeugt werden. Die Client-Software versieht die abgehenden Ströme mit einem Zeitstempel mit einer Zeit bezüglich des lokalen Taktgebers. Wie erörtert worden ist, ist eine freie Improvisation nicht möglich, da die inhärenten Verzögerungen beim Übertragen der Daten zu den mehreren Clients ästhetisch unannehmbar sind. Es ist außerdem wichtig, dass es einen kontinuierlichen Strom der Musik gibt. Dies ist schwierig, da die Kontinuität nicht inhärent ist. Falls Menschen nicht unmittelbar antworten können, dann verbinden sich die inhärenten Verzögerungen, wobei ein kontinuierlicher Strom des Tones nicht aufrechterhalten werden kann.
Es ist erkannt worden, dass ein kontinuierlicher Strom des Tones erzeugt werden kann, indem ein Schleifenpunkt festgelegt wird. Es kann z. B. ein Basstrommel-Muster festgelegt werden, das zwei Takte lang ist. Dieses Muster wird durch den Server zu den Clients gesendet, die dann kontinuierlich das Zwei-Takt-Muster zyklisch durchlaufen. Dies ist in 3 veranschaulicht, in der das Bezugszeichen 30 den durch einen Client definierten und zum Server gesendeten Datenstrom bezeichnet. Das Bezugszeichen 32 stellt denselben Datenstrom dar, der immer wieder durch die Clients wiederholt gespielt wird.
Folglich sendet der Server einen Datenstrom, der einen Abschnitt oder einen Musikschnipsel mit irgendeiner festgelegten Zeitdauer angibt, zu jedem der Clients, die von dem Client verschieden sind, bei dem er erzeugt worden ist. Die Clients empfangen die Daten und synchronisieren sie bezüglich ihres lokalen Taktgebers. Der Schnipsel oder das Muster wird immer wieder wiederholt. Die Folge, die jeder Client selbst erzeugt hat, ist bereits auf den lokalen Taktgeber synchronisiert, wobei sie mit einem Zeitstempel versehen worden ist, bevor sie zum Server gesendet wird.
Es wird erkannt, dass jeder Client das gleiche musikalische Erlebnis hat. Es macht nichts, dass es inhärente Ausbreitungsverzögerungen gibt, da die Musikfolgen nur von einer durch jeden lokalen Taktgeber festgelegten relativen Zeit abhängig sind. Folglich macht es nichts, falls die inhärenten Verzögerungen zu jedem Client verschieden sind.
Während die Schleifenbildung der Folgen die Probleme der Verzögerung überwindet, ist sie in einigen Situationen künstlerisch einschränkend oder unangemessen. 4 veranschaulicht, wie ein zusätzlicher Grad der Ausgereiftheit hinzugefügt werden kann, indem eine Folge von Folgen erzeugt wird und die Folge von Folgen immer wieder wiederholt wird. In 4 werden drei Folgen A, B und C erzeugt. Selbstverständlich können diese drei Folgen in irgendeiner beliebigen Folge, hier A, A, B, C, erzeugt werden. Diese Viersegmentfolge wird zum Server gesendet, der sie zu jedem der anderen Clients verteilt, wo sie kontinuierlich in einer Schleife durchlaufen wird. Folglich ist der bei jedem Client abgespielte Strom AABCAABC usw.
5 zeigt, wie ein Netz aus vier Clients eine Partitur mit vier Parts spielen kann. Die vier Parts 1 bis 4 können z. B. eine Schnarrtrommel, ein Bass, eine Gitarre und ein Klavier sein. Die Linie 40 der Schnarrtrommel ist eine Folge AABC, die Linie des Basses 42 ist eine einfache Folge A, die Linie der Gitarre 44 ist AB und die Linie des Klaviers 46 ist ABCD. Der entsprechende Client sendet die Folge zum Server, der jede der Folgen von Folgen zu jedem der anderen Clients verteilt. Die durch jeden Client wiedergegebene resultierende Partitur ist in 6 gezeigt.
In dem gezeigten Beispiel besitzt jede der Folgen die gleiche Länge. Dies muss nicht der Fall sein. 7 zeigt das Beispiel eines hinzugefügten fünften Parts 48, der eine einzelne Folge mit der vierfachen Länge der durch jeden der anderen Parts verwendeten Folgen ist. Folglich kann in dem Beispiel die Folge A des fünften Parts eine Acht-Takt-Folge sein. Es macht nichts, dass sie eine andere Länge besitzt, da ihre Daten mit den relativen Werten des Taktgebers mit einem Zeitstempel versehen worden sind. Die Länge der Folge ist außerdem beliebig, obwohl ungewöhnliche Längen Phaseneinstellungseffekte erzeugen können; die Ausrichtung ändert sich mit den anderen Mustern. Es würde üblicher sein, dass die Folgenlänge mit einer musikalischen Eigenschaft, wie z. B. einer Akkordsequenz, verknüpft ist, wobei es üblich ist, dass längere Folgen ein ganzzahliges Vielfaches der kürzesten Folge sind.
In 8 ist die Operation des Clients beim Erzeugen einer Folge oder einer Folge von Folgen gezeigt. Im Schritt 50 wird zuerst die erste Folge erzeugt, gefolgt von den nachfolgenden Folgen, falls es geeignet ist, wobei das Ganze dann im Schritt 52 mit einem Zeitstempel versehen und im Schritt 56 zum Server gesendet wird.
Die Operation der Zeitstempelung und des lokalen Taktgebers ist durch den Ablaufplan nach 9 veranschaulicht. Der lokale Taktgeber ist, wie früher erklärt worden ist, ein relativer Taktgeber, der durch synchronisierte Datenströme (Datenfolgen), die vom Server empfangen werden, mit den lokal erzeugten Folgen verwendet wird. Der Taktgeber ist eingestellt, um eine Folge von eine veränderliche Zeit voneinander entfernten Schlägen oder Impulsen zu erzeugen. Die Schläge sind typischerweise eine Anzahl von Millisekunden voneinander entfernt, wobei die Folgendaten auf diesen Taktgeber ausgerichtet sind.
Im Schritt 60 wartet der Client auf den nächsten Schlag, der durch den Taktgeber erzeugt wird, wobei die Clients den Schlag überwachen. Im Schritt 62 überprüft der Client, ob es irgendwelche übriggelassene Ströme gibt, die zu spielen sind, falls nein, kehrt die Routine in einer Schleife zum Schritt 60 zurück, um auf den nächsten Schlag zu warten. Der Client schreitet durch jeden der Ströme, wobei er überprüft, um festzustellen, ob es noch weitere zu spielende Daten gibt. Falls die Antwort im Schritt 62 ja lautet, geht die Software zum Schritt 64 weiter, in dem der nächste Datenstrom erfasst wird. Im Schritt 66 überprüft der Client, um festzustellen, ob es irgendwelche wiederzugebende Daten beim aktuellen Schlag für den aktuellen Strom gibt. Falls es keine Daten gibt, kehrt die Routine zum Schritt 62 zurück. Falls es auszugebende Daten gibt, werden alle Daten für diesen Schlag und diesen Strom ausgegeben, in welcher erforderlichen Form auch immer. Es wird erkannt, dass die Schritte 60–66 als ein Mittel wirken, um die empfangenen Folgen mit dem lokalen Taktgeber des Clients zu synchronisieren.
In dem gegebenen Beispiel würde das Datenformat das MIDI-Format sein, es könnte jedoch irgendein Audio- oder Videoformat oder sogar eine digital gesteuerte Lichtausgabe an einem oder mehreren der Datenausgänge sein.
Der Client überprüft dann, ob es noch weitere übriggelassene Datenströme gibt, die auszugeben sind. Wenn es keine gibt, dann wartet er auf den nächsten Schlag.
Das System ist im Kontext von "Schlägen" beschrieben worden, die relative Zeitwerte sind. Dies ist zweckmäßig, da eine Zwei- oder n-Takt-Folge normalerweise eine ganzzahlige Anzahl von gleich beanstandeten Schlägen besitzen würde. Es könnten jedoch absolute Zeitwerte verwendet werden, obwohl dies komplexer ist. Die Zeit ist immer noch relativ, da die Daten vom Server auf den lokalen Taktgeber synchronisiert werden.
Anstatt den Taktgeber nach jeder Folge oder Folge von Folgen zurückzusetzen, erhöht sich der Schlagwert. Wie aus 2 entnommen werden kann, enthält der Taktgeber 26 einen Zähler 29.
Die Tabelle 1 im Folgenden hilft, zu zeigen, wie das System arbeitet, um Parts mit verschiedener Länge synchronisiert zu halten. Es wird ein Part, angenommen der Basspart, betrachtet. Die Tabelle 1 zeigt, wie die Daten des Bassparts aussehen könnten.
Musterlänge: 16
Tabelle 1
Da die Musterlänge 16 Schläge beträgt, wiederholt sich das Muster alle 16 Schläge. Folglich wird beim 1. Schlag jeder Schleife eine C2 gespielt, eine D2 beim dritten Schlag und eine E2 beim 9. Schlag. Der Taktgeber steuert und synchronisiert die Folgen mit mehreren Längen, die zu verschiedenen Zeitpunkten ankommen, indem er das Modulo oder den Rest der Division der Musterlänge und des Gesamtschlag-Zählstandes nimmt. Folglich wiederholt sich das Muster der Tabelle 1, wenn der lokale Taktgeber durch 0, 16, 32, 48 usw. schreitet. Falls der Zählstand des Taktgebers 115 ist, spielt der lokale Client den dritten Schlag der Folge, da die Folge 16 Schläge lang ist und 115/16 = 7 Rest 3 gilt. Im selben Beispiel würde eine Musterlänge von 32 im 19. Schlag als 115/32 = 3 Rest 19 erscheinen.
Aus der vorangehenden Beschreibung ist klar, dass die Zeitstempel relative Zeitwerte sind. Folglich wird für jeden Datensatz angenommen, dass alle Werte des Taktgebers von einem Wert von null versetzt sind. Der Client hält einfach einen Zeiger auf das aktuelle Muster und den Zählstand im aktuellen Muster für jeden Strom. Dieser Zähler wird mit jedem Ticken des lokalen Taktgebers inkrementiert. Wenn der Zähler gleich der Länge des aktuellen Musters für den Strom ist, wird er auf 0 zurückgesetzt, während der Musterzeiger auf das nächste Muster inkrementiert wird. (Wenn das Muster das letzte im Makro-Muster ist – d. h. "D" in "ABCD" – dann wird der Musterzeiger eingestellt, damit er zurück auf das erste Muster im Makro-Muster zeigt.) Es gibt viele Verfahren, die verwendet werden, um die Werte des lokalen Taktgebers umzusetzen. Das Modulo-Verfahren, auf das oben Bezug genommen worden ist, funktioniert für Muster, die alle die gleichen Längen besitzen, wie sie in der bevorzugten Implementierung verwendet werden.
Weil der Client die Anordnung der Datensätze (Muster), die Länge jedes Musters und den Wert des konstant inkrementierenden lokalen Master-Taktgebers kennt, kann er sehr leicht unter Verwendung einfacher Mathematik bestimmen, in welchem Muster (Datensatz) er spielen sollte und welche Position (welcher Zählstand) im Datensatz für jeden Strom gespielt wird. Jeder Strom besitzt eine Menge von Mustern und ein Makro-Muster (Muster von Mustern), die bezüglich der anderen Ströme ausgerichtet und deshalb synchronisiert sind, da jeder Strom seine Ausgabe auf dieselbe Prozedur und denselben lokalen Taktgeber stützt.
Es sollte angegeben werden, dass andere Synchronisationsverfahren möglich sind und den Fachleuten auf dem Gebiet einfallen werden. Das beschriebene Verfahren erlaubt die Synchronisation und die Schleifenbildung mehrerer Ströme mit unterschiedlicher Länge ohne Einschränkung.
Es ist aus der vorangehenden Beschreibung klar, dass die Datenströme von einzelnen Clients am Ende jedes Clients zusammengebracht werden. Der Client kann tatsächlich jeden Datenstrom separat halten, obwohl die Datenströme gemeinsam erklingen, wenn eine Audioausgabe erfolgt. Es gibt keinen Grund, dass die Daten kombiniert werden müssen.
Die Behandlung der Datenströme beim Client kann aus dem folgenden einfachen Beispiel verstanden werden.
Es wird angenommen, dass 3 Datenströme in einer speziellen Sitzung vorhanden sind; der Bass, ein Keyboard und eine Trompete. Die Datensätze für die drei Instrumente können wie folgt sein:
Bass: AB
Keyboard: ABCD
Trompete: A
Es gibt insgesamt 7 verschiedene Datensätze, wobei jeder mit einem Datenstrom paarweise angeordnet ist, diese Muster können in einer beliebigen Reihenfolge angeordnet sein, wie z. B.
Bass: AB
Keyboard: ABCD
Trompete: A
Diese Makro-Muster wiederholen sich in der vorher beschriebenen Weise.
Jedes Mal, wenn der lokale Taktgeber tickt, schreitet der Client durch jeden Strom und bestimmt, ob es irgendwelche auszugebenden Daten gibt, wobei er sie ausgibt, wie es notwendig ist, er könnte z. B. eine Note spielen.
Es kann erkannt werden, dass die Datenströme als bei den lokalen Clients kombiniert wahrgenommen werden, anstatt kombiniert zu werden, der Client hält jedoch die Daten für jeden Strom als eine separate Entität. Die Code-Auflistungen im Code des Anhangs eins sind für ein Stromobjekt angegeben. Jedes Stromobjekt in diesem Beispiel hält seine eigenen Daten. Die Daten werden niemals mit anderen Stromobjekten kombiniert. Sie sind nur so zu hören, als ob sie kombiniert wären.
Das beschriebene System basiert auf einem Server, der die Daten zu den lokalen Clients zurückwirft. Jeder Client besitzt die Fähigkeit, Daten zu senden und zu empfangen, wobei sich die gesendeten Daten aus einer beliebigen Anzahl von Datenströmen zusammensetzen, die eine Folge von mit Zeitstempeln versehenen Ereignissen darstellen; der Zeitstempel ist ein beliebiger relativer Wert des Taktgebers. Die Folge der Daten wird durch die lokalen Clients in einer Schleife durchlaufen, um den Eindruck eines konstanten musikalischen Stroms zu geben. Die gesendeten Folgen können selbst Folgen von Folgen sein, um zu ermöglichen, dass ein komplexeres musikalisches Muster aufgebaut wird. Die Wiedergabe wird durch den lokalen Taktgeber des Clients gesteuert, auf den die Daten unter Verwendung der relativen Werte des Taktgebers synchronisiert werden, was erlaubt, dass die Datenströme im richtigen Takt ungeachtet der Client/Server/Client-Zeitverzögerungen gespielt werden.
Die Beschreibung ist unter der Annahme gegeben worden, dass ein erster Client Informationen zum Server sendet, gefolgt vom zweiten usw.
Alle Muster besitzen Zeitwerte, wobei angenommen wird, dass sie vom Zeitpunkt 0 versetzt sind. Die Zeit des lokalen Taktgebers ist beliebig, wenn alles wiedergegeben wird, weil alle Muster diese relativen Werte des Taktgebers verwenden. Dies bedeutet, dass der Zeitpunkt, zu dem der lokale Taktgeber eines Clients startet, beliebig ist. Er muss nicht auf irgendeinen der Clients warten, um zu starten, damit alles funktioniert. Alles, worauf es ankommt, ist, dass der lokale Client irgendeinen Wert des Taktgebers besitzt, von dem er die relativen Werte des Taktgebers versetzen kann.
Es wird nun die Struktur des Datenstroms ausführlicher betrachtet. Die Tabelle 2 im Folgenden zeigt ein Beispiel eines geeigneten Formats für einen der Datenströme. Der Strom umfasst einen Kopfabschnitt und einen Datenabschnitt.
Tabelle 2
Dieser Datenstrom könnte als ein vom Client zum Server oder vom Server zum Client gesendetes Paket oder Muster betrachtet werden. Es besteht aus den folgenden Elementen:

A) Der Kopf, der umfasst: 1. Die Strom-ID: Wenn ein neuer Strom erzeugt wird, wird einem neuen In strument im Musikbeispiel ein eindeutiger ID-Wert zugeordnet. Die Art, in der die ID zugeordnet wird, spielt keine Rolle. Alles, worauf es ankommt, ist, dass jeder Strom einen eindeutigen ID-Wert besitzt und dass alle Clients und der Server diese ID dem Strom zuordnen. Folglich erlaubt das Strom-ID-Element im Kopf, dass die Daten geeignet mit dem Strom paarweise angeordnet werden, wenn die Daten für den Strom ausgesendet werden. 2. Die Muster-ID: Für jeden Strom gibt es mehrere Muster. Gleich den Strömen muss jedes Muster identifiziert werden – d. h., jedes Muster muss seine eigene ID besitzen. Ein Bassmuster könnte z. B. ein Muster "A" und ein Muster "B" besitzen. In diesem Fall sind "A" und "B" die Muster-IDs. Wie das Muster identifiziert wird, ist wichtig, solange wie es irgendein Standardverfahren des Identifizierens und Unterscheidens der Muster ist. Eines könnte z. B. Wörter oder Zahlen verwenden. Das im Anhang 1 enthaltene Code-Beispiel verwendet die Buchstaben A bis E, um die Muster zu identifizieren. 3. Die Musterlänge: Die Länge eines Musters ist nicht durch die Zeit des letzten mit einem Zeitstempel versehenen Elements im Muster bestimmt. Ein Muster kann 16 Sekunden lang sein, gleichwohl kann es überhaupt keine Ereignisse besitzen (d. h., ein Muster des Bassparts könnte völlig stumm sein). Die Länge des Musters kann in einer von zwei Arten festgelegt sein: (i) Es kann eine vorgegebene Länge besitzen. In einem Musikprogramm können z. B. alle Muster immer eine Länge von 4 Metren besitzen. Der im Anhang 1 enthaltene Code macht diese Annahme. (ii) Sie kann als ein Parameter im Datenkopf enthalten sein.
B) Die Daten: Der Rest der Daten sind die mit Zeitstempeln versehenen Datenpaare. Im Fall des Instrumentenparts könnten diese aus Zeit-/Notenereignissen bestehen. In einem weiteren Fall, z. B. digitales Video, könnten sie aus Zeit-/Rahmenereignissen bestehen. Es gibt keine Beschränkungen für die Daten. Die Zeitstempel sind relative Zeitwerte. Das heißt, es wird angenommen, dass das Muster zum Zeitpunkt 0 beginnt. Dies erlaubt, dass die Muster durch die Clients bezüglich des lokalen Taktgebers wiedergegeben werden – es gibt keine Abhängigkeit von der absoluten Zeit.

Die größte Beschränkung ist, dass einer der Zeitstempel-Werte höher als die Länge des Musters sein kann. Das heißt, falls die Musterlänge 5 Sekunden beträgt, würde es kein Ereignis geben, das bei 10 Sekunden auftritt.
Folglich findet die folgende Prozedur statt, wenn die Daten in die Client-Software kommen:

1. der Client empfängt die Daten;
2. der Client bestimmt durch das Lesen der Strom-ID aus dem Kopf des Datenpakets, welchem Strom die Daten zugeordnet sind;
3. der Client bestimmt durch das Lesen der Muster-ID aus dem Kopf des Datenpakets, welches Muster für den Strom die Daten sind;
4. der Client bestimmt durch das Lesen des Datenelements der Musterlänge im Datenpaket die Länge des Musters;
5. der Client liest die Zeitstempel-/Datenpaare bis zum Ende der Daten, (Anmerkung: ein Muster kann leer sein, es kann eine Strom-ID, eine Muster-ID, eine Musterlänge, aber keine Daten besitzen).

Folglich kann ein Beispiel-Datenpaket wie dieses aussehen:
Tabelle 3

Bemerkung: Die Musterlänge beträgt 6 Sekunden, aber das letzte Ereignis tritt bei 5 Sekunden auf.

Nun wird die Art, in der die Schleifenlänge bestimmt wird, beschrieben. Falls die Muster für die Ströme verschiedene Längen besitzen, tritt die Phaseneinstellung auf, wie früher erwähnt worden ist. Falls z. B. die 3 Ströme Bass, Keyboard und Trompete vorliegen, wobei sie Makro-Muster besitzen, deren Gesamtlänge 1, 2 bzw. 3 Metren beträgt, wird die Folge alle 6 Metren wiederholt. Mit anderen Worten, die Schleifenlänge ist 6 Metren lang. Folglich ist die Länge der Schleife die kleinste Zahl, von der alle Gesamtlängen jedes Stroms ein Faktor sind. Für die Längen 1, 2 und 3 ist die kleinste Zahl, für die sie alle ein Faktor sind, 6. Wenn die Sekunden als ein Zeitmaß verwendet werden und 4 Ströme mit Makro-Mustern einer Gesamtlänge von 20, 40, 60 bzw. 80 Sekunden vorliegen, dann würde die Länge der Schleife 240 Sekunden betragen, da 240 die kleinste Zahl ist, für die alle Längen ein gemeinsamer Faktor sind.
Die Schleifenlängen können sich dynamisch ändern, es könnte z. B. einfach das Makro-Muster für einen Strom von "AB" in "ABAC" geändert werden, wobei sich seine Länge verdoppelt. Falls der Rest der Ströme auf Makro-Muster nur aus "A" gesetzt wäre, würde dies die Länge der Schleife verdoppeln.
Falls Menschen mit Mustern arbeiten, die sich an geraden Grenzen nicht schließen, tritt die Phaseneinstellung auf.
Die 10–12 veranschaulichen das in Bezug auf tatsächliche Musikfolgen beschriebene Verfahren. In 10 ist das Verfahren gegen die Achse 71 gezeigt, die die wirkliche Zeit darstellt. Die erste Stufe ist für den Client, um seine Folge aufzuzeichnen. Dies tritt bei 72 auf, wo der zweite Client einen Basspart aufzeichnet, der einen Takt aus vier Viertelnoten umfasst: G C G' B. Diese Folge wird dann bei 74 zum Server gesendet, der das Muster zum anderen Client zurückwirft. Jeder Client besitzt seinen eigenen laufenden lokalen Taktgeber, wobei die empfangenen Daten beim ersten Client wiedergegeben werden, indem die Folge immer wieder wiederholt wird, und beim zweiten Client wiedergegeben werden, indem die erzeugte Folge immer wieder wiederholt wird. Der Figur kann entnommen werden, dass die Ein-Takt-Folge viermal wiederholt wird, obwohl es in der Praxis eine sehr viel größere Anzahl ist. Die relative Zeit der Noten in der Folge wird aufrechterhalten, da der erste Client durch seinen lokalen Taktgeber gesteuert wird. Durch Vergleich der lokalen Taktgeber der ersten und zweiten Clients kann jedoch festgestellt werden, dass die zwei nicht miteinander synchronisiert sind. Wie früher erklärt worden ist, ist dies unerheblich, da der Spieler keine Wahrnehmung dessen hat, was bei irgendeinem der anderen Clients zu hören ist.
11 veranschaulicht ausführlicher, was geschieht, wenn ein Muster aus zwei Folgen durch einen der Clients erzeugt wird. In dieser Veranschaulichung ist für die Bequemlichkeit nur ein Client gezeigt. Der Server hat ein Muster empfangen, das die Folge A, gefolgt von der Folge B umfasst. Wie aus der Veranschaulichung entnommen werden kann, ist die Folge A dieselbe Kombination aus vier Noten, wie sie in der vorhergehenden Figur beschrieben worden ist. Die Folge B umfasst eine Viertelnote tiefes C, gefolgt von einer G-Achtelnote und einer D-Achtelnote und dann einer A-Viertelnote, einer Achtelpause und einer G'-Achtelnote. Wie durch die Kästen 80, 82 veranschaulicht ist, sendet der Server die zwei Folgenmuster zum Client, der sein Wiedergabemuster auf die empfangene Folge AB setzt. Die Folge A wird zuerst empfangen und wiedergegeben, wobei die Folge B ohne musikalische Diskontinuität zwischen den zwei Folgen empfangen und wiedergegeben wird. Dann wiederholt der Client die Folge von Folgen ABABABABAB usw. so oft, wie es erforderlich ist.
12 zeigt die Notenschrift einer Sitzung mit vier Clients, die schematisch bei 90 gezeigt sind. Der erste Part umfasst eine einzige Folge, die vier Takte dauert; der zweite Part umfasst ein Folgenpaar AB, wobei jedes einen Takt dauert und den Folgen nach 11 entspricht; der dritte Part umfasst eine einzige Ein-Takt-Folge, während der vierte Part vier Ein-Takt-Folgen A, B, C, D umfasst. Die Clients hören den ersten Part, der alle vier Takte wiederholt wird, den zweiten Part, der alle zwei Takte wiederholt wird, den dritten Part, der jeden Takt wiederholt wird, und den vierten Part, der alle vier Takte wiederholt wird.
In der beschriebenen Ausführungsform wirft der Server keine Folge zu dem Client zurück, von dem sie gesendet worden ist. Dies ist bevorzugt, da es keine Notwendigkeit gibt, die Daten zu empfangen, die bereits auf den lokalen Taktgeber der sendenden Clients synchronisiert sind. Der Server könnte jedoch die Daten zum sendenden Client zurücksenden, obwohl dies die Menge der Daten vergrößern würde, die der Server senden muss.
Der beigefügte Anhang zeigt eine Code-Auflistung für ein einfaches Stromobjekt. Jedes Stromobjekt ist separat, aber es verwendet denselben Code und wird parallel ausgeführt. Dieser Code zeigt eine sehr einfache Implementierung des Konzepts der Schleifenbildung mit festen Musterlängen. Es funktioniert unter Verwendung relativer Werte der lokalen Taktgeber; der lokale Taktgeber führt ständig eine zyklische Wiederholung aus, wobei deshalb eine Betrachtung des Codes, wie er abläuft, keine Bestimmung einer absoluten Zeit liefern könnte. Der Code läuft außerdem zyklisch durch die Muster von Mustern.
13 fasst die funktionalen Schritte in dem beschriebenen Verfahren zusammen. Sie kann außerdem als ein funktionaler Blockschaltplan der Hardware-Anforderungen des Systems oder der Hardware-Äquivalente der durch Software ausgeführten Schritte betrachtet werden. Folglich erzeugt bei 120 ein Client-Computer eine Datenfolge oder eine Folge von Folgen. Im Schritt 122 werden diese Daten mit einem Zeitstempel versehen und im Schritt 124 zu einem Server gesendet. Im Schritt 126 wirft der Server dann die Daten zu jedem weiteren Client zurück. In dem durch die strichpunktierte Linie 128 dargestellten Schritt empfängt ein repräsentativer lokaler Client die Daten, synchronisiert sie auf seinen eigenen lokalen Client und gibt die Daten wieder. Spezifischer werden die Daten im Schritt 130 und im Schritt 132 synchronisiert. Der lokale Client stellt die Schlaglänge ein, wobei er bei jedem Schlag die folgenden Schritte ausführt:

(i) der Schritt 132 gewinnt einen Datenstrom wieder;
(ii) der Schritt 134 untersucht die Daten;
(iii) der Schritt 136 gibt die Daten aus; und
(iv) der Schritt 138 inkrementiert den Zähler des Taktgebers.

Die Schritt 120 bis 138 werden für jeden der Client-Computer ausgeführt.
Ein Nachteil der beschriebenen Ausführungsform ist, dass sie keine Improvisation erlaubt. Jeder Spieler muss unter Verwendung der beschriebenen Schleifenbildungsstruktur spielen, obwohl es einen bestimmten Grad der Flexibilität in der Struktur jeder Schleife gibt.
Es ist selbstverständlich, dass die beigefügte Code-Auflistung nur eine beispielhafte Ausführungsform ist, wobei andere Zugänge zur Implementierung annehmbar sind und den Fachleuten auf dem Gebiet klar sind.
Ein weiterer Aspekt der Erfindung erlaubt, dass ein Spieler frei improvisiert, ohne durch die Schleifenbildungsprozedur eingeschränkt zu sein. Dies ist in 14 gezeigt, in der der sechste Spieler 100 (der als "Solo" gezeigt ist) ein Solist ist, der frei über den anderen fünf Spielern improvisiert. Mit anderen Worten, die sechste Linie ist keine Folge von sich wiederholenden Schleifen, sondern eine kontinuierliche Musiklinie.
Die Taktgeber der lokalen Clients können durch einen durch den Server zu jedem Client gesendeten Startbefehl gestartet werden. Da der Startbefehl gleichzeitig zu jedem Client gesendet werden kann, sind die Clients etwa synchronisiert. Die Synchronisation ist nicht genau, aber sie liegt innerhalb der größten Übertragungsverzögerung für jeden der Clients. Falls z. B. die mittleren Netzverzögerungen für die drei Clients 100 ms, 1500 ms bzw. 500 ms betragen, sind ihre entsprechenden Taktgeber im Bereich von 1500 ms synchronisiert. Weil die Clients jeder einzeln durch den Server ausgelöst werden können, können Gruppen von Clients zu getrennten Zeitpunkten synchronisiert werden. Folglich kann der Server alle mit Ausnahme von einem der Clients verzögern. Dies ist in 15 veranschaulicht, in der der Taktgeber des Solisten (d. h. der Taktgeber des Improvisators) durch einen vom Server zu ihm gesendeten Startbefehl gestartet wird. Dann wird einige Zeit später jeder der anderen Clients durch einen Startbefehl vom Server gestartet.
In diesem Fall sind alle bis auf einen der Clients etwa hinter einem einzelnen Client (der Sololinie) synchronisiert. Der Solist kann dann einen kontinuierlichen Datenstrom zum Rest der Clients senden, die die Daten vom Solo-Client in einem Puffer 70 (2) puffern und sie auf ihren lokalen Taktgeber synchronisieren. Weil im Rest der Datenströme die Instrumentalparts in der vorher beschriebenen Weise in einer Schleife durchlaufen werden, stört die Verzögerung zwischen dem Solo-Client und den Rest der synchronisierten Parts die Kontinuität der zeitabhängigen Daten für jeden der Clients nicht. Die Verzögerungsprobleme zwischen allen Clients werden durch die beschriebene Schleifenbildungsprozedur gehandhabt. Während die an den Solo-Client gesendeten Nicht-Solo-Daten ankommen, nachdem die Sololinie begonnen hat, sind sie ein Satz sich wiederholender Folgen, wobei sie deshalb beim Solo-Client auf den lokalen Taktgeber synchronisiert werden können.
Folglich sendet der Solo-Client einen kontinuierlichen Datenstrom, der mit Zeitstempeln bezüglich des lokalen Taktgebers des Solisten versehen ist. Diese Daten werden zum Server gesendet, der wiederum die Daten an alle anderen Clients zurückwirft, deren lokale Taktgeber etwa hinter dem Solo-Client synchronisiert sind. Weil die Daten bezüglich des lokalen Taktgebers synchronisiert sind, wird die freie Improvisation des Solisten synchron mit den in einer Schleife durchlaufenen Daten gehört. Die Schleifenbildungstechnik erlaubt, dass sowohl der Solist als auch die relativ verzögerten, etwa synchronisieren Clients dieselbe Wahrnehmung der musikalischen Kontinuität ungeachtet ihrer Unterschiede in der absoluten Zeit besitzen.
Die Zeitstempelung des Solisten ist ein Spezialfall der früher umrissenen Prozedur. Der Solist wird als ein riesiges Muster behandelt, das in Teilen zum Client gesendet wird; es bildet per se tatsächlich keine Schleife. Es kann als ein ständig größer werdendes Muster von Mustern oder als ein Muster, das in großen Stücken gesendet wird, betrachtet werden.
Die Variabilität der Schleifenlänge und die Bestimmung der Schleifenlänge ist bei der Solistenlinie ein wenig anders. Der Part des freien Solisten kann einfach als ein sehr langes Muster betrachtet werden, das in großen Stücken gesendet wird. Der Client fädelt die Solistendaten einfach zusammen. Wenn der Solist verwendet wird, ist es wahrscheinlich erwünscht, dass die Schleifenlänge bereits gesetzt ist, um die Ausrichtung des Spiels der Solisten nicht fliegend zu ändern, obwohl dies interessante, wenn auch nicht notwendigerweise ästhetisch angenehme Ergebnisse erzeugen könnte.
16 zeigt einen Überblick über die Ausführungsform der Sololinie der Erfindung, die zu der nach 13 ähnlich ist.
Die Erfindung ist in Form eines frei improvisierenden Clients beschrieben worden. Dies bedeutet, dass ein Solo-Client-Computer die improvisierte Linie bereitstellt. Das bedeutet nicht, dass es nur ein einzelnes Solo auf einmal gibt. Es könnten Gruppen von Spielern in dem Client mit einem Computer, der leistungsfähig genug ist, und bei einer Bandbreite, die hoch genug ist, spielen, wobei ein ganzes Orchester Solo spielen könnte, solange wie sie durch denselben Client aufgezeichnet werden.
Ähnlich könnten die Folgen für jeden der anderen Clients oder alle Clients in der ersten Ausführungsform durch eine Anzahl von Spielern bereitgestellt werden, die alle durch denselben Client aufgezeichnet werden.
Im Schritt 140 wird der Solo-Client durch einen vom Server gesendeten Startbefehl gestartet. Dann sendet der Solo-Client bei 142 einen kontinuierlichen Datenstrom zum Server. Zu einem Zeitpunkt T = 0 + n sendet im Schritt 144 der Server einen Startbefehl zu den Nicht-Solo-Clients. Diese Clients erzeugen im Schritt 146 eine Datenfolge und senden sie an den Server. Im Schritt 148 wirft der Server den kontinuierlichen Datenstrom vom Solo-Client zu jedem der Nicht-Solo-Clients zurück, wobei die Clients die empfangenen Daten in der in Bezug auf den ersten Aspekt der Erfindung beschriebene Weise mit den entsprechenden lokalen Taktgebern resynchronisieren. Der Server wirft im Schritt 150 außerdem die von den Nicht-Solo-Clients empfangenen Datenfolgen zum Solo-Client und zu den Nicht-Solo-Clients, die entweder den Client, der die Daten erzeugt hat, enthalten oder nicht enthalten, zurück. Die empfangenen Daten werden dann wieder im Schritt 152 resynchronisiert, wobei die Daten von den Solo- und Nicht-Solo-Clients in einer früher beschriebenen Weise bei jedem Client ausgegeben werden können.

Claims

Verfahren zum Synchronisieren von Daten von mehreren Quellen über ein Client-Server-Netz, das die folgenden Schritte umfasst: Senden eines ersten Startbefehls von dem Server (10) zu einem ersten Client (12), um bei dem ersten Client (12) einen lokalen Taktgeber (26) zu starten; Senden eines kontinuierlichen Datenstroms von dem ersten Client (12) zu dem Server (10); Senden eines weiteren Startbefehls von dem Server (10) zu mehreren weiteren Clients (12), um in jedem der weiteren Clients (12) einen lokalen Taktgeber zu starten, wobei der weitere Startbefehl in Bezug auf den ersten Startbefehl verzögert ist; Senden einer Datenfolge von jedem der mehreren weiteren Clients (12) zu dem Server (10); Senden des kontinuierlichen Datenstroms von dem Server (10) zu jedem der mehreren weiteren Clients (12); Resynchronisieren des empfangenen kontinuierlichen Datenstroms bei jedem der mehreren weiteren Clients (12); Senden der Datenfolgen von dem Server (10) zu jedem der mehreren weiteren Clients (12) und zu dem ersten Client (12); wobei der Schritt des Sendens das Zurücksenden einer gegebenen Datenfolge zu einem entsprechenden weiteren Client (12), von dem aus sie gesendet wurde, entweder enthält oder nicht enthält; Resynchronisieren der empfangenen Datenfolgen bei jedem der Clients (12) auf den lokalen Taktgeber (26); und mehrfaches Wiederholen der empfangenen und lokal erzeugten Datenfolgen bei jedem der Clients (12).
Verfahren nach Anspruch 1, bei dem eine oder mehrere der Datenfolgen eine Folge von Datenfolgen umfassen.
Verfahren nach Anspruch 1 oder 2, bei dem jede Datenfolge einen Part eines Musikinstruments repräsentiert.
Verfahren nach Anspruch 3, bei dem eine oder mehrere der Datenfolgen durch eine digitale Schnittstellenvorrichtung (22) für Musikinstrumente oder MIDI-Vorrichtung erzeugt werden.
Verfahren nach Anspruch 4, das das Wiedergeben der empfangenen Datenfolgen auf der MIDI-Vorrichtung (22) umfasst.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem die von jedem Client (12) zu dem Server (10) gesendete Datenfolge Daten bezüglich einer Folge aus einer oder mehreren Musiknoten umfasst und die relative Zeit der Note sowie andere die Note beschreibende Parameter enthält.
Verfahren nach einem vorhergehenden Anspruch, bei dem die Länge jeder Datenfolge veränderlich ist.
Verfahren nach einem vorhergehenden Anspruch, bei dem die Länge der Datenfolge, die durch jeden Client (12) erzeugt wird, gleich ist.
Verfahren nach einem vorhergehenden Anspruch, bei dem ein oder mehrere Clients (12) eine Datenfolge mit einer Länge erzeugen, die von jener der ersten Datenfolge verschieden ist.
Verfahren nach Anspruch 2, bei dem die Länge jeder Folge der Folge von Folgen gleich ist.
Verfahren nach Anspruch 2, bei dem die Folgen, die die Folge von Folgen umfassen, unterschiedliche Längen haben.
Verfahren nach Anspruch 9, bei dem die Länge jeder längeren Folge ein ganzzahliges Vielfaches der Länge der kürzesten Folge ist.
Verfahren nach einem vorhergehenden Anspruch, das für jeden lokalen Taktgeber (26) umfasst: Setzen einer Schlaglänge; und bei jedem Schlag: a) Wiedergewinnen eines Datenstroms von dem Server (10); b) Untersuchen des Datenstroms für wiederzugebende Daten; c) Ausgeben der Wiedergabedaten; und d) Wiederholen der Schritte a) bis c) für jegliche verbleibenden Datenströme.
Verfahren nach Anspruch 13, bei dem jeder lokale Taktgeber (26) einen Zähler (29) enthält und das den Schritt des Inkrementierens des Zählers (29) bei jedem Schlag umfasst.
Verfahren nach Anspruch 14, bei dem die zu jedem Client (12) gesendete Datenfolge Folgenlängendaten enthält und das den Schritt umfasst, bei dem der kumulative Zählstand des Zählers durch die Folgenlänge geteilt wird und der Schlag der momentanen Folge aus dem Rest bestimmt wird.
Verfahren nach einem vorhergehenden Anspruch, bei dem der kontinuierliche Datenstrom in einem Puffer (70) in jedem der mehreren weiteren Clients (12) gespeichert wird und der Resynchronisationsschritt Daten, die von dem Puffer wiedergewonnen werden, mit dem lokalen Taktgeber (26) resynchronisiert.
Computerlesbares Speichermedium, das so konfiguriert ist, dass es einen Computer dazu veranlasst, die folgenden Schritte auszuführen: Empfangen eines ersten Startbefehls von einem Server (10) zu dem Computer, um einen lokalen Taktgeber (26) in dem Computer zu starten; Senden eines kontinuierlichen Datenstroms von dem Computer zu dem Server (10); Empfangen mehrerer Datenfolgen von dem Server (10); Synchronisieren der empfangenen Folgen mit dem lokalen Taktgeber (26); mehrfaches Wiederholen der empfangenen Datenfolgen, um Ausgangsdaten zu erzeugen; Senden der Ausgangsdaten und des kontinuierlichen Datenstroms zu einem Ausgang.
Computerlesbares Speichermedium nach Anspruch 17, bei dem der Schritt des Empfangens einer Datenfolge, der von dem Computer ausgeführt wird, das Empfangen einer Folge von Datenfolgen umfasst.
Computerlesbares Speichermedium nach Anspruch 17 oder 18, bei dem der kontinuierliche Datenstrom und die Datenfolgen von dem Server (10) jeweils Daten, die eine oder mehrere Musiknoten identifizieren, sowie die relative Zeit der Note und andere die Note beschreibende Parameter enthalten.
Computerlesbares Speichermedium nach Anspruch 17, 18 oder 19, bei dem die Längen der von dem Server (10) empfangenen Datenfolgen veränderlich sind.
Computerlesbares Speichermedium nach Anspruch 18, bei dem die Folgen, die die Folge von Folgen enthalten, unterschiedliche Längen haben.
Computerlesbares Speichermedium nach Anspruch 18, bei dem die Länge jeder Folge der Folge von Folgen gleich ist.
Computerlesbares Speichermedium nach einem der Ansprüche 17 bis 22, bei dem der Synchronisationsschritt umfasst: a) Wiedergewinnen einer Datenfolge von dem Server (10); b) Untersuchen der Datenfolge auf Daten, die zu den Ausgabevorrichtungen ausgegeben werden sollen; c) Ausgeben der Ausgangsdaten; d) Wiederholen der Schritte a) bis c) für jegliche weiteren Datenfolgen.
Computersystem (20), das umfasst: eine Zentraleinheit (23) und einen zugeordneten Speicher (27), einen lokalen Taktgeber (26) sowie eine Eingabevorrichtung (22) zum Eingeben von Daten in das System; Mittel, um eine Datenfolge von der Eingabevorrichtung (22) zu empfangen und um die eingegebene Folge mit dem lokalen Taktgeber (26) zu synchronisieren; Mittel, um die Datenfolge an einen entfernten Server (10) zu senden; Mittel, um mehrere weitere Datenfolgen, die in verschiedenen Computersystemen erzeugt werden, von dem Server (10) zu empfangen; Mittel, um die empfangenen Folgen mit dem lokalen Taktgeber (26) zu synchronisieren; Mittel, um die eingegebene Folge und jede empfangene Datenfolge mehrmals zu wiederholen; Mittel, um die mehreren wiederholten eingegebenen Folgen und empfangenen Folgen zu einer Ausgabevorrichtung zu senden; einen Puffer (70); Mittel, um einen kontinuierlichen Datenstrom in dem Puffer zu empfangen; Mittel, um den Datenstrom von dem Puffer (70) mit dem lokalen Taktgeber (26) zu synchronisieren; und Mittel, um den kontinuierlichen Datenstrom zu der Ausgabevorrichtung (22) synchron mit den wiederholten Datenfolgen auszugeben.
Computersystem (20) nach Anspruch 24, bei dem die Ausgabevorrichtung (22) und die Eingabevorrichtung (22) Mittel, um Musiknoten zu erzeugen und abzuspielen, enthalten.
Computersystem (20) nach Anspruch 25, bei dem die Ausgabevorrichtung (22) und die Ausgabevorrichtung (22) eine MIDI-Vorrichtung sind.
Computersystem (20) nach Anspruch 24, 25 oder 26, bei dem die Sendemittel ein Modem (24) oder eine andere Netzverbindung umfassen.
Computersystem (20) nach einem der Ansprüche 24 bis 27, bei dem die Mittel zum Empfangen und Senden von Folgen Mittel umfassen, um eine Folge von Folgen zu empfangen und zu senden.
Computersystem (20) nach einem der Ansprüche 24 bis 28, bei dem die Mittel zum Empfangen und Senden von Folgen Mittel umfassen, um die Daten, die eine Folge von Musiknoten umfassen, wovon jede eine Länge, eine Höhe, eine Amplitude und eine relative Zeit hat, darzustellen.
Computersystem (20) nach einem der Ansprüche 24 bis 29, bei dem die Mittel zum Ausgeben von Daten zu einer Ausgabevorrichtung umfassen: Mittel, um bei jedem Schlag des Taktgebers Datenströme aus der Folge wiederzugewinnen; Mittel, um einen gegebenen Datenstrom auf auszugebende Daten zu untersuchen; und Mittel, um die auszugebenden Daten auszugeben.
Vorrichtung zum Synchronisieren von Daten von mehreren Quellen über ein Client-Server-Netz, die umfasst: Mittel, um einen ersten Startbefehl von dem Server (10) zu einem ersten Client (12) zu senden, um bei dem ersten Client einen lokalen Taktgeber zu starten; Mittel, um einen kontinuierlichen Datenstrom von dem ersten Client (12) zu dem Server (10) zu senden; Mittel, um einen weiteren Startbefehl von dem Server (10) zu mehreren weiteren Clients (12) zu senden, um in jedem der weiteren Clients (12) einen lokalen Taktgeber (26) zu starten, wobei der weitere Startbefehl in Bezug auf den ersten Startbefehl verzögert ist; Mittel, um eine Datenfolge von jedem der mehreren weiteren Clients (12) zu dem Server (10) zu senden; Mittel, um den kontinuierlichen Datenstrom von dem Server (10) zu jedem der mehreren weiteren Clients (12) zu senden; Mittel, um den empfangenen kontinuierlichen Datenstrom bei jedem der mehreren weiteren Clients (12) zu resynchronisieren; Mittel, um die Datenfolgen von dem Server (10) zu jedem der mehreren weiteren Clients (12) und zu dem ersten Client (12) zu senden; Mittel, um die empfangenen Datenfolgen bei jedem der Clients (12) auf den lokalen Taktgeber (26) zu resynchronisieren; und Mittel, um die empfangenen Datenfolgen bei jedem der Clients (12) mehrmals zu wiederholen.
Vorrichtung nach Anspruch 31, bei der eine oder mehrere der Datenfolgen eine Folge von Datenfolgen umfassen.
Vorrichtung nach Anspruch 31 oder Anspruch 32, bei der jede Datenfolge einen Part eines Musikinstruments repräsentiert.
Vorrichtung nach Anspruch 33, bei der die Erzeugungsmittel eine digitale Schnittstellenvorrichtung (22) für Musikinstrumente oder MIDI-Vorrichtung umfassen.
Vorrichtung nach Anspruch 34, die Mittel umfasst, um die empfangenen Datenfolgen auf der MIDI-Vorrichtung (22) wiederzugeben.
Vorrichtung nach Anspruch 34, bei der die Datenfolge, die von jedem Client (12) zu dem Server (10) gesendet wird, Daten bezüglich einer Folge aus einer oder mehreren Musiknoten umfasst und die relative Zeit der Note sowie andere die Note beschreibende Parameter enthält.
Vorrichtung nach einem der Ansprüche 31 bis 36, bei der die Länge jeder Datenfolge veränderlich ist.
Vorrichtung nach einem der Ansprüche 31 bis 37, bei der die Länge der von jedem Client (12) erzeugten Datenfolge gleich ist.
Vorrichtung nach einem der Ansprüche 31 bis 38, bei der ein oder mehrere Clients (12) eine Datenfolge mit einer Länge, die von jener der ersten Datenfolge verschieden ist, erzeugen.
Vorrichtung nach Anspruch 32, bei der die Länge jeder Folge der Folge von Folgen gleich ist.
Vorrichtung nach Anspruch 32, bei der die Folgen, die die Folge von Folgen enthalten, unterschiedliche Längen haben.
Vorrichtung nach Anspruch 39, bei der die Länge jeder längeren Folge ein ganzzahliges Vielfaches der Länge der kürzesten Folge ist.
Vorrichtung nach einem der Ansprüche 31 bis 42, die für jeden lokalen Taktgeber (26) umfasst: Mittel, um eine Schlaglänge zu bestimmen; Mittel, um bei jedem Schlag den Datenstrom von dem Server wiederzugewinnen; Mittel, um bei jedem Schlag den Datenstrom auf wiederzugebende Daten zu untersuchen; und Mittel, um die Wiedergabedaten bei jedem Schlag auszugeben.
Vorrichtung nach Anspruch 43, bei der jeder lokale Taktgeber (26) einen Zähler (29) enthält, wobei die Vorrichtung ferner Mittel umfasst, um den Zähler bei jedem Schlag zu inkrementieren.
Vorrichtung nach Anspruch 44, bei der die Datenfolge, die zu jedem Client (12) gesendet wird, Folgenlängendaten enthält, wobei die Vorrichtung ferner Mittel umfasst, um den kumulativen Zählstand des Zählers (29) durch die Folgenlänge zu teilen und um den Schlag der momentanen Folge aus dem Rest zu bestimmen.