Beiträge von martin

    bei GO bin ich jetzt fündig geworden! Man muss unter: Anzeige -Koppeln -Koppeln Pedal - bei Pedal zusätzlich zum Button "BAS" den U.O.Button aktivieren dann geht’s mit dem Manualbass bei GO .

    Add GO: Unison off braucht man nur, wenn das zugewiesene MIDI Signal nicht auf dem zugehörigen Werk in Normal-Lage spielen soll.

    U.O. bei einen Einmanualigen deutet auf ein Verständnisproblem hin. Du weisst den Keyboard NUR den ersten Manual zu - keine MIDI Zuordnung für andere Manuale/Pedal. Dann nutzt du am HW Couplel Panel die BAS Funktion für das Pedal.

    Aber jetzt habe ich ein neues Problem: Kurz vor Ende des Ladevorgangs der Modifizierten Fassung (gleiche ODF) erscheint die Fehlermeldung: "Ladefehler. Zu wenig Speicher - nur Teile der Orgel wurden geladen. Bitte Speicherverbrauch mittels der Sample Ladeeinstellungen reduzieren"

    1. Version (HW-Ordner): Reservierter Speicher 3,906; Mapped Memory 12036,486; Memory Poolsize 3,90 von 20731,514

    2. Version (GO-Ordner): Reservierter Speicher 16187,5 von 16184 (!); Mapped Memory 0,000; Memory Poolsize 16187,5 von 32768

    Was steht als Speicher-Limit in den GO Einstellungen? Hast du den Speicher seit der GO Inbetriebnahme aufgerüstet - das Limit wächst da nicht automatisch mit.

    PS: Wenn nur Teile geladen werden, wirkt der Cache nicht voll (genauso wie beim ersten erfolgreichen Laden). Du musst eine Einstellung finden (wahrscheinlich von 16 GB Limit auf 30 GB Limit gehen - ansonsten im Organ-Dialog die Ladeeinstellung von Orgelteilen reduzieren), die vollständig ladet.

    Wenn das Lauchpad nur einen USB Ausgang hat, wir es nur kompliziert in den MIDI Merger kommen (dh. PC müsste per MIDI Out Daten senden).

    Wenn die beiden PCs in einen Netzwerk sind, kannst du aseqnet (Teil von ALSA) virtuelle MIDI Leitungen zwischen den PCs über das Netzwerk legen.

    GO sollte diese erkennen und darauf senden/empfangen können.

    Mit aconnect könnte man bei Bedarf eine Weiterleitung zwischen virtuellen und echten MIDI Port machen.

    Wenn du im Betriebsystem eine virtuelle MIDI Port anlegst und mit einer externen MIDI Software beschickst, hast du vollen Möglichkeiten des GO MIDI Matching zur Verfügung.

    Der GO interne MIDI Player kann bei Aufnahmen vom GO MIDI Recorder mit den gleichen Sampleset die Registierung mitabspielen - das läuft über eine Menge von Sampleset und GO spezifisichen MIDI Nachrichten. Die Detailsemantik ist noch nicht abgeschlossen/100% fix/kann noch geändert werden - daher gibt es keine Schnittstellenbeschreibung.

    Ein GO MIDI Recording besteht aus einer größeren Menge von Setup Nachrichten [für ein spezifisches Sampleset] und dann folgt die eigentliche Aufnahme. Was über welche Nachricht genau gesteuert wird, hängt vom Setup-Teil ab (dh. eine Mapping-Tabelle kannst du nur für das Set von Setup-Nachrichten machen). Die Register-Steuerung selbst läuft Größtenteil über NRPN ab.

    Es ist illusorisch, ein vollständiges, konformes Set an Setup-Nachrichten selbst zusammenzustellen - da muss man eine GO MIDI Aufnahme weiterbearbeiten. Am besten nimmst du was auf, wo du alle releventen Steuerelemente in einer bekannten Reihenfolge (vielleicht mit einer Noten als Referenz-Punkten dazwischen) betätigst - damit du leicht zu einer Referenz kommst, was was ist.

    Es gibt am Markt (billige) MIDI Interfaces, die fehlerhafte MIDI Daten liefern - in den diversen Foren findet man einige Threads dazu.

    Welchen Tastendrücken entspricht das MIDI Log oben?

    Nimm mal einen MIDI Monitor (egal ob GO intern oder extern) und versuche herauszufinden, was als Ein- und Aus-MIDI Nachricht für die einzelnen Tasten kommt.

    Wenn nur die value bei "Aus" immer etwas höher als 0 ist, wird man das Problem lösen können.

    Eine nichtinitialisierte Variable halte ich für unwahrscheinlich - da sorgt schon ganz viel C++ Code dafür.

    GO erfordert ein explizites Speichern, wenn Änderungen aufgehoben werden sollen. Man soll gefahrlos Dinge ausprobieren können und sich nicht ungewollt Einstellungen dauerhaft zerstören können [zB: Stichwort: Setzerbenutzung wenn man Set aktiviert hat - da ist mal schnell etwas geändert]. Wenn der Benutzer sich sicher ist, dass die Einstellungen OK sind, soll er explizit (auch per MIDI) speichern.

    Ein Beenden von GO steht [auch wenn es einen Menüeintrag dazu gibt] nicht im Zielbild - GO ist dafür geplant, dass man ohne Shutdown einfach den Stecker zieht.

    Relevant für die Ladezeit ist nur das GO Cache Verzeichnis - das sollte auf den schnellsten Datenträger liegen. Das Sampleset selbst kann ruhig auf einen langsamen Datenträger liegen. Der Cache entspricht der Kopie, die du erwartet hättest.

    Es gibt 2 GO Formate:

    - *.orgue Files - die kann man direkt nutzen (Über den Install-Befehl registrieren oder einfach im Organ Package Verzeichnis ablegen).

    - Klassische Samplesets zum selbst Entpacken - da gibt es nichts zu installieren.

    Die Dateiauswahl sollte per Default nur den jeweils passenden Dateityp zur Auswahl anbieten. *.organ sollte bei "Install Organ" nicht zur Auswahl bereit stehen..

    Bezüglich hängender Pedal-Töne: Nimm einen MIDI Monitor (zb MIDI Ox oder das MIDI Event Logging von GO) und beobachte, ob bei einem Hänger auch wirklich ein Note Off ankommt.

    Wenn nicht, musst du im Bereich Orgel/MIDI Interface nach Fehlern suchen. Ansonsten wird der Fall für mich interessant.

    PS: Wenn Tönen auf einem Manual/Pedal generell hängen bleiben und man die MIDI Zuordnung händisch gemacht hat, sollte man das MIDI Learning ("Listen for Events") nutzen.

    Die Meldung ist etwas merkwürdig. Würde auf einen falschen Wert in der GrandOrgueConfig-Datei hindeuten. Mir ist nur unklar, wie der dort hineingeschrieben werden kann.

    Der interne MIDI Player ist für die Wiedergabe von GO MIDI Recording ausgelegt - vor allem mit selben Sampleset unter Beibehaltung der Registrierung. Bei Dritt-MIDI Dateien gibt es nur eine fixe MIDI Kanal-Zuordnung.

    Volle Flexibilität bei der MIDI Zuordnung hat man nur, wenn man den MIDI Datenstrom über ein (virtuelles) MIDI Port an GO schickt.

    PS: In GO gibt es allerlei Koppeln auf den diversens Panels inkl. unison off (U.O.) Damit kann man beliebige Manual-Wechsel erreichen.

    Bitte nicht zu viel auf die Speicherverbrauchswerte geben. Die Frage ist immer, was wie gezählt wird. GO braucht auf allen Systemen ungefähr die gleiche Menge an Speicher, um ein Sampleset zu laden [beim GO Basis-Programm mag es unterschiede geben].

    Die Zahl 2 MB für Linux sagt klar aus, das der Cache nicht in deiner Speicherstatistik mitgezählt wird (wahrscheinlich weil es ein Memory-Mapped File ist).

    Nach euren Beiträgen habe ich gestern nochmals die Einstellungen angeschaut. Hatte den Cache auf die schnelle Platte ausgelagert und die CheckBox "Automatically manage Cache " aktiviert. Darunter kam es zu den fast 90 sec. Wartezeit für die Friesach.

    Habe gestern mit verschiedenen Einstellungen Versuche gemacht. Und siehe da: Es lädt alles Prima

    CheckBox Cache komprimieren: 35 sec

    CheckBox Perfom strict ODF :26 sec

    und jetzt kommt das Verrückte: Checkbox Automatically manage Cache: Jetzt plötzlich 32 sec.

    "Strict ODF" sollte nichts mit der Ladeperformance zu tun habe. In der ersten Sekunde vom Laden werden da Fehler geprüft oder eben nicht.

    Cache komprimieren lädet weniger Daten - aber die CPU hat viel mehr zu tun.In SSD Zeiten macht diese Option nicht mehr viel Sinn.

    GO nutzt beim Laden das (unkomprimierten) Cache Memory Mapping: GO sagt im wesentlichen nur "Lade", den Rest macht das Betriebsystem im Hintergrund. Da wäre ein Vergleich mit Linux sicher interessant.