RE: RustyPipes Open Source VPO Software

10.12.2025 22:52

Soubasse
#16

So

Wiederum kann es sein, dass man bei der nächsten geladenen Orgel mit demselben Knopf bei NoteOn einschalten will, und lässt man den Knopf los, soll wieder aus sein. Eine Auswahl, wie der "Impuls" interpretiert werden soll, kann also sehr sinnvoll sein.

Wieso eigentlich ein MIDI-Mapping? Weil mehrere Geräte angeschlosssen sein können, die auf demselben MIDI-Kanal senden, z.B. mehrere baugleiche Keyboards? Wenn das der Fall wäre, könntest du doch vlt. alternativ nach Device unterscheiden. Jedes hat in einem Betriebssystem doch bestimmt seine eigene ID. Sowohl in GO, als auch HW kann man diese Unterscheidung nutzen, oder aber ignorieren. Dann müsste man halt die Kanäle der Eingabegeräte sauber trennen (so mache ich es beispielsweise).

Auch in der anderen Richtung ist das natürlich relevant, weil man beim MIDI senden aus GO/HW/Rustypipes ggf. nur bestimmte Empfänger adressieren will.

Antworten

Beitrag melden

#17

11.12.2025 00:51

Untersatz32
#17

Untersatz32

Ich sehe es auch so wie @Soubasse in der Regel wird man wohl nur ein bestimmtes Gerät zur Steuerung der Register nutzen.

Antworten

Beitrag melden

#18

11.12.2025 01:01

Dividebysandwich
#18

Dividebysandwich

Die Frage ist: Reicht es wenn z.b. man sagen kann "Das MIDI Event schaltet den Stop für Channel 2 ein"? Das mit dem Note on / note off ueberlege ich mir auch noch, ich glaube auch dass es Sinn macht dass man beides machen kann, also pures ein oder aus, oder als "momentary switch" via note-on/note-off.

Und die Sache mit dem MIDI Mapping ist deshalb weil ich damit Switches simulieren kann. Ich will mir nämlich ersparen dass ich die komplette Logik die in den Files definiert ist nachbauen muss.

Antworten

Beitrag melden

#19

11.12.2025 11:42 (zuletzt bearbeitet: 11.12.2025 15:10)

Dividebysandwich
#19

Dividebysandwich

RustyPipes v1.1.0 ist da!

MIDI Control mapping wurde eingebaut, inklusive Lernfunktion. Einfach mit der Maus auf ein Register klicken:

Am unteren Rand gibt es jetzt Buttons zum Aufnehmen, und zwar MIDI und Audio.

Die Files liegen dann im User Config Verzeichnis, Subverzeichnis "recordings"

... und in der kommenden Version wird es dann auch sowas geben:

Antworten

Beitrag melden

#20

11.12.2025 16:10 (zuletzt bearbeitet: 11.12.2025 16:11)

Untersatz32
#20

Untersatz32

Zitat von Dividebysandwich im Beitrag #19
... und in der kommenden Version wird es dann auch sowas geben:

Verstehe ich das richtig, das man über dieses Webinterface dann die Orgel steuern kann? Also quasi ein Client nur die entsprechenden Anfragen stellen muss?

EDIT
Ich schaue es mir das Wochenende mal an. Die Aufnahmefunktion kann man genau so wie die Register mit Midi anlernen? :)

Antworten

Beitrag melden

#21

11.12.2025 17:02 (zuletzt bearbeitet: 11.12.2025 17:33)

Dividebysandwich
#21

Dividebysandwich

Hi,

Ja ich arbeite gerade daran, im git repo habe ich aktuell folgende API Funktionen drin:

EDIT: Das ist eine Schnittstelle die man nutzen kann um eigene Steuerungen zu bauen. Ich habe jetzt nicht vor ein eigenes Web-UI zu machen. Man kann die Funktionen aber im Swagger-UI direkt testen.

Die Aufnahmefunktion via MIDI steuern funktioniert derzeit noch nicht. Das kann ich aber bei Bedarf einbauen, evtl. auch so Sachen wie mapping presets aktivieren. Es geht aber schon jetzt alles über die REST API.

