MIDI-Probleme in neuesten GO-Builds (ab 1600)

  • Hallo an alle,

    zuletzt testete ich die neuesten Builds von GO stets an einem Laptop mit Win7 32bit. Es lief alles bestens. Nun wollte ich an meinen Win7 64bit Rechnern die 64bit-Version installieren, vor allem r1633. Und da begegnete mir ein recht merkwürdiges Verhalten von GO. Zunächst dachte ich, das Problem seien die virtuellen MIDI-Kabel oder die midiox-Einstellungen. Ich testete das uralte MyOrgan – und es lief normal. Vor allem zeigten mir die MyOrgan-Einstellungen die virtuellen MIDI-Kabel so, wie ich es eingerichtet habe. In GO hingegen sowohl beim 32bit – 1633 als auch bei 64bit – 1633 das gleiche, nämlich eine „wundersame Vermehrung“ der virtuellen MIDI-Kabel, wie es im nachfolgenden Photo zu sehen ist.

    Des weiteren wäre dies nicht tragisch, wenn ich nun nicht bei jedem Laden des ODF immer wieder mit Rechtsklick die einzelnen Orgelwerke mit den Klaviaturen verbinden müsste. Zwar behält GO die Einstellung im beschränkten Maß, indem die „note on“-Befehle ausgeführt werden, jedoch nicht die „note off“. Erst die erneute Verbindung mit den Klaviaturen ermöglicht beides, note on und note off.

    Bei meinem Laptop mit Win7 64bit, an welchem die früheren Versionen (unter 1600) liefen, lässt sich im MIDI-Einstellungsmenü keine Änderung vornehmen, ohne dass sich GO „aushängt“ - ebenso lässt sich GO nicht normal abstellen, sondern hängt sich ebenso aus.

    Hat noch jemand solche Probleme mit GO an 64bit Windows7-Rechnern? Und wie kann ich die Probleme lösen? An 32bit Win7-Rechnern habe ich solche Probleme nicht erlebt.

    Gruß an alle

    Felix

  • Zitat

    Original geschrieben von crofelix

    Des weiteren wäre dies nicht tragisch, wenn ich nun nicht bei jedem Laden des ODF immer wieder mit Rechtsklick die einzelnen Orgelwerke mit den Klaviaturen verbinden müsste.

    Felix

    Ja, hier. Dieses Problem hab ich auch. Allerdings arbeite ich hier mit Vista und GO 32-bit.
    Das Problem tritt bei mir mit den Hardware-Midi-Kabeln auf.
    Hab aber noch keine Lösung dazu :(

    Gruß,
    Marcus

    ?️ One chili a day keeps the doctor away!

  • Recht hast Du, Marcus, bei mir ebenso, auch mit den verkabelten MIDI-Verbindungen. Ich habe an verschiedenen Rechnern alles mögliche versucht, ergebnislos. Trotz dem hoffe ich, dass es eine Lösung geben wird. Die früheren fortgeschrittenen Builds haben solche Probleme nicht gemacht...

  • Zitat

    Zwar behält GO die Einstellung im beschränkten Maß, indem die „note on“-Befehle ausgeführt werden, jedoch nicht die „note off“. Erst die erneute Verbindung mit den Klaviaturen ermöglicht beides, note on und note off.

    Da sollte in r1645 behoben worden sein.

  • Hallo Martin,

    bist Du aber schnell!? Gesehen - getestet & Fehler behoben!!! Nun muss ich es an meinem neuen GO-Rechner testen. Am 64bit Win7 Laptop läuft nun alles bis auf die Hänger – ich hoffe, dass ich auch das in den Griff kriege … Cache löschen u.s.w.

    Vielen Dank – hoffentlich lässt die Asio-Version nicht all zulange auf sich warten.

    Herzliche Grüße
    Felix

    PS.

    Übrigens, auch der neue Eintrag im Untermenü mit den MIDI-Objecten finde ich für meine Zwecke optimal. Am liebsten arbeite ich mit Tastaturen, weniger mit Maus. Nun lässt sich mit Doppelklick alles schnell und sauber einstellen. Auch dafür danke ich Dir.

  • Zitat

    In GO hingegen sowohl beim 32bit – 1633 als auch bei 64bit – 1633 das gleiche, nämlich eine „wundersame Vermehrung“ der virtuellen MIDI-Kabel, wie es im nachfolgenden Photo zu sehen ist.

    3x das gleiche USB MIDI Keyboard ist für GO keine ungewöhnlich Konfiguration, daher wird neben den Namen auch noch eine OS spezifische ID herangezogen.(unter Windows die MIDI Port-Nummer).
    Wenn sich die ändert, erkennt GO ein anderes Gerät.

    GO erlaubt das einrichten von mehreren Events, so das du parallel mehrere Bezeichnungen konfigurieren kannst.

  • Ich bin etwas lahm, weil ich erkältet bin...

    Bei wiederholter MIDI-Quelle handelt es sich um midiface 4x4 von miditech, da ich einige Controller zusätzlich verwende (eine kleine Spielerei). Dieselbe bereitete mir keine Probleme.

    An meinem neuen GO-Rechner gibt es keine Vermehrung der MIDI-Verbindungen mehr! Auch die Notenhänger sind weg, note off wird erkannt.

    Auch die Latenz mit dem Direkttreiber von DMX 6fire von Terratec hält sich in Grenzen.

    Du bist echt spitze!!!

  • Zitat

    Am 64bit Win7 Laptop läuft nun alles bis auf die Hänger – ich hoffe, dass ich auch das in den Griff kriege … Cache löschen u.s.w.

    Ich halte es für am wahrscheinlichsten, das ein "Treiber" beim öffnen/schliessen der Audio/Midi Geräte hängen bliebt. Drücke einige Mal den Panic Knopf - das müsste die schnellste Variante sein, den Fehler zu provozieren.

  • Am 64-bit Win7-Laptop gibt es keine Notenhänger mehr. Das ist behoben! Das GO-Programm hängt sich aus, wenn ich das Audio- und Midi-Einstellungsmenü mit OK schließe oder wenn ich GO beenden möchte. Da ich durch die Erkältung leicht behindert bin, werde ich es vorläufig aufgeben. Denn, wenn es an einem anderen Rechner funktioniert, gibt es keinen Grund, dass es am Laptop nicht funktionieren sollte. Am Laptop werde ich nächste Woche GO neu einrichten, und alle alten GO-Builds entfernen. Neu installiert müsste alles funktionieren...

    Gruß und vielen Dank für die Unterstützung
    Felix

  • Hallo Martin,

    sowohl im dänischen Forum als auch in der SF-Developers-Liste werden weitere Probleme mit der ASIO-Version r1633 angesprochen. Diese Version ist wirklich fehlerhaft – die Probleme an meinem Laptop wurden von dieser Version verursacht, so dass ich selbst die vorherige Versionen, die mal lauffähig waren, schwer zum laufen bekomme, und wenn, dann instabil. Auf dem neuen Rechner sah ich „missing required value section manual000 entry 'MIDIKey 001'“, wenn ich die Einstellungen laden wollte. Da ich die Einstellungen zwischen verschiedenen Rechnern und Versionen übertragen möchte, speichere ich die MIDI- und Kombinationen extra. Mit r1633 konnte ich die Kombinationen laden, aber nicht die MIDI-Eisntellungen.

    Die ASIO-unabhängige r1653 funktioniert hingegen fehlerfrei – sowohl die früheren Einstellungen als auch die Kombinationen sind ladbar. Allerdings habe ich ohne ASIO mit Latenzen zu kämpfen, und wundere mich, wieso auf SF eine eindeutig schwer fehlerhafte Version gehalten wird, zumal Lars dazu schrieb: „This is an old bug that should already be fixed in more recent versions.“ Wenn man diese Version nicht updaten kann, wieso wird sie nicht entfernt?

    Auch frage ich mich, mit welchen Einstellungen ich die Latenzen unter 40ms kriegen kann. Ich habe alles probiert, was mir in den Sinn kam, und was ich so las. Vielleicht hast Du einen Tipp, nicht nur für mich. Im voraus danke ich.

    VG – Felix

  • Zitat

    sowohl im dänischen Forum als auch in der SF-Developers-Liste werden weitere Probleme mit der ASIO-Version r1633 angesprochen. Diese Version ist wirklich fehlerhaft – die Probleme an meinem Laptop wurden von dieser Version verursacht, so dass ich selbst die vorherige Versionen, die mal lauffähig waren, schwer zum laufen bekomme, und wenn, dann instabil. Auf dem neuen Rechner sah ich „missing required value section manual000 entry 'MIDIKey 001'“, wenn ich die Einstellungen laden wollte. Da ich die Einstellungen zwischen verschiedenen Rechnern und Versionen übertragen möchte, speichere ich die MIDI- und Kombinationen extra. Mit r1633 konnte ich die Kombinationen laden, aber nicht die MIDI-Eisntellungen.

    Allerdings habe ich ohne ASIO mit Latenzen zu kämpfen, und wundere mich, wieso auf SF eine eindeutig schwer fehlerhafte Version gehalten wird, zumal Lars dazu schrieb: „This is an old bug that should already be fixed in more recent versions.“ Wenn man diese Version nicht updaten kann, wieso wird sie nicht entfernt?

    Der Bug wurde in r1634 behoben und Verursacht beim Laden von alten Einstellungen Probleme. Um die ASIO Builds kümmern sich andere - da das ein Problem wird, habe ich den Build umbenannt.

    Zitat


    Auch frage ich mich, mit welchen Einstellungen ich die Latenzen unter 40ms kriegen kann. Ich habe alles probiert, was mir in den Sinn kam, und was ich so las. Vielleicht hast Du einen Tipp, nicht nur für mich. Im voraus danke ich.


    Samples per Buffer muss natürlich wesentlich kleiner als 1024 werden.

    GO für Windows unterstützt mehrere Audio APIs (WASAPI, DirectSound, WMME, WDM-KS), die man durchprobieren sollte. Weiters nicht vergessen: GO setzt für jeden PulseAudio basierten Treiber eine höhere "desired latency", damit es hoffentlich bei den meisten Anwendern stabil läuft (vgl. Properties vom Audio-Device in GO) - die muss natürlich auch runter.

    Thematisch würde ich es gerne hier weiterdiskutieren:
    http://mps-net.de/orgel/seite/in…ead&threadid=37

  • Danke, Martin! Mit kleineren Werten der Samples per Buffer habe ich nun doch die Latenz im Griff. Zu meiner eigenen Verteidugung muß ich anführen, dass ich die letzte Woche unter starker Bronchitis litt - z. Zt. bin ich in der Erholung, immer noch krankgescrieben...

    Trotz dem die Frage - wo finde ich r1634?

    PS.
    Die Frage erübrigt sich... Das neue Build steht im SF und mit dem r1665 gibt es keine Probleme mehr!

  • Von der r1633 blieb noch ein kleiner Bug selbst in der neuesten Version r1665 stecken – offenbar bloß bei mir, da sich sonst niemand dazu geäußert hat. Deshalb weiß ich nicht, ob es Probleme mit meinen MIDI-Einstellungen gibt.

    Wenn ich GO lade, sowohl mit r1653 als auch mit r1665, scheint zuerst alles normal zu sein. Ich kann an der virtuellen Orgel einige Akkorde spielen. Danach gibt es einen relativ kurzen Hänger, die Tasten des virtuellen Instrumentes bleiben so lange stecken, bis ich sie erneut drücke. Nach 5 bis 10 Sekunden kann ich dann weiterspielen, als ob nichts geschehen wäre. Auch das Laden einer anderen virtuellen Orgel verläuft normal.

    Ich dachte, dass irgendwelche Einstellungen von r1633 im System verborgen sind – deshalb löschte ich alle Einstellungen und Cache von GO. Am Verhalten des Programms änderte das nichts.

    Woher könnte dieses Problem stammen? Ich habe es an allen Rechnern mit GO, also mit unterschiedlichen MIDI-Konfigurationen...

    VG Felix

  • Ich hatte GO-Config vergessen zu löschen. Soeben habe ich alle 3 (Data, Cache und Config) gelöscht. Das Phänomen des kurzen Hängers blieb, allerdings nur beim ersten Start vom Rechner und von GO...

    Die letzte stabile Testversion war r1569, resp. r1613 ohne ASIO.

  • Seit 1613 hat sich zwar einiges geändert, aber mir ist nichts aufgefallen, was dieses Verhalten erklärt.

    Das Verhalten sieht so aus, wie wenn die MIDI Events nicht angekommen/gedropped werden.
    Innerhalb von GO/RtMidi kann das nicht passieren - die Events aus den diversen Queues würden einmal abgearbeitet werden.

    Wenn etwas gedropped wird, halte ich Windows bzw. den MIDI Treiber für den wahrscheinlichsten Ort.

    Ich würde mittels MIDI Monitor mitschauen, ob die Nachrichten überhaupt am PC ankommen bzw. anders sind.

    Man könnte auch GO mit extern abgespielten, ultra schnellen MIDI-Dateien stressen, um festzustellen, ob irgendwo etwas gedropped wird.

  • Bei r1653 gab es eine Aktivität, welche für mich nicht bedeutsam war – einige MIDI-Anschlüsse haben sich verdoppelt, ohne GO unspielbar zu machen, seit r1665 werden hingegen keine MIDI's verdoppelt...

    Ich werde mein MIDI-System nun genauer testen. Allerdings sind alle MIDI-Geräte per USB angeschlossen. Ich hatte die Vermutung, dass es mit der Anmeldung der Geräte zusammenhängt und lade GO erstmals nach dem Hochfahren des Systems mit nachfolgender BAT-Datei:

    @echo off
    timeout 2
    start "loopMIDI" "C:\Program Files (x86)\Tobias Erichsen\loopMIDI\loopMIDI.exe"
    timeout 1
    start /min "midiox" "C:\Users\Public\Desktop\MIDI-OX"
    timeout 3
    start "GrandOrgue" "C:\Program Files (x86)\GrandOrgue1665bit64\bin\GrandOrgue.exe"
    exit

  • Zwei Worte über mein System: Der Rechner wird innerhalb von 9 Sekunden hochgefahren und, dank Deiner Empfehlung mit SSD-Festpatten, brauche ich nur die in der BAT-Datei angegebenen Zeiten mit Timeout abzuwarten. Somit ist GO nach weniger als 20 Sekunden spielbar.

  • Ja, ich verwende MidiOX und LoopMidi. An den Rechnern mit 64-bit funktionieren midiyoke und ähnliche Verbindungen nicht, und unter allen möglichen Verbindungen ist LoopMidi z. Zt. die einzige Lösung, um Registerschaltung zuverlässig zu übertragen.

    MidiOX ermöglicht mir darüber hinaus, MIDI Signale von verschiedenen Quellen mit unterschiedlichen Programmen fehlerfrei zu teilen, wie GO, Sequenzer, Noten- und Midieditoren. Wenn ich nur zwei Programme an eine MIDI-Verbindung anschließe, gibt es Fehlermeldungen am RtMIDI. Außerdem überwache ich zeitweise den Datenfluss der Eingänge und der Ausgänge, und MidiOX filtert ebenso einige überflüssige MIDI-Daten.