Posts by martin

    Your computer should do the same as any expander: Receive MIDI events from the organ MIDI out and send the audio signal to any kind of speakers.


    In your case, connect organ MIDI out to MIDI in of your PC and PC midi out to the organ audio in. If the audio in is intented for an expander, it should mix the external audio signal with the organ sound.

    Habe gerade getestet auf einen GO 2242+patches - lädt problemlos.


    1) Überprüfe mal die Prüfsumme der Download-Datei - soll steht beim Sampleset download
    https://help.ubuntu.com/community/HowToMD5SUM
    2) Entpacke das Download-File nochmal in ein zweites Directory und vergleiche beide:
    https://apps.ubuntu.com/cat/applications/kompare/
    3) Computer sind nicht perfekt und können Fehler produzieren
    https://wiki.ubuntuusers.de/memtest/
    Bei merkwürdigen Verhalten würde ich es 2-3x den Speicher checken lassen. Wenn memtest etwas findet, sollte dein Vertrauen in den Rechner nachhaltig gestört sein.


    Bei 1 wäre es normal, wenn die Prüfsumme nicht stimmt, weil die Datei zu klein ist, weil der Download abgebrochen ist. Ansonsten dürften heutzutage auch bei 1+2 keine weiteren Verfälschungen mehr auftreten.
    Wenn doch, gibt es irgendwo einen schleichenden Defekt. Zum Testen ob, Software oder Hardware daran schuld ist, würde ich noch ein aktuellen OpenSuSE Leap 42.X installieren [ohne proprietäre Treiber]. Wenn beide Linux-Installation das gleiche Verhalten zeigen, ist es die Hardware.

    GO versteht auch PGM-Change (Stimmauswahl vom Keyboards) und kann auch mehr als ein 1 MIDI Event pro Element.


    Nutze auch "Log MIDI Events" in GO um auszuprobieren, was MIDI Nachrichten schickt.

    Ich tue mir etwas schwer mit der Interpretation. Note on/off Nachrichten von Kanal 3 haben das Muster 83/93 00-7f 00-7f. D3, C3, B2 passen da nichts in Bild. Man müsste ausprobieren, wofür D3, C3 & B2 stehen (ich nehme an die Tonhöhe).


    Schau dir den Zeitverlauf an:
    Zwischen den ersten und zweiten Note-On liegen 20ms, das dritte kommt erst 20ms später.
    Unter der Annahme, das meine Annahme von oben stimmt, würden die Tasten prellen.


    Ferndiagnosen sind schwer.


    Lass deinen MIDI Monitor live laufen und drück 3 Tastern herunter. Wenn es zu keinen Prellen kommt, hast du für jede Taste genau ein Note on und beim Loslassen ein Note off.
    Wenn du mehere gleichzeitig drückst/lossläst, sollte der Zeitabstand zwischen den Events für einzelnen Tasten minimal sein. Mach immer mehrere Versuche.


    Vergleiche es auch mal mit deinen MIDI Keyboard.


    Max ein paar MS unterschied zwischen den Tastendrücken ohne Prellen sind ideal.
    Ich habe mal 5 Tasten gleichzeitig bei einen MIDI-Keyboard getestet - kein Prellen (dh. nur 5 On und 5 Off-Nachrichten) und 0.5ms Abstand zwischen den einzelnen Note On bzw. Note off Events.

    Nimm einen MIDI Monitor Software mit genauer Timestamp-Anzeige [bzw. mach Aufnamen mit einen Sequenzer]. Drücke ein paar Tasten nebeneinander gleichzeitig - Eventuell stell ein Buch auf die Tasten und drücke es hinunter, damit man einen noch gleichmäßigeren Druck hinbekommt.


    Im MIDI Monitor (bzw. in der Aufnahme) vergleiche dann die Timestamps.

    Eine wunderbare Speichervermehrung gibt es leider nicht - den Arbeitsspeicher müssen sich die Instanzen teilen.


    Die Nutzung ist einfach: Ober den -i Kommandozeilen-Parameter einen Instanznamen übergeben.


    GO man page:

    Mein Empfehlung:
    * Aktuelles Raspian verwenden
    * Debian Source-Packet herunterladen und mittel dpkg-buildpackage rekompilieren


    Ein paar Hinweise, wenn man alte Anleitungen nutzt:
    * Der GCC für ARM von aktuellen Distributionen ist aktuell genug - dh. kein Anpassen der GCC Version mehr nötig
    * GO ist auf mehrere Binary-Pakete, die man alle gemeinsam installieren muss.


    PS: Wenn du Fehlermeldungen postest, kann man dir vielleicht helfen.


    PPS: Für OpenSuSE am Pi https://en.opensuse.org/HCL:Raspberry_Pi3 gibt es auch vorkompilierte Binaries (https://build.opensuse.org/pac…248:grandorgue/grandorgue aarch64).

    Quote


    Ich habe die Samples pro Puffer auf 128 gestellt... das hatte zur Folge, dass GO abstürzte. Sich aufgegangen hat. Ich habe dann schrittweise wieder auf 1024 erhöht, jetzt geht es wieder. Zeitweise habe ich manchmal noch ein ganz leichtes Knacken , das muss ich nochmal beobachten.


    Crash sollte nicht vorkommen. Ubuntu ergänzt Prozesse zur Laufzeit (Globale Menüs, Pulseaudio), also ist schwer vorherzusagen, was daran schuld ist.


    Um Informationen über einen Absturz zu sammeln:


    Debugger installieren:

    Code
    1. apt-get install gdb


    In einen Terminal eingeben:

    Code
    1. gdb /usr/bin/GrandOrgue
    2. run


    Jetzt dieses GO zum Absturz bringen. Dann eingeben:

    Code
    1. thread list
    2. thread apply all bt


    Die Terminal Ausgaben in eine Text-Datei kopieren und mit bitte zukommen lassen.

    Quote

    Original geschrieben von the_revelator
    2.
    Ich betreibe es ja (noch) mit Linux, da wird dann wohl nicht Windows Direct Sound stehen, aber etwas entsprechendes.


    Für Linux sollte es über ALSA laufen (Jack geht auch).
    Achtung: Viele Distributionen routen per Default auch die ALSA Sound-Ausgabe auch über PulseAudio.