EP3077924A1

EP3077924A1 - Vorrichtung, system und verfahren zur effizienten und verzögerungsarmen synchronisation graphenförmiger datenstrukturen

Info

Publication number: EP3077924A1
Application number: EP14811795.5A
Authority: EP
Inventors: Gabriel Gatzsche; Tobias Gehlhaar; Thomas Sporer; Maximilian HELLER; Mario SEIDENECK
Original assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Current assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date: 2013-12-05
Filing date: 2014-12-02
Publication date: 2016-10-12
Also published as: US20160283571A1; CN105934758A; DE102013225058A1; JP2017504104A; JP6311022B2; DE102013225058A8; WO2015082479A1

Abstract

Eine Vorrichtung wird bereitgestellt. Die Vorrichtung umfasst ein Datenmodell (110), wobei das Datenmodell (110) drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells (110) eine ID zugewiesen ist, wobei jeder dieser ein oder mehr Knoten durch seine ID von den anderen Knoten des Datenmodells (110) eindeutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells (110) jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell (110) gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells (110) aufweist, und wobei sich die Pfadangabe von jedem Knoten der besagten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet. Des Weiteren umfasst die Vorrichtung einen Controller, der zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells (110), der Attribute aufweist, eine Schreibfunktion umfasst, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist. Ferner umfasst die Vorrichtung einen Synchronizer (130). Der Synchronizer (130) ist dafür eingerichtet, eine Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells (110) bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie der Wert dieses Attributs zu aktualisieren ist, wobei die Aktualisierungsmitteilung den Knoten mittels der ID des Knotens bezeichnet. Der Controller (120) ist dafür eingerichtet, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung mittels der Schreibfunktion dieses Attributs zu aktualisieren.

Description

Vorrichtung, System und Verfahren

zur effizienten und verzögerungsarmen Synchronisation

graphenförmiger Datenstrukturen Beschreibung

Die Anmeldung betrifft die verzögerungsarme Synchronisation, und, im Speziellen, eine Vorrichtung, ein System und ein Verfahren zur effizienten verzögerungsarmen Synchroni- sation graphenförmiger, z.B. baumförmiger Datenstrukturen.

Eine große Anzahl von Software-Applikationen verwendet intern eine graphenförmige, z.B. baumförmig organisierte Datenstruktur. Eine solche baumförmig organisierte Datenstruktur ist Dabei kann der Zustand der Applikation in einer solchen Datenstrukturen ge- halten werden. Ändern sich Teile der Datenstruktur, so reagiert die Applikation darauf und ändert z.B. die Bildschirmdarstellung oder steuert ein angeschlossenes Peripheriegerät. Das zugrunde liegende Design-Pattern wird MVC (englisch: Model View Controller = Modell - Präsentation - Steuerung) genannt. Möchte man eine derartige Applikation, deren Zustand in einer solchen graphenförmigen, z.B. baumförmigen Datenstruktur gehalten wird, auf mehreren Geräten gleichzeitig ausführen, z.B. um mehrere Nutzer kollaborativ (gemeinschaftlich/zusammenwirkend) mit der Applikation arbeiten zu lassen, oder möchte ein Nutzer unterschiedliche Darstellungen der Applikation auf verschiedene Endgeräte, z.B. einen TabletPC und ein Mobiltelefon zum Zwecke besserer Bedienbarkeit verteilen, so muss folgendes passieren:

Zum einen müssen aufwändig Kommunikationsprotokolle zur Synchronisation der auf unterschiedlichen Endgeräten gleichzeitig laufenden Applikation geschaffen und implementiert werden. Diese Implementierung ist in der Regel teuer und zeitaufwändig und damit auch fehleranfällig.

Zum anderen müssen diese Protokolle schnell und effizient sein. Zwischen einer Nutzereingabe auf einem ersten Gerät und der Aktualisierung der Applikation auf einem weiteren Gerät darf keine spürbare Verzögerung auftreten. Gerade für die Steuerung von Audio- Systemen darf die Synchronisation nur wenige Millisekunden dauern. Im Stand der Technik sind bereits Vorrichtungen bekannt, mit denen man mit mehreren Mobilgeräten ein System gleichzeitig steuern kann, z.B. Mackie-Control, oder diverse iPad Steuerungen für Mischpulte. Die Kommunikation unterschiedlicher Clients (Klienten, Clientanwendungen) einer Applikation erfolgt derzeit in der Regel mit Hilfe von Datenbanken. Über ein Datenbankprotokoll werden Zustände in einer Datenbank gesetzt, welche wiederum an die unterschiedlichen Clients übertragen werden. Hierbei gibt es zwei Ansätze: Der erste Ansatz ist ein sogenannter Key-Value-Ansatz (Schlüsselwert-Ansatz), siehe z.B. die Redis-Datenbank. Zu einem Schlüssel wird ein Datensatz gespeichert. Über den Schlüssel kann schnell auf den Datensatz zugegriffen werden. Vorteil dieses Ansatzes ist hohe Performanz. Jedoch ist die Entwicklung komplexer Applikationen auf Basis des Key- Value-Ansatzes unüberschaubar, und damit teuer und fehleranfällig.

Der zweite Ansatz ist ein sogenannter dokumentenorientierter Ansatz, siehe z.B. CouchDb, MongoDb. Dabei liegen die Daten graphenförmig strukturiert vor, und können über einen Adress-Pfad (Adressen-Pfad) erreicht werden. Dieser Ansatz ermöglicht gut strukturierte Daten und somit einfach zu handhabende Applikationen. Die Entwicklung von Applikationen (Anwendungen) erfolgt damit schnell und unkompliziert. Nachteil ist, dass Zugriffe auf die Daten teuer sind. Für sich hochfrequent ändernde, niedrig latente Steuerdaten ist ein solcher Ansatz jedoch weniger geeignet.

Wünschenswert wäre es jedoch, wenn Konzepte bereitgestellt würden, die einerseits ho- he Performanz bei der verzögerungsarmen Synchronisation und bei der Datenaktualisierung realisieren, und die andererseits ein hohes Maß an Intuitivität beim Datenzugriff realisieren.

Eine Vorrichtung nach Anspruch 1 , ein Server nach Anspruch 14, ein Client nach An- spruch 21 , ein System nach Anspruch 25, eine Verfahren nach Anspruch 26 und ein Computerprogramm nach Anspruch 27 wird bereitgestellt.

Eine Vorrichtung wird bereitgestellt. Die Vorrichtung umfasst ein Datenmodell wobei das Datenmodell drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells eine ID zugewiesen ist, wobei jeder dieser ein oder mehr Knoten durch seine ID von den anderen Knoten des Datenmodells eindeutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells aufweist, und wobei sich die Pfadangabe von jedem Knoten der besag- ten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet.

In einer Ausführungsform kann beispielsweise jedem der Knoten des Datenmodells eine ID zugewiesen sein, wobei jeder der Knoten des Datenmodells durch seine ID von den anderen Knoten des Datenmodells eindeutig unterscheidbar ist.

Des Weiteren umfasst die Vorrichtung einen Controller, der zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells, der Attribute aufweist, eine Schreibfunktion umfasst, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist. Ferner umfasst die Vorrichtung einen Synchronizer. Der Synchronizer ist dafür eingerichtet, eine Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie der Wert dieses Attributs zu aktualisieren ist, wobei die Aktualisierungsmitteilung den Knoten mittels der ID des Knotens bezeichnet. Der Controller ist dafür eingerichtet, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung mittels der Schreibfunktion dieses Attributs zu aktualisieren.

In Ausführungsformen übernimmt die Schreibfunktion nicht nur das Setzen des Wertes im Datenmodell, sondern auch das Informieren des Synchronizers und/oder das Informieren weiterer Beobachter sowie weitere mögliche Funktionen wie beispielsweise das Aufzeichnen von Änderungen über die Zeit zum Zwecke der späteren Wiedergabe oder Rückgängigmachung.

Gemäß Ausführungsformen ist der Synchronizer dafür eingerichtet, Aktualisierungsmittei- lungen zu senden.

Ausführungsformen der Erfindung weisen gegenüber dem Stand der Technik zahlreiche Vorteile auf, beispielsweise Deutlich leichtere Erweiterbarkeit des Synchronisations- Protokolls, vollständig webbasierte Umsetzung transparente Synchronisation für den An- Wendungsentwickler und/oder leichte Einbindung neuer Komponenten. Während im Stand der Technik Anbieter lediglich ein Protokoll, nicht jedoch persistente Datenrepräsentation im Clienten und im Server, wird gemäß Ausführungsformen die persistente Datenreprä- sentation definiert und daraus das Protokoll abgeleitet. Ausführungsformen stellen weitere Tools bereit.

Gemäß einer Ausführungsform wird ein Server bereitgestellt. Der Server ist eine Vorrich- tung wie oben beschrieben. Ferner ist der Server dafür eingerichtet, eine Anmeldung von ein oder mehreren Clients entgegenzunehmen. Ferner ist der Server dafür eingerichtet, den ein oder mehreren Clients auf deren Anmeldung hin, Informationen über das Datenmodell zu übertragen, wobei diese Informationen über das Datenmodell die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells umfas- sen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell ferner für jeden Knoten des Datenmodells oder für die wenigstens zwei Knoten des Datenmodells angeben, welche ein oder mehreren der Knoten des Datenmodells diesem Knoten unmittelbar nachfolgen und/oder welche ein oder mehreren Knoten des Datenmodells diesem Knoten unmittelbar vorausgehen.

In einer Ausführungsform kann der Server z.B. dafür eingerichtet sein, den ein oder mehreren Clients auf deren Anmeldung hin, die ID von zwei oder mehreren der Knoten des Datenmodells des Servers zu übertragen. Gemäß einer weiteren Ausführungsform wird ein Client bereitgestellt. Der Server ist eine Vorrichtung wie oben beschrieben. Ferner ist der Client dafür eingerichtet, sich bei dem oben beschriebenen Server anzumelden. Der Client ist dafür eingerichtet, auf die Anmeldung beim Server hin, Informationen über das Datenmodell des Servers zu empfangen, wobei diese Informationen über das Datenmodell des Servers die Werte der Attribute von allen Knoten oder von zwei oder mehr Knoten des Datenmodells des Servers umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell des Servers ferner für jeden Knoten des Datenmodells oder für die zwei oder mehr Knoten des Datenmodells des Servers angeben, welche der Knoten des Datenmodells des Servers diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells des Ser- vers diesem Knoten unmittelbar vorausgehen. Ferner ist der Client dafür eingerichtet, sein Datenmodell abhängig von den Informationen über das Datenmodell des Servers hin zu aktualisieren.

Des Weiteren wird ein System bereitgestellt. Das System umfasst den oben beschriebe- nen Server und den oben beschriebenen Client. Dabei ist der Client dafür eingerichtet, dem Server eine Aktualisierungsmitteilung zu senden. Der Synchronizer des Servers ist dafür eingerichtet, die Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells bezeichnet, die des Weiteren ein Attribut dieses Knotens bezeichnet, und die angibt, wie der Wert dieses Attributs zu aktualisieren ist. Der Controller des Servers ist dafür eingerichtet, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung zu aktualisieren, wenn die Aktualisierungsmitteilung die ID des Knotens bezeichnet.

Ferner wird ein Verfahren bereitgestellt. Das Verfahren umfasst:

Empfangen einer Aktualisierungsmitteilung, die einen Knoten eines Datenmodells mittels einer ID des Knotens bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie ein Wert dieses Attributs zu aktualisieren ist, wobei das Datenmodell drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells eine ID zugewiesen ist, wobei jeder dieser ein o- der mehr Knoten durch seine ID von den anderen Knoten des Datenmodells ein- deutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells aufweist, und wobei sich die Pfadangabe von jedem Knoten der besagten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet. Und:

Aktualisieren des Wertes des in der Aktualisierungsmitteilung bezeichneten Attri- buts mittels der Schreibfunktion dieses Attributs in Abhängigkeit von der Aktualisierungsmitteilung.

In Ausführungsformen kann das Verfahren beispielsweise einen weiteren Schritt oder weitere Schritte umfassen, beispielsweise:

Generierung der IDs, und/oder

Aktualisierungen zwischen Client und Server

Abgleich der Datenmodelle zwischen Server und Client, und/oder

Spezifikation der Schreibfunktion / Speicherfunktion.

Des Weiteren wird ein Computerprogramm mit einem Programmcode zur Durchführung des oben beschriebenen Verfahrens bereitgestellt. Bevorzugte Ausführungsformen finden sich in den abhängigen Ansprüchen.

Nachfolgend werden bevorzugte Ausführungsformen der Erfindung unter Bezugnahme auf die Zeichnungen beschrieben.

In den Zeichnungen ist dargestellt:

Fig. 1 a zeigt eine Vorrichtung gemäß einer Ausführungsform,

Fig. 1 b zeigt die hierarchische Graphenstruktur des Datenmodells gemäß einer

Ausführungsform,

Fig. 1 c zeigt ein System gemäß einer Ausführungsform,

Fig. 2a zeigt ein Datenmodell, eine Beobachter-Struktur und eine Controller-

Struktur,

Fig. 2b zeigt einen möglichen Ablauf der Synchronisation zwischen einem Client und einem Server,

Fig. 2c zeigt ein Praxisbeispiel für die Einrichtung eines Beschallungssystems ohne Verwendung von UI.FM,

Fig. 2d - 2g zeigen erfindungsgemäße Anwendungsbeispiele zur verzögerungsarmen

Synchronisation gemäß Ausführungsformen,

Fig. 3 zeigt ein UI.FM System gemäß bevorzugter Ausführungsformen,

Fig. 4a - 4e zeigen weitere erfindungsgemäße Anwendungsbeispiele zur verzögerungsarmen Synchronisation gemäß Ausführungsformen,

Fig. 5a - 5c zeigen eine erfindungsgemäße Realisierung einer Web-Applikation gemäß einer Ausführungsform,

Fig. 6a, 6b zeigen weitere Ausführungsbeispiele der verzögerungsarmen Synchronisation gemäß Ausführungsformen, Fig. 7a - 7f zeigen ein Datenmodell und dessen programmiertechnische Umsetzung gemäß einer Ausführungsform,

Fig. 8a - 8g zeigen die Konsoleneingabe von Programmierbefehlen und die zurückge- lieferten Ergebnisse gemäß Ausführungsformen,

Fig. 9a - 9h zeigen die Änderung einer Datenstruktur durch Hinzufügung eines Attributs gemäß einer Ausführungsform, Fig. 10a - 10e zeigen, wie Nutzer sich gemäß einer Ausführungsform informieren lassen können, wenn ein Wert des Datenmodells sich ändert, und zeigt eine Alarmausgabe bei Wiedergabe einer Datenaufzeichnung ent sprechend der wiedergegebenen Datenaufzeichnung gemäß einer Ausfüh rungsform.

Fig. 1 a zeigt eine Vorrichtung gemäß einer Ausführungsform. Die Vorrichtung umfasst ein Datenmodell 1 10, wobei das Datenmodell 1 10 drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells 1 10 eine ID zugewiesen ist, wobei jeder dieser ein oder mehr Knoten durch seine ID von den anderen Knoten des Datenmodells 1 10 eindeutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells 1 10 jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell 1 10 gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells 1 10 aufweist, und wobei sich die Pfadangabe von jedem Knoten der besagten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet.

In einer Ausführungsform kann beispielsweise jedem der Knoten des Datenmodells 1 10 eine ID zugewiesen sein, wobei jeder der Knoten des Datenmodells durch seine ID von den anderen Knoten des Datenmodells 1 10 eindeutig unterscheidbar ist.

Mit anderen Worten weisen also zahlreiche der Knoten des Datenmodells eine Pfadangabe auf, die mehr als einen Knoten aufweisen. Ist folgt in einer Baumhierarchie beispielsweise ein Knoten„Renderer" unmittelbar dem Knoten„root", so kann die Pfadangabe bei- spielsweise„root.Renderer" lauten, und diese Pfadangabe weist somit zwei der Knoten des Datenmodells, nämlich „root" und „Renderer" auf. Über die Pfadangabe „root.Renderer" hinaus ist dem Knoten„Renderer" auch noch eine im Datenmodell eindeutige ID zugewiesen, beispielsweise die Zahl„2" (siehe z.B. Datenmodell 310 in Fig. 3). In jedem Fall aber, sind ID und Pfadangabe eines Knotens immer voneinander verschieden. Die ID, die dem Knoten zugewiesen ist, existiert also zusätzlich zur Pfadangabe. Zweck der Pfadangabe ist unter anderem, dass die Knoten des Datenmodells intuitiv über die Pfadstruktur ansprechbar sind, während die ID dazu dient, den Knoten durch einen kurzen Identifikator anzusprechen.

