Möglichkeiten der ODF Programmierung

Immer wieder, vor allem bei sehr großen ODFs, würde ich mir doch die eine oder andere zusätzliche Möglichkeit der Programmierung einer ODF wünschen z.B.:

- Include von Dateien
- Definition von Konstanten
- Globale Variablen
- einfache Anweisungen, Sprungfunktionen, Verzweigungen, Schleifen usw.
- leichte arithmetische Operationen

Vor allem die Definitionen zu den Samples nehmen mittlerweile den weitaus größten Teil einer ODF ein und sollten deshalb ausgelagert werden können. Außerdem wäre es gut, diese ganzen Ranks von der übrigen ODF aus mit einer quasi "Standardschnittstelle" bedienen zu können. Quasi so, dass man einen "Standardspieltisch" mit einem beliebigen "Pfeifenwerk" verbinden kann.

Für diesen Ansatz ist es etwas schade, dass die Ranks grundsätzlich fortlaufend nummeriert sein müssen. Damit ist ein flexibles, strukturiertes Vorgehen schwierig. Bei den Stops dagegen ist die fortlaufende Nummerierung nicht notwendig, weshalb also dann gerade ausgerechnet bei den Ranks ?!
Es gibt auch bei realen Orgeln durchaus leere Reihen auf den Windladen, die später noch mit Pfeifen bestückt werden könnten. Dieser Umstand ist in GO m.E. bisher noch ungenügend abgebildet.

Wurde über solche Dinge seitens der GO-Entwickler schon diskutiert? Was wäre evtl. mit wenig Aufwand realisierbar?

Die Schleife für die Pfeifendefinitionen wäre sicher eine Möglichkeit von vielen.

Aber auch eine Struktur wie if...then...else würde manche Möglichkeit bieten, besser interaktiv auf die Eingaben am Spieltisch reagieren zu können.
[hr] if Mixturenabsteller=true then

[white]______[/white]ignoriere alle Mixturen bei der Soundausgabe, egal wie sie gerade registriert sind

elseif 16Fußabsteller=true

[white]______[/white]ignoriere alle 16Fuß-Register bei der Soundausgabe, egal wie sie gerade registriert sind

else

[white]______[/white]dann ganz normal wie immer

endif
[hr]
solche Probleme habe ich gerade bei Doesburg. Bei HW scheint so etwas zu funktionieren. Man kommt mit dem Auslösen jedes Abstellers, fester Kombination oder Creszendo anstandslos wieder zur letzten Einstellung der Handregistrierung zurück.

Zitat

Original geschrieben von martin
Wie du schon geschrieben hast, ist die händische ODF Erstellung mühsam - jeder kluge Mensch wird zu einen Tool greifen.

Da bin ich der Meinung GO selbst sollte das Tool sein, mit dem man einigermaßen mit vertretbarem Aufwand eine virtuelle Orgel definieren kann. Das jetzige ODF ist noch praktikabel bei kleineren Orgeln, vor allem wenn sie noch ohne Multirelease sind.

Zugegeben ist nun Doesburg wirklich kein kleines Set. Da sieht es bis jetzt etwa wie folgt aus:

(Im Moment werden nur die Front-Kanäle genutzt und auch ohne die Tremulantenranks)
- Damit ist die ODF schon rund 2,6 MB groß und besteht aus ca 80.000 Textzeilen.
- rund 2,5 MB entfallen nur auf die Definitionen der Pfeifen - jede Menge im Grunde fast redundanter Code !!
- Die eigentliche Definition des Spieltisches in der ODF beträgt nur rund 66 kB - im Vergleich sehr wenig

Und man bedenke - das ganze ist nur eine Text-Datei !

Also da wäre ein einfacher Include einer externen Datei, die alle Ranks enthält schon eine sehr einfache Hilfe. Im Moment mache ich das eben jedesmal händisch mit dem Editor.

Zitat

Persönlich würde ich wahrscheinlich auf PHP zurückgreifen und ein Skript schreiben, was das komplette ODF generiert. Nicht redundante Passagen würde ich 1:1 durchschicken - für den Rest auf PHP zugreifen. Jede Änderung würde nur über das PHP passieren - das ODF nie direkt geändert.

Damit hat man alle geforderten Möglichkeiten, um ein ODF zu erstellen.