Antworten

Beitrag melden

#22

11.12.2025 17:38

Untersatz32
#22

Untersatz32

Das hört sich wirklich gut an.

Vielleicht für irgendwann und nebenbei so eine Ideen. Bei Einstellen der "Preload Frames" wäre eine Erklärung ganz hilfreich was dies bedeutet und wie es sich auswirkt. Ich würde vermuten man kann mit der ODF doch bestimmt recht gut abschätzen was welcher Wert für einen Speicherverbrauch zur Folge hat.

Was passiert eigentlich mit dem Sample welches vom Datenträger gestreamt wurde und nun beendet ist. Wird dies wieder aus dem Speicher entfernt? Der Linuxsampler bietet zum Beispiel auch ein Steaming an, aber auch ein erweitertes wo man eine Ramgrenze festlegen kann und einmal geladene Samples dann im Speicher verbleiben bis diese Grenze erreicht wurde. Dann werden die ältesten Samples im Speicher gelöscht. So was wäre ja eigentlich recht praktisch für die Stabilität, vor allem bei großen Sets. In der Regel nutzt man gerade bei Literatur ja einen nur kleinen Tonvorrat immer wieder.

Ich habe nur absolut keine Ahnung ob man so etwas einfach umsetzen könnte.

Antworten

Beitrag melden

#23

11.12.2025 23:13

Dividebysandwich
#23

Dividebysandwich

Preload Frames beschreiben: Gute Idee, das ist derzeit nicht wirklich selbsterklärend.

Ich behalte im "normalen" Modus nur den Anfang aller Samples im Speicher. Ich hatte sogar schon einen Sample-pool implementiert so wie du das beschreibst, aber ist dann folgendes passiert: Bei Systemen mit ausreichend schneller Disk gab es keinen Unterschied, es wurde nur noch mehr RAM verbraucht. Und wenn ich die Disk künstlich verlangsamt habe kam es dann bei den nicht im Speicher befindlichen Samples zu Aussetzern - also jede erste Note war kaputt, und erst beim zweiten mal klang es Fehlerfrei. Und wenn dann Samples aus dem Pool geflogen sind war der entsprechende Ton beim nächsten mal wieder mit Aussetzern behaftet.

Bezüglich Stabilität... Das Programm ist in Rust geschrieben. Die Speicherverwaltung passiert mittels "Borrow Checker". Man muss sich da wirklich anstrengen um die klassischen "Read after free" und "Use before alloc" Fehler zu machen. Memory Leaks kann man zwar immer noch produzieren, aber auch da gibt es im Compiler mehrere Sicherheitschecks die viele Fälle abfangen bevor das Ding überhaupt compiliert. RustyPipes wird nicht stabiler wenn ich weniger Samples von der Disk lese. Ausserdem kann man ja immer das Precaching aufdrehen, dann verhält sich auch jedes Sample gleich.

Antworten

Beitrag melden

#24

12.12.2025 17:12

Dividebysandwich
#24

Dividebysandwich

RustyPipes v1.2.0 ist da. [Download]

* REST API
* Perkussionseffekte für Manuale und Pedal
* Hilfetexte im Config-Dialog (hover-labels)
* UI Verbesserungen

Bildanh�nge

{[norights]}

Antworten

Beitrag melden

#25

12.12.2025 21:48

Soubasse
#25

So

Soubasse

Jetzt muss ich nochmal ganz doof fragen: wieso eine REST API? Das verbinde ich zuallerletzt mit Orgelspielen. Ich dachte hier sei MIDI der Kommunikationsstandard?

Antworten

Beitrag melden

#26

13.12.2025 00:55 (zuletzt bearbeitet: 13.12.2025 01:15)

Dividebysandwich
#26

Dividebysandwich

Zitat von Soubasse im Beitrag #25
Jetzt muss ich nochmal ganz doof fragen: wieso eine REST API? Das verbinde ich zuallerletzt mit Orgelspielen. Ich dachte hier sei MIDI der Kommunikationsstandard?