Des Weiteren umfasst die Vorrichtung einen Controller 120, der zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells, der Attribute aufweist, eine Schreibfunktion umfasst, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist.

Ferner umfasst die Vorrichtung einen Synchronizer 130. Der Synchronizer 30 ist dafür eingerichtet, eine Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells 1 10 bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie der Wert dieses Attributs zu aktualisieren ist, wobei die Aktualisierungsmitteilung den Knoten mittels der ID des Knotens bezeichnet.

Der Controller 120 ist dafür eingerichtet, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung mittels der Schreibfunktion dieses Attributs zu aktualisieren.

Dabei kann das Datenmodell 1 10 eine graphenförmige Struktur aufweisen. So kann zum Beispiel festgelegt sein, dass ein Knoten„root" dem Knoten„Renderer" vorausgeht. Diese Beziehung kann als ein Graph von von„root" nach„Renderer" definiert sein, bzw. ange- geben werden. Ferner kann zum Beispiel festgelegt sein, dass der Knoten „Renderer" dem Knoten„Scene" vorausgeht. Diese Beziehung kann als ein Graph von von„Renderer" nach „Scene" definiert sein, bzw. ansehen werden. Aus all solchen Beziehungen ergibt sich dann die graphenförmige Struktur des Datenmodells 1 10. Das Datenmodell 1 10 kann baumförmige hierarchische Struktur aufweisen, die als Sonderfall einer graphenförmigen Struktur angesehen werden kann. In einer baumförmigen hierarchischen Struktur existiert üblicherweise ein Wurzelknoten, dem alle weiteren Kno- ten des Datenmodells mittelbar oder unmittelbar nachfolgen. Ein solche baumförmigen hierarchischen Struktur ist in Fig. 1 b dargestellt..

Beispielsweise kann eine Pfadangabe „root.Renderer.Scene.srcO" den entsprechenden Knoten srcO in einer baumförmigen Hierarchie, wie die baumförmige Hierarchie der Fig. 1 b, eindeutig bezeichnen. Eine solche Pfadangabe umfasst den Knoten„srcO" und drei weitere Knoten des Datenmodells, nämlich„root",„Renderer" und„Scene". Nur„srcO" als Namen zu verwenden, um den entsprechenden Knoten eindeutig zu bezeichnen, ist unter Umständen nicht ausreichend, denn eventuell kommt der Knoten„srcO" als Name im Da- tenmodell mehrmals vor.

Eine ID, mit der der Knoten kurz und eindeutig angesprochen wird, kann beispielsweise eine Zahl sein. Beispielsweise könnte der Knoten srcO durch die ID„7" bezeichnet sein. Zur Unterscheidung der Begriffe ID und Pfadangabe kann folgendes erläutert werden. Eine einfache ID hat nur eine Anforderung: Sie muss einen Knoten lediglich systemweit eindeutig adressieren. Es reicht hier also beispielsweise alle Knoten einfach zu numme- rieren. Eine Pfadangabe erfüllt in der Regel über die ID hinausgehende weitere Eigenschaften: Sie umfasst lokale Knotennamen, welche einen Weg von der Wurzel des Graphen bis hin zum zu adressierenden Knoten über Zwischenknoten beschreiben. Im Gegensatz zur globalen ID muss der lokale Knotenname nur für den Knoten und seine Geschwisterknoten eindeutig sein. Über die Kombination der lokalen Knotennamen eines Knoten mit den lokalen Knotennamen der Eltern- bzw. Vorgängerelemente eines Knotens entsteht die ebenfalls systemweit eindeutige Pfadangabe.

In einer Ausführungsform kann die ID jedes der drei oder mehr Knoten des Datenmodells beispielsweise eine Zahl oder eine Zeichenkette oder ein Hashwert sein.

In einer Ausführungsform weist der Controller 120 zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells, der Attribute auf, eine Lesefunktion umfasst, wobei der Wert des Attributs mittels der Lesefunktion lesbar ist. Beispielsweise kann in einer besonderen Ausführungsform der Synchronizer 140 dafür eingerichtet sein, die Aktualisierungsnachricht zu empfangen, mit der darin enthaltenen ID eine zugehörige Controller-Subeinheit des Controllers 120 zu ermitteln, die für diesen Knoten zuständig ist (dafür besitzt der Synchronizer 140 beispielsweise ein Dictionary (Wörterbuch) / eine Map (Abbildung), welche zu jeder ID eine Referenz auf eine Control- ler-Subeinheit speichert), und dann dieser eine Information zu übergeben, welche den Namen des zu ändernden Attributs als auch den Wert enthält. Die Controller-Subeinheit des Controllers 120 ändert dann mit Hilfe der Schreibfunktion das Datenmodell 1 10.

Gemäß einer Ausführungsform ist der Synchronizer dafür eingerichtet, die Aktualisierungsmitteilung zu empfangen, die den besagten Knoten des Datenmodells bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren das besagte Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie der Wert dieses Attributs zu aktualisieren ist, wobei die Aktualisierungsmitteilung die Pfadangabe des Knotens bezeichnet, wobei der Controller dafür eingerichtet ist, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung zu aktualisieren.

In einer Ausführungsform bilden die drei oder mehr Knoten des Datenmodells eine gra- phenförmige, z.B. baumförmige Hierarchie, so dass jedem Knoten des Datenmodells wenigstens einer der Knoten des Datenmodells in der graphenförmigen Hierarchie unmittelbar nachfolgt und/oder mindestens einer der Knoten des Datenmodells in der graphenförmigen Hierarchie unmittelbar vorausgeht, wobei wenigstens einem der Knoten des Datenmodells zwei Knoten des Datenmodells in der baumförmigen Hierarchie unmittelbar nachfolgen.

Fig. 1 b zeigt eine solche graphenförmige Datenstruktur am Beispiel einer baumförmigen hierarchischen Datenstruktur des Datenmodells gemäß einer Ausführungsform. In der baumförmigen Hierarchie des Datenmodells folgen die Knoten„DHD®" und„Renderer" dem Knoten„root" unmittelbar nach. Umgekehrt geht der Knoten„root" geht den Knoten „DHD®", und„Renderer" unmittelbar voraus. Dem Knoten„Renderer" folgen die Knoten „LSSetups", „Scene", „Spatial Sound Wave" und „WavPI" unmittelbar nach. Umgekehrt geht der Knoten„Renderer" den Knoten„LSSetups",„Scene",„Spatial Sound Wave" und „WavPI" unmittelbar voraus, usw.

Gemäß einer Ausführungsform weist die Vorrichtung ferner eine Schnittstelle auf, die dafür eingerichtet ist, Informationen über Änderungen des Datenmodells entgegenzunehmen, die einem der Knoten des Datenmodels ein oder mehrere Attribute hinzufügen, wobei die Vorrichtung dafür eigerichtet ist, für jedes dieser hinzugefügten ein oder mehreren Attribute eine Lesefunktion und eine Schreibfunktion automatisch zu erzeugen, wobei der Wert des besagten Attributs mittels der Lesefunktion lesbar ist, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist. In Ausführungsformen ändert beispielsweise die erzeugte Schreibfunktion nicht nur den Wert des lokalen Datenmodells, sondern sorgt gleichzeitig dafür, dass der Synchronizer über die Änderung informiert wird, Änderungs-Events im System propagiert werden und/oder angeschlossene Beobachter auf die Änderung reagieren können und/oder wei- tere Dinge veranlasst werden, wie z.B. die Aufzeichnung von Automationsdaten, Und- o/Redo usw.

In einer Ausführungsform ist die Vorrichtung dafür eingerichtet, die Lesefunktion und die Schreibfunktion für jedes der Attribute jedes der Knoten des Datenmodells, der Attribute aufweist, mittels einer Webapplikation bereitzustellen, so dass die besagte Lesefunktion und die besagte Schreibfunktion mittels der Webapplikation nutzbar sind. In einer Ausführungsform kann die Webapplikation beispielsweise in JavaScript und/oder HTML implementiert sein. Gemäß einer Ausführungsform ist die Vorrichtung dafür eingerichtet, für eines der Attribute eines der Knoten des Datenmodells, auf eine Nutzereingabe hin, eine Änderungsüberwachung einzurichten.

Beispielsweise kann die Änderungsüberwachung dafür eingerichtet sein, ein „Event" (event = Ereignis) zu versenden bzw. auszulösen.

Beispielsweise kann z.B. die Vorrichtung dafür eingerichtet ist, einen Alarm auszugeben, wenn ein Wert eines der Attribute sich ändert, für das eine Änderungsüberwachung eingerichtet ist.

Um z.B. einen Alarm anzuzeigen, kann man einen Beobachter auf das Event registrieren. Dieser empfängt das Event und gibt dann einen Alarm aus. Statt der Ausgabe eines Alarms kann die Reaktion aber auch jede andere sein. Gemäß einer Ausführungsform wird ein Server bereitgestellt. Der Server ist eine Vorrichtung wie oben beschrieben. Ferner ist der Server dafür eingerichtet, eine Anmeldung von ein oder mehreren Clients entgegenzunehmen. Ferner ist der Server dafür eingerichtet, den ein oder mehreren Clients auf deren Anmeldung hin, Informationen über das Datenmodell zu übertragen, wobei diese Informationen über das Datenmodeii die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell ferner für jeden Knoten des Datenmodells oder für die wenigstens zwei Knoten des Datenmodells angeben, welche der Knoten des Datenmodells diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells diesem Knoten unmittelbar vorausgehen. Das Datenmodell enthält dabei beispielsweise auch die Knoten IDs.

In einer Ausführungsform ist der Server dafür eingerichtet, eine Anmeldung von zwei oder mehreren Clients entgegenzunehmen, wobei der Synchronizer des Server dafür eingerichtet ist, eine Nachricht von einem der Clients zu empfangen, die angibt, dass ein Wert eines Attributs eines Knotens des Datenmodells sich geändert hat, und wobei der Synchronizer des Server dafür eingerichtet ist, auf die Nachricht des besagten Clients hin, die anderen zwei oder mehreren Clients, die sich beim Server angemeldet haben, davon un- terrichtet, dass ein Wert eines Attributs eines Knotens des Datenmodells sich geändert hat.

Umgekehrt kann der Server auch das Datenmodell und Aktualisierungen von Client empfangen. Dies kann beispielsweise dann sinvoll sein, wenn der Client längere Zeit z.B. oh- ne Verbindung mit dem Server, z.B. offline gearbeitet hat.

Gemäß einer Ausführungsform ist der Server dafür eingerichtet, einem Gerät drahtlos, oder drahtgebunden eine Nachricht zuzusenden, die dem Gerät mitteilt, dass ein Attribut eines der Knoten des Datenmodells sich geändert hat.

In einer Ausführungsform ist die Vorrichtung dafür eingerichtet ist, dem Gerät die Nachricht drahtlos, z.B. mittels WLAN, mittels GPRS, mittels UMTS oder mittels LTE, zuzusenden. Gemäß einer Ausführungsform ist das Gerät ein Renderer zur Erzeugung von ein oder mehreren Lautsprechersignalen ist. In einer Ausführungsform kann das Gerät auch eine DHD®-Audio Matrix sein. Beispielsweise können die angeschlossenen Clients eine (3D) Audio-Workstation, ein Audio-Plugin (VST / RTAS / AudioUnits etc.) und/oder eine iPad®- App sein.

In einer Ausführungsform ist der Server dafür eingerichtet, vom Client Informationen über das Datenmodell des Clients zu empfangen, wobei diese Informationen über das Datenmodell des Clients die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells des Clients umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell des Clients ferner für jeden Knoten des Datenmodells des Clients oder für die wenigstens zwei Knoten des Datenmodells des Clients angeben, welche der Knoten des Datenmodells des Clients diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells des Clients diesem Knoten unmittelbar vorausgehen.

Gemäß einer weiteren Ausführungsform wird ein Client bereitgestellt. Der Server ist eine Vorrichtung wie oben beschrieben. Ferner ist der Client dafür eingerichtet, sich bei dem oben beschriebenen Server anzumelden. Der Client ist dafür eingerichtet, auf die Anmeldung beim Server hin, Informationen über das Datenmodell des Servers zu empfangen, wobei diese Informationen über das Datenmodell des Servers die Werte der Attribute von allen Knoten oder von zwei oder mehr Knoten des Datenmodells des Servers umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell des Servers ferner für jeden Knoten des Datenmodells oder für die zwei oder mehr Knoten des Datenmodells des Servers angeben, welche der Knoten des Datenmodells des Servers diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells des Servers diesem Knoten unmittelbar vorausgehen. Ferner ist der Client dafür eingerichtet, sein Datenmodell abhängig von den Informationen über das Datenmodell des Servers hin zu aktualisieren.

In einer Ausführungsform ist der Client dafür eingerichtet, dem Server Informationen über das Datenmodeil des Clients zu übertragen, wobei diese Informationen über das Daten- modell des Clients die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells des Clients umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell des Clients ferner für jeden Knoten des Datenmodells des Clients oder für die wenigstens zwei Knoten des Datenmodells des Clients angeben, welche der Knoten des Datenmodells des Clients diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells des Clients diesem Knoten unmittelbar vorausgehen.

Gemäß einer Ausführungsform kann der Client zur Erstellung objektorientierter Audioszenen eingerichtet sein.

Fig. 1 c zeigt ein System gemäß einer Ausführungsform.

Das System umfasst den oben beschriebenen Server 170 und den oben beschriebenen Client 160. Dabei ist der Client 160 dafür eingerichtet, dem Server 170 eine Aktualisie- rungsmitteilung zu senden. Der Synchronizer des Servers 170 ist dafür eingerichtet, die Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells des Servers 170 bezeichnet, die des Weiteren ein Attribut dieses Knotens bezeichnet, und die angibt, wie der Wert dieses Attributs zu aktualisieren ist. Der Controller des Servers 170 ist dafür eingerichtet, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung zu aktualisieren, wenn die Aktualisierungsmitteilung die ID des Knotens bezeichnet. Im Folgenden werden zunächst Grundkonzepte vom Ausführungsformen erläutert. Daran anschließend werden bevorzugte Ausführungsformen und deren Konzepte im Detail beschrieben.

Ausführungsformen stellen einen allgemeinen Mechanismus bereit, welcher die Vorteile Key-Value-basierter (Schlüsselwert-basierter) Datenbanken mit dokumentenorientierten Ansätzen kombiniert. Ziel ist, graphenförmig strukturierte Datenstrukturen in Echtzeit und/oder niedrig-latent bzw. verzögerungsarm miteinander zu synchronisieren.

Gemäß Ausführungsformen wird bei der Entwicklung einer Applikation folgendermaßen vorgegangen:

Es wird eine graphenförmige Datenstruktur definiert, welche die Daten der Applikation repräsentiert. Die Datenstruktur kann z.B. ein JSON- oder XML-Datensatz sein (JSON = JavaScript Object Notation = JavaScript Objekt-Notation; XML = Extensible Markup Lan- guage = erweiterbare Auszeichnungssprache).

Aus der graphenförmigen Datenstruktur wird mit Hilfe eines Code-Generators der ausführbare Controller- und Datenmodell-Code generiert. Dies kann Server- als auch Client- seitig erfolgen. Der so generierte Code umfasst beispielsweise Routinen zum Lesen und Schreiben der Daten in das Graphen-Modell, Routinen zum Benachrichtigen an Änderungen interessierter Beobachter, sowie Routinen zum Übertragen der Änderungen am Datenmodell an einen zentralen Server bzw. daran angeschlossene Clients.

Fig. 2a zeigt drei Strukturen, nämlich ein Datenmodell (Model) 201 , eine Beobachter- Struktur (View / Sicht) 203, sowie eine Controller-Struktur (Controller) 202, die basierend auf einem ursprünglichen Datenmodell, das graphenförmig ist, automatisch generiert werden.

Die erzeugte Controller-Struktur 202 umfasst dabei gleich den Code zur Synchronisation der Baum-Hierarchie mit dem Server und damit auch mit anderen Clients. Die Synchronisation kann dabei vom Client zum Server und/oder vom Server zum Client erfolgen. Fig. 2b zeigt einen möglichen Ablauf der Synchronisation zwischen einem Client 210 und einem Server 220. In Fig. 2b umfasst der Client 210 ein Datenmodell 21 1 , einen Controller 212, eine View 213 und einen Synchronizer (Synchronisator) 214. Der Server 220 umfasst in Fig. 2b ein Datenmodell 221 , einen Controller 222 und einen Synchronizer 224.