PHP-Skripte verwende ich zur Erstellung der Pfeifendefinitionen - man darf sich aber nicht täuschen lassen, wie viele Unregelmäßigkeiten doch in den Sample-Strukturdaten der Sethersteller vorkommen können, die solch eine Automatik auch wieder ruckzuck aushebeln können. Bei Doesburg ist das zum Glück diesmal nicht der Fall, aber bei der Prag z.B. war das extrem. Dann kann man doch fast alles von Hand schreiben.

Diese vielen Ausnahmen machen es m.E. auch fast unmöglich bzw. wenig sinnvoll, die komplette ODF mit einem Generator zu erzeugen. Da bläht sich der Aufwand zur Entwicklung des Tools schnell ins Unermessliche auf, das haben wir bei Wolfgangs ODF Generator erleben können.
Allerdings wäre ich ohne die PHP-Skripte sicher noch Jahre beschäftigt diese ODF zu tippen - so ist aber schon Land in Sicht.

Zitat

Mit der Zeit hat man auch einen Baukasten an Funktionen, die man wiederverwenden kann. Mit der Nummerierung sehe ich weniger ein Problem, weil ein Baukasten die Nummervergabe übernehmen kann

Allerdings werden ODFs dann nahezu unlesbar werden. Intelligenter wäre da, wenn man verschiedene Orgelbaugruppen auch verschiedenen Nummernkreisen zuordnen könnte, wie es die vergangenen Jahre z.B. gern mit der Nummerierung der Stops gemacht wurde: [Stop0xx] fürs Pedal, [Stop1xx] Manual1, [Stop2xx] Manual2 usw.

Bei Ranks geht das wie gesagt leider garnicht und bei Koppeln z.B. nur mit recht kleinen Zahlen unter 100. Ich würde kein Problem sehen, die Nummerierungen grundsätzlich überall von 000 bis 999 frei wählbar zu gestatten, also damit auch ein [Coupler1xx] der auf das Manual1 bezogen ist. Man wird sowieso nie verhindern können, wenn ein Programmierer Blödsinn programmiert, auch nicht mit eingeschränkter Nummerierungsmöglichkeit.

Zitat

Ein leeres Rank kannst du auch machen. Setzt die Pfeifenanzahl auf 1 und lade ein WAV mit Stille 8-)

Auf diesen "Trick" bin ich schon damals bei der Rotterdam ODF gekommen. Allerdings ist das ja nicht so die saubere Lösung die ich mir wünschen würde. Ich mag auch den HW-Sets nicht irgendwelche eigenen wave-Dateien hinzufügen, also suche ich immer eine möglichst kleine, "unauffällige" wave die das Set von Haus aus mitbringt. Warum darf ich in einem Rank nicht einfach die Pfeifenzahl auf 0 setzen ?? In einer Orgel geht man doch auch nicht hin und baut eine einzelne zugestopfte Pfeife auf eine leere Reihe der Windlade :L

Die Definition des Spieltisches in der ODF ist so schon nicht schlecht wie es jetzt bereits ist. Irgendwas muss man dem Generator ja auch an Infos mitgeben damit er was daraus machen kann. Das ist im Prinzip dann sowieso wieder das was man auch gleich direkt in die ODF schreiben kann.

Ich denke nicht, dass man hier viel Aufwand einsparen kann. Man nimmt sowieso Bausteine aus vorhandenen ODFs und kopiert vieles zusammen. Hier ist viel wichtiger, dass der ODF-Programmierer eben auch umfassende Kenntnisse von Orgeln hat und nicht nur vom Programmieren. Diese Kenntnisse hat auch ein Generator nicht wenn es ans Eingemachte geht. Die letzten, entscheidenden 5% "Intelligenz" werden ihm fehlen, denn es kommen mit jedem neuen Set auch wieder neue Problemstellungen auf einen zu.

Der Mammutaufwand sind eigentlich nur die Pfeifendefinitionen - die bekommt man aber auch eher über eine Programmier-Routine in den Griff. Das sollte aber m.E. auch in GO möglich sein, ohne externe Tools bemühen zu müssen.

Eine Schnittstelle zwischen Spieltisch und Ranks und irgend eine einfachere Art die Pfeifen zu definieren, die noch erfunden werden muss.

Wenn man Variablen hätte für den Pfad zu den Pfeifen und für die Dateinamen und die Releases, dann wäre doch schon viel gewonnen. Bei Doesburg z.B. wiederholt sich dann alles sehr gleichmäßig mit genau 1 Loop-Datei + 2 Release-Dateien über sämtliche Ranks hinweg. Ein Rank mit Variablen definieren und dann alle Parameter noch als Liste eingeben und schon hat man 200 Ranks a 73 Pfeifen - denn Doesburg verwendet für die meisten Register satte 6 Oktaven voller Pfeifen

