Beiträge von Mikelectric

    Meistens ist es bei mir so, dass ich am liebsten direkt aus den Büchern spiele. IMSLP-Noten habe ich mir zwar viele heruntergeladen, aber darauf greife ich doch eher selten zurück. Mitunter blättere ich am Bildschirm darin herum und versuche auch einige Stellen dann direkt vom Bildschirm zu spielen. Interessante Stücke drucke ich dann auch mal aus. Die Ausdrucke finden sich aber meist später auf verschiedenen Stapeln wieder die ich irgendwann mal sortieren will :-pipe: Mitunter kam es schon vor, dass ich dann das gleiche Stück irgendwann nochmal ausgedruckt habe.

    Für Stücke die ich als Repertoire lieb gewonnen habe, scanne ich dagegen die Noten sogar aus den Büchern ein und sammle sie innerhalb eines Dokumentes am PC (inkl. Finger- und Fußsätzen) um sie dann auch wieder gesammelt auszudrucken und in einem speziellen A4 quer Ordner mit A4 quer Hüllen abzulegen. Diesen Ordner lege ich dann auch sehr oft aufs Notenpult oder hole mir einzelne Blätter zum spielen raus.

    Meine Gedanken gehen auch in diese Richtung. Nur bin ich der Meinung, das UI sollte nur aus Komponenten bestehen, die an jeder virtuellen Orgel vorhanden sind und nicht noch zusätzliche Geräte erfordern wie Bildschirm, Tastatur, Maus oder den besagten Ziffernblock.

    Was immer vorhanden sein müsste an der virtuellen Orgel ist doch:

    - Manual 1 als Eingabemedium
    - Soundausgabe als Ausgabemedium

    Die Funktion dieser beiden muss zu Beginn allerdings sichergestellt werden.
    Dann muss man doch nur noch ein interaktives Konzept ausarbeiten, wie die Tasten belegt werden und welche Töne, Geräusche oder evtl. gesprochenen Texte die Rückmeldungen liefern. Bei Sprachausgabe muss man allerdings noch berücksichtigen, dass man dann die Texte in mehrere Sprachen aufnehmen müsste. Also vielleicht lieber nur Tonsignale a la hoher Ton = Ja/1 - tiefer Ton = Nein/0

    Man braucht dann eben etliche Definitionen und dazu eine ausreichende Dokumentation um die Einstellungen vornehmen zu können.

    Erst kürzlich hatte ich im Fernsehen einen Beitrag gesehen, wie jemand auf einer Klaviatur Schreibmaschine schreibt - schneller als auf einer normalen ASCII-Tastatur.
    Siehe z.B. hier:

    http://www.br.de/themen/klavier…mputer-100.html

    Gibt es denn tatsächlich so viel Orgelliteratur mit vorgegebenen Fingersätzen? Außer ein paar Orgelschulen ist mir nicht sehr viel bekannt. Zu den angegebenen Stücken konnte ich auch nichts mit Fingersatz ausmachen.

    Der ideale Fingersatz ist doch immer eine ziemlich persönliche Angelegenheit. Der eine hat große Hände und lange Finger und kann damit ganz anders greifen als jemand mit "kurzen, krummen Gichtknoten" :D Auch die verschiedenen möglichen Bewegungsabläufe liegen nicht jedem gleichermaßen.

    Was spricht denn dagegen den Fingersatz für diese Stücke selbst zu entwickeln? Mein Orgellehrer hat mal gemeint, erst wenn man alle Stufen der Bearbeitung eines Satzes durch hat, diesen flüssig spielen kann und seine eigene Interpretation dazu gefunden hat, dann ist es wirklich "sein eignes Stück" geworden.

    Aber solche Angebote von anderen Organisten mit Fingersätzen zu bestimmten Stellen schaue ich mir auch immer mit Interesse an.

    Hallo Stefan,

    sehr interessant. Ich bin gespannt wie Du weiter vorgehen willst. Ich nehme an es soll ein Spieltisch für eine virtuelle Orgel daraus werden? Dann nur um Gottes Willen nicht die originalen Tastaturen wegwerfen, auch wenn sie noch so verschimmelt aussehen. Das hat schon mal jemand gemacht, nur weil er eben der Einfachheit halber Kunststoff-Klaviaturen mit Midi eingebaut hatte. Da musste ich entsetzlich mit ihm schimpfen :D

    Ja, die Fotos sollten am besten auf einem externen Server liegen und dann hier verlinkt werden. Ich kann aber auch gerne hingehen und die Fotos aus dem Download auf meinem Server hier abspeichern und von Hand wieder einfügen, wenn Du es mir genehmigst. Kann halt ab und zu ein Weilchen dauern, so wie ich dann dazu komme sie in Deine Beiträge einzufügen.

    Gruß Michael

    Hallo Ponticulus,

    für jemanden der die originale Orgel nicht kennt, ist es natürlich kaum möglich eine sichere Aussage zu treffen, ob ein virtuelles Sampleset das Original richtig abbildet. Insofern muss ich sagen, bin ich mit vielen Ergebnissen trotzdem relativ zufrieden, auch wenn sie mir nur ein scheinbar realistisches Abbild einer Orgel vorgaukeln werden. Dessen bin ich mir durchaus bewusst. Ich bin natürlich froh, wenn es jemand genauer weiß und dann dem Sampleset-Hersteller entsprechende Hinweise zukommen lässt, damit dieser das Set nachträglich verbessern kann.

    Meines Wissens sind doch aber Orgeln mit C / Cis - Ladentrennung so aufgebaut, dass alle C aller Register auf einer Seite versammelt sind und alle Cis dann auf der gegenüberliegenden Seite und so weiter. Meist C links und Cis rechts von vorne auf die Orgel gesehen. Das ist ja alleine schon durch die zwei Windladen und die Trakturen, die am Wellenbrett verteilt werden, so vorgegeben. Natürlich kann das bei den Prospektpfeifen aufgrund von Verführungen wieder ganz anders aussehen. Dann sind die Gründe der Verteilung wahrscheinlich in den Vorgaben der optischen Aufteilung zu suchen, oder der Orgelbauer hätte sich vielleicht akustisch etwas bestimmtes dabei gedacht.
    Wenn allerdings Montre 8 und Prästant 4 gerade gegenläufig verteilt werden, so kommt mir das auch zunächst mal merkwürdig vor. Ist mir bisher aber ehrlich gesagt beim Menesterol-Set auch noch gar nicht unangenehm aufgefallen. Vielleicht bin ich da zu unkritisch ?! :/
    Es ist bestimmt auch die Frage, ob da die Sethersteller selbst so kritisch darauf achten. Manches Set kommt eben auf den Markt, weil irgendwann auch mal die Geduld bei diesem enormen Arbeitsaufwand ausgeht. Ich kann das durchaus nachvollziehen, was es bedeutet möglichst viele Details einer Orgel originalgetreu abbilden zu wollen.

    Was die Lautstärkeunterschiede einzelner Samples im Récit betrifft, so kann das durchaus verschiedene Ursachen haben. Dies kann durch die Aufnahme bedingt sein und nicht genügend korrigiert worden sein, es könnte aber auch eine Erscheinung sein, die evtl. nur mit der Abstrahlung der Lautsprecher beim Abspielen des Sets etwas zu tun hat. Womit hast Du denn Abgestrahlt? Ein guter Studio-Kopfhörer ist sicher am besten geeignet so etwas zu beurteilen.

    Ich werde aber beim nächsten mal auf die von Dir angesprochenen Punkte genauer achten, wenn ich das Menesterol-Set wieder benutze.

    Das volle Sampleset beinhaltet ja alle 3 Varianten, Dry, Wet/Surround, und Moist. Die Moist-Version ist mir auch aus dem Grund die liebste, weil sie keinen Klangbrei auch über die Lautsprecher liefert und so einfach ideal zum Üben für mich ist.

    Gruß Michael

    Zitat

    Original geschrieben von martin

    Wir beide haben das gleiche Ziel - nur mit anderer Hardware dahinter. GO Live funktioniert genau so mit Anstecken und davon booten, wie beim ein Raspberry PI Image. Bei einer großen Menge an Standard-Hardware geht GO Live einfach. Der Kompatibilitätstest durch die Entwickler ist bei der Hardwarevielfalt aber nicht mehr möglich.

    Es war (und ist) mir noch nicht ganz klar auf was der Thread genau hinauslaufen soll. Das Thema "Head-less" deutet ja zunächst lediglich auf ein System ohne Bildschirm hin - sehe ich das richtig? Damit wäre eigentlich auch nicht zwangsläufig eine Standardisierung und Plug & Play verbunden. An der umgebauten Eminent Sakralorgel betreibe ich das ja so (zumindest Zeitweise). Das ist aber bisher leider noch eine individuelle Einzel-Lösung die eher solchen Freaks wie uns vorbehalten bleibt. Das würde ich gerne ändern, damit auch ein (Computer-) Laie das realisieren kann.

    Zitat

    Original geschrieben von martin

    Über diese Thema und (neue) Ideen dazu wollte ich eigentlich hier diskutieren. Das Problem besteht für beide Lösungen.

    Ich denke beide Ansätze haben ja ihre Berechtigung.

    Bei der Lösung mit (beliebigem) PC und GO-Live USB-Stick sehe ich einfach für einen absoluten Computer-Laien evtl. unlösbare Probleme auf ihn zukommen. Kann man wirklich einfach irgendwo einen PC kaufen und den GO-Live Stick dranstecken und alles läuft? In wie viel Prozent der Fälle klappt das tatsächlich so? 30% ? oder 98 % ?

    Fraglich ob ein beliebiger PC überhaupt Linux-fähig ist oder zumindest nicht eine Komponente dabei hat die einem alles vermasselt. Was, wenn schlicht und einfach das BIOS so eingestellt ist, dass überhaupt nicht von USB gebootet wird? Schon hat der Laie sein gefürchtetes Problem und kommt mit dieser Kleinigkeit alleine nicht mehr weiter. Vor so etwas haben doch viele Angst und wollen deswegen lieber gar keinen Computer haben.

    Natürlich hat die PC-Lösung aber unbestreitbare Vorteile - jedenfalls für denjenigen der damit klar kommt. Aber man ist doch auf Informationen angewiesen welche System sich eignen, die man kaufen kann und von welchen man die Finger lassen muss weil es sonst nicht funktioniert.

    Für diejenigen die lieber nichts mit einem Computer zu tun hätten, könnte der Ansatz mit einem Raspberri Pi 2 oder einer ähnlichen Plattform geeignet sein. Diese Plattform ist dann immer zu 100 % identisch, egal wo man sie kauft. Steckt man die vorbereitete SD-Karte ein, dann müsste die Erfolgsquote auch tatsächlich bei 100 % liegen. Da könnte sich ein Computer-Laie dann schon im Voraus sicher sein.

    Zitat

    martin hat geschrieben:


    Bei wie vielen Varianten des Images bist du schon? "Du musst X verwenden" bringt nur etwas, wenn fast alle Anwender X einsetzen.

    Sicher liegt da grundsätzlich das selbe Problem wie bei der PC-Lösung. Aber es müsste machbar sein, eine gewisse Liste von Midi-Interfaces anzusammeln, die alle mit dem selben Image funktionieren können. Ich hätte in der Tat nicht vor, verschiedene Images deswegen anzubieten. Jedes Midi-Interface das von einem Raspberry Pi 2 automatisch beim Start erkannt werden kann und sich mit den voreingestellten Midi-Kanälen betreiben lässt, sollte doch geeignet sein - und zwar auch mit dem selben Image. Oder habe ich da noch einen Denkfehler?

    Die Frage ist dann natürlich, inwieweit eine bestehende Sakralorgel z.B. sich dann auf diese Midi-Kanäle einstellen lässt. Hier wäre dann vielleicht eine andere Vorgehensweise innerhalb von GO gefragt, wie man möglichst einfach und auch ohne Bildschirm solche Midi-Anpassungen vornehmen könnte.

    Vielleicht müsste man irgendwie mit einer Taste eine Konfigurationsroutine in GO starten können, die nach vorgegebenem Schema die Klaviaturen usw. per "auto-learn" ermittelt. z.b. in einer vorgegebenen Reihenfolge.
    Oder als Idee z.B. immer zuerst Manual 1 einlernen und wenn dieses feststeht, dann können die Tasten von Manual 1 (C,C#,D,D#...) als Eingabegerät für weitere Grundeinstellungen nach einem bestimmten Eingabeschema im Handbuch durchgeführt werden, damit sogar auch "Head-less".

    Zitat

    Original geschrieben von Offenbass 32'

    Wie stünde es denn um den Odroid U3?

    Bis jetzt sieht es ja nicht so aus, als ob GrandOrgue richtig auf dem Odroid U3 laufen würde. Es ist hier im zugehörigen Thread immer noch von einem massiven Problem mit Audio die Rede, für das es anscheinend noch keine Lösung gibt.
    Für mein Anliegen wäre der Odroid auch noch zu exotisch - sprich noch nicht weit genug verbreitet um ihn als Standardplattform bezeichnen zu können.

    Zitat

    Original geschrieben von Offenbass 32'

    Mein Plan ist ja, wenn meine Orgel irgendwann mal irreparabel ins Nirvana gehen sollte ein kleines PC System zu integrieren wo eine 3 manualige Orgel mit 50 Registern läuft. Das soll geschehen, ohne ein PC Gehäuse hintenreinzupacken. Alle Platinen sollen auf der Aluminisierten Holzplatte zum Liegen kommen. Platz ist dort genug...eine recht gute Abstrahlung schon drin und der Spieltisch ist unkaputtbar.

    Das würde ich dann aber eher als individuelle Einzel-Lösung betrachten und besser ein ordentlich schnelles Mainboard mit Intel CPU und reichlich RAM einbauen. 50 Register in so einer Orgel sind m.E. nichts mehr für billige Einsteigerlösungen oder Kleinst-Computer. Da würdest Du als fortgeschrittener Virtuellorgler wohl kaum Freude daran haben ;)

    Zitat

    Original geschrieben von chp

    ich habe nun versucht, Trakturgeräusch (Pedal, Manuale) hinzuzufügen, ...

    ...Die Geräusche beim Loslassen (wohl "rel"-Verzeichnisse bei Sonus Paradisi) habe ich aber nicht einbinden können. Ich habe versucht, die als Releases einzulesen (Release 99999, das ist doch quasi unendlich?), aber das hat nicht geklappt. Die "rel"-Vezeichnisse sind auch keine Unterverzeichnisse der "atk"-Verzeichnisse, sowie das bei den Releases bei Sonus Paradisi sonst anscheinend ist.

    ...aber bei Mikelectric hat das mit Sonus Paradisi Material ja auch nicht so einfach geklappt. Daher habe ich mir die ODF von Prague Barock heruntergeladen, um mir anzusehen, wie Mikelectric das gemacht hat, um es ggf. parallel zu machen. Leider hat Mikelectric in diese ODF die Trakturgeräusch dann anscheinend aber doch nicht eingebaut, ich habe jedenfalls nichts gefunden, was so aussieht.

    Die Trakturgeräusche habe ich in der Krzeszow ODF eingebaut. Das ist nun auch schon wieder über ein Jahr her und ich kam seither nicht mehr nennenswert zur ODF-Erstellung. Ich müsste selbst nachsehen, aber wenn ich mich recht entsinne, dann hatte ich mich bei Krzeszow entschlossen einfach auf ein Geräusch beim loslassen der Taste zu verzichten und stattdessen nur das Atk-Sample zu verwenden. M.E keine allzu große Einbuße an Realität, da die Trakturgeräusche meist sowieso etwas vom Sethersteller hinzugedichtet sind und nicht exakt der Originalorgel entsprechen :-pipe: Meistens wird die Taste auch nur kurz angeschlagen, dann sind Attack und Release Geräusch fast eins und da fällt es kaum auf. Und ob man nach lang gehaltenen Tönen das Zurückfallen der Taste in Wirklichkeit tatsächlich so hört wie im Set ist für mich in vielen Fällen auch etwas zweifelhaft. ;)

    Huch - wir sind ja schon auf Sendung :D

    Also ich denke für GrandOrgue wäre gut eine Lösung zu finden, die möglichst keine Computerkenntnisse erfordert und auch einem "Nur-Musiker" und "Nicht-Techniker" den Einstieg in die virtuelle Orgel ermöglicht. Ebenso wäre gut, dies auch "Nicht-Millionären" auf einfache Weise zu ermöglichen.
    Hier sehe ich gerade den Pferdefuß, der noch viele Interessenten von einer virtuellen Orgel abschrecken könnte. Mangels technischen Kenntnissen "begnügen" sich viele mit einer Sakralorgel, die man eben nur einschalten muss und losspielen kann. Dies können sich aber viele Orgelinteressiert oft auch gar nicht leisten.

    Mein Gedanke ist also eine Plattform zu finden, die so standardisiert ist und überall preiswert erhältlich ist, dass darauf ein günstiges Einstiegssystem aufgebaut werden kann.

    Das mit einem PC zu realisieren ist m.M.n. schon viel zu kompliziert. Viele wollen oder können keinen PC haben. Jeder PC ist wieder anders beschaffen und so wird auch das jetzige GO Live - System nicht unbedingt auf Anhieb laufen. Für viele Laien dürfte der Weg damit indiskutabel sein.

    Dagegen z.B. einen Raspberry Pi 2 in einem Laden um die Ecke zu kaufen und dann nur noch eine SD-Karte in den Slot zu schieben dürfte wohl fast jedem gelingen. Geht irgendwann etwas mit dem System schief, kann man einfach eine neue SD-Karte einsetzen und schon funktioniert die virtuelle Orgel wieder. Ggf. müsste man bei größerem Defekt eben den ganzen Raspberry Pi austauschen, was über den Daumen dann 50,- € kostet.

    Das alles geht bis dahin aber ohne fremde Hilfe eines Computerexperten !


    Was den Midi-Anschluss und dessen Konfiguration in GrandOrgue betrifft, so kann man über mögliche Lösungen diskutieren. Idealerweise ist dies alles auch schon fertig auf der SD-Karte konfiguriert. Es ist dann nur noch sicherzustellen, dass der Anwender in diesem Fall ein genau spezifiziertes Midi-(Kabel-)Interface verwendet. Der Raspberry Pi 2 hat aber auch noch frei verfügbare Ein- und Ausgänge integriert! Eine weitere Möglichkeit wäre also z.B. eine spezifische Aufsteckkarte zu entwickeln, die eine Midi-Schnittstelle enthält und evtl. direkt Anschlüsse für Register-Schalter bereitstellt.

    Mit so einer Lösung wäre schon mal das Computer-Problem relativ leicht in den Griff zu bekommen. Dann gibt es nur noch das Problem des Midi-Spieltisches :-C
    Aber mancher Einsteiger will eine virtuelle Orgel vielleicht auch erst mal nur mit einem billigen Midi-Keyboard ausprobieren. Oder verwendet eine ältere Midi-taugliche Sakralorgel dafür. Für diejenigen die etwas handwerklich begabt sind aber nichts mit Computern am Hut haben, wäre sicher auch eine detaillierte Bauanleitung für einen möglichst einfachen Spieltisch eine Option. Wer genug Geld hat kann sich natürlich heutzutage auch fertige Komponenten zulegen.

    Sicher ist der Raspberry Pi keine Rakete und nicht der ideale Computer für eine virtuelle Orgel, was die Leistungsfähigkeit anbelangt. Aber mit dem Modell 2 sollte doch schon möglich sein, für unter 100,- € einen einfachen Orgelexpander zu realisieren, der klanglich mit traditionellen Expandern mindestens mithalten kann.
    Voraussetzung ist natürlich ein geeignetes Sampleset, das einerseits schöne Klänge in einer ausreichenden Disposition anbietet und andererseits dem Computer nicht zu viel Leistung und Speicher abverlangt. Ich denke z.B. an so etwas wie das Set Esmuc, mit nicht zu viel Nachhall. Evtl. auch einfach das bestehende Demo-Set von GO.

    Vielleicht gibt es auch eine andere Hardwareplattform die geeigneter wäre als ein Raspberry Pi 2 ???
    Allzu exotische Minicomputer machen aber auch wieder wenig Sinn. Der Raspberry Pi ist immerhin sogar so weit verbreitet, dass die neue Version 2 sogar extra für die Lauffähigkeit unter dem kommenden neuen Microsoft Windows 10 auserkoren ist !

    Gruß Michael

    Da hast Du natürlich auch wieder Recht. Von wann stammt denn diese Version 0.1 ?

    In meinem persönlichen Archiv habe ich erst GrandOrgue Versionen ab 0.2 abgelegt mit Datum von 2009. Irgendwann zuvor gab es mal MyOrgan und den Übergang zu GO muss ich wohl verschlafen haben weil ich damals mehr mit Hauptwerk beschäftigt war.

    Das Problem bei der AMD "Bulldozer" Architektur ist, dass sie effektiv nur halb so viele CPU-Kerne haben wie angegeben. Also hat dieser Typ eigentlich keine 8 Kerne sondern nur 4 die für HW / GO wirklich von Nutzen sind.

    Die Leistung von HW / GO hängt ganz entscheidend von der "Floatingpoint-Unit" ab. Hier kann Intel eindeutig mehr glänzen und hat die schnellere Konstruktion. Mag sein, dass der besagte AMD diesen Nachteil zum Teil durch etwas höhere Taktfrequenzen wieder ausgleichen kann. Dadurch hat er aber einen deutlich höheren Strombedarf und muss intensiver ( und damit meist auch lauter ) gekühlt werden. Preislich spart man sich auch nichts, denn er liegt etwa zwischen einem i5 und einem i7 bei "vielleicht" vergleichbarer Leistung für HW / GO.

    Für andere Anwendungen kann er evtl. eher Vorteile gegenüber i5 / i7 ausspielen.

    Mit meinem Samsung S3 hatte ich es auch ausprobiert. Das Problem bei den allermeisten Geräten ist die Latenz, also die Zeitverzögerung des Tons vom Anschlag der Taste bis man ihn wirklich hört. Man merkt es erst so richtig, wenn man wirklich über Midi mal ein Keyboard dranhängt und versucht etwas zu spielen. Für mich war das auf dem S3 viel zu unbefriedigend. Gefühlt etwa eine Sekunde bis der gespielte Ton kommt - gemessen sicher deutlich weniger.

    Außerdem habe ich den Eindruck, dass die Klangqualität eben doch nicht vergleichbar ist mit HW / GO, auch wenn es sich augenscheinlich um die gleichen Samples handelt. Ich bin mir nicht sicher, aber es macht mir eher den Eindruck, dass nicht für jeden Ton ein eigenes Sample verwendet wird, sondern vielleicht nur ein Sample pro Oktave.

    Von Offenbass hat man zum Thema ja seither auch nichts mehr gelesen - ich kann nur vermuten, dass auch da die Latenz wohl zu hoch war. Das angepriesene Galaxy Nexus Smartphone mit dem das in ausreichender Geschwindigkeit funktioniert, gab es leider damals schon nicht mehr zu kaufen.
    Irgendwo hatte ich dieser Tage aber erst gelesen, dass ab Android Version 5 alles besser sein soll ?! Zu wünschen wäre das, denn die APP ist ansonsten prima und für unterwegs würde mir den Klang auch reichen.

    Hallo Christoph,

    das ist echt super wie Du Dich in das Thema ODF Programmierung hinein denkst. Es ist schon nicht so ganz einfach, vor allem wenn man versucht alle Optionen für ein Sampleset auszuschöpfen. Da ist es schon äußerst hilfreich, zumindest eine grundsätzliche Ahnung einer höheren Programmiersprache zu haben. In Zeiten von Commodore C64 Rechnern hatte wenigstens die Programmiersprache "Basic" in der Bevölkerung schon fast zur "Allgemeinbildung" gehört. :) Das ist seit Einführung von Windows-PCs leider wieder passé.

    Fortran und Pascal hatte ich dann während meines Studiums auch gelernt, aber später nicht mehr verwendet, denn dann war C mehr gefragt und später C++ als objektorientierte Sprache. Wenn man aber mal das grundsätzliche Prinzip von Programmiersprachen begriffen hat, dann ist eine weitere neue Sprache meist kein allzu großes Problem.

    PHP hat da auch wieder viele Parallelen und könnte Dir jetzt gerade in Verbindung mit GrandOrgue ODF sehr nützlich sein! Das was mir in GO-ODF immer an Möglichkeiten gefehlt hatte, das kann recht einfach mit PHP sogar "innerhalb der ODF" ergänzt werden. Da Du offenbar sowieso schon Berührungspunkte zu PHP hattest kann ich Dir nur dringend raten, mal ein Stündchen zwischendrin zu investieren und Dir den folgenden Thread anzusehen und zu verinnerlichen:

    MPS Orgelseite: Möglichkeiten der ODF Programmierung

    Hier hat martin anhand der von mir geäußerten Bedürfnisse eine Lösung geschaffen, die an Flexibilität und (relativer) Einfachheit kaum noch zu übertreffen ist. Alle anderen ODF-Generatoren usw. führen da stattdessen zwangsläufig in eine Sackgasse in der es nicht weiter geht, oder wenn, dann nur durch mühsame Hilfskonstruktionen, so wie Du es im Moment mit hin und her kopieren von einzelnen Programmteilen handhabst. Das alles könnte Dir PHP innerhalb von nur einer zu pflegenden Datei abnehmen !!
    Die funktionierende Grundkonstruktion ist fertig. Man kann das praktisch auch ohne PHP-Kenntnisse anwenden (hab ich auch nur ganz rudimentär).

    [hr]
    Zu Deinem aktuellen Problem:

    Sobald man ein Sampleset geladen hat, Einstellungen tätigt, wie z.B. alleine schon die Midi-Zuordnung der Klaviaturen und dann abspeichert, dann wird eine Datei mit diesen Einstellungen abgelegt, auf die fortan zurückgegriffen wird. Diese wird dann in Zukunft immer beim Laden dieses Samplesets verwendet. Das Problem ist aber, dass wenn man selbst eine ODF programmiert, sich dann dieses "Sampleset" permanent verändert und nicht gleich bleibt. Hinzu kommt, dass man gerne immer die aktuellste GO-Version installiert. Über kurz oder lang passt dann diese "Einstellungsdatei" nicht mehr mit den Gegebenheiten der GO-Version oder der ODF überein und es kommt zu solchen unerklärbaren Phänomenen. Martin kann da sicher technisch genaueres dazu sagen.

    Ich umgehe das wenn möglich, indem ich in der Entwicklungsphase einer ODF gar nicht auf "Speichern" gehe und damit keine Datei angelegt wird. Wenn nicht möglich, dann sollte zumindest nach größeren Änderungen im GO-Menü "Datei" der Punkt "Vorgabewerte wiederherstellen" angeklickt werden. Damit wird diese Einstellungsdatei zurückgesetzt und die Einstellungen müssen dann eben für die aktuelle GO/ODF Datei erneut vorgenommen werden.
    Damit sollte dann wieder alles normal funktionieren bis zur nächsten gravierenden Veränderung.

    Gruß Michael

    Zitat

    Original geschrieben von chilissimo

    ich bin gerade auf so 'nem Retro-Trip und
    hab mal wieder die "erste" GrandOrgue Version 0.1 rausgekramt :-O

    Grenzt irgendwie schon an Selbstgeißelung - oder? :/
    Schläfst Du nachts auch auf einem Nagelbrett ?

    Auf gut Deutsch:

    Keine Kaufempfehlung für solche kleinen Geräte, außer man will das unbedingt !
    Man kann damit nur sehr sehr kleine Orgeln spielen.

    Wenn irgend möglich, dann lieber einen normal großen PC kaufen oder wenigstens einen ordentlichen Mini-PC mit einer CPU der Firma Intel und möglichst viel Arbeitsspeicher (mind. mehr als 8 GB RAM).

    Da hat sich seither kaum was geändert. Sogar die CPU-Preise sind weitgehend stabil geblieben. Beim Mainboard-Standard mit Sockel 1155 ist jetzt stattdessen der Sockel 1150 aktuell. Dementsprechend sind die Bezeichnungen für i5 und i7 CPUs auch etwas andere.

    Beim Audio-Interface ist zu überlegen ob man sich noch ein Delta 1010 zulegen möchte, da es in den aktuell größeren Sockel 2011 Mainboards meist nicht mehr verwendet werden kann. Ich würde auf den Onboard-Sound zurückgreifen und wenn unbedingt Geld dafür ausgegeben werden soll, dann ein externes kaufen. Bei Windows sind die Steinberg UR22 oder UR44 zu empfehlen und bei Linux ist es wichtig ein damit kompatibles Audio-Interface zu verwenden.
    RME ist sicher auch nicht schlecht aber eben sehr teuer, weil die meisten Funktionen die darin enthalten sind nicht gebraucht werden. HW/GO greift nur auf den D/A-Wandler der Karte zurück. Alle anderen teuren Bauteile der Karten sind dabei absolut unnütz. Es sei denn, man will darauf z.B. gleichzeitig auch ein kleines Tonstudio betreiben.

    Auf eine SSD würde ich heute nicht mehr verzichten wollen. Die aktuellen HW-Versionen laden jetzt auch deutlich schneller von einer SSD.

    Oh nein - natürlich auch nicht.
    Die bleiben im Auto und gucken mir durch die großen Scheiben des Restaurants beim Essen zu ;-D
    Das geht im Frühjahr oder Herbst ganz gut, aber nicht im Winter oder im Sommer,
    weil es da zu kalt bzw. zu heiß im Auto wäre ;)