Das ist keine doofe Frage. MIDI Controls werden auch unterstützt und ich werde das auch noch ausbauen, aber mit REST kann man halt bidirektionale Sachen machen wie z.b. die Liste der Orgelstops übertragen. Spätestens beim Selektieren des Reverbs oder dergleichen passt MIDI einfach nicht. Ausserdem ist es wesentlich leichter physische Controls mittels HTTP Requests anzubinden. Und bei so Sachen wie Stops wo das exakte Timing nicht so wichtig ist reicht REST vollkommen aus. Und es war ein User-wunsch.

Siehe auch: https://github.com/GrandOrgue/grandorgue/issues/1563

EDIT: Zur klarstellung, der Sinn der REST API ist nicht dass man damit die Orgel "spielt", so etwas werde ich auch nicht einbauen. Hier geht es wirklich nur darum es leichter zu machen physische Konsolen mit Schaltern etc. zu bauen ohne dass alles mit MIDI laufen muss.

Aber die REST API ist komplett optional und wer sie nicht verwenden will kann sie einfach ignorieren.

Ich habe auch überlegt OpenSoundControl zu implementieren, aber das Protokoll wird kaum verwendet und die Spezifikation ist nicht wirklich spezifisch genug um wirklich brauchbar zu sein.

Antworten

Beitrag melden

#27

13.12.2025 21:40

Untersatz32
#27

Untersatz32

Ich habe mal in die gui_config.rs reingeschaut, einen Ratschlag hätte ich für Texte. Wenn möglich solltest du die Text außerhalb des Quelltextes haben, damit man das Programm mühelos übersetzen kann. Ich biete mich da gerne für eine deutsche Übersetzung an.

Antworten

Beitrag melden

#28

14.12.2025 01:45 (zuletzt bearbeitet: 14.12.2025 13:42)

Dividebysandwich
#28

Dividebysandwich

Zitat von Untersatz32 im Beitrag #27
Ich habe mal in die gui_config.rs reingeschaut, einen Ratschlag hätte ich für Texte. Wenn möglich solltest du die Text außerhalb des Quelltextes haben, damit man das Programm mühelos übersetzen kann. Ich biete mich da gerne für eine deutsche Übersetzung an.

Es gibt jetzt ein "locales" Verzeichnis im git repo, dort gibt es ein en.yaml mit allen Texten. Einfach auf de.yaml umbenennen und drauflos editieren :)

Edit: ich habe mal maschinelle Übersetzungen hochgeladen.

Antworten

Beitrag melden

#29

15.12.2025 15:50 (zuletzt bearbeitet: 15.12.2025 16:01)

Dividebysandwich
#29

Dividebysandwich

RustyPipes v1.3.0 ist da! [Download]

x) Resampling wurde verbessert und CUE marker werden jetzt richtig skaliert
x) Hauptwerk sample sets die single-samples mit CUE markern verwenden werden jetzt unterstützt
x) MIDI display verbessert
x) Probleme mit symlinks wurden behoben
x) Es gibt jetzt Übersetzungen!
x) Kommandozeilen-option zum forcieren einer bestimmten Sprache

Das MIDI Display sieht jetzt so aus und zeigt alle Kanäle an, die evtl die gleiche Note spielen:

Derzeit unterstützte Sprachen:

English (en)
Deutsch (de)
Französisch (fr)
Italienisch (it)
Spanisch (es)
Catalan (ca)
Czech (cs)
Dänisch (da)
Finnisch (fi)
Irisch (ga)
Schottisch Gaelic (gd)
Ungarisch (hu)
Indonesich (id)
Japanisch (ja)
Koreanisch (ko)
Latein (la)
Norwegisch Bokmål (nb)
Niederländisch (nl)
Flemish (nl-BE)
Polisch (pl)
Portugiesisch (pt)
Rumänisch (ro)
Russisch (ru)
Schwedisch (sv)
Klingonisch (tlh)
Ukrainisch(uk)
Chinesisch (Simplified) (zh-CN)
Chinesisch (Traditional) (zh-TW)

Und ja, Latein musste einfach sein :)