Beiträge von 0lru

Ich habe lediglich jede zweite Ader im Flachband auf Masse gelegt und zumindest damit keine Probleme gehabt bisher. Das ist auch gar so nicht unordentlich wie es aussieht. Ich meine eher so den Kleber, der die Sensoren auf dem einen Holz hält, dass vor den Tasten-Enden hängt. Das ist wahrscheinlich nicht so optimal

> So etwas kostet pro Sensor dann schnell mal 5-15 €

Wieso? Ich bekam 20 Stück für ~ 10€ (49E OH49E SS49E). Dann noch zwei Nano's (oder ähnliches aus China) dazu, vier Multiplexer (2€ oder so) und das Ganze in eine Brotdose gepackt. Allerdings.. ist da momentan viel 2K-Kleber im Spiel und wenn das mal kaputt geht.. vielleicht doch lieber mit Kicad o. Ä. in Zukunft arbeiten:-) ,was dann w. s. nochmal ein paar Euro mehr werden. Aber irgendwann.. werde ich das eventuell tun. Für 15-20€ hat man so eher schon das ganze Pedal (nicht schön, aber funktional) verkabelt (die 30 Magnete sind dann w. s. allerdings nochmal 10-20€). Prototyp halt

1711844514686.jpg

> Wir haben hier eine Orgel für die eine kleine Kinderbank einmal gebaut wurde. Somit können dort auch Kinder oder kleine Orgelspieler gut spielen. Allgemein ist der Spieltisch aber auch recht niedrig. Für mich sogar zu niedrig, ich sitze da immer wie eine Katze beim

Ich habe mittlerweile auch ein 30er ganz ähnlich "midifiziert". die Sensoren würde ich aber nicht nochmal wie hier "obe"n anbringen, sondern lieber hinten parallel zur Tasten-Bewegung (selbst da kann man den Anschlag noch mit Software ein wenig nach-kalibrieren). Um das ganze Kind-gerecht zu machen, habe ich lieber das Pedal hochgebockt und nehme bei den Manualen die genormte Höhe im Verhältnis zur Bank, weil das Ellenbogen-Gelenk auch beim Kind nicht so viel niedriger hängt als beim Erwachsenen. Geht natürlich nicht in einer Kirche, wenn da eine Mechanik dran hängt..

> Ich habe z.B. auf einer 1TB SSD PCIe Gen. 3x4, mit 3396 MB/s sequenzielles Lesen und 2625 MB/s sequenzielles schreiben, also nicht mal die schnellste, eine unter

> Windows fest definierte Auslagerungsdatei von 48 GB eingerichtet. Zusammen mit den 16 GB RAM ergeben sich damit 64 GB verfügbarer Speicher.

Ich hab gerade eine pcie-4.0, 7000MB/s mit Linux, GO und 8 Kernen + Hyperthreading installiert. Lädt alles sehr flott ;-).

Wenn man kann, würde ich selber zusammenbauen und eventuell schauen, dass ich auf dem Mainboard 4 Ram-Slots zur Verfügung habe.

Und das kann man auch, wenn man einen Schraubenzieher bedienen kann und sich bei Bedarf entsprechend Yout***-Videos raussucht.

Orgel spielen ist da wesentlich schwerer. Aktuell gibt es auch CPU's mit mehreren Kernen, die im 100-200€ liegen .. die Auslastung

der einzelnen Kerne ist zumindest bei GO so minimal, dass wahrscheinlich auch die 100€-Variante reicht.

Kann man GO-Ränke in Aeolus importieren?..

> Wobei die Ersteller

Ich meine das so, dass die Ersteller auch die Nutzer sind oder sein sollten.. und da ist das grafische Ding von GO sehr hinderlich.

So eine Darstellung wie von Aeolus (siehe oben) und dann halt editierbar, also mit "hinzufügen" und "entfernen" :-).. dann muss

der Ersteller auch gar keine GUI bauen und der Ersteller baut seine SampleSets mit GO "gerne" (und muss auch kein Nerd sein)

> Der unschätzbare Vorteil von Python ist ja, dass die Entwickler gezwungen werden sauberen Code zu schreiben

Man wird letztendlich nie dazu gezwungen. Glaube die Sprache ist relativ egal. Evtl. Go, was ja dann auch zu GO passt.

Wenn man GO besser machen mag, ist eher so eine schematische GUI angebracht, bei der man richtig

schön editieren kann (Manual hinzufügen, Ränke definieren, vielleicht sogar die Töne selber aufnehmen, deren

gemessene Tonhöhe anzeigen usw.). Und das halte ich für weniger Aufwändig als das, was GO macht:

Diese Bildchen-Darstellung ist für den Benutzer und auch den Entwickler eher hinderlich, sieht aber natürlich gut aus.

Ich versuche (nur) das (Modell) gerade aus Spaß mit Rust + Miniaudio zu bauen. Auf "GUI" hab ich aber eher wenig bis gar keine Lust..

Ist das so richtig(?): Im ODF wird ein "Rank" meistens nur dann erstellt, wenn der "Stop" (Register) mehrere "Rank"'s (Pfeifenreihen) hat.

Wenn der Stop dagegen nur einen Rank hat, definiert man die Pfeifen einfach im Stop selber und lässt die "Rank"-Definition weg

(die Definition des Ranks ist dann sozusagen implizit). Gibt es da noch andere Anwendungsfälle für die "Rank"-Struktur in GO?

Nun: Hier ging es um MIDI-Technik. Ich habe das mal ausprobiert und wir haben viel Spaß an diesem Spielzeug (<--!).

Dieses stellt eine Sonderanfertigung dar für einen Spieltisch, der u. A. aus einem bemalten Bad-Schrank mit