Ändert beispielweise eine Nutzerin (Anna) 205 etwas, dann wird dies dem Controller 212 des Clients 210 mitgeteilt. Der Controller 212 des Clients 210 ändert die baumförmige Datenstruktur (Model) 21 1 , und informiert mittels einer Aktualisierungsmitteilung gleichzeitig noch den Synchronizer 214 des Client 210. All das passiert, z.B. mit Hilfe der automa- tisch erzeugten Schreibfunktion.

Der Synchronizer 214 des Clients 210 überträgt die Änderung in einer Aktualisierungsmitteilung an den Server 220, z.B. an den Synchronizer 224 des Servers 220. Der Server 220 trägt wiederum auf die Aktualisierungsmitteilung hin die Änderung in sein lokales Da- tenmodell 221 ein, z.B. durch den Controller 222 des Servers 220. Daneben überträgt der Server 220 die Änderung gleichzeitig auch an alle Clients (in Fig. 2b nicht dargestellt).

Startet der Server oder eine Client-Applikation, so laden diese zunächst die Definition der graphenförmigen Datenstruktur und erzeugen mit Hilfe des zuvor angesprochenen Code- Generators den Applikations-Code.

Der Code-Generator kann dabei beispielsweise von einer Festplatte geladen werden, oder aber beispielsweise beim Anmelden vom Server an den Client übertragen werden. Weiterhin wird beispielsweise jedem Knoten der graphenförmigen Datenstruktur eine für den Client eindeutige ID zugeordnet.

Die Erzeugung der ID kann dabei beispielsweise folgendermaßen erfolgen. Jeder Client bekommt zunächst eine systemweit eindeutige Client-ID. Erzeugt ein Client einen neuen Knoten, so wird eine lokal eindeutige Knotenbezeichner mit der Client-Id zu einer systemweit eindeutigen Knoten-Id kombiniert. Dadurch ist nach Übertragung der Client-Id keine zentrale ID-Erzeugung mehr notwendig. Die Vorteile liegen hier vor allem darin, dass für das Erzeugen neuer Knoten im Clients keine Server-Abfragen notwendig sind. Damit ist der Client auch offline in der Lage, systemweit eindeutige IDs zu generieren. Voraussetzung ist jedoch, dass der Client mind. einmal mit dem Server verbunden war. Im Client lokal erzeugte Knoten sind (später) z.B. an den Server und die restlichen Clients zu übertragen und dort in die lokale Datenstruktur einzuhängen. Jedoch ist kein Umbenennen von IDs mehr nötig. Beispielsweise behält die ID ihre Gültigkeit nur zur Laufzeit. Mit Hilfe dieser ID ist es später möglich, jeden Knoten des Baumes direkt zu adressieren. Statt einer langen Pfad- Adresse wie z.B. ,,/stamm/ast/zweig/blatt/zelle" kann der Knoten des Baumes dann auch über die ID, die einen kurzen Hash darstellt, z.B. "0d4", adressiert werden. Dies ist gerade für Applikationen (Anwendungen) mit hohem Datenaufkommen von Bedeutung.

Sind Client und Server gestartet, so müssen zunächst die Datenstrukturen initial abgeglichen werden. Hat der Client eine Zeit lang offline gearbeitet, ist es oftmals sinnvoll, die Datenstruktur von Client zum Server abzugleichen, z.B. indem der Client den Server über die aktuelle Datenstruktur des Clients unterrichtet, damit der Server beispielweise seine Datenstruktur anpassen kann. Möchte hingegen der Client die bestehende Applikation nachträglich vom Server laden, dann ist z.B. die Datenstruktur vom Server zum Client abzugleichen, indem beispielsweise der Client die Datenstruktur des Servers von diesem erhält.

Nimmt man beispielweise an, dass die Daten vom Server auf den Client abgeglichen werden sollen, kann dies beispielweise wie folgt erfolgen: In einem ersten Schritt müssen die Knoten-IDs zwischen Client und Server abgeglichen werden, d.h. zugehörige Knoten auf Clientseite und auf Serverseite müssen die gleichen Adressen haben. Dazu generiert der Server beispielsweise einen ID-Baum, welcher die gleiche Struktur wie der Datenbaum hat, jedoch zunächst nur die IDs enthält. Alternativ dazu könnte der Server bzw. der Client beispielsweise auch eine Tabelle übertragen, wel- che Pfaden zu Ids zuordnet. Dieser ID-Baum wird an den Client übertragen. Dieser ersetzt die bestehenden IDs durch die des Servers. Beobachter (Views) des Baumes werden ebenfalls über die Umbenennung der IDs informiert.

Nach diesem Schritt müssen die tatsächlichen Baum-Daten vom Server auf den Client übertragen werden. Hier zwei Möglichkeiten, wie das beispielsweise funktionieren kann:

Beispiel 1 : Eine erste Möglichkeit ist, die Baum-Daten als baumförmige Datenstruktur an den Client zu übertragen und in die entsprechenden Knoten zu parsen (einzutragen). Beispiel 2: Eine zweite Möglichkeit ist, die Baum-Daten Knoten für Knoten einzeln vom Server an den Client zu übertragen. Dazu werden beispielsweise die Daten des jeweiligen Knotens zusammen mit dem Knotenbezeichner bzw. Knotennamen in ein Datenpaket verpackt und an den Client übertragen. Dieser kann mit Hilfe der Knotenbezeichner den zugehörigen Knoten ermitteln und die entsprechenden Daten in diesen schreiben.

Die erste Möglichkeit wird verwendet, um größere Datenstrukturen initial vom Server an den Client bzw. umgekehrt zu übertragen. Die zweite Möglichkeit wird verwendet, um kleine, aber häufig auftretende Änderungen effektiv zwischen Client und Server auszutauschen.

Um mehrere Clients miteinander zu verbinden, ist es dabei ausreichend, wenn der Server die Datenpakete, die er von einem Client erhält, einfach an die anderen Clients weiterleitet. Durch das hier vorgeschlagene System besitzen alle Clients die gleiche Baumstruktur und dieselben IDs. Jeder der Clients ist damit in der Lage, Änderungs-Nachrichten der anderen Clients zu verstehen. Ausführungsformen kombinieren die Performance- Vorteile der Schlüsselwert- Adressierung (Key-Value-Datenbanken) mit den Möglichkeiten dokumentenonentierter Ansätze (z.B. XML, JSON-Daten) sowie der automatisierten Code-Generierung.

Die Key-Value-Adressierung von Daten ermöglichen einen schnellen maschinellen Zugriff auf Daten. Hierdurch wird eine hochfrequente niedriglatente Synchronisation von Software-Applikationen gewährleistet.

Der dokumentenorientierte Ansatz vereinfacht die Verwaltung von großen, komplex strukturierten Datensätzen. Der Zugriff auf die Daten, z.B. durch eine(n) Anwendungsentwick- ler/in, ist hierdurch sehr einfach. Anwendungen können dadurch schnell und effizient entwickelt werden.

Die automatische Code-Generierung erlaubt wiederkehrende Code-Bestandteile wie Controller, Publisher, Parser, Serializer, Synchronizer, Lese- und Schreibfunktionen automati- siert aus der graphenförmigen Datenstruktur zu erzeugen. Dies ermöglicht eine weitere Herabsetzung der Entwicklungsdauer für verteilte Software-Applikationen.

Ebenso spart auch die automatische Code-Erzeugung aus einer graphenförmigen Datenstruktur Zeit und Kosten für die Entwicklung verteilter Software-Applikationen. Eine Erwei- terung der graphenförmigen Datenstruktur bedeutet automatisch auch eine Erweiterung des Protokolls, eine Erweiterung des Parsers, des Serializers usw., des Synchronizers usw. Die Synchronisation zwischen den graphenförmigen Datenstrukturen erfolgt für den Anwendungsentwickler völlig transparent. Der Anwendungsentwickler definiert einfach seine Datenstruktur, den Rest übernimmt der Code-Generator. Dadurch das sowohl jeder Client, als auch der Server das gesamte Datenmodell (oder, gemäß Ausführungsformen, zumindest einen Teil des Datenmodells) besitzen, ist es möglich, Clients offline arbeiten zu lassen und später zu synchronisieren. Gleichzeitig wird die Stabilität des Systems deutlich erhöht. Jeder Client kann damit gleichzeitig als Backup des Servers agieren.

Ein maßgebliches Einsatzgebiet von Ausführungsformen liegt in der Web-Entwicklung. Hierbei wird der Code in der Regel offen als JavaScript, Ruby oder ähnliches, aber nicht in Form von Maschinencode übertragen. Technische Anwendungsgebiete sind beispielsweise kollaborative verteilte Echtzeitapplikationen, z.B., die Steuerung- und Überwachung von Maschinen, die Steuerung und Überwachung von Audio-Systemen, verteilte Software-Applikationen im Allgemein, und Webapplikationen. Ausführungsformen sind als ein User-Interface-Framework (UI.FM) realisiert, das z.B. webbasiert sein kann, und welches die Entwicklung verteilter Applikationen deutlich nutzerfreundlicher, kosteneffizienter und plattformübergreifend gestaltet.

Einige Ausführungsformen können beispielweise dafür eingesetzt werden, um 3D-Audio- Systeme gleichzeitig von mehreren Hörpositionen aus, z.B. in einem Stadion, akustisch einzurichten.

Fig. 2c zeigt ein Beispiel ohne Verwendung von UI.FM. Dabei stellt Fig. 2c die Bregenzer Seebühne dar. Vorne ist die Bühne 230 dargestellt. Auf der Bühne 230 sind eine große Anzahl Lautsprecher 231 , 232, 233, 23N installiert. Im Zuschauerbereich sieht man das FoH 240 ("Front of House": Der Platz in der Mitte vor dem Bühnenhaus, der Ort wo der Tonmeister den Ton mischt), dass die Lautsprecher 231 , 232, 233, 23N entsprechend einstellbarere Steuerparameter ansteuert. Das FoH umfasst ein Mischpult 241 , einen Richtungsmischer (RIM) 242, Konfigurationswerkzeuge (Config) 243, usw. Im großen Zu- schauerbereich 250 können beispielsweise 7.000 Personen sitzen. Angestrebt ist, dass alle Zuschauer einen optimalen Sound haben. Dazu geht man, wenn Ausführungsformen der Erfindung nicht zur Verfügung stehen, beispielsweise folgendermaßen vor: Man geht an einen ersten Platz, z.B. an eine Position 251 auf der rechten Seite. An dieser ersten Position 251 hört man sich den Klang an und gibt dann per Handy Änderungswünsche zum FoH 240 durch. Beim FoH 240 werden entsprechend Parameter geändert. Man hört sich dann den Sound an und, wenn man mit dem Sound zufrieden ist, bewegt man sich in eine zweite Position 252 , z.B. eine Position weiter links. Dort hört man sich entsprechend wieder den Klang an, übergibt dann per Funk wiederum Änderungswünsche zum FoH 240 durch. Beim FoH werden entsprechend wieder Parameter geändert, in der zweiten Position 252 hört man entsprechend wieder den geänderten Sound (Klang), und nimmt man entsprechend wieder einen Abgleich mit dem FoH vor. Dann bewegt man sich in die nächste Position und setzt das Verfahren entsprechend fort. Ein solches Verfahren ist sehr aufwendig und mühsam. Im Folgenden werden nun Ausführungsformen im Detail beschrieben. Dabei wird die Funktionalität von UI.FM erläutert. UI.FM ist ein neues User- Interface Framework (User- Interface Framework = Nutzer-Schnittstellen Rahmenstruktur).

Fig. 2d zeigt eine Ausführungsform, bei der die neue Lösung implementiert ist. Wiederum sind eine Bühne 260, ein FoH 270 und ein Zuschauerbereich 280 dargestellt. Im Beispiel der Fig. 2d, ist nun jedoch ein UI.FM Server 275 installiert. Der UI.FM Server 275 ist mit den Komponenten im System verbunden. Zu sehen sind drei verschiedene Endgeräte, nämlich zweimal ein iPad® 282, 283 und ein iPhone® 281. Bei den Endgeräten könnte es sich auch um beliebige, andere geeignete Endgeräte handeln.

Nun können sich beispielsweise drei Toningenieure 284, 285, 286 gleichzeitig auf unterschiedliche Positionen der Tribüne begeben, wobei jeder der Toningenieure 284, 285, 286 nun den Klang positionieren, konfigurieren und/oder einstellen kann. Die Änderungen werden jeweils über das jeweilige mobile Endgerät 281 , 282, 283 vorgenommen. Das mobile Endgerät 281 , 282, 283 ist mit dem UI.FM Server 275 verbunden z.B. über WLAN. Die Endinformation wird im UI.FM Server 275 eingestellt, und steuert dann entsprechend die Komponenten (in Fig. 2d nicht gezeigt) im Studioraum. Beispielsweise können Config, Rim und Mischpult dabei die Komponenten sein, die gesteuert werden. Änderungen, die ein Toningenieur 286 auf einem Endgerät 283 tätigt, werden sofort an die anderen Endgeräte 281 , 282 weitergegeben. D.h., die anderen Endgeräte 281 , 282 werden entsprechend aktualisiert. Das bedeutet, die anderen Teilnehmer (z.B. in Fig. 2d: die anderen Toningenieure) 284, 285 können sofort sehen, was einer der Teilnehmer 286 geändert hat, können die Änderung entsprechend hören, und darauf unmittelbar reagieren. Mit anderen Worten, ändert einer der Toningenieure in Position C etwas, was sich in Position C sehr gut anhört, aber nicht in Position B, so kann die Person 285 in Position B sofort darauf reagieren, etwas anderes einstellen und so wieder Änderungen vornehmen. Hierdurch wird ermöglicht, dass die drei Personen 284, 285, 286 in den Positionen A, B und C z.B. Steuerparameter untereinander optimal aushandeln können. Die Ausführungsform der Fig. 2d stellt also eine deutliche Vereinfachung und Verbesserung im Vergleich zu dem Vorgehen, dass unter Bezugnahme auf Fig. 2c erläutert wurde, dar.

Ein anderes Anwendungsszenario, nämlich die Einrichtung eines Soundsystems im Auto ist in Fig. 2e gezeigt. Zu sehen ist ein Fahrzeug, hier, z.B. ein Auto 255, mit vier Plätzen 261 , 262, 263, 264 darin. Im Fahrzeug ist entsprechend ein Beschallungssystem mit zahlreichen Lautsprechern 265 installiert. Erwünscht ist nun, dass für jeden Sitzplatz 261 , 262, 263, 264 ein optimaler Sound erzeugt wird.

Um dies zu realisieren können nun vier iPads® 266, 267, 268, 269 im Auto 255 verwendet werden. Vier Toningenieure 256, 257, 258, 259 können nun die vier iPads® 266, 267, 268, 269 im Auto 255 nutzen. So können die vier Toningenieure 256, 257, 258, 259 im Auto 255 gleichzeitig den Sound mithilfe der iPads® 266, 267, 268, 269 einstellen. So können die vier Toningenieure 256, 257, 258, 259 im Auto 255 den Sound sofort hören und mithilfe der iPads® 266, 267, 268, 269 einen optimalen (Gesamt-)Klang untereinander aushandeln, ebenso wie bereits für das Beispiel der Fig. 2d im Fall der Bregenzer Seebühne erläutert. Hierzu wird ein UI.FM Server 276 eingesetzt, mit dem die iPads® 266, 267, 268, 269 über Wifi verbunden sind. Alle Änderungen, die ein Benutzer 256 an einem Gerät 266 vornimmt, werden von dem Gerät 266 an den UI.FM Server 276 übertragen, und der UI.FM Server 276 überträgt die Änderungen an die anderen Geräte 267, 268, 269 weiter. Dies alles geschieht verzögerungsarm. Fig. 2f zeigt ein weiteres Ausführungsbeispiel gemäß einer Ausführungsform, in dem das Audiolabor des Fraunhofer Instituts für Digitale Medientechnologie in Ilmenau dargestellt ist. Hier ist sehr viel Server-Technik vorhanden, die untereinander kollaborieren sollen. Unter anderem ist in Fig. 2f ein Renderer 291 dargestellt, des Weiteren eine Lichtsteuerung 292, fem er ein Verstärker 293, und 294 eine Audiomatrix. Links in Fig. 2f, sind eine Reihe von Endgeräten dargestellt, beispielsweise ein PC-Arbeitsplatz 295, ein erstes i- Pad® (iPad® 1 ) 296, ein zweites iPad® 2 (iPad® 2) 297, und z.B. ein Endgerät 298 von einem Gast. So kann ein Gast beispielsweise auch sein Mobiltelefon 298 bei sich führen, das mit den anderen Geräten 291 , 292, 293, 294, 295, 296, 297 kollaborieren soll.

