Möglichkeiten der ODF Programmierung

    Ich würde mal sagen da bedarf es jetzt eines neuen PHP ODF Workshops. Denn bis hierher versteh ich grad nur Bahnhof. Ich hoffe das ändert sich. Diese PHP Teil hat wirklich eine sofort tadellos lauffähige ODF produziert???

    • Offizieller Beitrag

    Nein, es wurde keine lauffähige ODF "produziert". Die Prag ODF war zuvor ja schon lauffähig. Aber es wurden die Pfeifendefinitionen innerhalb dieser lauffähigen ODF automatisch neu generiert und an den entsprechenden Stellen eingefügt. Das zeitaufwändigste ist ja die Erstellung der Pfeifendefinitionen bei den großen Sets. Hier kann man dann Wochen oder Monate (oder bei Doesburg Jahre?) der Tipparbeit einsparen, wenn man automatische Routinen einsetzt. Diese Integration der automatischen Routinen innerhalb der ODF ist jetzt gelungen.

    Einen Workshop zur Hochsprachenprogrammierung (PHP, C++ o.ä.) werden wir hier kaum durchführen können. Dafür gibt es Programmierkurse und Hochschulen wo man so etwas über Monate und Jahre lernen kann. ;)

    Also bleibt diese Art der vereinfachten ODF Erstellung nur wenigen vorbehalten... Na ob das so zielführend ist ??? Ist denn die Trennung von Virtueller Konsole und GO nicht einfacher? Wie ich schon sagte...alles mit der Maus hinziehen und dann auf den Registerknöpfen die Pfade zu den Samples angeben ????
    So wie beim Lillypond und Frescobaldi...da fungiert Frescobaldi auch als Bedienkonzept für Lillypond...oder bei Open Suse und KDE... So in der Art war meine Vorstellung davon.

    @mh
    Wenn du dich für php interessiert, installier das Packet php5 und suche bei Google nach php tutorial.
    Unterschied zu den Webtutorials ist:
    * Du schreibest ODF Zeilen statt HTML aus.
    * Du startest es per CLI (in einen Terminal: php test.php) und leitest die Ausgabe in eine Datei um (php test.php > test.organ)
    Wenn es Fragen gibt, wird sie sicher jemand beantworten.

    • Offizieller Beitrag
    Zitat

    Original geschrieben von Offenbass

    Also bleibt diese Art der vereinfachten ODF Erstellung nur wenigen vorbehalten... Na ob das so zielführend ist ???

    Meine Anregung ging ja deshalb auch dahin, diese Zusatzfunktionen möglichst in GrandOrgue ODF direkt zu integrieren, um tatsächlich eine Vereinfachung für diejenigen zu erzielen, die ohnedies schon an der Programmierung von ODF genug zu kauen haben - und das wird wohl die Mehrzahl der Anwender sein.
    Ich bin in der glücklichen Lage, früher einmal Technische Informatik / Elektrotechnik studiert zu haben. Allerdings bin ich auch in der schlechten Lage, vieles von dem wieder vergessen zu haben, was ich schonmal gekonnt hatte. :D Dieser Beruf hat so enorm viele verschiedene Einsatzgebiete, dass man einfach nicht in jedem Bereich aktuell bleibt, sobald man sich einige Jahre auf ein bestimmtes Spezialgebiet konzentriert hat. Programmierung in C (was dem PHP ähnelt) liegt bei mir auch schon sehr viele Jahre zurück.

    Die ODF Programmierung auf grafischer Ebene durchzuführen und Objekte mit der Maus aus einem Baukasten zu ziehen, ist sicher interessant und sieht auf den ersten Blick sehr einfach und intuitiv aus. Ich habe aber in anderen Bereichen, z.B. bei SPS-Programmierung schon festgestellt, dass dem nicht unbedingt so ist. Die Eigenschaften der einzelnen Objekte, die man dann meist mit Klick auf die rechte Maustaste öffnet, enthalten dann nicht minder viele Parameter, wenn sie die selbe Funktion erfüllen sollen. Man muss zur Anwendung dessen dann genausoviel Ahnung von der Materie haben, und hat m.M.n. in vielen Fällen eine deutlich schlechtere Übersichtlichkeit als bei einer Programmierung in Textform. Es wird sicher auch viel Aufwand erfordern eine grafische Programmierung in GO überhaupt zu ermöglichen.

    Das Thema Programmierung von virtuellen Orgeln ist aber auch schon zu komplex, als dass man das sinnvoll der "Nebenamts-Organistin Lieschen Müller" beibringen könnte. Ist aber auch sicher nicht notwendig zum Spielen mit fertigen GrandOrgue-Sets.

    Graphische Tools fürs ODF stehen bei mir nicht auf dem Plan. (Persönlich stelle ich die Frage nach den wirklichen Nutzen: Kombi-Samplesets stehe ich kritisch gegenüber - die Samples von verschiedenen Orgeln zu etwas [b]guten[/b ]zu vereinigen, ist wesentlich mehr als Ranks in einen ODF zusammenzufügen. Für die Konversion von HW Samplesets wäre ein HW-XML to ODF Konverter wahrscheinlich sinnvoller). Jetzt aber wieder zurück zum Thema

    Ich wäre daran interessiert, wie du das ODF erweitern würdest.

    Meine Vermutung dazu ist:
    Entweder schlägst du etwas einfaches vor - dann wird bei komplexeren Problemstellungen (wie zB: Prag ODF) weiterhin bei etwas wie meiner Lösung landen.
    Oder du schlägst etwas vor, was defakto eine Programmiersprache darstellt.

    • Offizieller Beitrag

    Mein Gedanke würde schon in Richtung einer Programmiersprache gehen, mit der man weitestgehend alle üblichen Möglichkeiten hat. Defacto ist auch ODF schon als Programmiersprache anzusehen, mit der nicht mehr jeder Laie klarkommen kann. Insofern muss jeder nur soviel davon nutzen, wie er auch versteht.

    Es ist mir aber klar, dass es sicherlich einen großen Aufwand bedeuten würde, GO-ODF dahingehend zu erweitern. Deshalb auch eher die leise Anfrage nach ein paar kleinen Veränderungen, wie z.B. Include oder erweiterte, flexible Nummernkreise.

    Persönlich kann ich aber auch sehr gut damit leben, die ODF mit einem externen Generator zu produzieren, so wie jetzt beispielsweise mit den PHP-Skripten. Ich wollte mit der Diskussion hauptsächlich zum Nachdenken anregen, ob es auch Vereinfachungen geben könnte, die der durchschnittliche ODF-Programmierer leichter handhaben könnte.

    Vielleicht wäre es denkbar, auch zusätzlich einen GO-eigenen Standard für Samplesets festzusetzen, bei dem zumindest Samplesets die nach diesen Regeln in Zukunft aufgenommen und abgespeichert werden, mit einer einfachen GO-ODF Anweisung definiert werden können, ohne kilometerlange Pfeifendefinitionen eingeben zu müssen :I:

    Alle übrigen GO-fremden Samplesets könnte man dann ja auch mit externen Generatoren z.B in das GrandOrgue-Sample-Format transferieren.

    Hallo,

    Inspiriert von Offenbass-Martins Einwand, die programmatische ODF-Generierung für Normalsterbliche einfacher zu machen,
    freue ich mich nach einem Vormittag voller Reguläre-Ausdrücke-Wahnsinns folgeden Prototyp präsentieren zu können:

    http://lessodf.mictes.de

    Bisher ist damit noch nicht allzuviel machbar, aber durch Eingabe folgendes Codes:

    Code
    {Pipe 32
	path: .\OrganInstallationPackages\001161\SW\Cornett\@036-@C.wav
	MIDIKeyNumber: @36
	Test: @(q,w,e,r,t,z)
}


    Lassen sich die bisherigen Fähigkeiten meines Wochenendprojekts gut verdeutlichen.

    Bisher geht nur der Pipe-Befehl.
    Die 32 steht für die Anzahl der Pfeifen.

    Innerhalb der Klammern kann jedes beliebige Attribut eingegeben werden,
    dieses wird dann an die Pfeife angehängt.
    Der Wert des Attributes hat hinter einem Doppelpunkt zu stehen, da ich den einfacher zu lesen finde als Gleichheitszeichen.

    Folgende Variablen können verwendet werden:
    @ZAHL, z.B. @036 - Der Loop startet bei der 36, die vorstehende 0 wird erhalten
    @NOTE, z.B. @C - Der Loop geht c, c#, d, d#... durch, Groß-/Kleinschreibung hängt davon ab was man selber eingibt (c/C).
    @CUSTOM, z.B. @(q,w,e,r,t,z) in Klammern und kommasepariert, q,w,e,r,t,z wird wiederholt

    Mein Ziel ist es eine Art "Template-Sprache" für ODFs zu erschaffen.
    Sollte sie gut sein könnte man versuchen wg. der oft propagierten Ähnlichkeit von PHP und C++
    einen derartigen Perprocessort in GO zu integrieren, spää...ter.

    Über Feedback zur Syntax die ich mir da ausgedacht habe würde ich mich freuen.
    Ich werde mich heute Abend nochmal ransetzen.

    Einen eigenen Thread wollte ich dafür noch nicht eröffnen, vieeeel zu beta.
    Den Quelltext würde ich auf Anfrage zugänglich machen.

    Gruß,
    Michael

    Interessanter Ansatz - ist vielleicht wirklich Anfängerfreundlicher. Die Webseite könnte man jetzt als Schreibhilfe beim ODF Erstellen nutzen.

    Ich persönlich gehe mehr nach Arbeitsersparnis. Für Multi-Releases brauche ich mehrere Pfade pro Pfeife - und das für jeden Stop extra wiederholt. Die Angabe eines Pfad-Prefix + der Release-Zeitpunkt ist wesentlich arbeitssparender. Eine kompakte Beschreibung mit nur ein paar Werten ist ein guter Ausgangspunkt, um mehr zu generieren.

    Ich frage mich, ob ein Preprozessor in GO wirklich eine so gute Idee ist. Damit verschwindet die Zwischenstufe ODF. Das ODF ist zwar langatmig zu schreiben - aber sehr einfach zu lesen. Man sieht auf den ersten Blick, welcher Ton zur Pfeife geladen wird. Selbst ich würde nicht nachvollziehen, was mein PHP Code macht, sondern einfach im ODF nachschauen.

    PS: Die ganze Javascript basierte Oberfläche hat bei mir immer wieder Probleme gemacht.

    • Offizieller Beitrag

    Das finde ich eine pfiffige Idee, eine Online-Unterstützung für ODF-Erstellung anzubieten. So kann sich der Laie den Aufwand ersparen selbst mit PHP hantieren zu müssen. Eine Hand voll Parameter in die "Web-Mühle" geworfen und „Rickeracke! Rickeracke! Geht die Mühle mit Geknacke“ - kommt eine fertige Registerdefinition dabei heraus :A

    Mir war gestern Abend auch noch "langweilig" und so habe ich schonmal das nächste ODF-Projekt begonnen. Dabei habe ich die neuen PHP-Skripte von Martin natürlich gleich voll zum Einsatz gebracht.

    Für das SP-Set Krzeszow habe ich auf diese Weise 50 Register Front und Rear, sowie eine grobe lauffähige ODF zusammengeschustert. Nach rund 6 Stunden Arbeitszeit konnte ich das 76 kB große PHP- Skript auf rund 2,5 MB ODF-Datei "aufblasen" - Ich konnte damit sofort ohne irgendwelche Fehler die Krzeszow laden und spielen.
    Natürlich werden jetzt noch unzählige Stunden in das Projekt fließen, bis alle orgelspezifischen Details auch in der ODF umgesetzt sind. Jede Orgel hat wieder andere Eigenheiten, die man beim Spielen mit einem Set garnicht gleich so ohne weiteres wahrnimmt.

    So langsam kehrt auch schon ein wenig Routine im Umgang mit den großen Sets ein. Man muss eben heftig und hoch konzentriert darauflostippen und sieht in einer Stunde dann schon ganz gute Fortschritte.

    Für die Erstellung der Pfeifendefinitionen mit den neuen Skripten benötige ich nur noch ca. die halbe Zeit gegenüber den einfachen Skripten die ich zuvor benutzt habe. Das ist schon ein großer Fortschritt :-thanks: Aber viel weiter lässt sich das m.E. nicht mehr optimieren.

    Es fließt nach wie vor viel Zeit in die Herstellung der Bezüge zwischen Registern, Manualen, Koppeln usw. - jedes Ding der Orgel hat eben einen Namen und möchte an jeder Stelle in der ODF mindestens einmal erwähnt sein - ich wüsste aber auch nicht wie man das vereinfachen sollte. Irgendwo muss man eben mitteilen wie die Orgel beschaffen sein soll.
    Eine drastische Vereinfachung wäre höchstens, tatsächlich die Daten aus der Hauptwerk XML automatisch übernehmen zu können. Andererseits kommt man so zu Fuß der Funktionsweise einer bestimmten Orgel so unglaublich detailliert nahe, wie sonst kaum.

    Gibt es eigentlich schon die Berufsbezeichnung "Virtueller Orgelbauer" ? :D

    Mir ist es nun gelungen die Komplette Wildervank durch meinen Generator zu jagen.
    Der Output enstpricht 1:1 meiner orginalen Wildervank ODF und funktioniert Einwandfrei unter GO.
    Mit Codes ist das Ganze 1479 Zeilen kürzer als die normale ODF, das "Übersetzen" hat ca. 1 Sekunden gedauert.
    Ich habe beide Dateien als Beispiele unter der "About" bzw. "Über" Seite zur Ansicht hochgeladen.

    Nachdem ich noch ein Paar Regex-Fehler ausgemerzt habe scheint das ganze nun einigermaßen stabil zu funktionieren. Eine Liste der momentan verfügbaren Codes ist unter "How to use" / "Anleitung" einsehbar.

    Zitat

    PS: Die ganze Javascript basierte Oberfläche hat bei mir immer wieder Probleme gemacht.


    Browser, Version, NoScript?

    Als Referenz habe ich Firefox genommen, den ich jetzt ausnahmsweise nicht besingen werde.
    Dort tauchen keine Fehler auf.

    Chromium lief ebenfalls einwandfrei.
    Der IE hingegen macht (natürlich mal wieder) Zicken.

    Gruß,
    Michael

    http://packages.debian.org/wheezy/iceape

    Ich habe versucht, mein Problem genauer herauszuarbeiten:
    Beim Paste mit der mittleren Maustaste startet die Oberfläche automatisch eine Umwandlung. Danach kann man nichts mehr ändern.
    Anscheinend waren dabei meine erweiterten Versuche so weit vom unterstützen Syntax entfernt, das ich nur meine Eingabe in einen nicht veränderbaren Textfeld gesehen habe.

    PS: Ein Weiterbearbeiten der Eingabe wäre wünschenswert.

    Jetzt nochmal eine Frage dazu...lässt sich denn die XML Datei aus dem HauptwerkSet nicht irgendwie durch so einen PHP Kollegen jagen um hinten eine fast fertige ODF rauszubekommen? Oder kann man aus der XML Datei nichts machen? Oder die XML Datei direkt als ODF nehmen????

    Theoretisch könnte man aus dem XML Informationen herausholen und ein ODF daraus generieren.

    Das Problem ist nur:
    1) So ein ODF wäre ziemlich sicher ein abgeleitetes Werk => Weiterverbreitung nur mit Einverständnis das HW-XML Erstellers nach dessen Bedingungen.
    2) HW hat (teilweise) andere, interne Strukturen als GO. Das zu Mappen ist nicht einfach.

    Wer erstellt für gewöhnlich die XML ? Der Sethersteller oder ein externer?
    Ich frage deshalb weil es da doch bei SP keine Probleme geben sollte...oder?
    Denn die XML sind doch bestimmt immer nach dem selben Muster gestrickt..

    Desweiteren kamen mir persönlich die Hauptwerk XMLs die ich bisher gesehen habe gerade zu "obscured" vor.
    Mit Simplexml ist das in PHP zwar technisch recht problemlos, aber Martin hat schon sicherlich Recht mit der Aussage dass es nicht einfach ist HW XMLs auf GO ODFs zu mappen.
    Und vom Aufwand her wäre das quantitativ bereits die Hälfe des von mir erträumten Mammut-Projekts,
    da mann dann ein System bräuchte das aus zwischengespeicherten Informationen eine valide ODF strickt.

    Gruß,
    Michael

    Zitat

    Desweiteren kamen mir persönlich die Hauptwerk XMLs die ich bisher gesehen habe gerade zu "obscured" vor.

    Jede HW Version hat anscheinend ein leicht anderes XML Format (ein paar Tag +/-).

    Das "Kurze" Format kann man anscheinend in HW ins "Lange" Format umspeichern - es wird anscheindend nur ein Mapping der XML-Tags gemacht. a steht für das erste Element im Lang-Format, b für das zweite Element usw. Irgendwann geht es mit aa weiter (Ein bis 2 Buchstaben (o?) werden ausgelassen).

    Wenn man von einer HW-Version sowohl ein XML im langen wie auch im kurzen Format hat, ist das Mapping dazwischen technisch kein Problem.

    Da mein erstes Versuchs-ODF noch nicht veröffentlicht werden soll, habe ich ein weiteres ODF (Krzeszow) für andere als Muster Beispiel umgebaut.

    Merwürdigerweise werden bei einigen Ranks die Note 34 geladen (und 35 frei gelassen):

    PHP
    <?php
$pipeinfo = array("mainnorelease"=> true, "releasecuepoint" => true);
initList($list);
addRank($list, 1, 1, ".\\000872\\pipe_atk\\pos\\hautbois8", 34, array(180, 380, -1), $pipeinfo);
$list["Pipe002"] = ".\\000870\\pipe\\mech\\mech_null.wav";
addRank($list, 3, 54, ".\\000872\\pipe_atk\\pos\\hautbois8", 36, array(180, 380, -1), $pipeinfo);
printList($list);
?>

    Auf den ersten Blick scheint aber 034 nirgends mit einen Manual verbunden zu werden, ist also unnützer Balast im Speicher und macht die ODF Struktur etwas komplizierter. Andererseits ist es ein schönes Beispiel, wie man mit Unregelmäßigkeiten umgeht :D