Support for Ubuntu 18.04 ends on April 2023, so the user should use a newer version, or should build his GrandOrgue himself. Those who cannot or do not want to switch can use Flatpak. https://flathub.org/apps/details/net.sourceforge.GrandOrgue
So, it won't be possible (easily) to release new version of GrandOrgue for old systems after that date.
Wouldn't an AppImage be an option that Github allows? That works on all systems. https://en.wikipedia.org/wiki/AppImage
gibt es eigentlich wieder eine Quelle die man bei seiner Distribution einfügen kann um über Updates informiert zu werden?
Da ich die Schwellerlogik in den Code für die Manual-Tastenabfragen mit reinmachen und während Schwellerbetätigung weiterspielen will, habe ich mit "millis()" gearbeitet. Im Endeffekt das gleiche, nur dass hier gemessen wird, wieviel Zeit seit dem letzten Aufruf vergangen ist, statt eine Programm-weite Pause einzulegen.
Zu dem Thema würde ich dir das Thema Multitasking mal nahelegen. Der Arduino hat die Bibliothek Scheduler.h. Im Grunde erstellst du mehrere Funktionen und diese laufen nebeneinander zu gleichen Zeit. Hast du Funktion A und Funktion B, dann läuft A ganz normal weiter wenn B auf etwas wartet. Dabei muss man jedoch im Hinterkopf behalten, dass man da mit etwas Glück einen Code bauen kann, der nicht mehr zu debuggen ist 
Hier mal ein Beispiel, wo der normale Loop des Programms läuft und nebenbei gleichzeitig noch Loop2 und Loop3.
In deinem Fall könnte im normalen Loop die Tastenabfrage stehen und im Loop2 könntest du alles was den Schweller betrifft regeln.
Ich überlege ja immer noch wie ich einen bzw. zwei Kniehebel für ein Harmonium midifizieren könnte. Dann könnte ich mit GO gut Harmonium mit Ausdruck spielen. Aber das ist technisch wohl genau so verzwickt wie ein Schweller und außerdem habe ich noch kein gutes Sampleset gefunden für das sich der Aufwand lohnen würde.
Die Frau (Sabine) ist ziemlich fähig in dem, was sie da produziert.
Ja dem kann ich nur zustimmen. Ich vermute einmal sie wird einen entsprechenden technischen Hintergrund haben. Das ist definitiv keine Laienarbeit. Was sie macht ist natürlich nur ein möglicher Weg. Wie sagt man doch so schön? Viele Wege führen nach Rom. Das mit der Schräge am Brett wusste ich aber auch nicht.
Wenn man den Fuß aufs Schwellpedal auflegt, könnte man z.B. die ersten ca. 200 ms ignorieren, um die dadurch ungewollte Bewegung des Pedals bzw. Midi-Signale zu vermeiden.
Auf den ersten Blick eine gute Idee, auf dem zweiten jedoch nicht. Wie will der Controller wissen dass du gerade erst den Fuß auf das Pedal legst und nach wann nimmt er an, dass du das Pedal nicht nutzt? Ich spiele ein längeres Stück auf dem Manual, der Schweller bleibt erst einmal in dieser Position, bis er minimal verändert wird um ganz leicht zu justieren. Dann würde das schnell ignoriert werden. Man könnte natürlich eine Lichtschranke oder so einbauen, aber das wäre glaube ich absurd
Wie würde man das machen, wenn der Zielwert durch verzögertes hochzählen noch nicht erreicht ist und sich das Pedal schon wieder in der Gegenbewegung befindet? Das Hochzählen abbrechen und in die aktuelle Richtung zählen? Wie groß sollte man die Zeitspanne wählen, die einem Vollausschlag 0..100 (oder als Midi 0..127) entspricht? 750ms?
Ich habe es recht einfach gelöst. Die Steuerung besteht aus zwei Teile. Der eine Teil erfasst die aktuellen Messwerte und speichert diese ab. Der zweite Teil kümmert sich um die Midi Daten. Ich nutze da einen Timer. Im Loop läuft die Erfassung ständig und in einem gewissen Intervall (z.B 250ms) wird die zweite Funktion einmal aufgerufen. Die nutzt im Grunde zwei Variablen. Die IstStellung also der Wert der als letztes per Midi gesendet wurde und die SollStellung welche die Messungen ergeben haben. Nun folgt eine kleine Abfrage nach dem Prinzip Wenn IstStellung < SollStellung dann IstStellung + 1. Wenn IstStellung > SollStellung dann IstStellung - 1. Dann wird die aktuelle IstStellung gesendet. Wenn jedoch IstStellung = SollStellung, dann passiert nichts.
Das ist eigentlich die simpelste Lösung. Man kann da auch endlos verfeinern mit größeren Schritten je weiter man von der SollStellung entfernt ist und immer kleinere je nähe man kommt und so weiter.
Ich würde da aber zu einem Pi Pico raten als Controller. Mit 5 Euro unschlagbar günstig und der Vorteil gegenüber dem Arduino ist dass man ihn dank Python sehr gut Debuggen kann. Beim Arduino muss man beim experimentieren ständig Compilieren, schreiben und dutzende Printausgaben über die Serielle Verbindung machen um überhaupt zu sehen was passiert. Beim Pico muss ich das Programm nicht einmal schreiben, es wird einfach übergeben und befindet sich nur im Ram. Der unschlagbare Vorteil ist aber dass ich so während das Programm läuft alle Werte sehen kann und sogar Parameter ändern kann die sofort gelten.
in dem Video und dem dort verlinken Code wirst du bestimmt auch einige Anregungen finden. Wenn du einen 3D drucker hast kannst du das sogar selbst drucken, oder mit der Datei bei jemanden bestellen.
Gerade wieder gefunden
Ich kaufe daher jetzt einigermaßen helle E10 LEDs und fertig.
Hast du schon einmal LED's ausprobiert? Ich habe die Erfahrung gemacht dass nicht alle Fotowiderstände (vor allem ältere) mit LED zurecht kommen. Du musst auch darauf achten dass deine LED einen anständigen Treiber hat bzw. eine stabilisierte Spannung anliegt. Andernfalls flimmern die LED in der Netzfrequenz und dann hast du keine stabilen Werte da die Widerstände sehr schnell so was erkennen.
Mein Schweller kommt aus einer alten Wersi Orgel und da habe ich auch eine 5v Birne verbaut. LED hat bei mir nie gut gearbeitet und so ein gedimmtes Lämpchen lebt ja auch eine Ewigkeit.
Kopfzerbrechen hat mir die "Glättung" der Midi Signale bereitet. Also gerade wenn man seinen Fuß auf das Pedal setzt oder wegnimmt, dann ändern sich die Werte durch die Bewegung sehr stark und das will man ja nicht haben. Auch dass ohne Bewegen des Schwellers mal die Werte etwas schwanken will man ja nicht ständig übertragen, da es unnötig ist und das System beansprucht. Ich habe mir daher eine Routine geschrieben die nicht sofort bei einer Veränderung Daten sendet, sondern mehrmals hintereinander schaut ob die Werte plausibel sind. Bedeutet ich habe z.B einen Wertbereich von 0 - 100 und bei der ersten Messung in der eine Veränderung eintritt habe ich 10, dann 1. Dann kann ich davon ausgehen, dass die 10 zustande gekommen ist wegen einem Aufsetzen oder Absetzen des Fußes. Zusätzlich sendet mein Pico (habe es nicht mit dem Arduino gemacht) bei schnellen Veränderungen diese langsam. Bedeutet ich bringe z.B den Schweller von der Startposition in die Endposition so schnell es geht. Dann sendet mein Programm die Veränderungen nach und nach, also nicht Wert 0 und dann Wert 100 sondern über die Zeit 1,2,3,4,5,usw. eben so wie ein echter Schweller wo man die Klappen bewegt auch reagieren würde. Alles andere hört sich nämlich falsch an.
Also einige Herausforderungen zum Programmieren, aber es lohnt sich. Aber in der Praxis nutze ich den Schweller kaum, eher Crescendo.
Ich benutze GrandOrgue schon sehr lange und ich kann nicht wirklich Probleme daran erkennen. In der Regel liegen Probleme mit GrandOrgue eher an der Hardware oder am Unvermögen der Anwender.
Naja, wenn alles so ideal ist, dann stellt sich ja die Frage warum die Anbieter von Samplesets diese in der Regel nicht für GO verfügbar machen. Nebenbei sagte ich ja nicht dass GO schlecht sei, sondern lediglich dass ich keine große Zukunft im Moment sehe und ich äußerte ja auch mein Bedauern darüber. GO ist quasi die einzige freie Lösung für Sample basierte Orgelsimulation und daher ohne Alternative im freien Sektor. Einige ganz wenige Sets zeigen ja auch dass GO einiges kann und sich nicht verstecken muss. Aber auf regulären Weg bleiben dem GO Nutzer die meisten Sets verwährt. Abgesehen von dem Wunsch der Hersteller ihre Sets schützen zu können (was durchaus berechtigt ist) beklagen sich ja auch viele darüber das die Sets in GO im Vergleich zu HW doch sehr anders klingen. Woran das nun liegt sei mal dahingestellt, aber die Anbieter von Sets haben scheinbar ein Problem mit GO und alleine schon aus diesem Grund ist GO eben keine gute Alternative für diejenigen die gerne ein bestimmtes Set nutzen wollen was es eben nicht dafür gibt.
Natürlich kann man DRM und co kritisch sehen (ich mag es auch nicht), aber eine Orgelsimulation lebt nun einmal von verfügbaren Sets und wenn die Hersteller ihre Gründe haben diese nicht anzubieten, dann müssten die Entwickler schauen was sie dagegen tun könnten. Moralisch ist es vielleicht richtig einige Wünsche nicht umzusetzen, aber den Nutzer der möglichst viel möchte ist Moral da eher egal.
GO profitiert eben davon dass es keine freie Alternative gibt. Solche Dinge wie JOrgan brauchen wir vermutlich nicht erst betrachten. Bei den meisten Fähigkeiten von GO ist man eben darauf angewiesen dass ein Ersteller von einem Set diese auch nutzt. Der normale Endnutzer (wie ich) kann sich überhaupt nicht daran setzen und hoch komplexe Modifizierungen vornehmen direkt in den ODF. Es mag ja sein das GO allen anderen überlegen ist, aber das meiste davon ist für den Laien der sich nicht hunderte Stunden etwas über diverse Quellen aneignet überhaupt nicht nutzbar.
Wann sollte das gewesen sein? Seit Du hier im Forum bist, höre ich von Dir jedenfalls nur Gelästere über GrandOrgue.
Ich habe leider kein Protokoll wann ich wo etwas einreiche. Aber ich stehe ja durchaus nicht alleine mit der Meinung da, dass GO so wie es jetzt ist kaum zu überschauen ist. Tausende Zeilen Code ohne ein einzigen Kommentar, Umsetzungen wo sich jeder Programmierer fragt "Warum?" und so weiter. In einem anderen Thread sind wir ja schon soweit gekommen, dass man wohl Jahre und sehr fähige Programmierer brauchen würde um dort eine saubere Struktur reinzubekommen, so dass man auch mithelfen könnte.
Ich kann mich nicht erinnern, dass du jemals etwas für GrandOrgue getan hättest.
Ich habe einige Fehler gemeldet und Ursachen für abstürze inkl. Patch der die Ursache löst. Die einzige offizielle Reaktion war immer "Der Kreis der Betroffenen ist zu gering als dass sich das einpflegen des Patches lohnt".
Ich kann mich noch nicht mal erinnern, dass du GrandOrgue jemals so intensiv benutzt hättest, dass du die vorhandenen Funktionen wirklich kennen würdest, um überhaupt so ein Urteil zu fällen.
Ich habe es sehr lange sehr intensiv genutzt (als Anwender nicht Ersteller von Sets) und habe mich nach einem oder zwei Jahren eben dagegen entschieden weil die Probleme in anderen Lösungen nicht auftreten und dort Funktionen nutzbar sind die GO so nicht bietet. Davon abgesehen kann GO hunderte nützliche Funktionen haben, wenn bestehende Fehler nicht behoben werden, dann ist das eben eher ein Nachteil.
Und warum lässt man die MacOS-Anwender, die noch die Intel-basierte Hardware der Jahre 2009 bis 2018 mit MacOS 10 verwenden und nicht schon wieder updaten können bzw. wollen, im Regen stehen?
Vermutlich weil GO inzwischen zu einer One Man Ego Show geworden ist. Ich rechne dort ehrlich gesagt nicht mehr mit Fortschritten die über ein paar Textänderungen und kosmetische Dinge gehen. Bei Github sieht man ja recht schnell wer das sagen hat und was er zu notwendigen Maßnahmen sagt. Es ist offensichtlich das außer ihm keiner was beizutragen hat und jeder der es doch versucht, der wird als Ketzer verbrannt.
Ich hoffe dass ich mich irre, aber GrondOrgue wird in dieser Form nicht mehr weiterentwickelt werden. Von Version v0.3.1.2342-1 bis v3.8.0-1 gab es quasi nichts neues, außer ASIO und über den Nutzen kann man nun streiten. Der Rest waren solche Dinge wie "Fixed hyperlinks to the GO distribution in INSTALL.md" oder noch viel innovativer "Fixed translation of temperaments' names".
Nein, ich denke der Zug ist abgefahren. Vielleicht forken es fähige Programmierer bzw. ein Team von Programmierer und investieren erst einmal 2-5 Jahre Ordnung reinzubringen um dann zu schauen ob es Sinn macht, oder man neu anfängt.
mal kritisch nachgefragt, passiert bei GO im Moment eigentlich etwas, außer ein paar Bugfixes die eigentlich nicht erwähnenswert sind?
Gib gerne mal eine Rückmeldung...
So, ich habe mich nun das erste mal in meinem Leben daran gemacht eine ODF zu erstellen... Vermutlich totaler Murks, aber es lädt die Orgel
Einfach die Definition entpacken und in den Hauptordner kopieren. Getestet mit GO unter Linux. Vielleicht ein guter Anfangspunkt um damit weiter zu arbeiten... Viel Glück 
Ich würde mich da auch sehr interessieren, ist ein schönes kleines positiv. Wäre auch sehr schön z.B für alte Hardware. Vielleicht findet sich ja jemand, sollte ja für jemanden der sich etwas damit auskennt kein so großer Akt sein. Muss ja optisch nicht genau so umgesetzt werden. Einfach die Buttons erst einmal und gestalten kann man das dann immer noch.
Sehe ich es richtig, dass die Änderungen eigentlich nur Ordnung in das Projekt bringen und einen kleinen Fehler beheben?
Wäre ganz praktisch wenn man eine Stabile Version anbietet und eine mit Neuerungen. Dann könnte man seine Update Notwendigkeit besser bewerten und tappt nicht ungewollt in eine experimentelle Version.
Alf du könntest dich vielleicht mal an Dietrich Wierczeyko von Binaturalpipes wenden. Er hat schon viele Orgeln sehr gut aufgezeichnet und kennt die Probleme vermutlich und wird dir bestimmt wenn du freundlich fragst ein paar Ratschläge geben. Zumindest so wie ich ihn einschätze ist er sehr offen für solche Dinge.
Vielleicht gibt er dir ein paar Tipps wie du mit den Problemen umgehen kannst. Vor allem bei dem erstellen von Dry Sets ist das Problem der lauten Umgebung ja immer ein gewisses Problem. Gut hier haben wir eine Orgel da ist absolute Stille weil die gesamte Windanlage in Nebenraum ist, aber so was ist sehr selten
Der Gleichrichter- und Gebläsebrumm macht sich bei den höheren Tönen besonders stark bemerkbar, es entsteht quasi eine Zweistimmigkeit.
Ich vermute der Ton vom Gebläse wird genau so wie Pfeifen untereinander auch in der Tonhöhe von der Pfeife dazu verändert
Ideal wäre da bestimmt eine Orgel ohne Motor mit Handbetrieb
Hat zufällig jemand Erfahrung mit dem Rausrechnen solcher Grundgeräsuche? Wird da das Pfeifensignal "angeknabbert" und verliert an Fülle?
Entscheidend ist m. E., dass das Sample mit einem Nulldurchgang beginnt und ebenso endet.
Naja du kannst es mit dem Noisegate versuchen. Einen Stillen Teil analysieren und dann diesen Wert als Referenz nehmen und schauen wie viel du entfernt bekommst bevor der eigentliche Ton verändert wird. Aber das ist eben sehr schwierig und langwierig. Jedes entfernen verändert ja den Klang etwas.
Der Kopf spielt eben eine große Rolle beim fühlen. Natürlich beim konzentrierten üben blendet man vieles aus, aber es ist eben doch ein Unterschied ob man in der Kirche sitzt oder Zuhause. Selbst mit einer Kabine Zuhause bleibt es die eigene Wohnung und wird nicht zu einer Kirche. Man muss nur aufpassen wenn man besser ausgestattet ist als die Gemeinde, nicht das es Sonntag 9:30 Uhr klingelt und sie den Gottesdienst in deinem Wohnzimmer machen wollen 😅