Beispielsweise kann erwünscht sein, dass die Hardware 291 , 292, 293, 294, in Fig. 2f rechts, durch die Geräte 295, 296, 297, 298, in Fig. 2f links, gesteuert werden kann. So soll es beispielweise möglich sein, dass alle Parameter durch die Geräte 295, 296, 297, 298 in Fig. 2f links einstellbar sind.

Die Verknüpfung der Geräte 295, 296, 297, 298 in Fig. 2f links mit der Hardware 291 , 292, 293, 294 in Fig. 2f rechts wird durch einen UI.FM Server 290 realisiert. Der UI.FM Server 290 ist einerseits mit der Hardware 291 , 292, 293, 294 in Fig. 2f rechts, verbunden. Z.B. werden zwischen dem UI.FM Server 290 und dem Renderer 291 Pegeldaten und Steuerdaten ausgetauscht. Entsprechend ist auch die weitere Hardware 292, 293, 294 in Fig. 2f rechts, mit dem UI.FM Server 290 verbunden. Entsprechend sind auch die Endgeräte 295, 296, 297, 298 in Fig. 2f links mit dem UI.FM Server 290 verbunden. Wenn nun ein Benutzer etwas über eines der iPads® 296, 297, z.B. über„iPad® 1 " 296 eingibt, beispielsweise Steuerinformation, wird diese Eingabe entsprechend an den UI.FM Server übertragen 290. Der UI.FM Server 290 übergibt dann diese Information entsprechend an die Peripherie-Hardware 291 , 292, 293, 294 in Fig. 2f rechts.

UI.FM weist zahlreiche Vorteile auf. So kann der UI.FM Server beispielsweise als Webserver 215 realisiert sein, wie in Fig. 2g gezeigt, und die Clients, beispielsweise iPads® 216, 217, können Webclients 226, 227 realisieren. Es muss also auf den Clients 216, 217 keine Software installiert werden, sondern der Webserver 215 liefert die Software beim Anmelden der Clients 216, 217 an die Clients 216, 217 aus. Durch eine Realisierung als Webserver 215 bzw. als Webclients 226, 227 wird sehr viel Aufwand eingespart.

Ein weiterer Vorteil von UI.FM ist, dass das System in verzögerungsarm funktioniert. Steuerparameter, die in einem der Clients 216, der beispielweise als Webclient 226 reali- siert ist, gesetzt werden, werden sofort an den UI.FM Server 215 übertragen. Der UI.FM Server 215 überträgt die Steuerdaten dann unmittelbar an die ein oder mehreren weiteren Clients, z.B. an ein weiteres iPad® 217. Auf den (ein oder mehreren) weiteren Clients 217 befindet sich dann ebenfalls jeweils ein Webclient 227. Der jeweilige weitere Webclient 227 auf den entsprechenden weiteren Endgeräten 217 aktualisiert dann unmittelbar den betreffenden Parameter. Gleichzeitig informiert der UI.FM Server 215 die angeschlossene Peripherie, beispielsweise einen Renderer 229 über die Parameteraktualisierung. Gemäß einer Ausführungsform kann der Client dafür eingerichtet sein, in einem Webbrowser zu laufen. Der Vorteil ist, dass, dadurch, dass das Programm Client-seitig im Webbrowser läuft, der Anwendungsentwickler eine Kommandozeile (Bezugszeichen 228 in Fig. 2g) öffnen kann, in der er direkt Befehle direkt eingeben kann. Z.B. kann in dem Ausführungsbeispiel der Fig. 2g der Befehl„scene.sourceO.pos = " ... eingegeben werden, wodurch beispielsweise die Position von„sourceO" geändert werden kann. Das System ist also sehr gut skriptfähig. In einer Ausführungsform kann der Client z.B. dafür eingerichtet sein, dem Server die ID von zwei oder mehreren der Knoten des Datenmodells des Clients zu übertragen.

Im Folgenden wird ein System und dessen Komponenten anhand eines Beispiel-Setups erläutert, das in Fig. 3 dargestellt ist. Es versteht sich, dass jede einzelne der Komponen- ten der Fig. 3 für sich alleine realisiert werden kann, und damit für sich alleine eine Ausführungsform darstellt. Ferner versteht sich, dass allgemeine Verfahren und allgemeine Realisierungen, die in Bezug auf eine oder mehrere Komponenten der Fig. 3 beschrieben sind, auch allgemein realisiert werden können, und somit auch als allgemeines Verfahren bzw. als allgemeine Realisierung eine Ausführungsform der Erfindung darstellen.

In Fig. 3 ist zum einen ein Arbeitsplatz-PC dargestellt 350. Des Weiteren zeigt Fig. 3 ein mobiles iPad® 360. Darüber hinaus zeigt Fig. 3 einen Renderer 380 und eine Audiomatrix Einheit 390, z.B. eine DHD®-Audio Matrix Einheit. Ferner ist in Fig. 3 ein UI.FM Server 300 dargestellt.

Der Renderer 380 kann Untermodule umfassen, z.B. ein Untermodul Spatial Sound Wave 381 . Ferner kann der Renderer 380 beispielsweise eine Szene halten, z.B. ein einer Szenen Einheit 382. Ferner kann der Renderer 380 beispielsweise eine Lautsprecher Setup Einheit 383 zum Konfigurieren eines Lautsprecher-Setups umfassen. Weitere Untermodu- le können vorhanden sein. So kann z.B. ein Wav Player 384 zusätzlich vorhanden sein. Ebenso kann die Audiomatrix Einheit 390 Untermodule aufweisen. So kann z.B. die DHD®-Audiomatrix Einheit 390 beispielweise eine Koppelpunktmatrix in einem Koppelpunktmatrix Untermodul 391 umfassen. Der UI.FM Server 300 ist dafür eingerichtet, die reale Welt, wie sie beispielsweise der Renderer 380 und/oder die DHD®-Audiomatrix darstellen 390, in ein graphenförmiges, beispielsweise ein baumförmiges Datenmodell 310 abzubilden. So ist z.B. in der Darstellung des UI.FM Servers 300 in Fig. 3 rechts das Datenmodell 310 dargestellt. Oben im Datenmodell 310 ist ein Wurzelknoten ("Root") dargestellt. Unter dem Wurzelknoten ist die DHD©-Audiomatrix ("DHD®") und der Renderer dargestellt. Der Knoten DHD® im Datenmodell 310, der die DHD®-Audiomatrix 390 darstellt, weist unter sich einen Knoten „Koppelpunktmatrix" auf. Diese Repräsentation der Koppelpunktmatrix 391 wiederum weist Knotenpunkte auf, beispielsweise x₀, Xi und x₂. Die Darstellung des Renderers 380 im Datenmodell 310 wiederum, hat unter sich die Knoten „Lautsprecher-Setup", „Wav Player" und„Scene" als nachfolgende Knoten, die die realen Untermodule des Renderers 380 darstellen. Die Scene wiederum hat Quellen, z.B. srcO, srd und src2. Die Quellen srcO, srd , src2 ihrerseits haben wiederum Eigenschaften, z.B. eine Position pos, eine Rotation rot, on/off, mute, usw. All diese Untermodule, Attribute und Beziehungen können vom Datenmodell 310 abgebildet werden. So stellt das Datenmodell 310 einen besonders vorteilhat ausgebildeten Speicher dar.

Im Folgenden wird das Zusammenspiel von UI.FM Server 300 und Peripherie-Hardware 380, 390 erläutert:

So stellt sich eine besondere Schwierigkeit, wenn realisiert werden soll, dass, wenn z.B. die Position einer der Quellen srcO, srd , src2 im Datenmodell geändert wird, z.B. der Renderer 380 diese Information erhält und auch entsprechend in eine Änderung der Position der entsprechenden Quelle z.B. srcO, srd oder src2 umsetzt.

Um eine Lösung hierfür zu realisieren, wird eim UI.FM Server 300 ein Controller 320 ein- geführt (Controller = Steuereinheit). So gibt es z.B. zu der srcO des Datenmodells ebenfalls einen Knoten srcO in dem Controller 320 des UI.FM Servers 300. Für jede Eigenschaft der Quelle srcO, z.B. für die Eigenschaften„pos",„rot",„on/off" und„mute", weist der Controller 320 eine entsprechende Funktion zum Setzen des Wertes der Eigenschaft und eine entsprechende Funktion zum Auslesen des Wertes der Eigenschaft auf. So stellt der Controller 320 beispielsweise eine setPos(... )-Funktion zum Setzen des Wertes der Eigenschaft pos, und eine Pos(... )-Funktion zum Lesen des Wertes der Eigenschaft pos bereit. Möchte man z.B. die Position im Datenmodell ändern, so ruft man die setPos(... )~ Funktion auf. In der setPos(... )-Funktion wird die aktuelle Position angegeben, auf die die Position gesetzt werden soll, z.B. (1 , 2, 3). Durch den Aufruf der Funktion setPos(... ) im Controller 320 wird die Position pos im Datenmodell geändert. Wenn davon die Rede ist, dass ein Attribut einen Wert hat, so ist der Begriff „Wert" breit zu verstehen, und umfasst z.B. Zahlenwerte, String -Werte, also Werte, die Worte oder Sätze darstellen, Tupel von Zahlenwerten, wie (1 , 2, 3) oder z.B. Tupel von String-Werten, z.B. („Hallo Welt",„Code"), und beliebige andere Arten von Wert-Typen. Neben der bloßen Möglichkeit, Werte von Attributen (Eigenschaften) festzulegen und zu ändern, stellt die setPos(... )-Funktion zudem die Möglichkeit bereit, angeschlossene Views (Views = Sichten) zu informieren.

In einer Ausführungsform wird einem Gerät, beispielsweise dem Renderer 380 oder der DHD®-Audio Matrix 390 drahtlos oder drahtgebunden eine Nachricht zuzugesandt, die dem Gerät mitteilt, dass ein Attribut eines der Knoten des Datenmodells 310 sich geändert hat.

Hierzu ist, um z.B. den Renderer durch eine solche Nachricht zu steuern, beispielsweise ein Renderer Treiber 330 zu programmieren, der eine View darstellt, also eine Sicht auf das Datenmodell 310 und/oder deren Attribute, bzw. eine Sicht auf die Controllerstruktur 320 darstellt. Durch derartige Views kann die Peripherie, z.B. der Renderer, entsprechend gesteuert werden. Beispielsweise kann sich der Renderer-Treiber 330 des UI.FM Servers 300 bei dem Knoten srcO des Controllers 320 des UI.FM Servers 300 als View registrieren. Der Renderer- Treiber wird hierdurch eine Sicht (View) auf den srcO Knoten des Controllers 320. Setzt man nun die Position im Datenmodell durch Aufruf von src0.setPos(... )-Funktion des Controllers 320 des UI.FM Servers 300, so wird gleichzeitig die View 330 (also der Renderer Treiber 330) entsprechend unterrichtet.

Auf eine solche Unterrichtung hin, lädt der Renderer-Treiber 330 dann die Eigenschaft pos der srcO, (also Position der Quelle srcO), die aktualisiert wurde, aus dem Datenmodell 310. Die Eigenschaft kann dem Renderer-Treiber 330 aber auch im Rahmen der Unter- richtung mitgeteilt werden. Dadurch entfällt der Zugriff auf das Datenmodell.

Darüber hinaus generiert der Renderer-Treiber 330 eine Protokollnachricht und schickt diese Protokollnachricht an den Renderer 380. Beispielsweise kann es sich bei der Protokollnachricht um eine OSC-Kontrollnachricht (OSC = Open Sound Control)-Nachricht handeln. Über den Renderer-Treiber 330 hinaus, oder alternativ zum Renderer-Treiber 330, kann der UI.FM Server 300 weitere Treiber umfassen, die z.B. auch auf die Quelle srcO des Controllers 320 registriert sind, wobei diese weiteren oder alternativen Views aber ein anderes Verhalten aufweisen. Wiederum wird beispielsweise bei Ändern der Eigenschaft pos der srcO (also der Position der srcO) das Datenmodell geändert und alle angeschlossene (also entsprechend registrierten) Treiber werden benachrichtigt. Die angeschlossenen Treiber generieren entsprechende Protokollnachrichten, die an die entsprechende Hardware-Peripherie übertragen werden. In der Hardware-Peripherie werden dann entsprechende Änderungen vorgenommen.

Auch der umgekehrte Weg der Datenübermittlung und Aktualisierung ist möglich: Beispielsweise kann ein Prozess, z.B. im Renderer 380, die Position z.B. der srcO ändern. In diesem Fall sendet der Renderer 380 eine Protokollnachricht an den entsprechenden Renderer-Treiber 330. Der Renderer-Treiber 330 wird durch eine solche Nachricht unter- richtet, dass sich die entsprechende Position geändert, er ruft die setPos(... )-Funktion der srcO des Controllers 320 auf, und der Wert der Eigenschaft pos der srcO im Datenmodell 310 wird daraufhin geändert.

Um zu vermeiden, dass der Renderer-Treiber 330 von einer Änderung der Position der srcO informiert wird, die er selbst veranlasst hat (unter Umständen, aber nicht notwendigerweise, Gefahr einer Endlosschleife), kann der Renderer-Treiber 330 des UI.FM Servers 300 festlegen, dass er von einer Änderung der Position der srcO, z.B. einer Änderung, die er selbst veranlasst hat, nicht informiert werden möchte. Analog können im UI.FM Server 300 weitere Treiber, z.B. ein Renderer-Treiber z.B. für die DHD®-Audio Matrix Einheit 390 realisiert werden.

Im Folgenden werden weitere Eigenschaften des Controllers 320 des UI.FM Servers 300 beschrieben.

Es sollte beachtet werden, dass nicht nur die Quelle srcO, sondern auch die weiteren Quellen srd und src2 sowie die Scene vom Controller 320 umfasst sind. Mit anderen Worten gibt es zu jedem Knoten im Datenmodell 310 eine Controller-Subeinheit. Dies ist eine wichtige Eigenschaft des UI.FM Servers 300. So ergibt sich schließlich neben der Datenmodell-Hierarchie 310, die eine Baumstruktur hat, eine Controller- ^

Hierarchie 320, die ebenfalls eine Baumstruktur analog hierzu hat. Diese Baumstruktur des Controllers 320 sieht dann ebenso aus, wie die Baumstruktur der Datenmodell- Hierarchie 310. Gemäß Ausführungsformen kann die Datenmodell-Hierarchie 310 des UI.FM Servers 300 vom Nutzer definiert werden. Beispielsweise kann die Datenmodell-Hierarchie 310 des UI.FM Servers 300 vom Nutzer vollständig definiert werden. Beispielsweise kann entweder aus der Datenmodell-Hierarchie 310 die Controller-Hierarchie 320 erzeugt werden, oder umgekehrt kann auch aus der Controller-Hierarchie 320 die Datenmodell-Hierarchie 310 generiert werden. In einer bevorzugten Ausführungsform wird die Controller- Hierarchie 320 definiert und die Datenmodell-Hierarchie 310 daraus abgeleitet.

So ist also eine besondere Eigenschaft des UI.FM Servers 300, dass zwei parallele Hierarchien, nämlich die Controller-Hierarchie 320 und die Datenmodell-Hierarchie 310 ne- beneinander existieren und miteinander verknüpft sind. So weist jeder Knoten in der Controller-Hierarchie 320 eine entsprechende Referenz auf den entsprechenden Knoten in der Datenmodell-Hierarchie 310 auf. Beispielsweise kann eine Referenz zwischen dem Root-Knoten der Controller-Hierarchie 320 auf den Root-Knoten der Datenmodell- Hierarchie 310 existieren. Es existiert also eine Verbindung zwischen der Controller- so- wie Datenmodell-Hierarchie 310 und der angeschlossenen Hardware-Peripherie.

Im Folgenden wird die Verbindung zwischen den Steuergeräten und dem UI.FM Server 300 bzw. zwischen den Steuergeräten und der Controller-Hierarchie 320 bzw. der Datenmodell-Hierarchie 310 des UI.FM Servers 300 beschrieben.