Die Verzeichnisstrukturen einzulesen ist ein interessanter Ansatz, den auch schon Wolfgang mit seinem ODF Creator verfolgt hatte. Dazu hatte ich ihm schon die Scans von zahlreichen Samplesets zur Verfügung gestellt um diese zu analysieren. Leider treten von Set zu Set auch da immer wieder mal neue Unregelmäßigkeiten oder auch gänzlich andere Strukturen auf, in denen die Set-Hersteller ihre Sampledateien verwalten. Es gibt da leider keine Norm. Das hat zur Folge, dass auch die Routinen, bzw. Generator-Skripte immer wieder neu angepasst werden müssen.

Bis jetzt verwende ich PHP-Skripte, die einfach die Codezeilen fortlaufend generieren. Das hat durchaus Vor- und Nachteile ebenso wie das Einlesen der Verzeichnisse Vor- und Nachteile hat. Es ist leider nicht so, dass einfach alle Dateinamen aus dem Verzeichnis 1:1 in Pfeifen-Definitionen gewandelt werden können. Teilweise handelt es sich bei den Dateien nicht um Samples sondern um alles Mögliche anderes, was der Beschreibung der Orgel dient, wie z.B. Grafiken, Geräuschsamples usw.
Außerdem liegen immer wieder einzelne Pfeifen mit 2 oder mehr Loop-Sample-Dateien für den selben Ton vor. Hier muss man also ganze Dateien überspringen, sonst hat man aufeinanderfolgend mehrmals den selben Ton in die ODF übernommen.

Auch die Release Dateien können an ganz unterschiedlichen Orten in den Verzeichnissen liegen. Teilweise ist das erste Release in der Loop-Attack-Datei bereits enthalten und die folgenden in extra Dateien, teilweise werden nur extra Dateien für die Releases verwendet. Die Unterverzeichnisse für Releases können auch ganz unterschiedlich organisiert sein. Manchmal ist auch die Release-Time nicht im Verzeichnisnamen angegeben, so dass dieser Wert erst mehr oder weniger erraten werden muss.

Bei der angesprochenen problematischen ODF handelt es sich um das Set "Prague Baroque" von Sonus Paradisi. Im Prinzip läuft diese ODF bereits schon seit einiger Zeit, es ist aber noch einiges an Feinarbeit notwendig, und es gibt noch weitere Gründe, weswegen ich diese ODF im Moment noch nicht veröffentlichen möchte.
Außer der teilweise willkürlichen Groß- und Kleinschreibung kamen noch die Probleme hinzu, dass das Original nur kurze Oktaven hat, die ODF aber voll chromatisch als erweitertes Set funktionieren sollte. Außerdem mussten alle fremden Zungen, deren Samples von einer ganz anderen Orgel in Wien stammen, manuell auf die exakte Stimmtemperatur der Prager Orgel gepitcht werden, um auch die originale Stimmung verwenden zu können.

Nachdem wir hier nun so ein schönes Skript besitzen um die Verzeichnisse einzulesen, kann ich aber doch im Dateianhang die Verzeichnisstrukturen dieses Sets zur Verfügung stellen. Wenn man diese aufmerksam analysiert, wird so manches von dem oben geschriebenen deutlicher werden.

Deshalb kann das Generator Skript mit Header von Martin so sicher noch nicht wirklich in der Praxis funktionieren.

Der Ansatz, auch die "übrige" ODF mit in das PHP-Skript zu integrieren ist sicher noch einige Überlegung wert. Ich hatte das auch schon angedacht, aber mangels unzureichender Erfahrung mit PHP bis jetzt nicht umgesetzt. Aber aus dem Beispiel kann ich doch einiges lernen!

In der Prag ODF verwende ich noch die Pfeifendefinitionen innerhalb der Stops. Das geht noch bei kleineren Orgeln. Für die kommenden ODFs der großen Sets habe ich beschlossen, zukünftig sämtliche Pfeifen nur noch in Ranks zu organisieren. Alle Ranks werden dabei zu einem Block zusammengefasst und derzeit ganz am Ende der ODF angehängt. Das schafft doch deutlich mehr Übersicht und Flexibilität. Deshalb auch der Wunsch, diese Ranks auch physisch vom Spieltisch zu trennen und aus der ODF auszulagern (Include).

