• Hallo. Bernd, meinst du eine Windows-Emulation auf dem Mac oder eine zweite Installation auf dem Windows-PC? Die neueste Version liegt ja für verschiedene Betriebssysteme vor.

    Was ich oben beschrieben hab, war die native Mac-Version. Man braucht m. E. keine Emulation (oder ich merk's nicht). Als Standard-/Zweitinstallation auf dem Windows-PC dürfte es die vorhandene Version überschreiben. Aber vielleicht äußern sich die Fachleute hier noch dazu.

    Gruß

    Alf

  • Unter Linux sollte das ohne Probleme auch ohne Sandbox oder Docker-Container, etc. gehen. Man kann nur nicht ohne Weiteres verschiedene Versionen eines Paketes mit den Paketmanagern (snaps mal ausgenommen, aber das sind ja auch keine klassischen Pakete) installieren.

    Wenn man aber die Archive mit den ausführbaren Dateien runterlädst, können diese direkt gestartet werden. Mit geänderter $HOME-Variabel kann man für jede Version die Konfigurations- und Cachdateien in unterschiedlichen Verzeichnissen ablegen.

    Für ein 64-Bit Ubuntu und die aktuelle GO-Version sieht es dann bspw. so aus, die Versionsnummern sind ggf. natürlich anzupassen:

    Bitte zur Sicherheit vorher Backups der Konfigurationsdateien ~/GrandOrgue* anlegen!


    Cache und Konfiguration liegen dann unterhalb des Verzeichnis alt-home, die Konfigurationen können natürlich, soweit unter den Versionen Kompatibel, einfach kopiert/eingefügt werden wie man es braucht.

    Ein normal per Paket installiertes GO wird, soweit ich das bisher beobachtet habe, dabei nicht angefasst. Für die zusätzliche Version werden auch keine Startmenüeinträge oder sonstigen Verknüpfungen im System angelegt, es findet keine "Installation" im klassischen Sinn statt. Man kann sie nur direkt aus dem Verzeichnis starten. Auchtung: Ändert man vor dem Start von GO nicht die die $HOME-Variable (der export-Befehl), so werden für Konfiguration und Cache die Dateien im Home-Verzeichnis genutzt und ggf. überschrieben. Zum Starten also immer ins entpackte Archiv wechseln, Umgebungsvariable neu festlegen und dann GO ausführen:

    Bash
    cd grandorgue-3.6.1-1.linux.x86_64
    export HOME=$(pwd)/alt-home
    ./bin/GrandOrgue


    Will man tatsächlich mehrere Versionen gleichzeitig ausführen, könnte es sein, dass noch ein Wrapper notwendig ist, um eine separate dbus-Session zu starten, dann würde der letzte Befehl dbus-launch ./bin/GrandOrgue lauten. Habe ich aber bisher noch nicht mit GO ausprobiert, könnte auch ohne laufen.

    Edit: Bei den export-Befehlen fehlte der absolute Pfad (der pwd-Teil), GO hat da ein wenig gemeckert im Log, wahrscheinlich wegen PulseAudio. Ist an beiden Stellen ergänzt

  • Hallo,

    ich weiß nicht, ob ich hier mit meiner "Latenz-Demo" (siehe Anlage) falsch lande,

    das Thema ist ja ein alter Hut und im Forum schon so oft mit unterschiedlichesten Aspekten durchgeprochen worden.

    Als Hobby-Orgelspieler hat's für mich bei Orgelsoftware aber ne gewisse Bedeutung - wohl wissend, dass man sowas auch bei mechanischen Orgeln hat, je nach räumlichen Gegebenheiten, von der Latenz des Gemeindegesangs ganz zu schweigen...

    Habe deshalb gerade 'ne dreiteilige Miniaufnahme gemacht:

    Mein Sk1 Hammond-Keyyboard spielt einen 8-Fuß (Pipe Organ Register, kein Sinus-Zugriegel) und dient als Referenz - nicht, weil es besonders gut klingt, sondern weil es eine für mich unhörbare Latenz hat.

    Dazu hab ich über Usb-Midi (nacheinander) immer (nur) ein 2'-Register mit folgenden Apps auf dem Mac M1 mini registriert:

    1. dem Programm Grandorgue...

    2. einer App aus dem Mac Store mit dem Sample einer spanischen Grenzingorgel von einer Firma wohl aus dem Polargebiet... (sorry, Gedankenblitzle)

    3. einer weiteren Church Orgel App aus dem Store (Zielgruppe Bestattungsfirmen?), die m. E. nicht mit Einzelsamples arbeitet (aber ich kann auch irren.)

    Ich will nicht großartig 'ne Bewertung abgeben. Dass Grandorgue hier bei mir schlechter abschneidet, liegt vielleicht auch an meiner Konfiguration...

    (Wenn ich mir vorstelle, wieviel know how hier im Forum verteilt wird, und das open source, werd' ich automatisch bescheiden.)

    Jeder Organist hat seine eigenen Schwerpunkte, was Klang, Vielfalt, Authenzität, Spielbarkeit usw. angeht.

    Grandorgue läuft bei mir noch auf älteren PCs mit Win 7 und MX Linux, aber speziell meine Linux-Kenntniss sind nach dem, was ich so im Forum lese und nicht kapiere, sehr ausbaufähig, gilt erst recht bei Äolus / GrandOrgue auf dem Raspberry.

    Grüße

    Alf

  • Grandorgue läuft bei mir noch auf älteren PCs mit Win 7 und MX Linux, aber speziell meine Linux-Kenntniss sind nach dem, was ich so im Forum lese und nicht kapiere, sehr ausbaufähig, gilt erst recht bei Äolus / GrandOrgue auf dem Raspberry.

    Wenn du Aeolus nutzen willst auf dem Raspberry Pi, dann musst du eigentlich nur das Organnery Image runterladen, auf Speicherkarte schreiben und Stecker einstecken. Dann musst du nichts weiter wissen oder einrichten:

    https://organnery.com/download.php

    GO ist eigentlich auch nicht weiter kompliziert. Paket runterladen und unter dem Raspbian OS doppelklicken und es ist installiert. Ich würde es dir aber nur mit dem 64 Bit Abbild raten, GO für den 32Bit ARM läuft so gut wie überhaupt nicht sinnvoll.

    ich weiß nicht, ob ich hier mit meiner "Latenz-Demo" (siehe Anlage) falsch lande,

    Die Latenz ist ja allgemein eher mäßig bei einer Sample Lösung. Wenn dir die Latenz sehr wichtig ist, dann sind Synthetische Lösungen für dich wohl besser geeignet wie Aeolus aber auch Organteq weil beide bedingt durch die Technik flotter arbeiten können. Wobei die Latenz wohl unterschieden werden muss zwischen technischer Latenz und gefühlter Latenz. Die technische ist ja die Verarbeitung der Informationen da sollten alle in etwa gleich flott sein. Kann natürlich sein, dass die eine Lösung einen besseren Midi Stack hat aber die Unterschiede sollten wirklich im unfühlbaren Bereich liegen. Die gefühlte Latenz ist eher die zwischen Tastendruck und Reaktion die man hört. Da kommt es sehr stark auf das Set an. Ein Dryset ist gefühlt oft flotter und direkter während eins mit Hall schon träger erscheint. Aber auch der Faltungshall kann die Latenz negativ beeinflussen. Zum einen weil es mehr Rechenleistung braucht aber auch der Weg des Schalls dabei eine Rolle zum Zuhörer spielt. Ich spiele daher ungern mit Faltungshall weil es mit zu träge ist. Zumindest in GO und mit meinen Einstellungen.

    Melodeum.de - Wissenswertes zu Harmonium

  • Hallo Haralder, danke für die Infos. Der Raspberri ist zurzeit teuer und fast nicht zu kriegen - aber das klingt interessant, werd mich langsam vortasten. (Hab auch noch 'nen Dongle von einer uralten Hauptwerkversion rumliegen, den ich nicht nützen kann, weil ich das Programm auf dem Laptop zerlegt hab. Weiß nicht mal mehr die Version.)

  • Wenn dir der P400 eine Option ist (Pi 4 mit 4GB und Tastatur) damm bekommst du ihn gerade günstig bei Berrybase https://www.berrybase.de/neu/raspberry-pi-400-de?c=2411 da kannst du neben Aeolus auch GrandOrgue mit vielen Sets nutzen die mit 4GB Ram passen. Die allermeisten z.B von https://piotrgrabowski.pl laufen dort ohne Probleme, dann eben im Zweifel nur mit 16 Bit. Aber da hört man quasi keinen Unterschied.

    Melodeum.de - Wissenswertes zu Harmonium

  • Ich tendiere eher zu Organnery, bräuchte da aber einen 3b oder 3b+:

    "Current image version 0.7.5 is ONLY compatible with model Raspberry Pi 3B ou 3B+, it will NOT boot on other models such as RaspberryPi4"

    Mal schaun, wann die wieder (preislich erträglich) lieferbar sind.

    Für GrandOrgue zögere ich, mir so einen P 400 anzuschaffen, obwohl er aussieht wie mein C64 früher:

    PI 4 Prozessor, Broadcom BCM2711 Chipsatz

    64 bit Quad Core ARM v8 Cortex-A72 @ 1,5 GHz

    Aber leistungsmäßig entspricht der wohl(?) meinem Zotac:

    Intel Celeron N2930 1,83 GHz 4 Kerne 8 GB Ram

    Da läuft zurzeit Win 7, aber ich muss für MX Linux quasi nur die SSD wechseln.

  • Aber leistungsmäßig entspricht der wohl(?) meinem Zotac:

    Intel Celeron N2930 1,83 GHz 4 Kerne 8 GB Ram

    Wohl eher nicht. Dein Celeron wird den Raspberry Pi alt aussehen lassen. Die ARM Prozessoren sind dort eher langsam und der N2930 vs dem Quad Core ARM v8 Cortex-A72 ist eher ein Vergleich wie "Pentium 2 VS I7".

    Aber für GO reicht das vollkommen aus. Eigentlich braucht GO kaum CPU Leistung und ich lehne mich mal aus dem Fenster un behaupte jede ernsthafte CPU der letzten 15 Jahre ist mehr als genug dimensioniert . Der Ram ist eben der limitierende Faktor.

    Melodeum.de - Wissenswertes zu Harmonium

  • Also ich nutze auf meinem P400 mit 4GB Ram die Skrzatusz und Lipiny ohne Probleme, natürlich nur mit 16 Bit. Die Walcker Wildervank läuft z.B ohne Einschränkungen mit 24 Bit. Man muss eben kleine Abstriche machen, aber wenn man schaut das ein Raspberry PI mit 4GB Ram komplett nur rund 60 Euro kostet, dann ist das beeindruckend was man damit schon machen kann. Für Zuhause wenn man nicht die großen Sets spielen will ist es also durchaus eine sinnvolle Lösung.

    Mit den Raspberry Pi Modellen die 8GB haben sollte man noch mehr Möglichkeiten haben. Vielleicht hat der Raspberry Pi 5 ja noch bis zu 16 oder 32 GB Ram. Dann kann man auch größere Sets ohne Probleme nutzen. Was die Prozessorleistung betrifft komme ich außer beim Laden der Sets nicht über 3-5% Auslastung.

    Melodeum.de - Wissenswertes zu Harmonium

    • Offizieller Beitrag

    Deswegen sympathisiere ich ja auch schon viele Jahre mit der kleinen Himbeere. ^^ Was mit dem Raspi 4 inzwischen schon an Samplesets machbar ist, ist echt erstaunlich. Drum habe ich mir auch noch extra die Version mit 8 GB geleistet. Hatte nur noch keine Zeit ihn auszuprobieren. Es ist auch erst ein GO in 64 Bit zu bauen, um mehr als 4 GB RAM verwenden zu können.

  • Endlich hab ich den Zusammenhang Samples pro Buffer und Verzögerung realisiert!

    (Steht auch "irgendwo" im Forum.) Insofern ist meine Aufnahme weiter oben, was GrandOrgue betrifft, Makulatur...)

    Aber ich hätte noch Anfängerfragen:

    - Kommt das Demo von GO mit nur 2 Samples pro Oktave aus? (Ich finde nur wenig Samples pro Register.)

    - Auf den Wavedateien der einz. Töne findet man (z.B. bei Obersuhl) 5 Loops markiert, aber es ist wohl nur einer aktiv. Stimmt das oder werden da je nach Spielweise unterschiedliche Loops angesteuert? (In 'ner Anleitung zu Wavlab las ich, dass auch mehrere Loops ineinandergreifen können um fließende Übergängen zu erzielen. Das dürfte bei Orgeltönen nicht erforderlich sein.)

    (Mein Traum in der Ferne wäre, zunächst mal Registergruppen von der Pfeifenorgel, auf der ich spiele, zu samplen und z.B. mit GO zu spielen. Was das ODF angeht, müsste ich mich wohl als Schmarotzer betätigen. Ich habe noch nie Loops erstellt, bin also noch weit weg von der Praxis und von brauchbaren Ergebnissen.)

  • Aber ich hätte noch Anfängerfragen:

    - Kommt das Demo von GO mit nur 2 Samples pro Oktave aus? (Ich finde nur wenig Samples pro Register.)

    - Auf den Wavedateien der einz. Töne findet man (z.B. bei Obersuhl) 5 Loops markiert, aber es ist wohl nur einer aktiv. Stimmt das oder werden da je nach Spielweise unterschiedliche Loops angesteuert?

    1) Ja, die Demo ist sehr platzsparend gebaut und verwendet die wenigen Samples für viele gespielten Töne.

    2) Beim Laden eines Sets bestimmst du ob alle Loops, oder nur ein Loop geladen werden soll (schau mal unter "Einstellungen" nach "Loop Loading"). Wenn es mehrere Loops gibt, wird m.W. zufällig einer der vorhandenen beim Drücken einer Taste aktiv.

  • (Mein Traum in der Ferne wäre, zunächst mal Registergruppen von der Pfeifenorgel, auf der ich spiele, zu samplen und z.B. mit GO zu spielen.

    Ich denke das wäre bei einem eigenen Set das man aufnehmen will auch am Anfang die einzige Sinnvolle Variante. Ich würde vermutlich beim ersten Versuch mal ein einzelnes Register nehmen und beim untersten Ton anfangen und dann in Quinten die Töne nehmen. Wenn das funktioniert und ich etwas mehr Erfahrung habe, dann wären Terzen vermutlich eine gute Idee und am Ende Einzeltöne jeder Taste.

    Ganz am Anfang würde ich es wohl aber erst einmal mit einem einzelnen Ton versuchen und diesen dann in eine nutzbare Form bringen :)

    Melodeum.de - Wissenswertes zu Harmonium