Im Stand der Technik wird das Datenmodell 310 in einer Datenbank organisiert. Im Stand der Technik sendet ferner der Client Anfragen an die Datenbank, erhält Antworten von der Datenbank zurück und kann mit den erhaltenen Daten arbeiten. Ferner kann gemäß dem Stand der Technik sich der Client auf Knoten des Datenmodells 310 registrieren und bekommt Nachrichten, wenn sich der Knoten des Datenmodells ändert. Das Datenmodell selbst kann beispielsweise in einer Datenbank gespeichert sein. Die Organisation des Datenmodells 310 und des Handlings, wie das Datenmodell 310 beispielsweise zu aktualisieren ist, wird dabei jedoch im Stand der Technik vollständig dem Anwendungsentwickler überlassen. Gemäß einer Ausführungsform wird ein Mechanismus bereitgestellt, der dem Anwender sehr viel Arbeit abnimmt. Dieser Mechanismus wird im Folgenden erläutert.

Beim Start eines Clients, z.B. des Arbeitsplatz-PCs 350, meldet sich der Client bei dem UI.FM Server 300 an (siehe Punkt (1 ) zwischen Arbeitsplatz-PC 350 und UI.FM Server 300 in Fig. 3). So erfolgt zunächst eine Anmeldung durch den Client beim UI.FM Server 300.

Der UI.FM Server 300 überträgt dann die Controller-Hierarchie 320 an den Client (siehe Punkt (2) zwischen Arbeitsplatz-PC 350 und UI.FM Server 300 in Fig. 3). Mit der Controller-Hierarchie 320 wird auch die Datenmodell-Hierarchie 310 übertragen. Dies kann implizit dadurch erfolgen, dass der Client beispielsweise die Datenmodell-Hierarchie 310 aus der Controller-Hierarchie 320 ableitet oder aber, die Datenmodell-Hierarchie 310 wird explizit neben der Controller-Hierarchie 320 übertragen.

Durch Übertragung der Controller-Hierarchie 320 (und eventuell zusätzlich der Datenmodell-Hierarchie 310) liegt beim Client dieselbe Hierarchie wie auf dem UI.FM Server 300 vor. D.h. beim Client, z.B. dem Arbeitsplatz-PC 350 liegen die Controller-Hierarchie 352 und das Datenmodell 351 vor.

Die Übertragung von Controller-Hierarchie 320 und Datenmodell-Hierarchie 310 kann auch für weitere Clients durchgeführt werden, wie, z.B. neben dem Arbeitsplatz-PC 350, auch für z.B. ein iPad® 360, wenn sich diese beim UI.FM Server 300 anmelden. So weist das iPad® 360 in Fig. 3 eine Controller-Hierarchie 362 und ein Datenmodell 361 auf, ebenso wie der Arbeitsplatz-PC in Fig. 3.

Die Controller-Hierarchie 352 des Arbeitsplatz-PCs 350 weist eine„root" (Wurzel) auf und darüber hinaus, identisch zu der Controller-Hierarchie des UI.FM-Servers 300, die der Wurzel„root" nachgeordnete Knoten, z.B. unter anderem srcO und dessen nachgeordnete Knoten. Gleiches gilt für das Datenmodell in den Clients, z.B. für das Datenmodell des Arbeitsplatz-PCs 350 und für das Datenmodell des iPads® 360. Auch in deren Controller- Hierarchien 352, 362 finden sich beispielsweise die Quelle srcO.

In jedem Client, der sich beim UI.FM Server 300 anmeldet, wird initial die gleiche Daten- modellstruktur 351 , 361 wie im UI.FM Server eingerichtet. Dies gilt beispielsweise für die Controller-Hierarchie 362 und das Datenmodell 361 des iPads® 360. Somit sind sämtliche Controller-Hierarchien 352, 362 und Datenmodelle 351 , 361 der Clients 350, 360 mit dem Datenmodell 310, und der Controller-Hierarchie 320 des UI.FM Servers 300 abgeglichen.

Des Weiteren erfolgt die eigentliche Datenübertragung vom Server zum Client (siehe Punkt (3) zwischen Arbeitsplatz-PC 350 und UI.FM Server 300 in Fig. 3). So muss vom Server 300 zum Client 350 eben nicht nur die hierarchische Struktur von Controller- Hierarchie 320 und Datenmodell 310 übertragen werden, sondern eben gerade auch die eigentlichen Daten, beispielsweise also, z.B. welche Werte die Attribute im Datenmodell jeweils haben (also zum Beispiel welche/n Wert/e die Position pos der Quellen srcO, srd , src2 jeweils hat, usw.

Gemäß Ausführungsformen ist jedem Knoten der Controller-Hierarchie 320 des UI.FM Servers 300 eine ID zugeordnet. Die ID dient dazu, Knoten schnell zu adressieren. So müsste aufgrund der graphenförmigen Struktur der Controller-Hierarchie 320 und des Datenmodells 310 normalerweise ein kompletter Pfad angegeben werden, z.B. „root/Renderer/Scene/srcO", um ein bestimmtes Element im Datenmodell bzw. in der Controller-Hierarchie zu adressieren. Dadurch, dass nun jedem Knoten eine ID zugewiesen wird, hat man jedoch einen kurzen Identifikator für jeden der Knoten und kann den jeweiligen Knoten somit durch seinen Identifikator adressieren. Bildlich gesprochen liegt also für jeden Knoten eine kurze "Telefonnummer" vor, die statt der Angabe eines langen Pfades verwendet werden kann. Beispielsweise hat in der Controller-Hierarchie 320 des UI.FM Servers 300 der Knoten„root" die ID 0, der Knoten „DHD®" hat die ID 1 , der Knoten „Renderer" hat die ID 2, der Knoten„LSSetups" hat die ID 3, der Knoten„WavPl." (Wav Player) hat die ID 4, der Knoten„Koppelpunktmatrix" hat die ID 5, der Knoten„Scene" hat die ID 6, der Knoten„srcO" hat die ID 7, der Knoten„srd " hat die ID 8, usw.

Entsprechend werden die IDs vom UI.FM Server 300 zum Client 350 übertragen (siehe Punkt (4) zwischen Arbeitsplatz-PC 350 und UI.FM Server 300 in Fig. 3) und in das Datenmodell 351 und in die Controller-Hierarchie 352 des Clients 350 eingeschrieben, zum Beispiel in das Datenmodell 351 und in die Controller-Hierarchie 352 des Arbeitsplatz- PCs Clients 350.

Es folgt also nach der Datenübertragung die I D-Übertragung. D.h., es wird ein I D-Baum generiert, der die gleiche Struktur wie die Controller-Hierarchie hat. Unterschied ist, dass in den einzelnen Knoten die IDs stehen. Die IDs werden dann in die entsprechenden Knoten geschrieben. Bei den obigen Ausführungen versteht es sich, dass die Punkte (2), (3) und (4) bei der Initialisierung des Clients 350 beim UI.FM Server 300 in beliebiger Reihenfolge ausgeführt werden können.

Im Folgenden wird ein Beispiel gemäß einer Ausführungsform erläutert, bei dem eine (Schall)-Quelle mittels eines Arbeitsplatz-PCs 350 umpositioniert wird. Mit anderen Worten wird beispielsweise eine Web-Applikation, die auf einem Arbeitsplatz-PC 350 läuft, dazu verwendet, die räumliche Position einer, z.B. virtuellen, (Schall)-Quelie umzupositio- nieren. So kann zum Beispiel ein Szenario vorliegen, bei dem z.B. der jeweilige Klang dreier Schallquellen in drei separaten Audiosignalen aufgenommen wird.

Beim späteren Mischen dieser drei Audiosignale zu einem Gesamtsignal werden dann die drei Audiosignale entsprechend der virtuellen Position der Schallquelle gemischt. Befindet sich etwa die virtuelle Position einer ersten Schallquelle weit entfernt von der angenommenen Zuhörer-Position, so ist der Anteil ihres Audiosignals am Gesamtsignal in der Regel geringer als der Anteil des Audiosignals einer zweiten Schallquelle, deren virtuelle Position sich nahe an der angenommenen Zuhörer-Position befindet. Oder aber es werden aus den z.B. drei Audiosignalen der drei Quellen eine Mehrzahl von Lautsprechersignalen erzeugt. Befindet sich etwa die virtuelle Position einer ersten Schallquelle weit entfernt von der (angenommenen) Position des jeweils betrachteten Lautsprechers, so ist der Anteil ihres Audiosignals am Lautsprechersignal für diesen Lautsprecher in der Regel geringer als der Anteil des Audiosignals einer zweiten Schallquelle, deren virtuelle Position sich nahe an der (angenommenen) Lautsprecher-Position befindet.

Mit der angesprochenen Web-Applikation auf dem Arbeitsplatz-PC 350 können also die (virtuellen) Positionen der (Schall-)quellen eingestellt werden, wodurch vom Arbeitsplatz- PC 350 aus gesteuert werden kann, wie der Renderer 380 die einzelnen Audiosignale der Quellen zu einem Gesamtsignal, oder zu einer Mehrzahl einzelner Lautsprechersignale mischt.

Um die jeweilige Quelle bewegen zu können, wird beim Client (z.B. dem Arbeitsplatz-PC 350) eine View (Sicht) 353 eingerichtet. Hierfür umfasst der Arbeitsplatz-PC 350 diese View 353. In der View 353 des Arbeitsplatz-PCs 350 in Fig. 3 ist eine Quelle 358 dargestellt. Die Quelle 358 wird z.B. durch ein Touchscreen angezeigt, kann mit dem Finger berührt und z.B. durch Ziehen bewegt werden. Wenn diese Bewegung passiert, wird beispielsweise ein Event ausgelöst.

Eine Bewegung dieser Quelle durch den Anwender führt dabei beispielsweise dazu, dass die Quelle in eine neue Position bewegt wird, z.B. in die Position (x, y, z) = (8, 9, 10). Diese Position wird über die Funktion setPos(... ), die Teil der Controller-Hierarchie ist, ent- sprechend an der Quelle srcO gesetzt. Der Controller 352 des Clients 350 umfasst gleichzeitig einen Update-Mechanismus, der bereits sinngemäß im Zusammenhang mit dem UI.FM Server 300 besprochen wurde. Wie auch der UI.FM Server 300 hat also auch der Arbeitsplatz-PC 350 eine View 353. Die setPos(... )-Funktion, die bei Bewegen der Quelle aufgerufen wird, setzt eine Position im Datenmodell des Arbeitsplatz-PCs.

Die Positionsänderung der Quelle im Datenmodell 351 des Arbeitsplatz-PCs 350 wird darauffolgend an den UI.FM Server 300 übertragen. Zur Datenübertragung wird gemäß Ausführungsformen die oben beschriebene ID verwendet. Dabei informiert beispielsweise eine Einheit des Controllers des PCs 350, die für die srcO zuständig ist, einen Synchroni- zer (Synchronisator) 354 des Arbeitsplatz-PCs 350.

Den Synchronizer 354 kann man sich dabei als eine Art View vorstellen, der informiert wird, wenn sich Daten ändern. So verwendet der Synchronizer 354 die entsprechende ID und generiert eine Nachricht, beispielsweise, dass sich in dem Knoten mit der ID 7 die Position geändert hat, und was der Wert der entsprechenden Position ist (z.B. (8, 9, 10)). Diese vom Synchronizer 354 generierte Aktualisierungsmitteilung, z.B. eine Nachricht "7: Pos: (8, 9, 10)" wird zum UI.FM Server 300 übertragen.

So gibt es auch auf dem UI.FM Server 300 einen Synchronizer 340, der die durch die Aktualisierungsmitteilung übermittelte, neue Position der srcO empfängt. Der Synchronizer 340 des UI. FM Servers 300 übermittelt die empfangene Position an den Knoten mit der entsprechenden ID, also hier, z.B. dem Knoten mit der ID 7.

Der Synchronizer 340 des UI.FM Servers 300 ermittelt daraufhin mittels der ID den ent- sprechenden Knoten des Controllers 320. So ermittelt der Synchronizer 340 beispielswei- se, dass es sich bei dem Knoten mit der ID 7 um den Knoten srcO handelt, und ruft die setPos(... ) Funktion des srcO-Controller-Knotens auf.

Die setPos(... )-Funktion trägt die Position in das Datenmodell 310 des UI.FM Servers 300 ein, und unterrichtet darüber hinaus den Renderer-Treiber 330 über die neue Position. Der Renderer-Treiber 330 seinerseits übergibt die neue Position an den Renderer 330.

Was den Synchronizer 300 des UI.FM Servers 300 betrifft, wird die Nachricht vom Arbeitsplatz-PC 350 wird von Synchronizer 340 mit minimaler zeitlicher Verzögerung an alle weiteren Clients weitergeleitet, z.B. an das iPad® 360. Das iPad® 360 weist dieselbe Controller-Hierarchie 362 und Datenstruktur 361 mit denselben IDs auf wie der UI.FM Server 300. Ferner umfasst das iPad® 360 zudem einen Synchronizer 364. Der Synchronizer 364 des iPads® 360 trägt diese ID genauso in sein Datenmodell 361 ein. Wenn das iPad® Views aufweist (in Fig. 3 z.B. die View 363), überträgt der Controller 362 die Infor- mation vom Synchronizer 364 über die geänderte Position nicht nur in das Datenmodell

361 des iPads® 360, sondern zusätzlich auch in die View 363 des iPads® 360. Die View 363 des iPads® 360 wird also aktualisiert.

Statt mittels des Arbeitsplatz-PCs 350 kann ein Nutzer analog zu der obigen Beschrei- bung auch auf dem iPad® 360 eine Quelle bewegen. Die Information würde analog über die setPos(... )-Funktion des Controllers 362 des iPads® 360 geschrieben. Der Controller

362 des iPads® 360 würde das Datenmodell 361 des iPads® 360 aktualisieren. Ferner würde der Controller 362 des iPads® 360 den Synchronizer 364 des iPads® 360 informieren. Der Synchronizer 364 des iPads® 360 würde diese Information in einer Aktualisie- rungsmitteilung zum Synchronizer 340 des UI.FM Servers 360 übertragen. Der Synchronizer 364 des UI.FM Servers 360 würde die in der Aktualisierungsmitteilung enthaltene Information unmittelbar zu Synchronizern anderer Clients weiterleiten, z.B. zum Synchronizer 354 des Arbeitsplatz-PCs 350. Ferner würde der Synchronizer 340 des UI.FM Servers 300 diese Information auch im Controller 320 des Servers 300 setzen. Der Controller 320 des UI.FM Servers 300 würde die Position von srcO im Datenmodell 310 des Servers 300 aktualisieren. Ferner würde der Controller 320 des Servers 300 den entsprechenden Treiber des Servers über die Positionsänderung unterrichten. Dieser Treiber, also hier, der Renderer-Treiber 330, würde den Renderer 380 entsprechend informieren. Im Folgenden sollen nun besondere Vorteile der bereitgestellten Konzepte gemäß Ausführungsformen dargestellt werden. Gemäß Ausführungsformen, ist der Code, der die oben beschriebene Funktionalität realisiert dazu geeignet, im Webbrowser zu laufen. In einer Ausführungsform kann man beispielsweise über den Browser die Serverseite aufrufen, z.B. über eine URL. Der Code für den Arbeitsplatz-PC 350 wird live übertragen und wird dann auf dem Arbeitsplatz-PC 350 sofort ausgeführt. Hierdurch entfallen aufwendige Installationsprozesse.

Ein weiterer großer Vorteil betrifft die Dokumentation. Dadurch, dass die komplette Datenmodell-Hierarchie an den Client, z.B. an den Arbeitsplatz-PC 350 übertragen wird, liegt dort eine semantisch intuitiv sehr verständliche Systembeschreibung vor. Auf diese Systembeschreibung kann auf dem Client 350 einfach zugegriffen werden. Ferner liegt die Systembeschreibung wegen ihrer hierarchisch strukturierten Baumstruktur dann auch in verständlicher Form vor. Hierdurch entfällt Dokumentationsaufwand. Ausführungsformen stellen Mittel zur dynamischen Codegenerierung bereit, z.B. die dynamische Erzeugung von ausführbarem Code. Das System ist Web-basiert, wobei mithilfe von Funktionen andere Funktionen generiert werden können. Diese anderen Funktionen, die geniert wurden, sind dann ausführbar. Das bedeutet, dass der Anwender nur minimal die Controller-Hierarchie definieren muss, und sämtlicher anderer Code zum Synchroni- sieren zum Zuweisen von IDs usw. automatisch generiert werden kann.

Z.B. kann der Anwender einfach definieren, dass die Quelle srcO eine Eigenschaft, z.B. eine Position (x, y, z) hat, mit dem Standardwert (x, y, z) = (0, 0, 0). In Ausführungsformen ist das System dafür eingerichtet, aus dieser Information automatisch zwei Funktio- nen zu generieren, z.B. die Funktion ,,Pos()", um den Wert des Attributs pos der srcO zu lesen, d.h. um den Wert der Position der Quelle srcO zurückgeliefert zu bekommen, und die Funktion setPos(... ), um eine neuen Wert für das Attribut pos der Quelle srcO festzulegen, z.B.„setPos(8, 9, 10)", wodurch der Wert des Attributs pos auf (x, y, z) = (8, 9, 10) festgesetzt werden kann.

Indem der Anwendungsentwickler einmal die Information hinterlegt, dass z.B. ein Attribut pos mit dem Standardwert (0, 0, 0) hat, werden in Ausführungsformen automatisch die obigen beiden Funktionen generiert, und zwar für jedem der Clients, z.B. im Arbeitsplatz- PC 350, indem die Clients die Controller-Hierarchie übernehmen. Mit anderen Worten ist zum Definieren eines solchen Controllers, z.B. einer solchen Controller-Einheit des Knotens srcO, extrem wenig Information nötig. Ein weiterer Vorteil ist, dass Ausführungsformen der Erfindung einerseits einen intuitiven Zugriff und andererseits eine Zugriff auf Knoten der Datenstruktur ermöglichen, der gleichzeitig schnell ist. Ausführungsformen verbindet also sowohl die Eigenschaft der Intu- itivität als auch die Eigenschaft der Schnelligkeit, während herkömmliche Systeme normalerweise entweder intuitiv oder schnell, nicht aber beides sind.

Die Intuitivität der Datenstruktur ist vor allem wichtig für den Anwendungsentwickler. Wenn der Anwendungsentwickler eine Information im Datenmodell setzen möchte, dann muss diesem recht einfach ein Weg bereitgestellt werden, wie er z.B. an die Information der Quelle srcO herankommt.

Gemäß einer Ausführungsform generiert das System hierfür einen Befehlssatz, mit dem im Browser einzelne Knoten leicht adressierbar sind. Z.B. kann man im Browser eine Kommandozeile öffnen. In diese Kommandozeile kann der Nutzer oder Anwendungsentwickler Folgendes eingeben: "root.Renderer.Scene.src0.setXyz(8, 9, 10)". Eine solche Zeile ist hochgradig intuitiv, wenn man die entsprechende Struktur der graphenförmigen Datenstruktur kennt. Man kann also sehr leicht, d.h. intuitiv, auf Information der Datenstruktur zugreifen, Informationen laden, Informationen aktualisieren. Bei alledem wird der Dokumentationsaufwand wird sehr gering, denn die Datenstruktur ergibt sich bereits aus ihrem hierarchischen baumförmigen Aufbau.

Gemäß Ausführungsformen werden wenn die Baumstruktur einmal definiert wurde, automatisch Befehle, die z.B. in JavaScript die Punktoperatoren zwischen den Knoten ermög- liehen, generiert. So generiert in Ausführungsformen beispielsweise der Browser- bzw. die Server-Kommandozeile diese Punktoperatoren. Die Controller-Struktur ist dabei derart gestaltet, dass diese Operatoren einfach verwendet werden können.

In Ausführungsformen wird ein Pfad zu einem gewünschten Knoten also dadurch ange- geben, dass z.B. ausgehend vom Wurzelknoten oder ausgehend von einem seiner Nachfolgeknoten, die aufeinanderfolgenden Knoten bis zum gewünschten Knoten nacheinander angegeben werden, wobei aufeinanderfolgende Knoten jeweils durch einen Punkt getrennt werden. So kann beispielsweise auf den Knoten srcO z.B. durch Angabe des Pfades "root.Renderer.Scene.srcO" oder z.B. durch Angabe des Pfades „Rende- rer.Scene.srcO" zugegriffen werden (wenn beispielsweise klar ist, dass der Wurzelknoten „root" immer der erste Knoten ist). Nur einfach„srcO" zum Zugriff anzugeben, ist, wenn Knotennamen nicht eindeutig sein sollten, nicht ausreichend, denn es kann beispielsweise mehrere Knoten in einer Datenstruktur mit dem Namen„srcO" geben. Außerdem würde hierdurch die Intuitivität der Datenstruktur verlorengehen. So intuitiv die hier beschriebenen Pfade für den Anwendungsentwickler auch sind, so ineffizient sind sie, wenn solche Knoptenzugriffe sehr hochfrequent / sehr häufig ausgeführt werden.

