Was, ich wusste ja nicht, dass man die Farben verändern kann...
Meiner Erfahrung nach eine ganz dumme Funktion in einem Forum
Was, ich wusste ja nicht, dass man die Farben verändern kann...
Meiner Erfahrung nach eine ganz dumme Funktion in einem Forum
Hallo, eine Frage, Kann ich die neueste Version unter Windows parallel installieren um sie zu testen?
Danke
Bernd
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
GO kann auf dem selben Betriebssystem immer nur in einer Version verwendet werden. Es ließe sich zwar in verschiedene Verzeichnisse installieren, überschreibt sich dann aber gegenseitig Daten.
Ein Programm wie Sandboxie wäre eine Idee. Da installiert man verschiedene Versionen in unterschiedlichen Sandboxen und sie sehen nur was in ihrer kleinen Welt passiert
Ob GO nun tatsächlich mit Sandboxie läuft weiß ich nicht, müsste jemand probieren. Wer Lust hat nur los, ist kostenfrei: https://sandboxie-plus.com
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!
# herunterladen des Archives für 64-bit Linux (geht auch über den Browser):
$ wget https://github.com/GrandOrgue/grandorgue/releases/download/3.6.1-1/grandorgue-3.6.1-1.linux.x86_64.tar.gz
# entpacken:
$ tar -xzf grandorgue-3.6.1-1.linux.x86_64.tar.gz
# in das entpackte Verzeichnis wechseln:
$ cd grandorgue-3.6.1-1.linux.x86_64
# Verzeichnis für für Config+Cache erstellen:
$ mkdir alt-home
# Umgebungsvariabel $HOME auf das neue Verzeichnis setzen:
$ export HOME=$(pwd)/alt-home
# GrandOrgue starten
$ ./bin/GrandOrgue
Alles anzeigen
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:
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.
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.
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.
BTW wenn du es genau wissen willst
GrandOrgue selbst braucht nur sehr wenig RAM und CPU-Leistung. Diese Ressourcen benötigt das Sampleset, je größer und je mehr Polyphonie gefordert wird, umso mehr. Da ist ein Raspberry Pi sehr schnell am Ende angekommen.
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.
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.
inzwischen gibt es ja fertige Pakete für 64 Bit. Nur wenn du es testet, dann nimmt DietPi. Desktop minimal mit Lxde und laufenden GO braucht etwa 90MB Ram. Zumindest die 32 Bit ARM Fassung hatte bei mir nie gut funktioniert, bzw. mir war die Latenz von 5 Sekunden zu hoch ?
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