Posts by Toothbrush

    Hallo,


    auch ich bin noch unterwegs. Ich bitte meine lange Abwesenheit zu entschuldigen, aber Arbeitsplatzwechsel, gefolgt von Umzug etc., haben dafür gesorgt, dass die verschiedenen Bastelutensilien relativ lange in ihren Kartons verpackt waren.


    Ich schiebe das Thema einfach noch einmal an, denn inzwischen ist ja der Raspi 4 mit bis zu 4 GB auf dem Markt und ich erinnere mich, dass auf meinem alten PC mit 4 GB schon eine ganze Menge mit GO möglich war, solange man es nicht übertrieben hat.


    Hat von euch hier nochmal jemand Versuche unternommen?



    VG


    Toothbrush

    Hallo,


    auch ich stehe vor dem Problem Grand Orgue mit Win10 64 sauber zum funktionieren zu bringen.


    Ich habe es zwar mit ein paar Tricks hinbekommen meinen Edirol UA 25 zum Laufen zu bekommen und auch das Midi-Interface funktioniert, aber mit Latenzen habe ich auch so meine Probleme.


    Leider haben alle Versuche den Asio for all ans Funktionieren zu bringen auch nichts erbracht. Einen Choral in gemessenem Tempo spielen ist ok, aber sobald 16-tel, Triolen etc. kommen ist der Spaß rum. Da ist es auch egal, welches Sampleset ich nehme.
    Das C-Dur Präludium aus den kleinen Präludien und Fugen ist z.B. nicht spielbar.


    Ich verwende einen Laptop mit Core i5 und 2,4 GHz, der sich mit max. 27% Auslastung eher noch zu langweilen scheint. Auch in den 8GB RAM ist beim GO Demo Sampleset reichlich Platz über.
    Mit der on-Board Soundkarte ist die Klangqualität leider sehr mies, aber ich denke da hat man bei einem Buissness-Lappi einfach nicht soweit gedacht und eben nicht einen guten Chip mit guten D/A-Wandlern investiert.


    Meine Erfahrungen mit Midi-Kabel sind die, dass man so gut wie keine Vorhersage treffen kann, welches unter Win10 funktioniert und welches nicht, es sei denn der Anbieter schreibt explizit, dass Win10 unterstützt wird.


    Ein nicht funktionierendes Chinakabel habe ich mal aus Neugier geknackt, und siehe da, es stellte sich heraus, dass Opa Wu nix vom Midi-Standard hält, denn Optokoppler und Diode suchte man vergeblich. Die Lötstellen waren zwar im Layout geätzt und auch gebohrt, aber überbrückt.
    Wahrscheinlich hat man einfach nur ein funktionierendes Kabel eines anderen Herstellers 1:1 kopiert und dann die vermeintlich entbehrlichen Komponenten weggelassen.


    So, nun aber zu meiner Frage: hat jemand hier eine Empfehlung für ein gescheites USB-Audio-Interface mit MIDI Funktion, welches brav unter Win 10 arbeitet und vielleicht auch ASIO unterstützt? Wie gesagt, beim Lappi ist mit dem onBoard Sound wirklich nix zu reissen.


    VG


    Toothbrush

    Hallo,


    danke für die Antwort.
    Zur Zeit steuere ich GO ausschließlich über die Maus am Monitor, da ich keinen Touchscreen habe, und meine Orgel zwar auch den Status ihrer Registerwippen per Midi ausgibt, aber ich die Tonerzeugung nicht deaktivieren kann, weshalb die Registerwippen in Verbindung mit GO nicht nutzbar sind.


    Das Problem der Aktivierung von Tremulant und Violoncello tritt also beim Mausklick auf eines der beiden Manubrien auf dem Orgelscreen auf.



    VG
    Toothbrush

    Hallo,



    ich habe mir das Giubasco-Sampleset auch installiert, nachdem ich es geschafft habe für meinen etwas angejahrten Lappi noch ein paar GB aufzutreiben.


    Was soll man sagen, ein absolut tolles Sampleset und in die Flauto a camino "verhört" man sich ja eigentlich sofort.


    Allerdings habe ich ein kleines Problemchen: Wenn ich den Tremulanten startet, meint GO das Violoncello im Hauptwerk ebenfalls ziehen zu müssen.
    Umgekehrt funktioniert das übrigens auch: Ziehe ich das Violoncello, so startet der Tremulant im Positiv und der Registerzug erscheint als aktiv. Da scheint wohl irgendwo für beide Ereignisse die gleiche Reaktion hinterlegt zu sein, so dass Violoncello und Tremulant immer zeitgleich auftreten.


    Nach intensivem Studium der Hilfedatei von GO war ich auch nicht wirklich schlauer.


    Hat jemand von euch eine Idee, wo ich zur Problemlösung ansetzen könnte?


    Wissentlich habe ich GO das zumindest nicht beigebracht......... :-shame:


    VG
    Toothbrush


    Hallo Michael,


    danke für deinen Beitrag. In der Tat scheinen nur wenig wirklich gerade Wege vom Arduino in den PC zu führen.



    Meiner Meinung nach muss die Steuerkonsole dabei immer als eigenständiges Gerät gesehen werden.


    Es gibt die Möglichkeit dem Arduino eine Midi-in und Midi-out Buchse zu verpassen. Damit könnte man ihn in den Midikreis zwischen Orgel und Edirol hängen.


    Die andere Variante wäre es, dem Arduino eine native Midi-Schnittstelle via USB zu verpassen, also quasi ein intelligentes USB-Midi-Kabel aus ihm zu machen.


    Dies kann, nach jetziger Recherche, auf 3 Arten geschehen:


    1. Entweder ich besorge mir ein USB-Midi- Kabel, messe das durch und speise die Mididaten vom Arduino einfach in die Midianschlüsse ein. Das Kabel würde sich dann USB-seitig als USB-Midi-Device beim PC anmelden und wäre mit GO oder HW oder was auch immer als Gerät ansprechbar.
    Vorteil: Der Arduino bleibt immer Arduino und ist über seinen USB-Port jederzeit umprogrammierbar, und jeder Arduino ist verwendbar. Ich schiele hier in Richtung des Mega2560, der eine hübsch große Anzahl I/O-Pins liefert.


    2. Flashen des USB-Chips auf dem Arduino
    Die Arduinos sind, bis auf wenige Ausnahmen, nicht nativ USB-fähig. Daher haben sie meistens einen gesonderten Serial-to-USB Chip verbaut, der die USB-Schnittstelle abbildet.
    Die Bandbreite der verbauten Chips reicht vom CH340, den die meisten Chinaklone verwenden, über den FTI-Chip, der häufig auf den originalen Boards verbaut wurde, oder den Atmel 16U2.


    Hier kann man ansetzen, da sich der Atmel 16U2 mit einer neuen Firmware flashen lässt und sich dem PC gegenüber dann als USB-Midi-Device ausgibt. Hier muss man beim Kauf seines Arduino gezielt nach Boards mit diesem USB-Chip suchen.


    Vorteil hier: Arduino Uno und Mega verfügbar
    Nachteil: Nach dem flashen keine USB Kommunikation zur Programmierung des Arduino mehr möglich, also ein fetter Stolperstein während der Entwicklung wenn die Software noch oft korrigiert werden muss. Um den Flash rückgängig zu machen benötigt man außerdem einen Programmer oder einen 2. Arduino, der als Programmer fungiert.


    3.Arduino mit nativer Midi-Unterstützung
    Hier sind 2 Optionen zu nennen: Der Arduino Leonardo oder Pro Mini bzw. der Ableger Teensy 2.0. Hier sind jeweils der ATmel 32u4 verbaut, die über eine native USB/Midi/HID-Schnittstelle verfügen.
    Diese Boards können sich über USB als Midi-Device ausgeben. Für die Arduinos ist das aber auch eine gewisse Pfuscherei, weil man die einfach mit der Firmware des Teensy 2.0 befeuern muss.


    Vorteil: Direkt über USB anzuschließen, kein Umweg über Midibuchsen
    Nachteil: Auch wieder ein gewisser Umweg.


    Als (inzwischen) verfügbare Alternative bietet sich die MIDIUSB-Library für den Arduino an. Die Library nutzt Teile der Midi-Library und bietet so eine USB gestützte Softwarelösung an.


    Leider ist es in meinen Augen recht aufwändig damit zu hantieren.


    Ich habe mich nach reiflicher Überlegung inzwischen für folgenden Weg entschieden:


    Arduino Leonardo mit Teensy-Flash
    für die ersten Tests und den Entwurf der Software.
    1. hatte ich noch einen Leonardo rumfliegen
    2.ist die Midi-Library des Teensy sehr komfortabel, was die Funktionen und Befehle angeht


    Ein sendNote-Befehl sieht z.B. so aus:


    [orange]usbMIDI.sendNoteOn(note, velocity, channel);[/orange]


    wobei die Eingabe der Wert als Ganzzahl und nicht Hex oder binär erfolgt.


    Wenn die Steuerkonsole mit dem "Flickwerk" erstmal läuft, würde sich auch eine etwas größere Investition in Hardware lohnen.
    Der aktuelle Teensy 3.5 liegt bei etwa 30€ und würde die endgültige Konsole befeuern. Während der Entwicklung wollte ich aber diese Investition erstmal nicht tätigen, da dies mein erstes Projekt mit Midi und Datenaustausch mit dem PC ist, und ich keine ungenutzte Hardware rumliegen haben wollte, wenn ich doch irgendwo hängenbleibe.


    Eine weitere Baustelle wird die Konsole selbst. Wie ich die Bedienelemente gestalte, muss ich noch sehen, aber im Augenblick kristallisieren sich Taster mit weißer Led-Beleuchtung heraus, ähnlich den Rundtastern, wie man sie von Spielautomaten kennt.
    Das ist jetzt zwar nicht richtig Orgel-like, aber da die Bedienkonsole ja irgendwo am Spieltisch unterkommen muss, wird sie sicher nicht so ergonomisch angeordnet sein können, wie die Registerzüge/-wippen. Daher scheinen mir 30-40mm Taster eine gute Idee, um für eine möglichst hohe Treffsicherheit beim Registrieren zu sorgen.



    VG
    Toothbrush

    Hallo,



    danke für eure Tipps. Mit 7Zip konnte ich tatsächlich in die .orgue-Datei hineingucken und es war alles an Bord, was ich so erwartet hätte.
    Jetzt kommt dann wohl die Phase des Bastelns. Ob ich es mir jetzt zutraue eine .orgue-Datei umzustricken, oder ob ich mir lieber die Samples ausleihe und mit dem Organbuilder neu kombiniere weiss ich allerdings noch nicht.


    Ich steige auch in der GO-Hilfe noch nicht so ganz durch, aber da hat sicher auch mein etwas eingestaubtes Englisch eine Aktie dran.


    Für weitere Tipps bin ich euch natürlich dankbar. Man muss ja nicht in jedes Schlagloch selber tappen.



    VG
    Toothbrush

    Hallo,



    danke für eure Antworten. Zeit für Musik ist doch was Feines, auch wenn ihr jetzt meine gesteigerte Aktivität in Form von meinen Fragen ausbaden müsst. :-organ:


    Ich habe mir Olivers Links jetzt (noch) einmal angeschaut und meine die ODF-Struktur -ansatzweise- begriffen zu haben. Was mir allerdings noch nicht ganz einleuchtet ist, wo ich die ODF finde bzw. wo sich die Einzelteile der Orgel dann herumtreiben, wenn ich so ein Sampleset lade.
    Mache in GO eine .orgue Datei auf, so erscheint ja meine Orgel brav und ist spielbar. Auf der Festplatte ist aber keine Veränderung zu bemerken. GO legt also keine Verzeichnisse an oder so. Daher nehme ich an, dass die Orgel nur im Cache "lebt" wenn GO eine .orgue-Datei lädt?


    Ich habe mein Lieblingssampleset (Pitea School of Music) mal intern begucken wollen, aber ich habe ja nur eine .orgue Datei, in der irgendwie Alles, inkl. Samples, drinsteckt.


    Ein Versuch mit dem Editor führt zu einem spektakulären Buchstabensalat auf dem Monitor, aber nicht zum gewünschten Blick unter die Motorhaube.


    Denn eine ODF passend zu meinen Wünschen und Bedürfnissen, die ja eigentlich nur anders auf ein Sampleset zugreift (sehr schön verdeutlicht Mike und gerade der Hinweis auf das Copyright war sehr wertvoll), wäre natürlich schon mein Ziel, gerade in Kombination mit meinem Projekt "Bedienpanel".


    Vielleicht könntet ihr die Dunkelheit meiner Gedanken hier noch ein wenig erhellen.



    Besten Dank
    Toothbrush

    Hallo liebes Forum,


    nachdem es eine ganze Weile ruhig um mich war, es war arbeitstechnisch einfach zuviel los, bin ich wieder intensiver am Start. Ganz untätig war ich zwischenzeitlich nicht, denn ich habe GO unter Verwendung eines fast schon historischen Edirol UA-25 zum Laufen bekommen und es spricht sogar mit meiner Dienstorgel. Dabei sind Viscount Orgeln und ihre Derivate (Benedikt) ja zuweilen als etwas zickick im Hinblick auf ihre MIDI-Konfiguration berüchtigt.



    Aber ich erzähle die Geschichte gerne einmal von Anfang an:


    Da ich es mit einem günstigen USB-Midi-Kabel nicht geschafft habe GO und meine Orgel zu verbinden, habe ich mich nach einem etwas solideren Interface umgesehen.
    Um einfach nur mal rumzuprobieren waren mir die aktuellen Geräte allerdings etwas zu teuer und ich hatte auch kein Gerät im Umfeld, welches ich einfach mal hätte ausleihen können.
    Gleichzeitig hätte ich es einem Händler gegenüber unfair gefunden, wenn ich nur auf Verdacht ein Gerät bestelle,
    2 Tage probiere und es dann zurückschicke, mit dem Erfolg, dass der Händler die Versandkosten am Hacken hat und das Teil außerdem als B-Ware verkaufen muss.


    Also habe ich angefangen die Kleinanzeigenportale abzugrasen und bin dann auf o.g. Interface gestoßen.
    30€ erschienen mir als akzeptablen Einsatz für das Experiment und so habe den Kameraden dann gekauft.
    Im Nachhinein muss ich dem Verkäufer für seinen preislichen Realismus sehr dankbar sein, denn wenn ich, mit inzwischen mehr Erfahrung und Durchblick sehe, welche Phantasiepreise teilweise für so einen Edirol-UA25 aufgerufen werden, obwohl nicht mehr in der Herstellung und mindestens mehrere Jahre alt ohne Win10 Treiberunterstützung), so freue ich mich an einen ehrenwerten Verkäufer geraten zu sein.


    Nach einiger Recherche war es mir möglich den Edirol doch mit Treibern zu versorgen, die zwar eigentlich nicht für Win10 gedacht sind, aber dennoch akzeptiert werden und funktionieren.
    Alles angekabelt, GO gestartet und das Midi-Setup mit Autodetect durchgeführt, und siehe da: Alles wurde anstandslos erkannt und funktioniert.


    Bei großen Samplesets und vielen gezogenen Registern kommt es zwar irgendwann zu Latenzproblemen, aber das ist wohl eher den limitierenden 4 GB meine Lappis geschuldet, der inzwischen auch schon 7 Jahre alt ist.


    Aber nun mal zu meinem eigentlichen Anliegen:


    Ich habe feststellen müssen, dass die Bedienung von GrandOrgue mittels Lappi auf der Orgelbank nun nicht wirklich ergonomisch ist, und auch keine zügigen Registerwechsel zulässt.
    Ein ausreichend großer Touchscreen steht aus Platz und Kostengründen nicht zur Disposition, und ich bin auch eher der haptische Typ, der gerne richtige Knöpfe und Züge zur Bedienung mag.


    Also soll eine Steuerkonsole für GrandOrgue her. Natürlich selbst gebaut.
    Da ich schon geraume Zeit auf dem Arduino-Sektor aktiv bin, habe ich mir natürlich einen Arduino als Arbeitsgrundlage herausgepickt. Hier gibt es inzwischen eine sehr gut dokumentierte Library, welche in der Lage ist Midi-Befehle direkt zu erzeugen, ohne zuvor den gewünschten Befehl händisch in binär dargestellte Bytes umwandeln zu müssen.


    Hier sind z.B. Befehle wie
    MIDI.sendNoteOn(42, 127, 1);
    möglich, der einen NoteOn Befehl für die Note 42 mit einer Velocity von 127 auf Kanal 1 erzeugt und über die serielle Schnittstelle verschickt.


    Hardwareseitig besteht jetzt nur noch das Problem dem PC und damit GrandOrgue mitzuteilen, was man von im möchte. Problematisch ist hier, dass der Arduino vom PC nicht als Midi-Device wahrgenommen wird. Es ist zwar ohne Probleme möglich über USB die seriellen Daten zu empfangen und in einem Terminalprogramm sichtbar zu machen, aber damit sind die Daten noch nicht in GrandOrgue angekommen bzw. GrandOrgue hat seine Aktionen auch noch nicht rückmelden können.
    Hier muss also ein geeigenter Weg gefunden werden.


    Ich sehe hier folgende Lösungsmöglichkeiten, die ich gerne mit euch diskutieren wollte, bevor ich mehr Zeit in die Entwicklung meiner Steuerbox stecke.


    1. Softwarelösung
    Hier gibt es Tools wie die Hairless Midi to Serial Bridge, die seriell empfangene Daten im Midiformat an die entsprechende Software weiterreichen, indem sie ein Midi-Gerät emulieren.


    2. Hardwarelösung
    a) Hacken eines billigen USB-to-Midi-Kabels
    Die Idee hierbei ist die, ein günstiges USB/Midi-Kabel zu knacken, dessen Midi-In mit den erzeugten Midi-Daten zu füttern und den eingebauten HID-Chip zu nutzen, dass Windows ein an den USB-Port angeschlossenes USB-Midi-Gerät erkennt, welches dann hoffentlich in Grandorgue neben dem Edirol UA-25 auftaucht.


    b) Dem Arduino eine Midibuchse-Verpassen und dann ein Midi-Signal an den Edirol schicken, der dieses Signal zusammen mit den Signalen vom Spieltisch über USB einspeist und an GO schickt. Da gibt es inzwischen günstige Shields, die auch mit einem Optokoppler galvanisch getrennt sind.


    c) Verwendung eines Teensy, der von Haus aus ein Midi to USB Interface hat. PC-seitig würde dann auch ein 2. USB-Midi Gerät an einem der USB-Ports auftauchen und hoffentlich von GO erkannt und akzeptiert.


    Die Hardwarelösungen erscheinen mir als am tragfähigsten, denn hiermit erspart man sich die Midi-Kette aus mehreren Geräten.
    Lösung 1 würde sicherlich auch noch gehen, sie blockiert zwar den USB-Port des Arduino dauerhaft, müsste also für Programmierarbeiten immer wieder stillgelegt werden, allerdings wäre da ja kein wirklicher Nachteil, da man ja nicht gleichzeitig Orgelspielen und programmieren will.
    Allerdings missfällt mir der Gedanke an eine weitere zwischengeschaltete Software mit möglichen Fehlerquellen, die ich nicht mit dem Multimeter diagnostizieren kann.



    Daher hier jetzt meine Frage an unsere GO-Psychologen: Mit welcher Lösung käme denn GO am ehesten klar?


    Aus dem Bauch heraus tendiere ich dazu eine Lösung zu wählen, welche die Midi-Daten über USB anliefert und als Midi-Device im Gerätemanager auftaucht. Nur müsste GO das eben handlen können.


    Bei Verwendung eines Arduino Mega stehen für kleines Geld 54 digitale I/O Pins zur Verfügung, was immerhin etwas über 20 Registertaster mit Rückmelde-LED ermöglichen würde. Durch ein paar Tricks könnte man das bis in den 3-stelligen Bereich hochtreiben, aber das ist ja nicht Ziel der Übung.


    Gerade wg. der o.g. Anforderungen.



    Auf eure Beiträge und Anregungen freue ich mich


    VG
    Toothbruhs



    Sollte aus dem Projekt etwas (hoffentlich) Brauchbares werden, würde ich das "Kochrezept", sowie die entstehende Software natürlich mit der Community teilen wollen. Ist doch klar. Aber erstmal gucken, ob das überhaupt was wird.

    Hallo wertes Forum,



    im Augenblick bin ich auf der Suche nach einem USB-Audio/Midi-Interface, welches seinen Dienst brav unter
    Win10, 64-Bit verrichten würde.


    Ich hatte mir bisher folgende Geräte angeschaut, konnte aber keine sichere Aussage finden, ob es mit Win 10 klappt.


    Nach einigen erfolglosen Versuchen mit einem günstigen USB-to-MIDI-Kabel habe ich mir überlegt, dass ein etwas hochwertigeres Produkt wahrscheinlich weniger Kompatibilitäts-Ärger machen wird. Außerdem braucht es sowieso eine bessere Audio-Ausgabe als das im Rechner verbaute Onboard-Zeugs.


    Warum also nicht 2 Fliegen mit einer Klappe schlagen?


    Hier aber die betrachteten Geräte:


    Tascam-us-4x4


    Edirol ua-25 (kein Treiber für Win 10 beim Hersteller)


    m-audio m-track2x2m


    Steinberg UR22mk2


    Focusrite Scarlett 2i4



    Für Erfahrungswerte und Empfehlungen wäre ich dankbar.



    VG
    Toothbrush

    Hallo,


    an anderer Stelle habe ich ja schon einmal laut über einen Expander auf Basis eines Raspi in Verbindung mit GO nachgedacht, wo man die verhältnismäßig geringe Registeranzahl / Fähigkeit zur Polyphonie (dem limitierten Speicher und der Prozessorleistung geschuldet) verwendet ein vorhandenes Instrument mit bestimmten Registern zu ergänzen. Der Vorteil hierbei liegt klar auf der Hand: Der GO-Pi-Expander ist jederzeit frei konfigurierbar, d.h. bei Bedarf können jederzeit andere Samples eingesetzt und ggf. sogar aufgenommen werden.


    Wie könnte so ein Projekt aussehen?


    Ich sehe im Augenblick verschiedene Unterprojekte, für deren Konzeption das Wissen des Forums erforderlich ist, weil ich selbst in der Materie noch nicht tief genug drin bin bzw. Einer allein niemals alle Kniffe und Tricks kennen, bzw. alle Aspekte auf dem Schirm haben kann.
    Jetzt könnte man natürlich sagen, dass man sich das Wissen ja im Vorfeld aneignen kann/soll. Ich halte davon nur bedingt etwas, zum Einen ist es richtig, dass man ein gewisses Grundwissen im Vorfeld erwerben muss, einfach um weiterführende Informationen verstehen zu können. Allerdings ist die Aneignung von Wissen ohne gleichzeitige Anwendung wenig effizient, weil wer hat schon Lust und bleibt bei der Stange, wenn es darum geht sich Berge von Theorie reinzuziehen, ohne dabei ein Ziel zu haben und Teilziele zu erreichen.


    Meine Ideen für Unterprojekte:


    1. GO und Raspberry Pi
    - qualitativ gute Audioausgabe - Soundkarte
    -Midi-Kommunikation-Steuerbefehle


    2. Registersteuerung/Benutzeroberfläche
    Bei einer solch kleinen Gesamtzahl an Registern macht das Aufstellen eine Monitors wenig Sinn, vielleicht fehlt sogar der Platz. Daher muss ein eigenes Interface her.


    Hier sehe ich 2 Möglichkeiten:
    DIY-Midi-Controller auf Basis Arduino/Teensy, der allerdings dann auch mit GO rede, bzw. von GO Rückmeldung über den Betriebszustand erhalten muss.


    Alternativ wäre eine Raspi-kompatibles Touchscreen, was jede Menge Hardware und Verkabelungsaufwand, sowie das Zusammenführen mehrerer Midi-Geräte/Signale überflüssig machen würde.


    3. Sample-Sets
    Hier stellt sich mir die Frage, wie man die Samplesets/GO an das vorhandene Instrument anpasst/intoniert? Bei einer kompletten Sample-Orgel kann man notfalls einfach nur mit den Samples arbeiten, die physische Orgel stellt mit dem Spieltisch nur die Bedienelemente zur Verfügung, wenn es klanglich nicht zueinander passt.


    Der GO-Expander ist jedoch allein nicht wirklich überlebensfähig, da er das vorhandene Instrument nur erweitern soll.


    Ich würde mich freuen, wenn ihr ein wenig zur Diskussion beitragen würdet und euer Fachwissen mit mir und den anderen teilt. Vielleicht wird dann aus der verrückten Idee ein brauchbares Winter/Forenprojekt


    VG
    Toothbrush

    Hallo,


    nachdem ich nun einfach alle mit Leerzeichen getrennten Begriffe der Fehlermeldung durch die Befehlszeile
    sudo apt-get install.... geschoben habe, hat Raspi sich dann doch mal zum kompilieren bequemt.
    Nach etwa 3 Stunden war er dann fertig.


    Ich mich schon gefreut und versucht nun go aus dem Paket zu installieren, aber Pustekuchen, nix war. Die Installation bricht mit Fehlermeldung ab. Leider keine genaue Angabe, was ihn stört. Habe den Compiler nach dem erneuten Download der Quelldateien nochmal angeworfen und hoffe, dass es nun erfolgreicher verläuft. Bin allerdings misstrauisch, weil der Compiler während der Arbeit gelegentlich meckert, dass er etwas nicht entfernen konnte, weil nicht gefunden usw. und dass er den Fehler ignoriert habe. Er läuft trotzdem weiter.


    Bin sehr gespannt auf das Ergebnis.



    VG
    Toothbrush

    Hallo,



    auch ich experimentiere gerade mit einem Raspi 2 herum, um damit GO laufen zu lassen. Ich habe hier zwar schon gelesen, dass der limitierte Arbeitsspeicher das Nadelöhr für die Anzahl der gleichzeitig klingenden Register und der Polyphonie sein wird, aber aber auf der anderen Seite Frage ich mich ernsthaft, wie viel Rechenleistung ein fertiger Expander hat/haben kann?
    Wahrscheinlich auch nicht wirklich viel.


    Mein Ziel wäre es daher mit einem Raspi oder einem anderen Minicomputer einen frei konfigurierbaren Expander auf GO-Basis zu bauen und nicht auf die Simulation einer real existierenden Orgel abzuzielen.
    Denn meine krichliche Dienstorgel ist eigentlich schon ok, nur an der einen oder anderen Stelle wären 2 Register pro Werk für ein Solo oder ein bestimmtes Literaturstück sehr willkommen.


    Da wäre ein Raspi natürlich eine günstige Option, wenn man ihn denn zum Laufen bekommt.


    Genau an dieser Stelle scheitere ich gerade, denn ich habe einen frisch mit Raspbian Stretch aufgesetzten Raspi 2 hier liegen, den ich versucht habe gem. der hier geposteten Step by Step Anleitung mit GO zu füttern. Bis zu einem gewissen Punkt spielt er mit, allerdings dann ist die Party auch schon wieder rum und nicht geht mehr (abgesehen vom normalen Raspi-System).


    Daher würde ich mich sehr freuen, wenn die Linuxisten hier in der Lage wären mir auf die Sprünge zu helfen.


    Ich beschreibe mal meine Aktionen bisher:


    1. Raspbian Jessie mit Win32DiskImager auf eine 32GB Class 10 SD geschrieben
    2. Raspi gestartet und die ganzen Basics konfiguriert: Gebietsschema, Uhrzeit, Netzwerk. SSH-Zugriff für Putty aktiviert, damit ich den Zwerg vom Desktop aus bedienen kann.
    3. Verbindung mit Putty hergestellt
    4. Raspi entmüllt und LibreOffice, Minecraft und den ganzen Anwendungsmist entfernt. Der Kerl soll Musik machen, keine Briefe schreiben
    4. Mit sud apt-get update Paketlisten aktualisiert
    5. Mit sudo apt-get upgrade das System auf den neuesten Stand gebracht


    Jetzt angefangen GO zu installieren:


    1. Aeolus mit sudo apt-get aeolus installier
    2. kmix mit sudo apt-get kmix installiert
    3.Compilerversion geprüft. Ergebnis: GCC V6.3.0. Sollte also passen.
    4. Zur Sicherheit neu gestartet
    5.Verzeichnis gobuild mit mkdir im Root angelegt
    6.Die Dateien
    grandorgue_0.3.1.2232-144.1.diff.gz
    grandorgue_0.3.1.2232-144.1.dsc
    grandorgue_0.3.1.2232.orig.tar.gz
    aus dem GO-Dispository für Debian 9 runtergeladen
    7. Dateien ins Verzeichnis gobuild verschoben
    8. Mit dpkg-source -x grandorgue_0.3.1.2232-144.2.dsc
    Source Packages entpackt. Dabei die Fehlermeldungen
    [red]dpkg-source: warning: extracting unsigned source package (grandorgue_0.3.1.2232-144.2.dsc)[/red]
    und
    [red]dpkg-source: warning: source package uses only weak checksums[/red]
    erhalten. Prozess ist aber durchgelaufen.
    9.Ins Verzeichnis [navy]/gobuild/grandorgue-0.3.1.2232 $[/navy] gewechselt
    10.Versucht den Compiler mit
    dpkg-buildpackage -rfakeroot zu starten
    folgene Fehlermeldung bekommen:
    [red] dpkg-source --before-build grandorgue-0.3.1.2232
    dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 7) cdbs cmake gettext po4a libjack-jackd2-dev libasound2-dev libwxgtk3.0-dev xsltproc devscripts libudev-dev libfftw3-dev libwavpack-dev
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)[/red]


    Dummerweise sagt er da nix von fehlenden Paketen, weshalb ich bisher noch nicht versucht habe etwas nachzuinstallieren.
    An dieser Stelle wäre ich auf Hilfe durch die Linux-Cracks im Forum angewiesen um weiterzukommen.


    Sorry für den langen Post, aber ich wollte den Fehler so genau wie möglich beschreiben, damit es nicht zu zig Rückfragen kommt und eine Chance besteht, dass wir den Fehler finden und beheben können.
    Mich kotzt das in Foren auch immer an, wenn Frage gestellt werden ohne die nötigen Infos und man nur mit Glaskugel antworten kann.


    Danke und VG
    Toothbrush

    Hallo liebes Forum,


    irgendwie blicke ich bei der Struktur der Samplesets noch nicht so ganz durch: Wo befindet sich denn was? Bzw. kann man die einzelnen Register irgendwo ausmachen?



    Meine Idee ist nämlich folgende:


    An anderer Stelle habe ich geschrieben, dass ich gerne versuchen würde mit GO und einem kleinen PC einen individuell konfigurierten Expander zu bauen.
    Wäre es dazu z.B. mögliche einzelne Register der frei verfügbaren Orgeln zu einem neuen Sampleset zusammenzustellen?


    Mit einem Expander wäre es ja das Ziel eine vorhandene Orgel zu ergänzen und in ihren Möglichkeiten zu erweitern, und nicht eine komplette Orgel zu simulieren.



    VG
    Toothbrush