Beispielsweise kann in einer Ausführungsform der Renderer 380 dafür eingerichtet sein, Pegeldaten zu generieren, die entsprechend über OSC Nachrichten an den Renderer- Treiber 330 des UI.FM Servers 300 übermittelt werden. Der Renderer-Treiber 330 setzt die Pegeldaten dann entsprechend in der Controller-Hierarchie 320 und damit im Datenmodell 310. Für 64 Quellen sind dies beispielsweise 64 Informationen, die z.B. 50 mal in der Sekunde aktualisiert werden, d.h. in der Sekunde sind in diesem Beispiel 3.200 Aktu- alisierungen nötig. In anderen Teilen des Systems können weitere hochfrequente Informationen regelmäßig entstehen, die abgearbeitet werden müssen. Zur Positionsaktualisierung wäre dann jedes Mal ein Pfad der Form "root.Renderer.Scene.src0.posXyz(8, 9, 10)" zu adressieren. Ein solcher Befehl würde dabei dann jedes Mal in einer Nachricht vom Client, z.B. dem Arbeitsplatz-PC 350, zum UI.FM Server 300 geschickt werden. Dies ist jedoch ineffizient.

Zur effizienteren Realisierung werden die oben bereits eingeführten IDs verwendet. Dadurch, dass jeder Knoten eine ID besitzt, die eine Art Hash-Wert darstellen, wobei die ID als kurze Adresse fungiert, kann alternativ zu dem langen Pfad, der für den menschli- chen Entwickler gut ist, auch die ID verwendet werden. Ein Beispiel wäre z.B. der Befehl „node[7].setXyz(8, 9, 10)". Hierdurch wird die Funktion ,,setXyz(... )" des Knotens mit der ID7 aufgerufen, also die setXyz(... ) Funktion des Knotens srcO.

Die hier verwendeten IDs stellen somit die Möglichkeit bereit, Elemente sehr kurz zu ad- ressieren, was die Synchronisation effizienter gestalten kann. Wenn bestimmte Informationen sich häufig ändern, z.B. wenn eine Quelle bewegt wird, was sehr viele Aktualisierungen nach sich zieht, wird nicht der oben beschriebene lange Pfad vom Client 350 zum UI.FM Server 300 übertragen, sondern die entsprechende ID. Dies kann auch beispielsweise durch eine kurze Instruktion der Form "7: pos: [8, 9, 10]" erfolgen, die beispielswei- se besagt, dass das der Wert des Attributs„pos" des Knoten mit der ID 7 (also srcO) zu (x, y, z) = (8, 9, 10) geändert werden soll. Die Möglichkeit, Elemente sehr kurz zu adressieren, kann vorteilhaft sein, wenn bestimmte Informationen sich häufig ändern, und ist z.B. bei der Synchronisation hilfreich. So zieht z.B. das Bewegen der Quelle 358 beispielsweise sehr viele Positions-Aktualisierungen nach sich. In diesem Fall wird nicht der lange Pfad vom Client zum Server übertragen, sondern die ID. Z.B. durch Datennachrichten der Form„7: pos: [8, 9, 10]" hat man sehr kurze Datennachrichten. Dies sind dann sehr effizient an den UI.FM Server 300 und alle Clients, z.B. das iPad® 360 übertragbar. Somit hat der lange Pfad den Vorteil, dass er intuitiv ist, insbesondere für den menschlichen Entwickler, während der kurze Pfad, also z.B.„7: pos: [8, 9, 10]", den Vorteil hat, für das System sehr gut verarbeitbar zu sein. Ein Datenübermittlung mithilfe der ID sehr schnell. Ausführungsformen vereinen beide Vorteile, indem sowohl der lange Pfad, als auch die kurze ID Adressierung bereitgestellt wird.

In Ausführungsformen werden beide Adressierungsmöglichkeiten automatisiert vom Sys- tem erzeugt wenn die Controller-Hierarchie und/oder die Datenstruktur definiert wird.

Nachfolgend werden wesentliche Fähigkeiten des Systems beschrieben.

Ausführungsformen weisen Multi-Client-Fähigkeit auf. Multi-Client-Fähigkeit heißt, dass man ein und dieselbe Applikation auf mehreren Clients startet. Beispielsweise kann dieselbe Applikation auf dem Arbeitsplatz-PC 350, auf dem iPad® 360, und beispielsweise auf weiteren Geräten gestartet werden. Jede Änderung, die auf einem Client, z.B. dem Arbeitsplatz-PC 350 getätigt wird, wird an alle anderen Clients 360 übertragen. D.h., die Applikation ist auf mehreren Bildschirmen gleichzeitig präsent und auch gleichzeitig sicht- bar.

In einem weiteren Anwendungsbeispiel kann ein Teil der Anwendung auf einem ersten Client dargestellt werden, z.B. dem Arbeitsplatz-PC 350, während andere Teile der Applikation beispielsweise auf einem zweiten Client, z.B. einem iPad®, 360 dargestellt werden können. So kann z.B. mit der linken Hand eine Quelle auf dem iPad® 360 stumm geschaltet werden, während mit der rechten Hand auf dem Arbeitsplatz-PC 350 eine Klangquelle positioniert wird. Eine solche Funktionalität kann als Multi Device Fähigkeit bezeichnet werden. Vorteilhaft ist des Weiteren eine Web-basierte Realisierung gemäß Ausführungsformen. Ein weiteres wesentliches Merkmal von Ausführungsformen ist deren Fähigkeit, Anfragen verzögerungsarm auszuführen. Wenn z.B. eine Quelle 358 in einem Browser eines Clients, z.B. des Arbeitsplatz-PCs 350 bewegt wird, dann wird diese Quellen-Bewegung fast ohne Zeitverzögerung an die anderen Clients, z.B. das iPad® 360 übertragen, und ist dort fast ohne Zeitverzögerung sichtbar. Das gleiche gilt für Pegeldaten, die z.B. vom Rende- rer 380 kommen. Es zeigt sich also, dass das System so schnell ist, dass es auch sehr hochfrequente Parameteränderungen verarbeiten kann.

Wie bereits angesprochen, hat der Controller 320 verschiedene Aufgaben, wobei eine Aufgabe darin besteht, das Datenmodell 310 zu ändern, wobei eine weitere Aufgabe darin liegt, die Treiber, z.B. den Renderer-Treiber 330, zu informieren, um des Weiteren die Synchronisation durch den Synchronizer 340 auszulösen.

Ferner weist der Controller 320, der in UI.FM 300 implementiert ist, noch eine weitere Fähigkeit auf, nämlich die Fähigkeit, Datenänderungen über die Zeit aufzuzeichnen. D.h. wenn man eine Quelle bewegt 358, kann diese Änderung vom Controller 320 aufgezeichnet werden und später wiedergegeben werden. Dies kann z.B. dazu verwendet werden, Quellbewegungen aufzuzeichnen. Entsprechend können diese aufgezeichneten Quellbewegungen später wiedergegeben bzw. abgespielt werden. Man kann dies als Automati- sierbarkeit beizeichnen.

Weiter unten wird noch beschrieben, wie die Controller-Hierarchie und das Datenmodell, d.h. die baumförmige Struktur ganz konkret aussieht. Ausführungsformen weisen die Eigenschaft der automatischen Codegenerierung auf, dass also die Lese- und Schreib-Funktionen zum entsprechenden Zugriff Knotenattribute automatisch generiert werden. Man spricht hier von dynamischer Codegenerierung.

In Ausführungsformen kann auch der Synchronizer-Code automatisch generiert werden. Nicht nur die Zugriffsroutinen, also die Lese- und Schrieb-Funktionen, sondern auch die Synchronisationsfunktionen können automatisch generiert werden.

Ferner weisen Ausführungsformen die Eigenschaft auf, dass aus der Controller-Definition und/oder aus der Definition der Datenstruktur automatisch der Code generiert werden kann, der die Views 363 benachrichtigt. Im Folgenden wird die Funktionalität von Ausführungsformen erläutert. So wird in einem beispielhaften Anwendungsfall die Beschallungstechnik eines Stadions eingerichtet werden. Zur Einrichtung der Beschallungstechnik können z.B. vier Personen beteiligt sein, also z.B. vier Toningenieure. Jeder der Toningenieure kann z.B. für einen Flügel des Stadions zuständig sein, z.B. einer für den Nordflügel, einer für den Südflügel, einer für den Ostflügel und einer für den Westflügel. Jeder der Toningenieure hat zudem beispielsweise ein iPad® bei sich. Mit diesem iPad® kann dann das zentrale Mischpult und die zentrale Soundeinrichtung gesteuert werden. Eine erste Person beginnt dann den Sound für seine Position optimal einzustellen. Danach beginnt die zweite Person den Klang einzustellen. Die zweite Person benutzt ebenfalls ein iPad®. Dann geht die dritte Person, dann die vierte Person ebenso vor. Der Sound kann auch gleichzeitig eingestellt werden. So kann jeder der Toningenieure gleichzeitig hören, welche Auswirkungen die Einstellungen der anderen Toningenieure haben. Gleichzeitig kann der jeweilige Toningenieure, der eine Änderung wahrnimmt, diese Änderung auch rückgängig machen oder anderweitig eingreifen. D.h., in diesem Beispiel können die vier Toningenieure zu viert gleichzeitig eine optimale Beschallungssituation erreichen. Dies wird dadurch erreicht, dass mit vier unterschiedlichen Mobilgeräten eine zentrale Applikation gesteuert wird. Um solche Applikatio- nen zu realisieren wird UI.FM bereitgestellt, das z.B. als Software Framework implementiert sein kann. UI.FM bezeichnet das sogenannte User Interface Framework. Dieses Framework erlaubt es, solche Applikationen viel schneller und einfacher zu implementieren als dies bisher möglich ist. Alle Applikationen, die von UI.FM entwickelt wurden, sind von Natur aus Multi-Client-fähig. So sieht man z.B. in den Fig. 4a eine Applikation, die auf ein iPad® 410 geladen ist Cli- entseitig ist die Applikation noch auf einen Arbeitsplatz-PC 420 geladen. Ferner ist die Applikation noch auf einen weiteren Client, einen weiteren Arbeitsplatz-PC 430 geladen. Insgesamt liegt die Applikation nun also auf drei verschiedenen Clients 410, 420, 430 vor.

Betrachtet man nun Fig. 4b, so kann auf diesem iPad® z.B. eine der acht Quellen 41 1 , 412, 413, 414, 415, 416, 417, 418 berührt und bewegt werden. Das Berühren und Bewegen einer der Quellen, z.B. mit einem Finger 419, ist beispielsweise in Fig. 4c gezeigt. Gleichzeitig mit dem Bewegen einer Quelle in einem Client 410 bewegt sich die Quelle in allen anderen Clients 420, 430 mit. Man steuert also mit dem Finger 419 auf einem Client 410 eine Quelle 416 und diese Quellpositionsänderung der Quelle 416 wird unmittelbar auf alle anderen Applikationen der anderen Clients 420, 430 übertragen. Statt mit dem Finger 419 kann die Quelle 416 auch mit einer Maus bzw. durch deren Mauszeiger bewegt werden. So kann die Quelle z.B. mit einer Maus auf einem PC bewegt werden und die entsprechende Quelle auf den anderen Clients, z.B. auf einem anderen iPad®, bewegt sich entsprechend mit. D.h. mehrere Leute können gleichzeitig mit einer Applikation arbeiten, und dort die Parameter ändern, wobei die geänderten Parameter werden an die anderen Endgeräte übertragen werden.

Ausführungsformen weisen die Möglichkeit auf, Anwendungen auf mehrere Endgeräte so zu verteilen, dass ein Arbeitsplatz erweitert wird. So ist z.B. in Fig. 4d einerseits der Arbeitsplatz-PC 420 im Hintergrund zu sehen, auf dem die acht verschiedenen Quellen 41 1 , 412, 413, 414, 415, 416, 417, 418 dargestellt sind.

