Beiträge von stephan

    Jetzt muss ich nochmal das Thema anschneiden.
    Und zwar geht es prinzipiell nochmal um das Ausschalten der Orgel über den Netzschalter, die mechanische Stellung der Manubrien und die Speicherung des Registerstatus in GO.
    Dreh ich den Saft ab, speichert GO NICHT den Registerstatus. Wechsel ich aber lediglich das Sample-Set, wird der Registerstatus gespeichert. Das führt insofern zu Problemen, wenn ich auf das vorige Sample-Set zurückschalte, dann stimmen die Manubrien mit den GO-Registern nicht mehr überein. Ich muss nun bei jedem Wechsel des Sample-Sets alle Manubrien ziehen und wieder abstoßen, um sicherzustellen, daß GO ebenfalls alle Register abgeschalten hat.

    Mir wäre es jetzt lieb, wenn man GO so einstellen könnte, daß überhaupt keine Zustandsspeicherung der Register stattfindet. Dass also alle Register nach dem Laden der Orgel ausgeschaltet sind. So muss ich beim Starten der Orgel oder beim Wechsel des SampleSets einfach alle Manubrien reinschieben, um mit GO synchron zu sein. Ist das möglich?

    Hab inzwischen auch schon mit Roman Sowa gesprochen, daß er eine Möglichkeit bietet, alle Schalt- und Poti-Zustände nach dem laden der Orgel (mittels eines MIDI-Signals) komplett zu senden. Er hat solche Anfragen jetzt schon vermehrt bekommen und wird es wohl in zukünftigen Firmwares einbauen. Allerdings werden bereits ausgelieferte Platinen diese nicht bekommen - eventuell nur durch Umtausch. Weiss aber nicht, ob er das macht...

    Wäre toll, wenn man in dieser Richtung eine Lösung ausarbeiten könnte.

    Zitat

    Original geschrieben von martin
    GO sendet den Zustand von allen Elementen, wenn es gestartet wird - wenn das Element aktiv ist, wird so der entsprechende Zustand hergestellt.


    Das ist schonmal sehr gut. Funktioniert aber leider nur für Register-TASTER. Manubrien und Schweller können ja leider im ausgeschalteten Zustand verstellt werden - besonders wenn 5 Kinder die Finger nicht davon lassen können ;)

    Zitat

    Aus meiner Sicht wäre es am sinnvollsten, wenn die MIDI Hardware eine PGM/CTLR Message hätte, bei deren Empfang sie den aktuellen Zustand von allen "passiven" Elementen wie bei einer Änderung schickt. In GO würde ich dann den Versand dieser Nachricht auf die ON-Led legen.


    Das wäre toll. Werde das mit PGM/CTLR mal gleich Roman als Verbesserungvorschlag weiterleiten!

    Zitat

    Original geschrieben von mike
    Was bringt diese Bauart eigentlich auf die Waage?


    Habs gerade mal gewogen: Sie wiegt ca. 70kg. Man kann ihn noch gut zu zweit tragen. Gewiss könnte man noch einiges einsparen, wenn man anstatt Multiplex- und OSB-Platten Tischlerplatten verwenden würde und anstatt Hartholz wie Ahorn vielleich alles aus Kirsch. Aber die Klaviatur + Verstärker und Lautsprecher sind schon ein Großteil des Gewichtes...

    Zitat


    Mein Spieltisch würde auch so aussehen, aber leider kann ich nirgends den speziellen Manubrienbohrer finden, der die viereckigen Löcher bohrt. So bleibt mir nur, bei stark gedimmtem Licht zu spielen :D


    :D Solltest du mal so ein Brettchen mit solchen Vierecklöchern brauchen, kann ich dir gerne eins fräsen - in das 10mm Pappelsperrholz lässt es sich fräsen wie Butter...

    Zitat


    Was GO und die verwendeten Samplesets anbelangt, so wäre es sicher das Beste, für jedes Set ein speziell auf diese Spieltruhe angepasstes ODF zu erstellen.


    Ich denke, das wäre die beste Lösung! Werd mich bei Gelegenheit mal in den ODF-Syntax einarbeiten...

    Zitat

    Original geschrieben von mike
    Spricht denn etwas dagegen das Zöblitz-Set in der Version 1.01 zu benutzen? Ist die evtl. inzwischen nicht mehr erhältlich?


    Ah, verstehe. Das ist kein Problem, hab auch die Version 1.01 noch. Werde diese dann verwenden. Vielen Dank!

    Zitat

    Original geschrieben von martin

    Ist dir etwas beim Kopieren passiert oder ist ein Bug im ODF?

    Kannst du einmal nachschauen, wie das File in der RAR-Datei genau heisst? (zB mit 7-zip).
    Die Schreibweise im ODF sollte mit der RAR-Datei übereinstimmen.


    Also, habs jetzt nochmal kontrolliert. Sowohl in der Original-RAR-Datei ist der Dateiname mit großem "C" geschrieben, als auch auf meinem Hauptwerk-Rechner. Es muss definitiv beim Kopieren auf den GO-Rechner passiert sein. Wie kann sowas geschehen?

    Hallo Reinhard,

    Zitat

    Original geschrieben von rr01
    Hast du vielleicht ein paar Bilder zu den Manubrien. Ich bin mir ja immer noch nicht sicher ob ich mein Projekt mit Manubrien oder Tastern gestalten soll


    Der Aufbau ist ganz einfach gehalten. Ohne Motor oder Hubmagnet oder Druckpunkt ;)
    Sie besteht aus einem Vierkantholz mit 15mm Durchmesser und ist in einer mit Kaschmir ausgetuchten Führung gelagert. Zwischen den Führungen hab ich den Wegbegrenzer über Langlöcher montiert, somit kann man den Nullpunkt sehr präzise einstellen. Hinten ist ein Magnet eingelassen, der dann einen Reedkontakt schaltet.

    Hier mal zwei Bilder von dem Aufbau:

    truhe05.jpg


    truhe06.jpg

    Hallo Martin,

    vielen Dank für deinen Post!

    Zitat

    Was ist das für ein Touchscreen-Model?


    Es ist folgendes von Pollin: Touchscreen 7" Pollin
    Ist auf jeden Fall Linux-tauglich, mein Kollege hat den unter Linux schon zum Laufen bekommen. Ich werd ihn mal fragen, was er da genau konfiguriert hat...

    Zu 1 (Splitpunkt)

    Zitat

    Wenn du den MIDI Kanal von der MIDI Hardware wechseln kannst, kannst du als zweites MIDI Event den anderen MIDI Kanal zuweisen und den Tastenbereich dort einschränken. So kannst du einen Split definieren.


    Hmm, tue mich etwas schwer, das zu begreifen. Ja, ich kann in der Midi-Elektronik einen Splitpunkt definieren, wodurch dann die linke Klaviaturhälfte auf einem anderen Kanal sendet, als die rechte Hälfte. Somit muss ich dann nur den Kanal der rechten Hälfte auf das Manual 2 des SampleSets verbinden. So möchte ich es auch: die linke Hälfte spielt NUR die Register des Hauptwerks, die rechte Manualhälfte NUR die Stimmen des Oberwerks.
    Soweit ich es verstehe, spielt bei deiner Lösung die linke Hand das Hauptwerk, die rechte dann ZUSÄTZLICH das Oberwerk, oder?
    Um die Lösung mit der Midi-Hardware zu realisieren müsste man dann halt die Möglichkeit haben, von GO eine SysEx-Message zu erzeugen, um den Splitpunkt zu aktivieren

    Zu 2 (Basskoppel)
    OK, das leuchtet mir ein. Bei mehrmanualigen SampleSets gibt es natürlich auch für jedes Manual eine Basskoppel. Dein Lösungsvorschlag gefällt mir, allerdings muss ich mich da erst in die ODF-Struktur einarbeiten. Kann momentan mit der Lösung leben. Muss halt aufpassen, dass ich immer alle beide Bassregister abstosse und das gewünschte wieder ziehe...

    Zu 3 (AutoSave)
    Also, ich hätte jetzt kein Problem damit, da beim normalen Betrieb von GO eh nur gelesen wird und die Platte schreibtechnisch fast gar nicht belastet wird. Ich glaub nicht dass es die Lebensdauer der SSD einschränkt (dank "Wear Levelling").
    Man könnte die Funktion ja zumindest als optionalen Schalter für den User bereitstellen!?
    Allerdings: Lieber wäre mir natürlich, wenn man das von der Midi-Hardware-Seite lösen könnte. Denn die Position der manuellen Registerzüge können ja im ausgeschalteten Zustand verändert werden, dann wäre es wieder nicht mit GO synchron. Optimal wäre es, wenn die Midi-Hardware nach dem Laden des SampleSets alle Zustände der Schalter und Schweller senden würde. Werde mal mit Roman Sowa darüber sprechen...

    Zu 4 (On-LED)
    Cool! Das wusste ich noch nicht! Wird das angebundene Midi-Signal auch beim laden eines anderen Sample-Sets nochmals gesendet? Und ist es möglich, für jedes Sample-Set ein eigenes MIDI-Event zu definieren? Dann könnte der Spieltisch erkennen, was für ein SampleSet gerade geladen ist (dies ist der einzige Punkt, den ich gegenüber Hauptwerk vermisse)

    Hallo,

    von Sonus Paradisi gibt es das Cembalo von Ruckers. Vielen herzlichen Dank für das ODF, das man hier auf der Seite für GrandOrgue downloaden kann!!
    Leider hab ich das Sample-Set nicht zum laufen gebracht. Hab das SampleSet vom (Windows-)Hauptwerk-Computer auf GrandOrgue/Linux kopiert.
    Beim laden bekomme ich folgende Fehlermeldung:

    Zitat

    Error while loading samples for rank 8' pipe .\000877\pipe\Cembalo_AB\2.man_8\072-C.wav: Failed to open file '.\000877\pipe\Cembalo_AB\2.man_8\rel99999\072-C.wav'


    Hab rausgefunden an was es lag: Linux unterscheidet bei Dateien/Verzeichnissen Groß-Kleinschreibung. Nun war die Datei als "072-c.wav" kopiert. Hab sie dann umbenannt und das "C" groß geschrieben, und siehe, sie lädt! :)

    Nur falls jemand die gleichen Probleme hat...

    Hallo,

    ich setze mittlerweile auch Zöblitz unter GO ein. Leider hab ich nun das Problem mit falschen Tönen bei Prizipal 8' und Flöte 4'. Das liegt wahrscheinlich wohl daran, daß ich die V1.02 installiert hab.
    Ist das aufwendig, die ODF umzuschreiben? Hat jemand einen Tipp, was man hier ändern muss?

    Hallo zusammen,

    so, sie sollte pünktlich zum Hochzeits-Einsatz fertigwerden - was dank eurer Unterstützung auch geklappt hat: Meine neue Truhenorgel powered by GrandOrgue! *freu*

    Ein paar technische Details zuerst:
    - Gehäuse aus Ahorn und Kirschbaum, gemischt mit Wenge (Intarsien)
    - Registerzüge ebenfalls aus Wenge
    - Midi-Elektronik von midi-hardware.com
    - Mini-Computer Intel NUC "NUC5i5RYH" (linux-tauglich, brauchte wirklich nix dazuinstallieren, einfach GO-Live-CD auf Festplatte installiert)
    - USB-MIDI-Schnittstelle "E-MU midi1x1 Tab" (wird ebenfalls automatisch erkannt)
    - Lautsprecher Magnat Vector 203
    - Verstärker Denon PMA 520 AE
    - Sample-Sets: St. Maria Nordheim, Silbermann Zöblitz, Velesovo und Ruckers Cembalo

    Nun noch ein paar Bildchen:

    truhe01.jpg


    im Gegensatz zu meinen bisherigen Spieltischen ist sie auch von hinten anschaulich, man kann sie somit auch mitten in den Raum stellen:

    truhe02.jpg


    Da bei einer GO-Orgel ein Computer eingebaut ist und man hin und wieder mal was konfigurieren muss oder ein neues Sample ausprobieren möchte, ist ein komplett Bildschirmloser Betrieb nicht möglich. Und da ich nicht immer einen Monitor+Tastatur zu diesem Zweck anschließen möchte, hab ich das im Mini-Format in eine Schublade integriert: Einen 7" Touchscreen von Pollin (Touch hab ich leider treibertechnisch noch nicht hinbekommen, bin ein Linux-Neuling), eine Bluetooth-Mini-Tastatur, ein MIDI-Display und der Programmier-Block von midi-hardware. Beim Spielen verschwindet alles wieder im Spieltisch und man sieht nur noch Mechanik ;)

    truhe03.jpg


    Unten im Gehäuse sind dann der NUC mit Verstärker und Lautsprecher untergebracht. Dadurch, daß alle 4 Seiten gleichmässig vergittert und mit Akustikstoff bespannt sind, kann man die Lautsprecher jeweils in alle 3 Abstrahlrichtungen drehen - je nach Aufstellungsort. Hat sich schon bewährt!

    truhe04.jpg


    Ein paar Details müssen jetzt noch realisiert werden, hier sind ein paar Features von GO vonnöten:

    1. frei wählbarer Splitpunkt
    Ich hab ja auch 2-manualige Samples eingespielt, deren Werke sich bisher nicht getrennt spielen lassen. Hab beide Manuale auf die eine Klaviatur gemappt. Nun hab ich über den Tasten noch einen MIDI-Taster eingebaut, mit dem ich die Klaviatur splitten möchte, sodaß mit der linken Hand das Hauptwerk und mit der rechten Hand das Oberwerk gespielt werden kann. Midi-Hardware.com bietet so etwas schon an, allerdings müsste ich dazu die Schublade rausziehen und einen Code eingeben, damit der Splitpunkt aktiviert wird. Die andere Möglichkeit besteht mittels einer SysEx-Message, durch die der Splitpunkt auch gesetzt werden kann, was GO ja leider (noch) nicht bietet. Bleibt wohl nur das programmieren einer kleinen MIDI-Software, die solch ein Signal senden kann - mal schauen

    2. BASS-Spielhilfe
    Um auch die Pedalregister mitzuverwenden (hab da 2 Registerzüge dafür gespendet) muss die BASS-Funktion, die GO ja glücklicherweise bietet eingeschalten werden. Bei dieser Art Spieltisch sollte sie aber immer aktiviert bleiben. Wäre toll, wenn man GO unter "Midi & Audio Einstellungen" -> "Initiale MIDI Konfiguration" noch das BAS-Element spendieren könnte, das dann nach dem Laden der Orgel ausgelöst wird und die BAS-Koppel betätigt.
    Bisher hab ich diese Koppel mit den beiden Pedalregistern verknüpft, was bei 2 Registern einen unschönen Nebeneffekt hat: Ich ziehe 2 Register und stoße eines wieder ab, so wird auch die BAS-Koppel durch das "NOTE-OFF"-Event deaktiviert.

    3. Auto-Save der gezogenen Register
    Ich nutze ja hier das komfortable "Saft abdrehen" zum "herunterfahren" der Orgel. Schön, daß das Linux so gut verträgt :) Leider vergisst GO die gerade gezogenen Register, die an meinem Spieltisch ja gezogen bleiben. Beim erneuten Hochfahren sind in GO wieder keine Register gezogen. Ich muss also immer alle Registerzüge beim Einschalten reinschieben und dann wieder ziehen, damit sie auch in GO aktiviert werden.
    Schön wäre es, wenn GO nach jedem Betätigen eines Registers die Zustände permanent speichert, dann wäre das Problem gelöst.

    4. MIDI-Signal nach Laden des SampleSets
    Wenn sich kein Monitor am Spieltisch befindet, wäre es hilfreich, mittels einer LED zu signalisieren, daß die Orgel nun geladen und spielbereit ist. Hier wäre ein MIDI-Signal hilfreich, das die LED ansteuern könnte.

    Ansonsten bin ich begeistert von GO/Linux und werde das Thema weiterverfolgen, man kommt hier mit VIEL weniger Mitteln zu einem Niveau, das Hauptwerk in nichts nachsteht! Danke besonders an Martin!

    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

    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??

    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?

    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 :)

    Zitat

    Original geschrieben von Erik
    Bestellst du dann direkt bei adafruit? Es gibt ja scheinbar auch eine deutsche Händler:
    http://www.exp-tech.de/

    Danke für den Tip! Aber ich werde trotzdem direkt bei adafruit bestellen, da ist es letztendlich noch um ein Stück günstiger ist und bei exp-tech bei den Tastern "Lagerbestand = 0" stehen hat ;)

    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...