Fragen betreffend ODF Programmierung

  • Tut mir leid, dass ich mich so spät melde. Da gab es ja in Zwischenzeit ein regelrechtes Kommunikations-Feuerwerk.

    Die Tools habe ich vor fast einem Jahr geschrieben, und damit meine Orgel mit den Friesach-Samples erstellt. Das hat wunderbar funktioniert, jedenfalls nach vielen Anläufen. Anfänglich war immer irgendwo ein Fehler drin, auch deshalb, weil ich selbst die Zusammenhänge in der ODF erst verstehen musste. In Zwischenzeit habe ich leider wieder viel vergessen. Aber:

    Function=And

    SwitchCount=1

    Switch001=40

    Der Function-Eintrag steht drin, weil es ohne den nicht geht (glaube ich). Die Einträge sind ziemlich verschachtelt und werden indirekt angesprochen. Ich sage der Orgel nicht, dass im Panel ein Schalter ist, sondern ein Element. Diesem Element erkläre ich, du bist ein Schalter und siehst so und so aus. Der Schalter wird in einem anderen Segment erklärt. In diesem Element wird bestimmt, dass keine Grand-Orgue Grafik verwendet werden soll. Ich möchte ja mein eigene Grafik verwenden. Ich ordne dann an anderer Position ein Rank dem Schalter zu, und ein Schaltgeräusch. Ich hätte auch alles in einem Block reinschreiben können. Schreibt man alles in ein Block, hat man die Übersicht, was alles mit dem entsprechenden Element zusammen hängt. Verwendet man aber Elemente, so wie ich es gemacht habe, hat man genau definiert, in welchem Feld die Maus wirkt, nämlich im Feld des Elementes. Sonst muss man nicht nur Schalter Position sondern auch dessen Größe angeben.

    Da ich aber davon ausgehe, dass ich nur ein Tool verwende, dass mir dann etwas generiert, was meine Orgel darstellt, ist es mir in dieser Situation egal, wie mein ODF aussieht.

    Leider ist mein Tool nicht für jede erdenkliche Art von Orgel-Design verwendbar. Da muss ich nachbessern!

    Kommen wir zur Funktion=And:

    Ich vermute ich hätte auch Function=Input setzen können, da ich nur eine Quelle für diese Aktion habe. Das müsste ich auch noch ausprobieren.

    Warum gibt es Function? Es könnte sein, dass mehrere Schalter auf das gleiche Ereignis (Register, Tremolo usw.) wirken. Zum Beispiel es gäbe einen Hauptschalter der das Gebläse einschaltet. Dann hätten alle anderen Stops ein Function=And, SwitchCount=2 und entsprechend die Zuordnung zum Registerschalter und dem Hauptschalter. Aber hallo? Ich will Orgel spielen und nicht irgendwelche Orgeln zum Spass simulieren. Zum spielen braucht man keinen Hauptschalter. Aber es könnte sinnvoll sein, bestimmte Aktionen wie das Tremolo mit anderen Aktionen zu verknüpfen. Dann braucht man wirklich diese Function als Verknüpfung.

    Richtig ist, wenn man nicht weiss, wie es funktioniert, erst mal mit was kleinem Anfangen. Ein Register eine Pfeife ist schon ziemlich klein.

    Wichtig bei den Tools: Panel 1 zeigt Pedal und Manuale. Außer dass man angibt, wie viel Manuale es geben soll, braucht man da eigentlich nichts zu tun. Es werden immer 30 Pedale-Tasten und 61 Manual-Tasten dargestellt. Kann man ändern. Aber selbst, wenn man nur ein Keyboard mit 55 Tasten hat, würde es dennoch funktionieren.

    Panel 0 ist das Panel mit den Schaltern. Das habe ich so gemacht, dass bei mir nach dem Start das Fenster mit den Schaltern erscheint. Ich muss ja nicht sehen, wie sich die Tasten bewegen, das sehe ich beim Spielen auf der Orgel.

    Mir ist der Ferrari mit angezogener Handbremse schnell genug.

    Mir ist das viel zu langsam. Ich verwende zusätzlich einen Faltungshall. Unter Windows kann ich nicht spielen, da die Töne deutlich verzögert kommen. Unter Ubuntu konnte ich die Latenzzeit auf 10ms drücken. Das schaffe ich mit Windows nicht.

  • Nachtrag zu den Function:

    Habs gerade probiert. Function=Input geht nicht. Also: Function=And mit SwtichCount=1 heist, es ist ein "Und" das eine 1 ausgibt wenn eine 1 eingegeben wird, da ja nur ein Eingang da ist. Macht logisch keinen Sinn, funktioniert aber in der ODF.

    Function=Or funktioniert übrigens auch.

  • du machst es dir zu schwer:

    Versuchen

    1. Nur ein STOP mit pipe001=.\xxx pipe002=.\xxx

    2. STOP mit Rank001

    3. STOP mit Rank001 und Rank002

    3. Mit Switchen

    Aufmerksamkeitspunkte:

    NumberOfStops=

    NumberOfRanks=

    NumberOfSwitchs=

    Da alles miteinander verbunden ist und man manches an mehreren Stellen angeben muss, wird es schnell unübersichtlich.

  • Hier verzweifle ich schon eine Weile:
    22.01.2022 20:36:09: 20:36:09: Fehler: Werteüberschreitung in Abschnitt 'Stop002' Eintrag 'Rank001': 2

    Rank001 heist, es ist der erste Rank. Rank001=2 heist, der erste Rank hat die Nummer 2 und verweist daher auf Eintrag [Rank002]

    Stelle ich Rank001=1, läuft GO durch und meckert bei Switch001=2

    Logisch, denn in dem Ausschnitt gibt es keinen [Rank001]. Davor war der letzte noch gültige Eintrag Switch001=2. Daher kommt auch die Fehlermeldung. Sie zeigt den letzten noch gültigen ausgeführten Befehl an.

  • Hallo VPO,

    ich habe mir Deine ODF angeschaut. Die Fehlermeldungen sind oft so rekursiv verschachtelt wie die ODF selbst. Der Fehler Werteüberschreitung in Abschnitt 'Stop002' Eintrag 'Rank001': 2" heist nicht, dass es im Abschnitt [Stop002] einen Fehler gibt. Nee. Der Fehler liegt im Abschnitt [Rank001] . Das ist zwar klar für GO aber nicht unbedingt für Menschen. Ich habe einfach die Beschreibung des Ranks mit einer Beschreibung von meiner Orgel überschieben. Jetzt ist der Fehler weg! Leider sind sehr viele andere Fehler aufgetaucht, da die wav nicht gefunden werden. Das ist aber zumindest logisch. Schau Dir unbedingt die Abschnitte [Rank001] und [Rank002] an. Da muss der Wurm drin liegen. Abgeänderte ODF habe ich beigefügt.

    Beim einlesen der ODF kann GO die NumberOfXXX selbst zählen.

    Ja stimmt! Das hat mich auch gewundert. Das ist entweder vom Programmierer übersehen worden, oder aber es hat was mit der Art des Einlesens der ODF zu tun. Normalerweise sollte man ja die ODF nicht von Hand schreiben, sondern maschinell machen lassen. Dann ist auch egal was drinnen steht. Leider erschwert dies auch das Verständnis der ODF. Ich hoffe aber, Du läßt Dich nicht von der Komplexität abschrecken, und wechselst wie viele zu Hauptwerk. Ich halte Grand Orgue immer noch für das bessere System, nämlich weil es offen ist.

  • Ein System wird durch OpenSource nicht unbedingt besser. In den Source schaut keiner der Anwender rein, ist für die also kein Mehrwert. Wenn bei GO der oder die Entwickler keine Zeit oder keine Lust mehr haben, dann war es das - ein Nachteil.

    Das Problem ist dann zusätzlich, dass wenn jemand etwas beitragen möchte oft vor einer Wand steht. Mache dir mal den Spaß und schlage im Forum bei Github einen Headless Mode für die Nutzung von GO ohne Display vor und schaue was passiert. Meine Prognose ist eine Diskussion die daran endet das einer der Entwickler es nicht verstehen kann wie jemand so was haben wollen würde.

    dann MUSS es weiterentwickelt werden

    Und wenn er es nicht kann, dann beschafft er sich Entwickler die es können. In einem Projekt wie GO ist man darauf angewiesen dass die wenigen Entwickler gute Programmierer, Physiker und Tontechniker sind. Da dies vermutlich nicht der Fall sein wird, werden einige Punkte wohl nie umgesetzt, nicht weil man es nicht will, sondern weil man es einfach nicht kann.

    Melodeum.de - Wissenswertes zu Harmonium

  • Ja eine Orgel bauen oder simulieren ist eben keine Einmann-Show. Ein fähiger Orgelbauer kann die Orgel mechanisch bauen, aber nicht Intonieren. Der Intonateur kann die Orgel wunderbar intonieren, aber nicht bauen. Der Orgelspieler kann sie in der Regel spielen, aber nicht bauen oder intonieren. Und davor sind ja auch noch Spezialisten die nur in der Lage sind das Material dafür herzustellen.

    Ich durfte beim Orgelbauer unter Anleitung einen Prinzipal selber bauen (als Metaller nicht so sehr neu), aber das intonieren war die Hölle. Aber irgendwo steht nun meine Pfeife und gibt der Orgel ihren Klang mit. Über die 20 Ausschüsse redet aber keiner mehr :) Wenn ich eine ganze Orgel intonieren müsste, das wäre ein Lebensprojekt...

    Melodeum.de - Wissenswertes zu Harmonium

  • den Startschuss für eine neue Software-Spezies ins Leben gerufen haben.

    Wichtig ist auch immer der Grund warum jemand etwas neues erstellt. Ich würde hier mal ein Zitat vom Aeolus Entwickler einstellen weil es ganz gut passt:

    My ambitions for Aeolus ar more modest. . .
    • Not a ’perfect’ imitation or replacement for a real organ.
    • A musical instrument, that can be enjoyed by musicians.
    • Give the user access to all parameters, to
    – modify and adapt the program to his/her own needs,
    – or even define a completey new instrument.
    • Have a framework for future research and development.


    Wichtig ist das man seinen Zielen dann treu bleibt und die Verwirklichung weiter vorauntreibt.

    Melodeum.de - Wissenswertes zu Harmonium