Gleichzeitig wurde der Arbeitsplatz um das iPad® 410 im Vordergrund erweitert. Beide Geräte 410, 420 sind voneinander getrennt. Auf beiden Geräten 410, 420 laufen unterschiedlichen Client-Applikationen. Auf dem PC-Arbeitsplatz 420 befindet sich ein Source Positioning Canvas, mittels dem man die Quellen 41 1 , 412, 413, 414, 415, 416, 417, 418 bewegen kann. Auf dem iPad® 410 befindet sich eine Mute Matrix (Stummschalt Matrix), mit der man einzelne oder alle Quellen 41 1 , 412, 413, 414, 415, 416, 417, 418 stummschalten kann.

So kann mit zwei Händen gleichzeitig der Positioning Canvas und die Mute-Matrix ge- steuert werden. So können z.B. mit der linken Hand ein oder mehrere Quellen stummgeschaltet werden, wie in Fig. 4e zu sehen ist, während die rechte Hand dazu verwendet werden kann, Quellen zu steuern und zu positionieren. Somit hat man einen PC- Arbeitsplatz 420, um eine zweite Applikation, die auf einem mobilen Endgerät 410 läuft, erweitert, und beide arbeiten perfekt zusammen für einen einzelnen Nutzer.

Gemäß Ausführungsformen ist UI.FM Web-basiert. Fig. 5a zeigt die Serverseite von UI.FM gemäß einer Ausführungsform. Nach Anklicken von "Apps" gelangt man auf die App-Seite, dargestellt in Fig. 5b. Beispielsweise kann die Applikation „ProductionApp" angeklickt werden, die auf dem UI.FM Server läuft, wodurch die„ProductionApp" geöffnet wird, wie in Fig. 5c dargestellt. Nun kann mit dieser Applikation („App" - Anwendung) gearbeitet werden. UI.FM läuft verzögerungsarm. Alles was in einer Applikation auf einem Client getan wird, wird schnellstmöglich an die entsprechende Applikation auf dem anderen Client übertragen. So können Realtime-Daten im Webbrowser angezeigt werden. Beispielsweise sind in Fig. 6a bis zu 32 Quellen anzeigbar und steuerbar. Die Pegel dieser bis zu 32 Quellen werden mit 25 Bildern pro Sekunde aktualisiert. Genauso werden auch die bis zu 32 Quellpositionen aktualisiert, und zwar in kürzester Zeit.

In einer Ausführungsform kann die Änderung eines Attributs eines der Knoten des Da- tenmodells aufgezeichnet werden. So sind in UI.FM sind grundsätzlich sämtliche Parameter automatisierbar. Beispielsweise wird in Fig. 6b ein Szenario gezeigt, bei dem man eine Aufzeichnung starten kann, eine Quelle bewegen kann, die Aufzeichnung stoppen kann, und dann die Aufzeichnung starten kann, so dass die Quellbewegung, die zuvor vollzogen wurde, nun abgespielt wird. Ausführungsformen ermöglichen somit das Aufzeichnen von Parametern.

In Ausführungsformen von UI.FM kann der Anwendungsentwickler ein graphenförmiges, z.B. baumförmiges Datenmodell definieren, wie es z.B. in Fig. 7a dargestellt wird. In Fig. 7a ist ein beispielhaftes Datenmodell einer Beispielanwendung dargestellt. Der Wurzelknoten ist in Fig. 7a nicht als„root" sondern als "ssc" bezeichnet, an dessen Bedeutung als Wurzelknoten jedoch, ändert sich nichts. Es existieren verschiedene Unterknoten, wie z.B. "clock", "demoPlayer" und "audio". Unter dem Knoten "audio" existieren verschiedene Unterknoten, z.B. der Unterknoten "scenes". Der Knoten "scenes" umfasst den Unterknoten "sceneO". Der Unterknoten "sceneO" wiederum umfasst die Unterknoten "soloManager", "manage3d" und "sources". Unter dem Knoten "sources" liegt die Quelle "srcO". Des Weiteren liegen unter dem Knoten "audio" die Unterknoten "micSetups", "IsSetups" und "virtualLsSetups". Insgesamt werden also die Daten, die im System vorkommen, graphenförmig, z.B. baum- förmig strukturiert.

Fig. 7b und 7c zeigen ein Beispiel, wie ein Datenmodell ganz konkret formuliert wird. Konkret handelt es sich um die Definition einer Quelle. Hier definiert man zunächst die Attribu- te des Objekts, in einer Quelle z.B. die Position, die Rotation, ob sie gebraucht wird (isUsed), ob es die Quelle ausgewählt ist (isSelected), ob die Quelle gesperrt ist (isLocked), ob die Quelle stummgeschaltet ist (isMuted), oder beispielsweise ob die Quelle eine 3D Quelle ist, usw.

Jedem dieser Attribute wird dabei ein Standardwert zugeordnet. Der Standardwert wird zugleich verwendet, um den Datentyp des Attributs zu bestimmen. Zudem existieren verschiedene Optionen, die spezifizieren, welche dieser Attribute automatisiert werden sollen („automate all attributes except" = automatisiere alle Attribute bis auf).

Ferner wird definiert, wie die Timeline aussehen soll für die Automatisierung (timeline con- figuration = Zeitplan Konfiguration), und wie dicht benachbart Auszeichnungspunkte, also Keyframes, sein sollen. Des Weiteren sollen beispielweise räumliche Benachbarungen, sowie Richtungsänderungen angebbar sein. Eine Optimierung der Datenaufzeichnung / der Automatisierung, die oben beschrieben wurde, wird erreicht. Des Weiteren kann auch noch beschrieben werden, dass nicht alle Attribute unmittelbar in einer Datei gespeichert werden, sondern nur bestimmte. Es bestehen also ganz verschiedenste Kombinationsoptionen.

Eine neue Controller-Untereinheit für einen neuen Knoten kann durch den Aufruf von NewControllerClass im Datenmodell erzeugt werden. Diesem Aufruf werden der Name, die Attribute, die childCreationFunction und Optionen übergeben. Auf diese Weise wird der neue Knoten definiert.

Darüber hinaus sind die einzelnen Knoten noch in eine graphenförmige z.B. baumförmige Hierarchie zu bringen. Die baumförmige Hierarchie wurde bereits in Fig. 7a grafisch dar- gestellt. So befindet sich die Quelle "sourceO" in einem Container "sources", der sich wiederum in einem Container "sceneO" befindet, der seinerseits in einem Container "scenes" liegt.

Für die Gestaltung des in Fig. 7a skizzierten Datenmodells gibt es verschiedene Pro- grammierbefehle, die in Fig. 7d, 7e, 7f illustriert werden. Dabei sind einerseits die Knoten zu definieren, ferner sind die Attribute der Knoten zu definieren und, die Knoten sind über vordefinierte Befehle einem Elternknoten zuzuweisen. Hierdurch kann eine entsprechende Hierarchie aufgebaut werden. Gemäß Ausführungsformen ist UI.FM ist in der Lage, aus der graphenförmigen, beispielsweise baumförmigen Datenstruktur eine Reihe nützlicher Tools abzuleiten, und bei- spielsweise automatisch zu erzeugen. Diese Software-Tools, z.B. Software- Entwicklungstools, werden im Folgenden beschrieben.

Ein erstes Tool realisiert die automatische Erzeugung von Programmierbefehlen zum Er- reichen von Knoten im Datenmodell. So generiert UI.FM automatisch aus der zuvor definierten Baumhierarchie Programmierbefehle. Fig. 8a zeigt hierzu ein Beispiel, bei dem eine JavaScript Konsole 810 geöffnet ist. Eine solche JavaScript Konsole 810 befindet sich z.B. in Browsern, wie Chrome® und Firefox®. Über diese Konsole kann auf das Datenmodel, das im Browser geladen ist, zugegriffen werden.

Gibt man z.B., wie in Fig. 8b gezeigt, die Knotenfolge "ssc.globalController.audio" in die JavaScript Konsole 810 ein, spricht man den„audio"-Knoten an, der zuvor erzeugt wurde. Unter dem Knoten "audio" existiert ein Unterknoten "scenes". Auf diesen Unterknoten "scenes" kann zugegriffen werden, indem hinter "audio." Der Name„scenes" hinzugefügt wird. Nur die ersten beiden Buchstaben von "scenes" müssen eingegeben werden, "sc" wird dann automatisch zu "scenes" ergänzt. Das liegt daran, dass nun automatisch aus der zuvor definieren, beispielsweise baumförmigen Hierarchie der richtige Programmierbefehl angehängt wurde, live und dynamisch. Als nächstes wird der Knotenname "sce- neO" hinzugefügt, dann der Unterknoten "sources" angesprochen werden, und schließlich die Quelle "srcO". Das System bietet beim Eingeben der jeweiligen ersten Buchstaben der Knotennamen jeweils mögliche Ergänzungen an, da das System die entsprechenden Unterknoten bereits kennt, die in Frage kommen. Der vollständige Pfad zu "srcO" ist in Fig. 8c gezeigt. In Fig. 8d ist darüber hinaus spezifiziert, welche Eigenschaft der Quelle geändert werden soll, dort durch den Funktionsaufruf "setXyz". Der Befehl„setXyz" ist automatisch generiert worden. In der Datendefinition wurde hingegen lediglich "xyz: [0,0,0]" eingegeben, wie in Fig. 8d gezeigt. Es wurde also lediglich definiert, dass ein Attribut existieren soll, das xyz heißt, und das den Standardwert [0,0,0] hat. UI.FM hat aus dieser Zeile automa- tisch den Befehl„setXyzQ" generiert.

Fig. 8e zeigt den Befehl, um die Quelle in die Position [-100, -100, 0] zu verschieben. Wird der Befehl durch Drücken von Enter abgesetzt, so wird die Quelle automatisch verschoben, wie in Fig. 8f gezeigt ist. Dies liegt beispielsweise daran, dass innerhalb der automa- tisch erzeugten setXyz-Funktion ein Event (Nachricht) erzeugt wurde. Die Quelldarstellung hat diese Nachricht abonniert und konnte daraufhin ihre Position ändern. Der Anwendungsentwickler kann somit einfach, intuitiv auf die Bestandteile, d.h. auf die Knoten des Datenmodells zugreifen. Neben der setXyzQ-Funktion gibt es auch automatisch eine Funktion zum Lesen, die automatisch generiert wird. Diese Funktion ist in Fig. 8f dargestellt und mit "xyzQ" bezeichnet. Wird der entsprechende Befehl„xyzQ" abgesetzt, so wird die aktuelle Position, "[-100, -100, 0]" ausgegeben. Verschiebt die Position, wie in Fig. 8g gezeigt, und ruft man erneut die Funktion zum Anzeigen der aktuellen Position auf, so wird die aktuelle Position der Quelle ausgegeben. Gemäß Ausführungsformen ist UI.FM in der Lage, automatisch den Synchronisationscode zu erzeugen, um Attribute oder Eigenschaften von einer Quelle A auf dem Client 1 auf die gleiche Quelle A auf dem Client 2 zu übertragen. In Fig. 9a ist eine Programm zu sehen, die zweimal als zwei Applikationen 910, 920 gestartet wurde. Ein neues Attribut kann nun schnell und einfach hinzugefügt werden. So zeigt Fig. 9b in einem weiteren Fenster das Datenmodell einer Quelle, das bereits oben beschrieben wurde. Nun kann, wie in Fig. 9c gezeigt, ein weiteres Attribut einfach hinzugefügt werden.

So wird in Fig. 9c das Attribut "uifm" mit dem Wert 'uifm' hinzugefügt. Das Attribut hat also einen String (eine Zeichenkette) als Wert. Durch die bloße Einfügung einer Zeile unter „attributes" wurde ein neues Attribut eingefügt.

Damit so vorgenommene Neudefinition zum Tragen kommt, kann es beispielsweise erforderlich sein, den Server 300 neu zu starten, wie in Fig. 9d gezeigt. So kann mit einer Ser- verkommandozeile wird der UI.FM Server 300 neu gestartet. Nach dem Neustart des Servers 300 werden auch die beiden Applikationen 910, 920 neu gestartet.

In Fig. 9e ist dargestellt, dass nun dieses neu eingefügte Attribut "uifm" in beiden Applikationen 910, 920 über den automatisch generierten Befehl "uifm()" abgefragt werden kann, und als Rückgabewert den Datenstring "uifm" liefert. Dies funktioniert sowohl im Client als auch im Server.

Ebenso ist es möglich, durch eine automatisch generierte Funktion "setUifmQ" den Wert des Attributs uifm zu ändern. Dies ist in den Fig. 9f und 9g gezeigt. Die so vorgenommene Aktualisierung des uifm Attributs in der ersten Anwendung 910 wird automatisch zur zweiten Anwendung 920, in Fig. 9g rechts, übertragen. Eine Abfrage des uifm Attributs mittels der automatisch generierten Funktion uifm() liefert auch in der rechten Anwendung 920 der Fig. 9g den aktualisierten String "Gabriel Gatzsche".

Genauso kann umgekehrt auch in der rechten Anwendung der Wert des Attributs uifm neu gesetzt werden, z.B. auf "Base camp", wie in Fig. 9h gezeigt. Eine solche Aktualisierung wirkt sich sofort unmittelbar auch auf die linke Applikation 910 in Fig. 9h aus. UI.FM erlaubt also eine schnelle und einfache Erweiterung des Datenmodells und erlaubt die schnelle und einfache Erzeugung von Synchronisationscode. UI.FM erzeugt automatisch Code, mit dem angeschlossene Beobachter (Observer) sich informieren lassen können, wenn ein Wert des Datenmodells sich ändert, (siehe z.B. Pub- lisher-Observer, ein Design-Pattern). Es ist kein menschlicher Beobachter gemeint, sondern ein Programm-Modul, dass eine Änderungsnachricht abonniert und diese automatisch zugestellt bekommt, sobald sich das Datenmodell ändert.

So kann, gemäß einer Ausführungsform, z.B. für eines der Attribute eines der Knoten des Datenmodells, auf eine Nutzereingabe hin, eine Änderungsüberwachung eingerichtet werden. Beispielsweise wird ein Alarm ausgegeben, wenn ein Wert eines der Attribute sich ändert, für das eine Änderungsüberwachung eingerichtet ist. Die Ausgabe eines Alarms ist dabei nur ein Beispiel. Eine andere Möglichkeit ist, z.B. dass die Titelleiste des Browsers aktualisiert wird oder ähnliches.

Dies wird unter Bezugnahme auf Fig. 10a erläutert, wo eine Änderungsüberwachung eingerichtet wird. Durch den in der Konsole eingegebenen Befehl ,,on('change[uifm]', function ()" wird das System veranlasst, die nachfolgend definierte Funktion aufzurufen, wenn der Wert von uifm sich ändert. In der functionQ Definition der Fig. 10a wird definiert, dass in diesem Fall ein Alarm ausgegeben werden soll, der den Wert der Eigenschaft uifm zeigt. Drückt man nun Enter in der Konsole, ist der so definierte Beobachter registriert. In Fig. 10b wird nun der Wert von uifm in 'production app' geändert. Daraufhin erscheint, wie in Fig. 10c gezeigt, ein Alarm, der den neuen Wert von uifm, nämlich "production app" ausgibt. Dies funktioniert auch, wenn ein zweiter Client geöffnet wird.

In Fig. 10d ist das Öffnen eines zweiten Clients gezeigt. Dort wird in einer Konsole der Wert von uifm durch die Funktion "setUifm" geändert. Obwohl der Wert von uifm im zweiten Client geändert wurde, wird auch im ersten Client der Alarm ausgegeben, dass sich der Wert von uifm in "overhead" geändert hat, wie in Fig. 10e zu sehen ist. Im Detail wurde der neue Wert von uifm vom zweiten Client auf den Server übertragen, vom Server wurde der Wert auf den ersten Client übertragen, dort wurde der Wert von uifm entsprechend aktualisiert und der Beobachter wurde informiert, was zur Ausgabe des Alarms, wie in Fig. 10e gezeigt, geführt hat.

Mit UI.FM ist es auch sehr einfach, Timeline Daten aufzuzeichnen. Wie oben beschrieben, wurde das uifm Attribut zum Datenmodell hinzugefügt. In einer Ausführungsform wird aufgrund dieses Attributs auch automatisch Code erzeugt, um Timeline Daten aufzuzeich- nen. Beispielsweise können verschiedene Änderungen des Wertes uifm über die zeitlich aufgezeichnet werden. Ein Drücken auf z.B. eine Playtaste, kann dafür sorgen, dass die Zeit losläuft. Setzt man nun den Wert von uifm zunächst auf "Freitag", dann auf "Samstag", dann auf "Sonntag", so werden diese Datenänderungen in ihrer zeitlichen Reihenfolge im Zeitverlauf aufgezeichnet.

Aktiviert man nun beispielsweise den Lesemodus / Wiedergabemodus, so werden die zuvor aufgezeichneten Daten wieder über die Schreibfunktion aus der Timeline in das Datenmodell geschrieben. Angeschlossene Beobachter (Views) werden informiert und geben beispielsweise automatisch Alarme (englisch:„Alerts") ausgegeben, und zwar je- weils zu dem Zeitpunkt in der Abspielung, zu dem auch der Wert während des Aufnahmemodus geändert wurde. So wird beispielsweise in Fig. 1 1 der Alarm "Sonntag" zu dem Zeitpunkt ausgegeben, zu dem in der Wiederholung der Aufzeichnung auch der Wert "Sonntag" geändert wird. Ausführungsformen erlauben also Aufnahmen des von Eingaben, die bei ihrer Wiedergabe durch das System zeitlich richtig wiedergegeben werden, und beispielsweise zeitlich richtig Alarme entsprechend der Aufnahme ausgeben.

Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwen- dung eines Hardware-Apparats), wie zum Beispiel einen Mikroprozessor, einen programmierbaren Computer oder einer elektronischen Schaltung durchgeführt werden. Bei eini- gen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.

Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer BluRay Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steu- ersignale gespeichert sind, die mit einem programmierbaren Computersystem derart zusammenwirken können oder zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.

Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem pro- grammier-baren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.

Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerpro- grammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahin gehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.

Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger ge- speichert sein.

Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschi- nen-lesbaren Träger gespeichert ist. Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.

Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Daten- träger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist. Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahin gehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.

Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahin gehend konfigu- riert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.

Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist. Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobilgerät, ein Speichergerät oder eine ähnliche Vor- richtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.

Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.

Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Ein- zelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.

Claims

Patentansprüche

Vorrichtung (160, 170; 300, 350, 360), umfassend, ein Datenmodell (1 10; 310, 351 , 361 ), wobei das Datenmodell (1 10; 310, 351 , 361 ) drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells (1 10; 310, 351 , 361 ) eine ID zugewiesen ist, wobei jeder dieser ein oder mehr Knoten durch seine ID von den anderen Knoten des Datenmodells (1 10; 310, 351 , 361 ) eindeutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells (1 10; 310, 351 , 361 ) jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell (1 10; 310, 351 , 361 ) gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells (1 10; 310, 351 , 361 ) aufweist, und wobei sich die Pfadangabe von jedem Knoten der besagten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet, ein Controller (120; 320, 352, 362), der zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells ( 10; 310, 351 , 361 ), der Attribute aufweist, eine Schreibfunktion umfasst, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist, und einen Synchronizer (130; 340, 354, 364), wobei der Synchronizer (130; 340, 354, 364) dafür eingerichtet ist, eine Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells (1 10; 310, 351 , 361 ) bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie der Wert dieses Attributs zu aktualisieren ist, wobei die Aktualisierungsmitteilung den Knoten mittels der ID des Knotens bezeichnet, und wobei der Controller (120; 320, 352, 362) dafür eingerichtet ist, den Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung mittels der Schreibfunktion dieses Attributs zu aktualisieren. Vorrichtung (160, 170; 300, 350, 360) nach Anspruch 1 , wobei jedem der Knoten des Datenmodells (1 10; 310, 351 , 361 ) eine ID zugewiesen ist, und wobei jeder der Knoten des Datenmodells durch seine ID von den anderen Knoten des Datenmodells (1 10; 310, 351 , 361 ) eindeutig unterscheidbar ist.

Vorrichtung (160, 170; 300, 350, 360) nach Anspruch 1 oder 2, wobei der Controller (120; 320, 352, 362) zu jedem Attribut von jedem der drei oder mehr Knoten des Datenmodells (1 10; 310, 351 , 361 ), der Attribute aufweist, eine Lesefunktion umfasst, wobei der Wert des Attributs mittels der Lesefunktion lesbar ist.

Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die ID jedes der drei oder mehr Knoten des Datenmodells eine Zahl oder eine Zeichenkette oder ein Hashwert ist.

Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die drei oder mehr Knoten des Datenmodells (1 10; 310, 351 , 361 ) eine gra- phenförmige Struktur aufweisen, so dass jedem Knoten des Datenmodells (1 10; 310, 351 , 361 ) wenigstens einer der Knoten des Datenmodells (1 10; 310, 351 , 361 ) in der graphenförmigen Struktur unmittelbar nachfolgt und/oder einer der Knoten des Datenmodells (1 10; 310, 351 , 361 ) in der graphenförmigen Struktur unmittelbar vorausgeht, wobei wenigstens einem der Knoten des Datenmodells (1 10; 310, 351 , 361 ) zwei Knoten des Datenmodells (1 10; 310, 351 , 361 ) in der graphenförmigen Struktur unmittelbar nachfolgen.

Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die Vorrichtung (160, 170; 300, 350, 360) ferner eine Schnittstelle aufweist, die dafür eingerichtet ist, Informationen über Änderungen des Datenmodells (1 10; 310, 351 , 361 ) entgegenzunehmen, die einem der Knoten des Datenmodels ein oder mehrere Attribute hinzufügen, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eigerichtet ist, für jedes dieser hinzugefügten ein oder mehreren Attribute eine Lesefunktion und eine Schreibfunktion automatisch zu erzeugen, wobei der Wert des besagten Attributs mittels der Lesefunktion lesbar ist, und wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist.

7. Vorrichtung (160, 170; 300, 350, 360) nach einem der Ansprüche 1 bis 5, wobei die Vorrichtung (160, 170; 300, 350, 360) ferner eine Schnittstelle aufweist, die dafür eingerichtet ist, Informationen über Änderungen des Datenmodells (1 10; 310, 351 , 361 ) entgegenzunehmen, die einem der Knoten des Datenmodels ein oder mehrere Attribute hinzufügen, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eigerichtet ist, für jedes dieser hinzugefügten ein oder mehreren Attribute eine Schreibfunktion automatisch zu erzeugen, wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist, wobei die Schreibfunktion dafür eingerichtet ist, den Synchronizer (130; 340, 354, 364) und/oder eine View (213; 330, 353, 363) zu informieren, wenn der Wert des Attributs sich ändert.

8. Vorrichtung (160, 170; 300, 350, 360) nach einem der Ansprüche 1 bis 5 oder nach Anspruch 7, wobei die Vorrichtung (160, 170; 300, 350, 360) ferner eine Schnittstelle aufweist, die dafür eingerichtet ist, Informationen über Änderungen des Datenmodells (1 10; 310, 351 , 361 ) entgegenzunehmen, die einem der Knoten des Datenmodels ein oder mehrere Attribute hinzufügen, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eigerichtet ist, für jedes dieser hinzugefügten ein oder mehreren Attribute eine Schreibfunktion automatisch zu erzeugen, wobei der Wert des Attributs mittels der Schreibfunktion änderbar ist, wobei die Schreibfunktion dafür eingerichtet ist, Änderungen des Werts des Attributs über die Zeit zum Zwecke der späteren Wiedergabe oder Rückgängigmachung aufzuzeichnen.

9. Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eingerichtet ist, die Lesefunktion und die Schreibfunktion für jedes der Attribute jedes der Knoten des Datenmodells (1 10; 310, 351 , 361 ), der Attribute aufweist, mittels einer Webapplikation bereitzustellen, so dass die besagte Lesefunktion und die besagte Schreibfunktion mittels der Webapplikation nutzbar sind.

10. Vorrichtung (160, 170; 300, 350, 360) nach Anspruch 9, wobei die Webapplikation in JavaScript und/oder HTML implementiert ist.

Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eingerichtet ist, für eines der Attribute eines der Knoten des Datenmodells ( 10; 310, 351 , 361 ), auf eine Nutzereingabe hin, eine Änderungsüberwachung einzurichten.

Vorrichtung (160, 170; 300, 350, 360) nach Anspruch 1 1 , wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eingerichtet ist, einen Alarm auszugeben, wenn ein Wert eines der Attribute sich ändert, für das eine Änderungsüberwachung eingerichtet ist.

Vorrichtung (160, 170; 300, 350, 360) nach einem der vorherigen Ansprüche, wobei die Vorrichtung (160, 170; 300, 350, 360) dafür eingerichtet ist, eine Vornahme einer Änderung eines Attributs eines der Knoten des Datenmodells (1 10; 310, 351 , 361 ) aufzuzeichnen.

Server (170; 300), wobei der Server (170; 300) eine Vorrichtung (160; 310) nach einem der Ansprüche 1 bis 13 ist, wobei der Server (170; 300) dafür eingerichtet ist, eine Anmeldung von ein oder mehreren Clients (160; 350, 360) entgegenzunehmen, wobei der Server (170; 300) dafür eingerichtet ist, den ein oder mehreren Clients (160; 350, 360) auf deren Anmeldung hin, Informationen über das Datenmodell (310) zu übertragen, wobei diese Informationen über das Datenmodell (310) die

Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells (310) umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell (310) ferner für jeden Knoten des Datenmodells (310) oder für die wenigstens zwei Knoten des Datenmodells (310) angeben, welche der Kno- ten des Datenmodells (310) diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells (310) diesem Knoten unmittelbar vorausgehen.

15. Server (170; 300) nach Anspruch 14, wobei der Server (170; 300) dafür eingerichtet ist, eine Anmeldung von zwei oder mehreren Clients (160; 350, 360) entgegenzunehmen, wobei der Synchronizer (340) des Servers (170; 300) dafür eingerichtet ist, eine Nachricht von einem der Clients (160; 350, 360) zu empfangen, die angibt, dass ein Wert eines Attributs eines Knotens des Datenmodells (310) sich geändert hat, und wobei der Synchronizer (340) des Servers (170; 300) dafür eingerichtet ist, auf die Nachricht des besagten Clients (160; 350, 360) hin, die anderen zwei oder mehreren Clients (160; 350, 360), die sich beim Server (170; 300) angemeldet haben, davon unterrichtet, dass ein Wert eines Attributs eines Knotens des Datenmodells (310) sich geändert hat.

Server (170; 300) nach Anspruch 14 oder 15, wobei der Server (170; 300) dafür eingerichtet ist, einem Gerät (380, 390) drahtlos oder drahtgebunden eine Nachricht zuzusenden, die dem Gerät (380, 390) mitteilt, dass ein Attribut eines der Knoten des Datenmodells (310) sich geändert hat.

Server (170; 300) nach Anspruch 16, wobei der Server (170; 300) dafür eingerichtet ist, dem Gerät (380, 390) die Nachricht drahtlos zuzusenden.

Server (170; 300) nach Anspruch 16 oder 17, wobei das Gerät (380, 390) ein Renderer (380) zur Erzeugung von ein oder mehreren Lautsprechersignalen ist.

Server nach einem der Ansprüche 14 bis 18, wobei der Server (170; 300) dafür eingerichtet ist, vom Client (160; 350, 360) Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) zu empfangen, wobei diese Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) ferner für jeden Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) oder für die wenigstens zwei Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) angeben, welche der Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Da- tenmodells (351 , 361 ) des Clients (160; 350, 360) diesem Knoten unmittelbar vorausgehen.

