Junge, Junge, wie die Zeit vergeht, in dem Jahr war ich Neuling hier...
In der Tat gibt es verschiedene Vorlieben für die Darstellung der Screens. GO bietet verschiedene Möglichkeiten , sowohl animierte Komplettscreens wie auch Pnels auf denen lediglich grafisch minimierte Stopps gezeigt werden. Ich komme damit recht gut zurecht. Meine Composite Orgel hat sowohl einen Komplettscreen wie auch Panels zum Programmieren der Walze. Da am Ende meines Projects alle Stopps von der Orgel selbst bedient werden brauche ich die Panels lediglich zum Programmieren der Walze oder Setzer
Gruß
Bernd
Kann das an der Übersetzung liegen? Ich verstehe, dass "Windows" in der Menüleiste in der deutschen Version von GO mit "Ansicht" (Singular) übersetzt wurde. In der niederländischen Version ist es "Venster", was (vielleicht besser) mit "Fenster" ins Deutsche übersetzt werden kann. Aufmerksamkeitspunkt für Michael?
Ich muss mich korrigieren. Allerdings steht in der deutschen Version „ANZEIGE“ und nicht „Ansicht“ und ich war auch etwas zu schnell und nachlässig mit der englischen/internationalen Version. Dort heißt es nicht „Windows“, sondern „Panel“.
Ich habe auch auf die niederländische Übersetzung verwiesen, weil Michael gerade an einer Überarbeitung der deutschen Übersetzung arbeitet.
Wenn aber "ANZEIGE" das beste deutsche Wort ist, um anzuzeigen, dass sich die Bedienfelder/Bedienfenster darunter befinden, wird mein Vorschlag gerne fallen gelassen.
Genau so hat ein Interface für einen Orgelspieler nachdem die Software konfiguriert wurde auszusehen.
Genau so? Dies ist auch mit GO möglich, zum Beispiel:
Ich habe ein Update der GrandOrgue-Version meiner OnderhorstKabinetorgel in Vorbereitung. Die neueste Version von GO erforderte eine Anpassung des Odf, um die Beschriftungen auf den Registern lesbar zu halten. Ich möchte diese Gelegenheit nutzen, um gleichzeitig einige weitere Verbesserungen vorzunehmen. Eine davon ist das Hinzufügen eines Simplescreens für die Bedienung.
Ich habe
gerade am Layout gearbeitet, als diese "Einladung zum Plagiat"
hereinkam. Um ehrlich zu sein, bin ich mit dem Ergebnis sehr
zufrieden, (@VPO
) also wenn VPO keine Einwände dagegen hat, dass ich so von
ihm "inspiriert" werde
, dann wird es so sein (danke).
(N.B. Die
Veröffentlichung des Updates/Upgrades wird noch eine Weile dauern, da ich
auch den Tremulanten auf das gleiche Niveau wie in der HW-Version
bringen möchte
)
Genau so? Dies ist auch mit GO möglich,
Das ist doch jetzt mal ein tolles Beispiel, was mit GranOrgue alles möglich ist. 
Da bin ich schon gespannt auf die neue Version der Onderhorst.
Was muss man genau beachten, um die Schrift lesbar zu halten? Ich wollte auch mal nach und nach meine alten ODF überarbeiten und in die Filebase stellen.
Was muss man genau beachten, um die Schrift lesbar zu halten?
Ideal wäre es wenn man bei GO die Möglichkeit anbieten würde mit Vector Grafiken zu arbeiten. Diese können ohne Qualitätsverlust auf alle Auflösungen skaliert werden und bieten sich für solche Zwecke geradezu perfekt an. Im Grunde weg von dieser genauen Pixelangabe und sagen Breite und Höhe sind 1000 und ich positioniere Button 1 auf 25x25 mit der Höhe 10 und Breite 50 Pixel. Dann kann GO das auf jede beliebige Auflösung automatisch anpassen.
Das ist doch jetzt mal ein tolles Beispiel, was mit GranOrgue alles möglich ist.
Da bin ich schon gespannt auf die neue Version der Onderhorst.
Was muss man genau beachten, um die Schrift lesbar zu halten? Ich wollte auch mal nach und nach meine alten ODF überarbeiten und in die Filebase stellen.
Die Skalierung des Bildes funktioniert soweit ich das bisher testen konnte grundsätzlich gut. Samplesets mit unterschiedlichen Bildgrößen werden jetzt auf meinem kleinen Bildschirm richtig und angemessen dargestellt.
Ich habe nur ein Problem mit bemerkt mit der Schriftgröße der im Odf definierten Texte. Ich habe für “DispLabelFontsize” den Standardwert "Normal" verwendet. Dies ergibt nun aber eine viel kleinere Schrift. Ich habe auf GitHub gefragt, ob dies ein vielleicht ein "Bug" ist oder die neue Normalität, aber habe bisher noch keine Antwort erhalten.
Wenn aber im Odf “DispLabelFontsize=Normal” durch “DispLabelFontsize=Large” ersetzt wird, wird der Text wider wie bisher angezeigt.
Was passiert, wenn man statt "Normal" oder "Groß" eine Zahl eingibt, habe ich noch nicht getestet.
Ich plane, dies zu tun, bevor ich die ODFs anpasse, die ich in die Filebase geladen habe
Für den Simplescreen für die Kabinettorgel habe ich mich jetzt für grafische Abbildungen der Buttons inklusive Text entschieden. Dadurch wird sichergestellt, dass der Text proportional zum Bild skaliert wird, unabhängig davon, was sich sonst noch im GO-Programm ändert.
Ideal wäre es wenn man bei GO die Möglichkeit anbieten würde mit Vector Grafiken zu arbeiten. Diese können ohne Qualitätsverlust auf alle Auflösungen skaliert werden und bieten sich für solche Zwecke geradezu perfekt an.
Dann kann GO das auf jede beliebige Auflösung automatisch anpassen.
Im Grunde weg von dieser genauen Pixelangabe und sagen Breite und Höhe sind 1000 und ich positioniere Button 1 auf 25x25 mit der Höhe 10 und Breite 50 Pixel.
Also ist es jetzt schon ganz einfach
"Schwellwerk" in deutscher Schreibweise finde ich sehr gut.
Bevor man eine Kopie zieht, sollte man die Weiterentwicklung abwarten und erst mal mit einer Code-Analyse beginnen.
Ein paar Gedanken als Beitrag zur Diskussion über die mögliche Zukunft von GO:
- Für eine komplette Neuprogrammierung könnte die moderne Programmiersprache PY (Python) infrage kommen. Da tut sich momentan viel, insbesondere auf dem Gebiet „Industrie 4.0“. Für VR (Virtual Reality) und auch für die Spieleprogrammierung gibt es da kostenlos geniale Grafikbibliotheken. Für PY scheint es auch funktionierende MIDI-Treiber zu geben: https://pypi.org/project/py-midi/
Zudem soll sich angeblich auch ASIO integrieren lassen. Heutzutage scheint PY für technikaffine Studenten die erste Wahl zu sein.
- Anstatt einer vollständigen Neuprogrammierung könnte sich ggf. ein Aufsatz auf „Kontakt“ lohnen. In den letzten Jahren hat sich „Kontakt 5“ zum quasi Industriestandard für virtuelle Instrumente gemausert (mitteleweile in V6 verfügbar). Den Player gibt es kostenlos. https://www.chip.de/downloads/Kontakt-6-Player_79967104.html
Auch bei Miditzer scheint es schon Überlegungen in diese Richtung gegeben zu haben:
https://miditzer.org/forum/viewtopi…cc36b7a9e2aaf39
Vermutlich muss man sich bei NI die Vollversion kaufen, um die passende Entwicklungsumgebung zu erhalten.
Wenn ich mich recht erinnere hat da schon vor längerer Zeit innerhalb des Orgelforums jemand berichtet, dass er seine vO nach Kontakt „exportiert“ hat.
Mit Linux könnte Kontakt so seine Probleme haben; ist halt keine openSource-Software.
Ich denke Python ist da gänzlich ungeeignet. So gerne ich selbst Python nutze, solche Projekte werden dort keine Freude machen. Eine Sprache die interpretiert ist, ist für Echtzeit Anwendungen absolut ungeeignet.
Ja die GUI z.B könnte man gut in Python umsetzen, aber logisch betrachtet sofern man ohnehin wenig Manpower hat wäre es nicht klug verschiedene Sprachen zu nehmen. Ich persönlich würde keine Audiomanipulation in Python machen wollen. Ich bin schon über einige Probleme gestolpert als ich einen simplen Jack Stream in einer MP3 speichern wollte.
Ja ich weiß mit verschiedenen Python Interpretationen oder nativen Compiler kann man viel machen, aber da muss man schauen ob das auch auf allen Plattformen gut läuft. Spätestens bei Android und iOS wird es kompliziert. Vor allem wenn man native Bibliotheken nutzt.
Wenn ich JavaScript besser könnte, dann würde ich ja glatt sagen Javascript mit NodeJS wäre eine super Sache. Läufdt auf jeder Hardware und ist sehr flott. Aber mit JavaScript kann man eben auch Code schreiben der ganz mies ist
C# wäre zum Beispiel eine gute Sprache für so etwas. Läuft mit Mono unter jedem System und die Sprache ist sehr modern.
...Vermutlich muss man sich bei NI die Vollversion kaufen, um die passende Entwicklungsumgebung zu erhalten.
Wenn ich mich recht erinnere hat da schon vor längerer Zeit innerhalb des Orgelforums jemand berichtet, dass er seine vO nach Kontakt „exportiert“ hat.
Mit Linux könnte Kontakt so seine Probleme haben; ist halt keine openSource-Software.
Jeder kann (das ist nicht wirklich einfach) , wenn er will und die Kontakt Vollversion und auch noch die passenden Samples hat, sich eine Orgel damit bauen. Er könnte das Instrument dann auch weiterverkaufen (Rechteeigentum an den Samples vorausgesetzt) entweder nur an die, die auch die Kontakt-Vollversion haben oder an die die den Player haben. Dann muss man sich aber auch mit NI auseinandersetzen, da die dann mitverdienen. Andererseits braucht dann der Käufer kein Geld für den Sampler auszugeben, da dieser ja dann kostenfrei ist.
Ich komme ja durchaus aus dem "Kontakt" Universum. Da gibt es wirklich geniale Instrumente. Ich habe auch dort eine Orgel, da allerdings ist z.B. das Ziehen der Register eben nicht so einfach möglich.
Ich denke schon, dass hier NI-Kontakt komplett anders arbeitet, als z.B. HW, das ja letztlich auch nur ein "Sample-Player" ist, aber mit Funktionen, die genau auf Orgeln ausgerichtet ist. Kontakt macht da ganz andere Dinge. Kontakt ist ein Generalist. Ich befürchte, dass das eine Orgel mit den Funktionen, die man als "Orgelspieler" erwartet, nicht funktionieren wird.
Kontakt ist ein Generalist. Ich befürchte, dass das eine Orgel mit den Funktionen, die man als "Orgelspieler" erwartet, nicht funktionieren wird.
Genau so ist es. Deswegen wurde ja Hauptwerk erfunden und konnte so erfolgreich werden. Von diesem Konzept wieder ab zu kommen, hin zu Kontakt o. ä. Sampleplayern, wäre ein Gang zurück in die Steinzeit.
Mir scheint, die Komplexität von GrandOrgue wird von Manchen völlig unterschätzt. Die Kunst ist nicht, eine schicke Programmiersprache zu finden, sondern einen Programmierer zu finden, der so eine hoch komplexe Aufgabe überhaupt versteht und dann auch noch lösen kann.
Das Anforderungsprofil für einen GO-Programmierer lautet ungefähr:
Sehr gute Kenntnisse im Orgelspiel
Gute physikalische Kenntnisse, besonders in der Akustik
Sehr gute Kenntnisse in numerischer Mathematik
Tiefgreifende Kenntnisse in der Audio-Signalverarbeitung
Ausreichende Kenntnisse in maschinennaher Programmierung
Weitreichende Kenntnisse von Programmierung in gängigen Hochsprachen
Ausreichend Kenntnisse über verschiedene Betriebssysteme
Wenn möglich gute Kenntnisse über strukturierte Programmierung
Am besten auch Ahnung von grafischen Benutzeroberflächen und Ergonomie
Im Idealfall auch noch die Bereitschaft und Fähigkeit für Teamwork
Der feste Wille, täglich über Jahre hinweg kostenlos zu arbeiten
Solche Leute gibt es nicht wie Sand am Meer! Ein Wunder, wenn sich da überhaupt jemand findet. Da ist die Chance am größten, wenn man eine der weit verbreiteten etablierten Programmiersprachen verwendet, die für so etwas überhaupt geeignet sind. Da landet man wohl unweigerlich bei C / C++.
Für eine kommerzielle Orgelsoftware findet man vielleicht etwas eher so einen Programmierer. Aber nur vielleicht.
Insofern ist es für mich müßig, über eine Neuprogrammierung von GrandOrgue zu reden. Wir sollten froh sein, dass wir so eine Software bereits als Open Source in der Hand haben und einfach versuchen, diese zu verbessern. Selbst dafür finde ich hier offensichtlich niemanden.
Mikelectric die Programmierer oder jemand aus dem Team wären clever wenn sie sich an z.B Hochschulen und Universitäten wenden. Da könnten Studenten aus diesen Fachrichtungen dran arbeiten, viel lernen während sie auf dem vorhandenen aufbauen und Verbesserungen könnten in das Projekt zurück fließen. Nebenbei begeistert man so junge Menschen für das Instrument.
