Mini-Computer für GO (wenn möglich unter Linux)

  • Hallo,

    für einen kleinen Spieltisch mit wenig Platz im Gehäuse benötige ich einen Mini-Computer. Es werden eher kleinere Sample-Sets installiert.
    Bei der Recherche bin ich auf folgenden Mini-Computer "NUC" von Intel gestoßen, der mir sehr zusagen würde. Diese NUCs sind sehr leise und haben auch sehr gute Bewertunen. Es wird in Kürze ein neues Modell herausgebracht mit Intel-Prozessoren der 5. Generation (i5-5250U):
    http://www.intel.de/content/www/de…pecs-guide.html

    Meine Frage nun: Könnte mal jemand (wohl am besten martin) über die technischen Daten schauen, ob die Komponenten LINUX-kompatibel sind? Wenn ja, würde ich mich es wagen, das Ganze mal auf Linux zu installieren - ansonsten wirds halt Windows werden (kostet halt ne Lizenz)

    Gruß
    Stephan

  • Hast du schon einmal ins Spezifikations-PDF von Intel geschaut?
    Dort steht bei Modellen "Linux compatibility".

    Wie ich schon an anderer Stelle geschrieben habe, Intel Desktop CPUs, HD Grafik, Desktop Chipsatz, Netzwerk-Karten haben einen guten Linux Support (Bei den embedded Produkten von Intel muss das nicht so sein, da muss man genauer prüfen).

    Einzig wenn das Gerät zu neu auf den Markt ist und die Treiber noch nicht in der aktuellen Release der Distribution gelanden sind, könnte es Probleme geben. Dann muss man auf die Entwicklungsversionen der Distribution zurückgreifen oder bis zum nächsten Release warten.

  • so, für ein kleines Truhenorgelprojekt hab ich mir jetzt den NUC5i5RYH geordert. Gibts hier bei notebooksbilliger
    Laut Intel ist dieses Modell Linux-tauglich - hoffentlich! Ich möchte das ganze rein mit GrandOrgue realisieren.

    Zum Einsatz sollen folgende Sample-Sets kommen (direkt am Spieltisch umschaltbar):
    - Prospectum Truhenorgel St. Maria Nordheim
    - Prospectum Silbermann Zöblitz
    - Sonus Paradisi Velesovo
    - Sonus Paradisi Cembalo Ruckers

    Ich hoffe, das macht der i5 alles schön mit und möglichst mit interner Soundkarte.
    Gibt es Empfehlungen für eine USB-MIDI-Schnittstelle für Linux?
    Wegen mangelhaften Linux-Kenntnissen möchte ich die Live-CD testen und dann auf die SSD installieren. Wichtig wäre mir auch noch, daß ich dir Orgel einfach mit einem Netzschalter ausschalten kann, ohne das das System Probleme macht. Windows mag das ja gar nicht, aber hab noch im Hinterkopf, daß GrandOrgue-LiveCD so konfiguriert ist, daß es problemlos möglich ist!?

    Werde darüber weiter berichten...

    Gruß
    Stephan

  • Linux bringt einen USB MIDI Treiber mit, der alle class-compilant Devices [dh. was der USB MIDI Spezifikation entspricht] unterstützt. Das Interface sollte eine (funktionsfähige) Firmware enthalten, da man sich sonst diese erst besorgen muss.

    http://alsa.opensrc.org/USBMidiDevices

    Die Power-Off Funktion in GO Live ist als "Strom-Aus" realisiert - nicht als Herunterfahren. Der Live-Installer schlägt als Dateisystem xfs vor - das sollte man dafür beibehalten.

    Das ist aber nur für den regulären Betrieb [alles fertig installiert, man ändert nur noch die Konfigurartion in GO].
    Nach Updates sollte man das System noch ein paar Minuten laufen zu lassen bzw einmal "sync" einzugeben.

  • Hallo,

    NUC angekommen, 8 GB RAM rein, SSD rein, USB-E-MU-MIDI-Schnittstelle rein, GO-Live-CD rein, angeschaltet, SuSE fährt hoch, GO fährt hoch, Demo-Sample wird geladen, Soundkarte erkannt, MIDI-Schnittstelle erkannt -> WOW!!

    Martin, vielen Dank für deine Arbeit!

    Hab gleich noch den Live-Installer gestartet und das ganze auf SSD verbannt. In 10s ist nun der NUC mit GO und Demo-Sample gestartet.
    Musste nun natürlich gleich noch einen wichtigen Punkt ausprobieren: Im BIOS unter Powermanagement einstellen, daß der NUC bei Stromwiederkehr sofort hochfährt. Dann hab ich mal alles gestartet und den Netzstecker gezogen. Eingesteckt und er fährt ohne Meckern wieder hoch.

    Also, sieht schon ganz toll aus, der NUC mit GO. Bin jetzt mal auf die Latenz mit der internen Soundkarte gespannt, hab gerade noch keine MIDI-Tastatur zur Hand...

    Gruß
    Stephan

    • Offizieller Beitrag
    Zitat

    Original geschrieben von stephan

    In 10s ist nun der NUC mit GO und Demo-Sample gestartet.
    Musste nun natürlich gleich noch einen wichtigen Punkt ausprobieren: Im BIOS unter Powermanagement einstellen, daß der NUC bei Stromwiederkehr sofort hochfährt. Dann hab ich mal alles gestartet und den Netzstecker gezogen. Eingesteckt und er fährt ohne Meckern wieder hoch.


    Da kommt schon Freude auf, wenn sich der Spieltisch verhält wie eine Orgel:
    Einschalten - kurz darauf Spielen - Klack Ausschalten - fertig

    Das funktioniert bei mir jetzt schon über zwei Jahre ohne Probleme. Einzig schade, als ich unlängst GO updaten wollte, stellte sich raus, dass meine Linux-Version inzwischen veraltet war und deswegen GO nicht upgedatet werden konnte. Beim Update von Linux ging dann leider einiges an den Einstellungen von Linux flöten. Das hat unnötig Nerven gekostet. Also damit leider doch etwas eingeschränkte Langzeit-Anwendertauglichkeit. Andererseits gibt es für Sakralorgeln meistens auch kein Update der Betriebssoftware und man muss eben mit dem Stand leben.

    Manche SSDs können wohl bei dieser Betriebsweise Schaden nehmen: siehe hier

  • Zitat

    Einzig schade, als ich unlängst GO updaten wollte, stellte sich raus, dass meine Linux-Version inzwischen veraltet war und deswegen GO nicht upgedatet werden konnte.

    Ich produziere Linux-Builds nur für Distributionen, die noch Support haben.
    In der Regel kann man das Source-Packet auch für ältere Distributionen selbst kompilieren. Es muss aber ein CMake 2.8 und wxWidgets 3.0 vorhanden sein [ wx < 3.0.2 verursacht Bugs - ob ein für einen selbst störender Bug verursacht wird, muss man ausprobieren].

  • Zitat

    Hab gleich noch den Live-Installer gestartet und das ganze auf SSD verbannt. In 10s ist nun der NUC mit GO und Demo-Sample gestartet.

    Da hätte ich noch eine geniale Optimierungsmöglichkeit:

    Mach ein terminal auf, gib "su" ein.
    Dann mach
    leafpad /etc/default/grub
    Ändere GRUB_TIMEOUT=8 auf =1

    Dann gibt ins selbe Terminal ein:
    leadpad /boot/grub2/grub.cfg
    Ändere wieder "set timeout=8" auf =1.

    Solle 7 Sekunden Bootzeit einsparen :D

    PS: Genau arbeiten. Sonstige Änderungen führen wahrscheinlich zu einen Boot-Fehler. Das System ist aber noch neu, so das eine Reinstallation möglich ist.

  • Zitat

    Also, sieht schon ganz toll aus, der NUC mit GO.

    GOLive ist ein eingeschränktes Linux-System. Es ist im Moment nur vorgesehen, das man Samplesets über den Browser über ein DHCP-fähiges LAN downloaden kann.

    Der Filemanager hätte angeblich Unterstützung für Windows Netzwerk-Freigaben. Es gibt dort den Menüeintrag Network - eventuell findet der einen lokalen PC. Wenn nicht könnt man noch die Eingabe von smb://<IP-Addresse bzw. Hostname>/ im Filemanager versuchen. Wenn der Zugriff klappt, kann man auch von dort auf die Platte kopieren. Falls du da etwas ausprobierst, wäre ich am Ergebnis interessiert.

    Eine Enduser-freundliche Variante zum Zugriff auf Wechseldatenträger ist nicht vorgesehen. Man kann über den Yast zwar mounten, das sollte man vor den Abschalten/Reboot aber wieder ungeschehen machen, da ein nicht entfernter Wechseldatenträger zu Bootproblemen führen könnte.

  • vielen Dank, Martin!
    Ich hab die Zeit vom Bestätigen des Boot-Managers (der am Anfang tatsächlich 8s runterzählt) gemessen. Das Zählen ist nun tatsächlich weg und er startet gleich durch.
    Allerdings braucht der NUC bis das BIOS geladen ist bis zur Anzeige des Bootmanagers ebenfalls 10s. Muss mal nachlesen, von anderen BIOSen kenn ich eine Option "QuickBoot", vielleicht gibt es die da auch irgendwo...
    Aber echt genial schnell und ohne zusätzliche Lasten :)

    Gruß
    Stephan

  • Ist das Booten von anderen Geräten als von der Festplatte abgedreht?

    Kannst du in einen Terminal noch eingeben:

    Code
    su
    systemd-analyze time
    systemd-analyze blame


    und den Output posten? Mich würden die Timing-Daten interessieren.

  • Hallo Martin, hiermal die gewuenschte Ausgabe:

    systemd-analyze time:
    linux:/home/grandorgue # systemd-analyze time
    Startup finished in 1.758s (kernel) + 431ms (initrd) + 30.738s (userspace) = 32.928s

    dann
    system-analyze blame:
    30.050s wicked.service
    350ms home.mount
    209ms dev-sda1.device
    82ms display-manager.service
    28ms systemd-udev-trigger.service
    19ms systemd-fsck-root.service
    17ms systemd-modules-load.service
    15ms tmp.mount
    14ms dev-mqueue.mount
    14ms systemd-journald.service
    13ms systemd-sysctl.service
    12ms wickedd-dhcp4.service
    11ms wickedd-auto4.service
    11ms sys-kernel-debug.mount
    9ms console-kit-log-system-start.service
    9ms systemd-udevd.service
    7ms rc-local.service
    7ms kmod-static-nodes.service
    7ms systemd-random-seed.service
    6ms systemd-udev-root-symlink.service
    6ms systemd-readahead-collect.service
    6ms alsa-restore.service
    6ms wickedd-nanny.service
    6ms wickedd-dhcp6.service
    6ms systemd-readahead-replay.service
    5ms systemd-fsck@dev-disk-by\x2did-ata\x2dM4\x2dCT128M4SSD2_0000000011380319CCAA\x2dpart2.servi
    4ms wickedd.service
    3ms systemd-user-sessions.service
    3ms systemd-remount-fs.service
    3ms systemd-readahead-done.service
    2ms systemd-tmpfiles-setup-dev.service
    2ms systemd-tmpfiles-setup.service
    2ms systemd-update-utmp.service
    2ms systemd-update-utmp-runlevel.service
    1ms systemd-rfkill@rfkill1.service
    1ms systemd-rfkill@rfkill0.service

    was kannst du da jetzt genau rauslesen?

    Gruß
    Stephan

  • Zitat

    Original geschrieben von mike
    ... Beim Update von Linux ging dann leider einiges an den Einstellungen von Linux flöten. Das hat unnötig Nerven gekostet. Also damit leider doch etwas eingeschränkte Langzeit-Anwendertauglichkeit. Andererseits gibt es für Sakralorgeln meistens auch kein Update der Betriebssoftware und man muss eben mit dem Stand leben.


    Hmm, ich stell mir das in Zukunft so vor: Wenn eine neue Live-CD mit neuer GO rauskommt würde ich mir die 3 Ordner "GrandOrgue" "GrandOrgueCache" und "GrandOrgueData" sowie die GrandOrgueConfig sichern und dann den LiveInstaller alles neu aufsetzen lassen. Danach wieder die Ordner zurücksichern, geht das nicht?

    Da stellt sich nun mir auch die nächste Frage:
    In welches Verzeichnis muss ich die entpackten Daten (von Hauptwerk) reinkopieren und wo kommt die .organ ODF-Datei rein, damit sie GO auch als installierte Orgel erkennt?
    Es ist eine Demo-Orgel installiert (welche von Lars ist das überhaupt, klingt gar nicht übel!), aber ich finde in allen 3 Verzeichnissen keine Installationsdaten dieser Orgel??

    Gruß
    Stephan

  • Zitat

    Original geschrieben von stephan
    Hmm, ich stell mir das in Zukunft so vor: Wenn eine neue Live-CD mit neuer GO rauskommt würde ich mir die 3 Ordner "GrandOrgue" "GrandOrgueCache" und "GrandOrgueData" sowie die GrandOrgueConfig sichern und dann den LiveInstaller alles neu aufsetzen lassen. Danach wieder die Ordner zurücksichern, geht das nicht?

    GrandOrgueConfig enthält die globalen GO Einstellungen.GrandOrgueData die orgelspezifischen Einstellungen.
    Beides zusammen ist relativ klein.

    GrandOrgueCache gehört nicht gesichert. Der Inhalt wird vom GO bei Bedarf wieder hergestellt.

    Ansonsten gehören noch deine Samplesets gesichert - die Pfade zu den *.organ Dateien müssen gleich bleiben, damit GO die bisher gespeicherten Einstellungen wieder zuordnet.
    In GrandOrgue sind vorgeschlagene Verzeichnisse für diverse Anwenderfiles. Wenn man dort alles ablegt, vereinfacht das die Sicherung.

    Zitat


    Da stellt sich nun mir auch die nächste Frage:
    In welches Verzeichnis muss ich die entpackten Daten (von Hauptwerk) reinkopieren und wo kommt die .organ ODF-Datei rein, damit sie GO auch als installierte Orgel erkennt?
    Es ist eine Demo-Orgel installiert (welche von Lars ist das überhaupt, klingt gar nicht übel!), aber ich finde in allen 3 Verzeichnissen keine Installationsdaten dieser Orgel??

    Lars hat schon 2 seiner Samplesets im neuen .orgue Format veröffentlicht - die muss man nur nach "$HOME/GrandOrgue/Organ packages" kopieren. GO fügt diese spätestes beim nächsten Start automatisch in die Liste der verfügbaren Orgeln ein.
    Das GO Demo-Set ist eine künstliches Sampleset, das auf nur 20 MB Platzbedarf optimiert ist. Es wird auch im neuen Format geliefert und wird als Teil vom System unter /usr/share/GrandOrgue/package geliefert.

    Herkömliche Samplesets kannst du irgendwo in den Homedirectory entpacken. Der Umzug wird wahrscheinlich einfacher, wenn sie in $HOME/GrandOrgue/Organs landen. Wo die organ Datei genau laden muss, kommt auf den Ersteller dieser Datei an. Das ODF enthält relative Pfade zu den Samples.

    Noch ein Hinweis:

    Man kann die Installation aktualisieren.
    Im Terminal:

    su
    zypper refresh
    zypper update [und/oder zypper dup]

    Mittels "zypper install <name>" kann man aus den Angebot von "zypper update/dup" auch nur selektiv etwas installieren. Im Yast gibt es auch einen Packetmanager, der auch die Updates listet.

    Damit bekommst du OpenSuSE Systemupdates [z.B Security-Updates], GO Updates [Packete: grandorgue* ] und auch (beschränkt) Updates von der GO Live Config [Package goconfig*].

    Es müsste schon ein GO Update verfügbar sein [MIDI Monitor fix] - in den nächsten Wochen kommt noch ein GO Update, das diverse falsche Meldungen beim Laden von .orgue-Files behebt.

    • Offizieller Beitrag
    Zitat

    Original geschrieben von stephan

    Hmm, ich stell mir das in Zukunft so vor: Wenn eine neue Live-CD mit neuer GO rauskommt würde ich mir die 3 Ordner "GrandOrgue" "GrandOrgueCache" und "GrandOrgueData" sowie die GrandOrgueConfig sichern und dann den LiveInstaller alles neu aufsetzen lassen. Danach wieder die Ordner zurücksichern, geht das nicht?

    Nach dem Update von Linux waren bei mir die Einstellungen von GrandOrgue noch vorhanden. Gelöscht wurde davon nichts, womit ich auch gerechnet hatte. GO selbst war allerdings nicht mehr da, aber ich wollte ja sowieso auch GO updaten. Auch diverse von mir installierte Tools waren weg, z.B. die Dateiverwaltung Krusader, bzw. liefen eben nicht mehr.

    Meine Orgelrechner bestehen üblicherweise aus mind. 2 Laufwerken:
    1. eine SSD zum Booten mit Betriebssystem, inkl. GO und für den Orgelcache.
    2. eine große HDD für die Samplesets. (Wird im Prinzip nur noch benötigt, wenn ein Set ganz neu geladen wird)

    Größtes Ärgernis fand ich, dass das 2. Laufwerk, das ich mir vorher mühsam so eingerichtet hatte, dass es beim Start automatisch eingehängt wird, dies plötzlich nicht mehr tat und auch irgendwie nur unter anderem Pfadnamen verfügbar war als zuvor. Da steht man als Linux-Dilletant wie ich, dann plötzlich wieder vor echten Aufgaben :-afraid:
    Ich konnte den früheren Zustand bis jetzt auch nicht wieder so rekonstruieren. Die GO-Einstellungen (Midi-Register-Zuweisungen usw.) funktionierten aber auch sogar mit der wesentlich neueren GO Version gut.


    Zitat

    Da stellt sich nun mir auch die nächste Frage:
    In welches Verzeichnis muss ich die entpackten Daten (von Hauptwerk) reinkopieren und wo kommt die .organ ODF-Datei rein, damit sie GO auch als installierte Orgel erkennt?

    Was ODFs betrifft die ich für HW-Sets erstellt habe, so besitzen diese alle die selbe relative Position zu den Samplepfaden. D.h. alle ODfs kommen in ein und dasselbe beliebige Verzeichnis (z.B. namens "Samplesets") In dieses Verzeichnis werden auch alle Unterverzeichnisse entpackt, die im gepackten HW*.rar file die HW-typische ID-Nummer tragen. Bei St. Maria Nordheim also nur das Verzeichnis "000456" und bei Zöblitz "000458". Das war's. Beim ersten Start in GO einfach auf "Öffnen" und die zugehörige .organ Datei anklicken. Danach sind die Sets dort auch automatisch in der Orgelliste integriert.

  • Zitat

    Nach dem Update von Linux waren bei mir die Einstellungen von GrandOrgue noch vorhanden.


    GOLive hat keine Upgrade-Installation. Einen Teil der Änderungen [zB neue GO Versionen] kann man über die Aktualisierung der Packete bekommen.

    Ich arbeite schon an der nächsten Version. Neben der aktuellsten GO Version mit allen Fixes will ich das Timeout beim Bootmanager reduzieren und den Display-Manager los werden.

    Zitat

    Da steht man als Linux-Dilletant wie ich, dann plötzlich wieder vor echten Aufgaben :-afraid:


    Wieso hast du nicht um Hilfe gefragt?

    • Offizieller Beitrag
    Zitat

    Original geschrieben von martin

    Wieso hast du nicht um Hilfe gefragt?

    Nunja - Antworten auf allgemeine Linux-Fragen stehen ja schon irgendwo im Internet. Ist also nur mit etwas Mühe verbunden das zu suchen. Insofern wollte ich kein Orgelforum damit plagen :-wow:
    Von Windows war ich halt bisher gewohnt, dass bei Updates in der Regel nichts Wesentliches an Anwendungen und Einstellungen verloren geht. Bei Linux scheint das doch etwas anders zu sein.

  • Zitat

    [
    Wenn eine neue Live-CD mit neuer GO rauskommt würde ich mir die 3 Ordner "GrandOrgue" "GrandOrgueCache" und "GrandOrgueData" sowie die GrandOrgueConfig sichern und dann den LiveInstaller alles neu aufsetzen lassen. Danach wieder die Ordner zurücksichern, geht das nicht?


    Es gibt ein (aus meiner Sicht relevantes) Update der Live-CD.

  • Hallo,

    soo, komme endlich wieder mal dazu GO weiterzuinstallieren.
    Ich hab jetzt von meinem Hauptwerkrechner das Velesovo-Set in den Ordner /home/grandorgue/GrandOrgue/Organs Ordner kopiert und hier im Forum die entsprechende velesovo_wet.organ ODF.
    Diese .organ-ODF öffne ich mittels File -> Open. Es einscheint der Dialog "Loading sample set" und er lädt nun alle Register.
    Allerdings: nachdem der Ladebalken fast am Ende war, sieht es so aus, als würde GO abstürzen und sich selbst neu starten und es wird wieder automatisch das Demo-Sample-Set geladen :(
    Was könnte hier die Ursache sein? Gibts irgendwo ein Protokoll, wo man nachsehen kann, warum GO das SampleSet nicht anzeigen kann?

    Hab die aktuellste GoLive heruntergeladen und auf Festplatte installiert. Die GO-Version ist 0.3.1.2084

    Gruß
    Stephan