Server (170; 300) nach einem der Ansprüche 14 bis 19, wobei der Server (170; 300) dafür eingerichtet ist, den ein oder mehreren Clients (160; 350, 360) auf deren Anmeldung hin, die ID von zwei oder mehreren der Knoten des Datenmodells (310) des Servers (170; 300) zu übertragen.

Client (160; 350, 360), wobei der Client (160; 350, 360) eine Vorrichtung (160, 170; 300, 350, 360) nach einem der Ansprüche 1 bis 10 ist, wobei der Client (160; 350, 360) dafür eingerichtet ist, sich bei einem Server (170; 300) nach einem der Ansprüche 14 bis 20 anzumelden, wobei der Client (160; 350, 360) dafür eingerichtet ist, auf die Anmeldung beim Server (170; 300) hin, Informationen über das Datenmodell (310) des Servers (170; 300) zu empfangen, wobei diese Informationen über das Datenmodell (310) des Servers (170; 300) die Werte der Attribute von allen Knoten oder von zwei oder mehr Knoten des Datenmodells (310) des Servers (170; 300) umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell (310) des Servers (170; 300) ferner für jeden Knoten des Datenmodells (310) oder für die zwei oder mehr Knoten des Datenmodells (310) des Servers (170; 300) angeben, welche der Knoten des Datenmodells (310) des Servers (170; 300) diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells (310) des Servers (170; 300) diesem Knoten unmittelbar vorausgehen, und wobei der Client (160; 350, 360) dafür eingerichtet ist, sein Datenmodell (351 , 361 ) abhängig von den Informationen über das Datenmodell (310) des Servers (170; 300) hin zu aktualisieren.

Client (160; 350, 360) nach Anspruch 21 , wobei der Client (160; 350, 360) dafür eingerichtet ist, dem Server (170; 300) Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) zu übertragen, wobei diese Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) die Werte der Attribute von allen Knoten oder von zwei oder mehr der Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) umfassen, die Attribute aufweisen, und wobei die Informationen über das Datenmodell (351 , 361 ) des Clients (160; 350, 360) ferner für jeden Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) oder für die wenigstens zwei Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) angeben, welche der Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) diesem Knoten unmittelbar nachfolgen und/oder welche Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) diesem Knoten unmittelbar vorausgehen.

Client (160; 350, 360) nach Anspruch 21 oder 22, wobei der Client (160; 350, 360) dafür eingerichtet ist, in einem Webbrowser zu laufen.

Client (160; 350, 360) nach einem der Ansprüche 21 bis 23, wobei der Client (160; 350, 360) dafür eingerichtet ist, dem Server (170; 300) die ID von zwei oder mehreren der Knoten des Datenmodells (351 , 361 ) des Clients (160; 350, 360) zu übertragen.

System umfassend, einen Server (170; 300) nach einem der Ansprüche 14 bis 20, und einen Client (160; 350, 360) nach einem der Ansprüche 21 bis 24, wobei der Client (160; 350, 360) dafür eingerichtet ist, dem Server eine Aktualisierungsmitteilung zu senden, wobei der Synchronizer (340) des Servers (170; 300) dafür eingerichtet ist, die Aktualisierungsmitteilung zu empfangen, die einen der Knoten des Datenmodells (310) des Servers (170; 300) bezeichnet, die des Weiteren ein Attribut dieses Knotens bezeichnet, und die angibt, wie der Wert dieses Attributs zu aktualisieren ist, und wobei der Controller (320) des Servers (170; 300) dafür eingerichtet ist, den^* Wert dieses Attributs dieses Knotens in Abhängigkeit von der Aktualisierungsmitteilung zu aktualisieren, wenn die Aktualisierungsmitteilung die ID des Knotens bezeichnet.

Verfahren, umfassend, Empfangen einer Aktualisierungsmitteilung, die einen Knoten eines Datenmodells mittels einer ID des Knotens bezeichnet, wobei die Aktualisierungsmitteilung des Weiteren ein Attribut dieses Knotens bezeichnet, und wobei die Aktualisierungsmitteilung angibt, wie ein Wert dieses Attributs zu aktualisieren ist, wobei das Datenmodell drei oder mehr Knoten umfasst, wobei einem oder mehr der drei oder mehr Knoten des Datenmodells eine ID zugewiesen ist, wobei jeder dieser ein oder mehr Knoten durch seine ID von den anderen Knoten des Datenmodells eindeutig unterscheidbar ist, wobei wenigstens zwei der Knoten des Datenmodells jeweils ein oder mehrere Attribute aufweisen, wobei jedes der besagten Attribute einen Wert annehmen kann, der in dem Datenmodell gespeichert ist, wobei jedem Knoten der besagten wenigstens zwei Knoten eine Pfadangabe zugewiesen ist, wobei die Pfadangabe den jeweiligen Knoten, dem diese Pfadangabe zugewiesen ist, und wenigstens einen weiteren der drei oder mehr Knoten des Datenmodells aufweist, und wobei sich die Pfadangabe von jedem Knoten der besagten wenigstens zwei Knoten von der ID des jeweiligen Knotens unterscheidet, und

Aktualisieren des Wertes des in der Aktualisierungsmitteilung bezeichneten Attributs mittels der Schreibfunktion dieses Attributs in Abhängigkeit von der Aktualisierungsmitteilung.

Computerprogramm mit einem Programmcode zur Durchführung des Verfahrens nach Anspruch 26.