Auch für den Fall, alles nur noch in einem zentralen PHP-Skript zu verwalten, würde ich die Ranks als separaten Block in diesem Skript zusammenfassen. Was allerdings die Wartung anbetrifft, so ändert sich im Allgemeinen an den Pfeifen später nichts mehr, sodass diese eigentlich auch nicht unbedingt neu zu generieren wären.

Es spräche aber auch noch einiges dafür, die Ranks eben gerade nicht zu integrieren, sondern als separaten Block getrennt vom Spieltisch zu belassen. Und zwar besteht dann die Möglichkeit, unterschiedliche "Rank-Blöcke" an diese "Spieltisch-ODF" zu binden. Nämlich zu Testzwecken während der Entwicklungsphase vollkommen leere Ranks ohne Pfeifen zu verwenden. Das vermeidet Ladezeiten, solange man z.B. nur an der Bildschirmgrafik bastelt.
Weiterhin kann man so leicht einen Rank-Block erzeugen, der dann nur die Pfeifen beinhaltet, die das Demo-Set zur Verfügung stellt. Ein weiterer Rank-Block nur mit den Wet-Samples ohne "Surround-Ballast", ein Block für das volle Surround-Set und möglicherweise Blöcke um nur Teilorgeln für kleinere Spieltische bzw- PC´s laden zu können - alles ohne dann sämtliche unnötigen Register im GrandOrgue Menü deaktivieren zu müssen, was bei großen Sets doch ziemlich Aufwand bedeutet.

Wichtig wäre hierfür aber eine Möglichkeit die Schnittstelle zwischen Spieltisch und Rank-Block einfach definieren zu können. Zwingend fortlaufende Ranknummerierung ist da eher etwas ungünstig. Auch Teilsets müssen die selben Ranknummern haben um zum Spieltisch zu passen. damit ergeben sich automatisch Lücken in der Rank-Nummerierung. Diese kann mein freilich mit den "leeren Ranks", wie ein paar Beiträge weiter oben beschrieben, füllen.

So - heute nochmal bei Tageslicht betrachtet, kommt schon mehr Klarheit auf

Ich versuche mal zusammenzufassen:

- Es wird eine Liste generiert, die lediglich alle Pfeifeninformationen eines einzelnen Ranks beinhaltet
- Zur Erzeugung dieser Liste gibt es eine "Library" mit Funktionen
- Diese Funktionen werden mit den nötigen Übergabeparametern aufgerufen
- in einer Funktion davon wird die Groß- Kleinschreibung mit dem tatsächlichen Pfad abgeglichen
- Die Funktions-Library wird als Header dem eigentlichen ODF-Code vorangestellt
- Die Liste der Pfeifeninformationen wird anstelle jeder Rank-Definition mittels PHP Code in den ODF-Code eingefügt
- Mittels einer separaten Scan-Routine wird die Verzeichnis-Struktur des Sets zuvor in eine Datei eingelesen
- Die so entstandene PHP-Quelldatei, die den ODF-Code enthält, wird zur ODF-Zieldatei compiliert
- Das heißt, wir haben dann eine in GrandOrgue lauffähige .organ Datei generiert

Vorteile gegenüber meiner jetzigen Methode:

- Die Einzelkomponenten müssen nicht mehr von Hand zur ODF zusammengefügt werden
- Bei konsequenter Anwendung ist nur die Wartung einer einzigen Source-Datei nötig
- Unstimmigkeiten in der Groß- Kleinschreibung der Sample-Dateien werden automatisch korrigiert
- Durch Erweiterung der Funktionen lassen sich evtl. auch andere Bereiche der ODF vereinfachen

Neutral:

- Der Gesamtaufwand zur Erstellung einer komplexen ODF ändert sich insgesamt nur unwesentlich
- Es wird für den Laien dadurch auch nicht einfacher eine ODF zu erstellen

Nachteile:

- Es sind konkretere Kenntnisse in PHP bzw. einer anderen höheren Programmiersprache nötig

Wie man sieht, überwiegen die Vorteile aber die Nachteile. Die PHP-Generatordatei zur kompletten Prague Baroque lässt sich übrigens vollkommen fehlerfrei zur lauffähigen ODF übersetzen :A

Da hast Du Martin, mal wieder ganze Arbeit geleistet - da wird auch wieder klar, warum GrandOrgue bisher schon so gut werden konnte :-respect: