Offenes Format für vibrationsbewusste Software

Ein offenes Format, mit dem eine Software die vibrierende Signatur eines Klangs lesen, speichern, vergleichen und übertragen kann.

EEV ist ein offenes Format, das entwickelt wurde, um die vibrative Identität eines Klangs strukturiert und lesbar zu erfassen. Es will nicht nur angeben, welche Note gespielt wird, sondern das bewahren, was die echte Signatur eines Klangs ausmacht: seine Teiltöne, seine Entwicklung, sein Ausschwingen, seine Dichte, seine Klangfarbe und sein globales Schwingungsverhalten.

Für einen Klangtherapeuten schwingen zwei Klänge mit derselben Grundfrequenz nicht unbedingt auf dieselbe Weise. Sie können eine andere Farbe, einen anderen Reichtum, ein anderes Ausschwingen und eine andere empfundene Qualität haben. Genau diese Unterschiede soll EEV strukturiert beschreiben, damit eine Software sie lesen, vergleichen, archivieren, übertragen oder für eine feinere Analyse nutzen kann.

Vier Qualitätsstufen

Das EEV-Format kann in mehreren Qualitätsstufen erzeugt werden. Ziel ist es nicht, die Natur des Formats zu verändern, sondern die Feinheit der Klangbeschreibung je nach Verwendungszweck schrittweise zu erhöhen.

ECO — Essentiell

Es eignet sich, wenn eine einfache Darstellung des Klangs ausreicht.

STANDARD — Erweitert

Er ermöglicht einen zuverlässigeren Vergleich und eine nuanciertere Lesart der Schwingungssignatur und bleibt dabei relativ kompakt.

HIGH — Fortgeschritten

Er ist für Anwendungen geeignet, bei denen die zeitliche Entwicklung und die Schwingungsmorphologie des Klangs in der Analyse wirklich zählen.

ULTRA — Detailliert

Er ist für Anwendungen gedacht, die die reichhaltigste mögliche Darstellung des Klangs für vertiefte Untersuchung und Resynthese verlangen.

Zwei öffentliche Formen des EEV-Formats

Das EEV-Format kann in zwei Hauptformen verbreitet werden.

EEV

Dies ist die grundlegende, lesbare und strukturierte Form des Formats.

EEVZ

Dies ist die komprimierte Version desselben Inhalts. Sie ermöglicht einen kompakteren Transport und eine kompaktere Archivierung, bei gleichbleibender Datenlogik.

Zwei Organisationsformen für Fingerprints

ENTRY

Eine einfache Struktur, die für einen einzelnen Schwingungs-Fingerprint ausgelegt ist. Sie ist die direkteste Wahl, wenn ein Klang nach dem anderen gespeichert, übertragen oder verarbeitet werden soll.

LIB

Eine Bibliotheksstruktur, die mehrere Fingerprints in einem organisierten Ganzen enthält. Sie ist nützlich, wenn eine Klangsammlung verwaltet, eine Referenzbasis aufgebaut oder mehrere Fingerprints in einer logischen Datei zusammengefasst werden sollen.

Warum EEV nützlich ist

EEV ist nützlich, sobald eine Software Klang anders als nur als Roh-Audio oder bloßen Notennamen behandeln muss.

Einen nutzbaren Schwingungs-Fingerprint bewahren.

Mehrere Klänge miteinander vergleichen.

Die klanglichen und schwingungsbezogenen Qualitäten eines Instruments erfassen.

Klangsignaturen archivieren.

Analysen zwischen Werkzeugen oder Software-Umgebungen übertragen.

Den Klang eines Instruments in seinem Wesen, seiner Seele neu erschaffen (Resynthese).

Wo ein Team beginnen sollte

Diese Website vermeidet es, dem Leser sofort das ganze Roh-Repository vorzuwerfen. Sie bietet einen kurzen Leseweg, damit ein Team den Implementierungsumfang schnell festlegen kann.

1. Den Vertrag abstecken

Die Format-Seite lesen, um Abschnitte, kanonische Reihenfolge, Transportvarianten und den Unterschied zwischen tolerantem Lesen und strengem Schreiben zu verstehen.

2. Die Architektur festlegen

Die Implementierungsseite lesen, um Container-Erkennung, Text-Parsing, internes Modell, Validierung, Export und Hashing voneinander zu trennen.

3. Das Rohmaterial vorbereiten

Die Aufnahme-Seite und die Ressourcen lesen, um eine korrekte Implementierung auf nutzlosen oder schlecht annotierten Aufnahmen zu vermeiden.

Kanonischer Vertrag

Die Kernarbeit beginnt mit dem realen v1-Vertrag: bekannte Abschnitte, Schreibreihenfolge, moderne Felder und die genaue Stelle tolerierter Legacy-Varianten.

Trennung der Schichten

Das Modell muss Identität, globale Messungen, Matrizen, Vektoren, Modi, Peak-Tracks und Interpretationsschichten unterscheiden. Sie zu vermischen macht den Code sehr schnell fragil.

Export-Disziplin

Ein Reader darf tolerant sein. Ein kanonischer Writer muss strikt, lesbar, stabil und reproduzierbar bleiben. Genau daraus entsteht Vertrauen in das Format.