Papprohr-Prospektpfeifen drauf besteht. Lieder zum mitsingen kann man trotzdem recht gut damit spielen, denn

das daran angeschlossene Subwoofer-System funktioniert ebenfalls. Manchmal etwas zu gut.

Ich empfehle nichtsdestotrotz ganz klar mehr Pedale (nach BDO), wenn dies beim Einbau in das Gesamtsystem möglich ist.

Weiterhin möchte ich darauf hinweisen, dass ich keine Verantwortung für irgendwelche Nachbauten übernehme.

> Eine nette Idee. Wobei so ein Pedal meiner Meinung nach problematisch ist, da Töne fehlen.

So ist das. War mir aber vorher schon klar (siehe oben).

Sensorik werde ich bei dem 30er ähnlich gestalten. Also kein "Reed".

Zitat

für unterwegs

Naja, die Pedale sind sehr eng beieinander (20 auf 60cm). Für Erwachsene wird es schon recht schwer das zu spielen.

Mechanik: Hinten habe ich die "Pedale" mit Lochplatten (60x12mm) "recht fest" verschraubt. Das Ganze

ist trotzdem noch ein wenig elastisch. Falls die doch mal brechen sollte, tausche ich die einfach aus. Für vorne waren Schenkelfedern

bestellt. Kamen nicht mehr rechtzeitig und hätten auch nicht gepasst. Daher die Gummis. Das werden letztendlich wohl noch

10x300mm Druckfedern oder so reinkommen.

Ansonsten sind das Leimholzplatten aus dem Baumarkt: Die waren ganz erstaunlich von der Restfeuchtigkeit

her. Die habe ich dann genau an der Verleimung durchtrennt und daraus die 5cm hohen Pedale gemacht. Anschließend

den Rahmen aus demselben Material und 6mm-Rundhölzern. Gedämpft mit Türdichtung und ziemlich hartem Filz drüber.

Vielleicht merkt man es: Die Zeit war knapp (3-6 Tage in "nicht-Vollzeit"?) :-). Die schwarzen Tasten sind gebeizt. Farbe gefällt mir nicht

so richtig. Wollte ein helleres Braun, aber egal. Darüber dann Hartwachsöl..

Hallsensoren: Das sind 20 "SS49E Linear Hall-effect"-Sensoren. Auf der Gegenseite habe ich 10x2mm Neodyn-Magnete verbaut.

Von den Magneten sind jeweils zwei gestapelt in einem Pedal mit Zweikomponentenkleber in einer gebohrten Vertiefung befestigt.

Die Sensoren habe auch mit diesem Zeug auf einer Leiste befestigt (wo das rote Isolierband dran ist).

Die ersten 16 Pedale werden mit 4051-Multiplexern abgefragt (so ähnlich wie hier: https://goetzmd.de/mehr-analoge-i…-bauen-teil-10/). Die restlichen 4 Sensoren hängen direkt am Nano (sieht man vielleicht auch

im Quelltext). Die Multiplexer habe ich auf einer sehr schmalen Platine verlötet, weil kein Platz mehr. Den Nano habe ich dann

mit 4 Streichhölzern woanders hin-geklebt. Auf dem 16-poligen Band habe ich mehrere Pfostenbuchsen befestigt. Da kann man

die Sensoren schön umstecken, falls was beim Löten was schief gelaufen sein sollte.

Für die Hallsensoren kann man in der Software eigene Schwellwerte angeben für den Anschlag. Das geht auch während dem

Betrieb: Dazu steuere ich den Ardino über die serielle Schnittstelle selber mit eigenem Protokoll und sende dann die MIDI-Befehle

über einen virtuellen Port (unter Windows braucht man dazu "loopMidi" oder ähnliches) z. B. zu GO.

Falls mal jemand sowas in der Art machen möchte. Mein Kind hatte sich einen eigenen Spieltisch gebaut und sich

ein Pedal dazu gewünscht. Bank war schon da, deshalb musste es etwas kleiner sein und darunter passen.

Quelltext ist hier: https://github.com/0lru/organ_midi_pedal

pedal0_small.jpg

pedal1_small.jpg

Zitat

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

Das hört man immer wieder, stimmt aber so nicht: NumPy ist ja z. B. auch nicht interpretiert. So sollte man das auch machen, sich aber im Klaren darüber sein,

dass das auch heißt, dass man in C++ oder Rust unterwegs sein wird. Das wiederum ist bei "Audio" ja meistens der Fall. Man muss das so sehen, wie bei den

Quake-ähnlichen Spielen früher. Eigentlich ist in diesem Bereich alles C/C++ (oder mittlerweile ein wenig Rust), aber eine interpretierte Skriptsprache

"dazu" ist schon recht sinnvoll. Python würde ich deshalb als Kandidat ganz weit oben sehen. Das ist ja kein MicroPython oder so.

Dazu kommt, dass viele Studenten in dieser Spracheausgebildet werden (Datenanalysten etc.) und auch Hobby-Entwickler damit arbeiten.. Ich persönlich würde GO nehmen, den C++-Loader als Modul in Python einbinden und anschließend versuchen die vorhandene Logik von GO nachzuempfinden (mit Qt oder Slint), damit ich die bereits vorhandenen Sets weiter verwenden kann.

Habe auch gerade einen "micro" per Lochraster verlötet zum testen. Klappt zwar ganz gut,

ist aber irgendwie unhandlich.

phc:

Wäre es nicht möglich/besser sowas wie einen atxmega mit 50 Pins o. Ä. zu nehmen, wenn man

sowieso schon mit entsprechender Software arbeitet? Also anstatt der Port-Erweiterungen.

Das USB-Ding sollte man doch dann irgendwie auch direkt da drauf kriegen.

Über sowas denke ich jedenfalls gerade nach.