Beiträge von martin

    Ein Bug ist mir aufgefallen, der nur Neuinstallationen betrifft.

    Schau bitte nach, ob es in den GO Settings eine Audio-Gruppe gibt. Wenn nicht, leg eine mit beliebigen Namen an und auf den Audio Output Tab mach ein Revert to Defaults.

    Deine Fehlerbeschreibungen sind sehr knapp, was eine Ferndiagnose nicht erleichtert.

    Mir war nicht bewusst, das dieses ODF eine geteilte Schleife realisiert - das wäre aber eine super Erklärung, wieso kein Ton erklingt. Also alle Register ziehen und mehrere Töne auf alle Manualen per Maus aktivieren.

    Ein aktuelles GO mit Demo-Set ohne ASIO Support:
    http://download.opensuse.org/repositories/h…/openSUSE_13.1/

    In den GO Settings gibt es eine Einstellung für den maximal genutzen Speicher. Wenn du das Laden abbrichst, kannst du dann in den GO Audio/MIDI Einstellungen das Limit ändern (senken).
    GO versucht bis zum Limit agressiv den Speicher vollzustopfen - wenn der Speicher zu voll wird, kann Windows viel mit sich selber beschäftigt sein. Wenn man die Auslagerungsdatei abdreht, hat Windows weniger Möglichkeit zum Trashing.

    Technische Limits für Sampledaten:
    32 Bit GO auf 32 Bit Windows: max 2GB (mit 3GB Bootswitch 3 GB)
    32 Bit GO auf 64 Bit Windows: max 3GB
    64 Bit GO auf 64 Bit Windows: im Moment auf einen PC nicht erreichbar.

    Checklist:
    * Irgendwelche Meldungen von GO, das es ein Problem mit der Soundausgabe hat?
    * Lautstärke in GO zu klein eingestellt?

    Wenn GO intern Sound produziert (dh. ein Register gezogen und eine Taste gedrück), bewegt sich die Lautstärke Anzeige oben in GO.

    * PC gibt Töne von sich (zB: beim Hochfahren)
    * Passender Soundkarten Eintrag in GO Audio/MIDI Einstellungen gewählt (versuch einmal etwas DirectSound im Namen)

    Für die Zuweisung von MIDI Elementen:
    * Sicherstellen, das das MIDI Interface von Windows erkannt wird (dh. sein Treiber installiert ist) Es wird dann auch in den GO Audo/MIDI Einstellungen aufgelistet
    * Dann einfach Rechst-Klick auf das Manual/Register/.. in GO und dann ein Detect Complex MIDI Event + OK. Hinweis: Bei der Zuweisung von Manualen mittels Detect Complex MIDI Event machen viele nicht genau das, was gefordert ist und haben dann ein nicht erwartes Verhalten von GO - dann hilft "Listen for Events".

    PS: Du kannst überzählige Manual-Testen wie auch viele andere Keyboard Steuerelemente diversen Schaltern von GO zuweisen.

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Drückst du die Tasten auf den Manuals am GO Bildschirm oder auf deinen MIDI Keyboard?

    Wenn der Empfänger kooperativ ist und die Datei in einen für dich lesbaren Format abspeichert, schon :D

    Das Problem ist nur, wenn dir mehrere User Änderungen als xls schicken, wirst du beim Zusammenführen eine Menge Arbeit haben.

    Bei der Methode mit den Foren-Posts musst du jedes Feld einzeln abschreiben/kopieren.

    An eine webbasierte Erfassung gedacht (Google spuckt da phpmyedit bzw. phpMyDataGrid aus) - mit regelmäßigen Sicherungen, falls ein Unglück bzw, Vandalismus passiert.

    Zitat

    Ich meine genau da liegt der Haken. Die verwendeten Library-Funktionen müssen jeweils abgestimmt sein auf den Prozessor der verwendet wird. Die Quad-Core-CPU vom Raspi 2 kann wohl grundsätzlich den Code für Raspi 1 noch verarbeiten, aber die gelinkten Libraries gehen nur von einem Single-Core aus, weswegen die übrigen drei Cores dann nicht verwendet werden. Möglicherweise würde es also reichen den compilierten Code zu belassen und nur die passenden Bibliotheken für Quadcore dazuzubinden. Allerdings würde ich doch auch gerne eine aktuelle GrandOrgue Version einsetzen wollen, weswegen das Neucompilieren sicher auch nichts schadet.

    Man sollte GO neu kompilieren, weil der letzte Build hier schon etwas alt ist.

    So es nicht jeweils eine extra Raspian Version für den PI 1 und den PI 2, wäre der GO Build äquivalent - egal ob er auf einen Pi1 oder Pi2 erstellt wurde.

    PS: Multi-Threading ist selbst auf Single-Core Linux Systemen "Pflicht".

    Die Nutzung von GCC 4.7 unter Debian wheezy ist kein Problem. Die Anpassungsanleitung von debian/rules + debian/control habe ich in diesen Thread auf Seite 2 gepostet.

    Zu Debian Jessie: Das hat nur mehr wxWidgets 3.0. Ab GO 1916 ist das Debian Packaging für Jessie (wx3.0) umgestellt.

    Also GO hätte schon die Möglichkeiten:

    Per Pipe999....AttackVelocity kann man Samples je nach Anschlag auswählen.

    Die Lautstäre-Anpassung von Tastengeräusch geht mittel MinVelocityVolume, MaxVelocityVolume (auch mit Pipe999...).

    Das konkrete Laptop Modell ist egal.

    Der Laptop muss etwas mehr RAM haben, als wie das Sampleset groß ist.
    Schnelle Platte bzw. SSD bedeutet kürzere Ladezeit.
    Der Prozessor sollte eher leistungsfähig sein. Du brauchst eine umso stärkere CPU, je mehr Polyphonie GO liefern soll. Die Anforderungen an die Polyphonie steigen, je mehr Register du gleichzeitig ziehst und je mehr Hall das Sampleset hat.

    Detect Complex MIDI Event soll die MIDI Events von gängigen Geräten richtig erkennen. Da gibt es eine Reihe von Merkwürdigkeiten (wie man an den diversen Event-Typen erkennen kann). Die Erkennungslogik ist ein Kompromiss, der diverse Annahmen enthält.

    Wenn es Erkennungsprobleme bei "releventen" Geräten gibt, schaue ich mir die Sache an, ob/wie man etwas verbesseren kann.
    Wenn man bei Eigenentwicklungen unbedingt ein bestimmtes Nachrichtenformat will und die Logik es nicht richtig erkennt, kann man entweder die erkannten Einstellungen nachbessern oder auf ein anderes Nachrichtenformat wechseln.

    PS: Genug Platz bieten RPNs/NRPNs [für On/Off] bzw. PGM Change (mit Bank Select LSB/MSB) [für Push-Buttons].