Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Moderatoren: MaxZ, ebastler, SeriousD
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Mehrstimmiger MIDI Interrupter
Moin,
Leider musste ich feststellen dass der Code (fast) aller Versionen einen kritischen Fehler im "Simple" Modus hat, der für Milisekunden lange ontimes sorgt. Es scheint mit dem gleichen Hardwarebug zusammenzuhängen, der mich schon ganz am Anfang ärgerte, und den ich nach etlichen Stunden probieren und debuggen mit v1.1 behoben hatte. Irgendwie muss er sich beim Umbau auf v2.0.0 wieder eingeschlichen haben; ich kann es nicht mehr genau sagen. Jedenfalls hat er sich bis zur kürzlich erschienen v3.1.1 gehalten.
Ich habe es als Anlass genommen, den kompletten Code auf den Kopf zu stellen (Git diff: >3500 Zeilen hinzugefügt, >2000 Zeilen entfernt. Und nein ich habe nicht die Ordnerstruktur umgebaut ). Anstelle dass jeder Modus seine Signale selbst generiert, gibt es jetzt für jeden Ausgang eine gemeinsame Schnittstelle für alle Modi, bei der jeder das Hinzufügen (und später entfernen) eines Tons beantragen kann. Alle Modi bauen also auf den gleichen Kern auf. Dies ermöglicht es, die Modi parallel laufen zu lassen und erlaubt es in Zukunft deutlich einfacher neue Features hinzuzufügen.
Zusätzlich wurde vieles optimiert und/oder ordentlicher strukturiert. Und so ganz nebenbei ist auch der oben geschilderte Bug rausgeflogen.
Ergebnis ist das neue Release v4.0.0
Warum man Modi parallel laufen haben soll erschließt sich derzeit vielleicht noch nicht, aber es gibt (wie ich finde sehr geile) Ideen, für die das eine Voraussetzung ist:
Netzpfuscher hatte die Idee, basierend auf einem Beschleunigungssensor Star Wars Lichtschwert Effekte zu erzeugen, die auf der TC wiedergegeben werden. Ich find das einfach Hammer und die Idee hat sofort nen Platz auf meiner Todo Liste bekommen.
Es ist geplant, irgendwann nen Audio Interrupter hinzuzufügen, d.h. nen Audioeingang aufgrund dessen ein Interrupter Signal generiert wird. Möglich ist es, sogar mit wirklich guter Qualität, wie unter anderem ein sehr erfolgreiche Teslaspulenmusikyoutubechannel zeigt (wo auch immer da die Worttrennung hingehört ). Noch besser wär natürlich, wenn man gleichzeitig mit dem Keyboard daneben spielen könnte
Übrigens, mein Oszilloskop hat sich geweigert nen gescheiten Tastgrad zu messen... Vielleicht war ich auch zu blöd; wer weiß. Schaut was mit dem unten angezeigten Tastgrad passiert, wenn der Puls links das Bild verlässt
Edit: als text geschrieben definitiv Schlafenszeit definitiv
Liebe Grüße,
Max
Leider musste ich feststellen dass der Code (fast) aller Versionen einen kritischen Fehler im "Simple" Modus hat, der für Milisekunden lange ontimes sorgt. Es scheint mit dem gleichen Hardwarebug zusammenzuhängen, der mich schon ganz am Anfang ärgerte, und den ich nach etlichen Stunden probieren und debuggen mit v1.1 behoben hatte. Irgendwie muss er sich beim Umbau auf v2.0.0 wieder eingeschlichen haben; ich kann es nicht mehr genau sagen. Jedenfalls hat er sich bis zur kürzlich erschienen v3.1.1 gehalten.
Ich habe es als Anlass genommen, den kompletten Code auf den Kopf zu stellen (Git diff: >3500 Zeilen hinzugefügt, >2000 Zeilen entfernt. Und nein ich habe nicht die Ordnerstruktur umgebaut ). Anstelle dass jeder Modus seine Signale selbst generiert, gibt es jetzt für jeden Ausgang eine gemeinsame Schnittstelle für alle Modi, bei der jeder das Hinzufügen (und später entfernen) eines Tons beantragen kann. Alle Modi bauen also auf den gleichen Kern auf. Dies ermöglicht es, die Modi parallel laufen zu lassen und erlaubt es in Zukunft deutlich einfacher neue Features hinzuzufügen.
Zusätzlich wurde vieles optimiert und/oder ordentlicher strukturiert. Und so ganz nebenbei ist auch der oben geschilderte Bug rausgeflogen.
Ergebnis ist das neue Release v4.0.0
Warum man Modi parallel laufen haben soll erschließt sich derzeit vielleicht noch nicht, aber es gibt (wie ich finde sehr geile) Ideen, für die das eine Voraussetzung ist:
Netzpfuscher hatte die Idee, basierend auf einem Beschleunigungssensor Star Wars Lichtschwert Effekte zu erzeugen, die auf der TC wiedergegeben werden. Ich find das einfach Hammer und die Idee hat sofort nen Platz auf meiner Todo Liste bekommen.
Es ist geplant, irgendwann nen Audio Interrupter hinzuzufügen, d.h. nen Audioeingang aufgrund dessen ein Interrupter Signal generiert wird. Möglich ist es, sogar mit wirklich guter Qualität, wie unter anderem ein sehr erfolgreiche Teslaspulenmusikyoutubechannel zeigt (wo auch immer da die Worttrennung hingehört ). Noch besser wär natürlich, wenn man gleichzeitig mit dem Keyboard daneben spielen könnte
Übrigens, mein Oszilloskop hat sich geweigert nen gescheiten Tastgrad zu messen... Vielleicht war ich auch zu blöd; wer weiß. Schaut was mit dem unten angezeigten Tastgrad passiert, wenn der Puls links das Bild verlässt
Edit: als text geschrieben definitiv Schlafenszeit definitiv
Liebe Grüße,
Max
-
- Beiträge: 87
- Registriert: Mo 22. Jul 2013, 20:55
- Wohnort: Andernach (Rheinland Pfalz)
- Hat sich bedankt: 11 Mal
- Danksagung erhalten: 12 Mal
Re: Mehrstimmiger MIDI Interrupter
Uh sehe erst jetzt das es hier ja auch weiter geht!
Aber primär wolltest du doch auf Netzpfuschers System umsteigen oder?
Wie läuft da eigentlich die Entwicklung des LWL-Interfaces?
Zur Duty Messung mit dem Rigol DS1000x kann ich nur sagen das laut relativ schwammiger Information im Handbuch
die Duty+ Messung als "+Pulslänge/Periode" definiert ist. Jetzt hat das Rigol natürlich eine schwere Zeit in dem Signal eine Pulslänge und eine Periodenlänge zu finden.
Leider gibt das Handbuch, bezüglich dem Verhalten bei aperiodischen Signalen, nicht mehr her... Womöglich hilft hier die Vavg Messung. Dann müsste man per Dreisatz auf den Tastgrad kommen.
mfg VEKTOR
Aber primär wolltest du doch auf Netzpfuschers System umsteigen oder?
Wie läuft da eigentlich die Entwicklung des LWL-Interfaces?
Zur Duty Messung mit dem Rigol DS1000x kann ich nur sagen das laut relativ schwammiger Information im Handbuch
die Duty+ Messung als "+Pulslänge/Periode" definiert ist. Jetzt hat das Rigol natürlich eine schwere Zeit in dem Signal eine Pulslänge und eine Periodenlänge zu finden.
Leider gibt das Handbuch, bezüglich dem Verhalten bei aperiodischen Signalen, nicht mehr her... Womöglich hilft hier die Vavg Messung. Dann müsste man per Dreisatz auf den Tastgrad kommen.
mfg VEKTOR
ALLES was ich sage kann auch FALSCH sein, M'Kay ?
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Mehrstimmiger MIDI Interrupter
Hi VEKTOR,
Ja, hab das Thema hier auch ehrlich gesagt etwas vernachlässigt; daher gibt's am Ende den aktuellen Stand. Irgendwann will ich auf den UD3 umsteigen, ja. Aber mittelfristig habe ich keine Zeit dafür und es gibt noch ein paar Einschränkungen, die ich nicht haben will. Dazu kommt, dass mein Syntherrupter durchaus Anklang findet im highvoltageforum, ich bin also nicht mehr der einzige Nutzer.
Den aktuellen Entwicklungsstand vom UD3 gibt's hier zu sehen: https://highvoltageforum.net/index.php?topic=188.100
Kann ansonsten nur sagen dass es auf der Todo Liste steht.
Mit deinen Erklärungen zum Rigol Oszilloskop hast du recht; sieht so aus als würde nur die erste Periode vermessen werden. Vavg funktioniert dagegen korrekt.
Und nun wie versprochen die Neuerungen seit dem letzten Post:
Liebe Grüße,
Max
Ja, hab das Thema hier auch ehrlich gesagt etwas vernachlässigt; daher gibt's am Ende den aktuellen Stand. Irgendwann will ich auf den UD3 umsteigen, ja. Aber mittelfristig habe ich keine Zeit dafür und es gibt noch ein paar Einschränkungen, die ich nicht haben will. Dazu kommt, dass mein Syntherrupter durchaus Anklang findet im highvoltageforum, ich bin also nicht mehr der einzige Nutzer.
Den aktuellen Entwicklungsstand vom UD3 gibt's hier zu sehen: https://highvoltageforum.net/index.php?topic=188.100
Kann ansonsten nur sagen dass es auf der Todo Liste steht.
Mit deinen Erklärungen zum Rigol Oszilloskop hast du recht; sieht so aus als würde nur die erste Periode vermessen werden. Vavg funktioniert dagegen korrekt.
Und nun wie versprochen die Neuerungen seit dem letzten Post:
- Ursprünglich was Syntherrupter zwar halbwegs leistungsstark, aber sehr leicht zu verwenden. Inzwischen ist die Komplexität jedoch soweit gewachsen, dass ein einzelner Startpost nicht mehr dafür ausreicht. Daher habe ich angefangen an einem Wiki zu schreiben: https://github.com/MMMZZZZ/Syntherrupte ... ation/Wiki Da fehlt noch vieles, aber es ist ein brauchbarer Anfang denke ich. Sobald alle Infos, die jetzt noch im Startpost stehen, migriert sind, wird der Startpost ordentlich zusammengekürzt, so dass er weniger erschlagend ist.
- ADSR/Hüllkurve wurde deutlich aufgebohrt.
- Anstelle von 4 Datenpunkten sind nun 8 möglich, wobei der Unterbau mit beliebig vielen Datenpunkten klar kommt.
- Exponentielle Verläufe sind jetzt möglich. Der Nutzer spezifiziert wie viele ("n") Zeitkonstanten ("tau") zwischen den letzten und jetzigen Datenpunkt gequetscht werden. Ein Wert von 0 ergibt einen linearen Verlauf. Positive/negative Werte "drücken" den Verlauf mehr Richtung Rechteck. Ein Beispiel. Zu sehen sind mehrere Kurven, deren Datenpunkte jeweils die gleiche Amplitude und Dauer haben. Daher schneiden sich alle Kurven in ihren 4 Datenpunkten. Der "n-tau" Wert ist allerdings für jede Kurve anders, weshalb der Verlauf zwischen den Datenpunkten auch anders ist. Die Daten wurden btw. nicht mit Excel generiert sondern tatsächlich aus dem uC ausgelesen. Das da ist der Verlauf wie er für jede einzelne Note in Echtzeit berechnet wird.
- Jeder Datenpunkt kann auf einen beliebigen anderen Datenpunkt verweisen. Somit sind Schleifen möglich. Schleifen in der Hüllkurve...? Hier ein Beispiel: https://www.youtube.com/watch?v=1p675bxQwFg&t=8m50s Dieses Beispiel lässt sich mit 4 Datenpunkten nachbilden (Schritt 8 ist immer Release, so wie Schritt 1 immer Attack ist):
Man beachte wie Schritt 3 zurück auf Schritt 2 verweist und somit eine Schleife erzeugt. Das Ergebnis sieht dann z.B. so aus:
Code: Alles auswählen
Schritt | Nächster Schritt | Amplitude | Dauer [ms] | n-tau --------+------------------+-----------+------------+------ 1 | 2 | 1.0 | 500 | 2.0 2 | 3 | 0.0 | 200 | 2.0 3 | 2 | 1.0 | 100 | -2.0 8 | 8 | 0.0 | 100 | 2.0
- Hüllkurven können endlich auf Syntherrupter selbst editiert werden. Ein grafischer Editor ist zwar leider nicht möglich, aber immer noch besser als nix.
- Editieren ist schön und gut, aber wenn man das jedes mal neu machen muss, ist es auch Kacke. Daher werden jetzt die Programme 20-39 im EEPROM gespeichert. Die Programme 0-19 sind Presets die beim Start immer gleich sind und alle anderen Programme sind leer (keine Hüllkurve; nur Note an, Note aus).
- Der angekündigte Lichtschwer Modus ist da! Einrichten ist recht einfach (siehe Wiki!). Jedes Lichtschwert besteht aus einem MPU6050 Sensor und einem ESP8266. Syntherrupter selbst kriegt ebenfalls einen ESP8266. Alle ESPs werden mit der gleichen Firmware geflasht und erkennen automatisch was ihre Rolle ist. Lichtschwerter und Syntherrupter können in beliebiger Reihenfolge eingeschaltet werden; die finden sich egal wie. Ein früher Test dieses neuen Modus ist hier zu sehen und hören:
Der Algorithmus, der die Frequenz aus der Bewegung errechnet, wurde seitdem noch leicht angepasst. Wirklich gut ist er noch nicht, aber zum Rumspielen reicht's allemal. - Dark Mode
Liebe Grüße,
Max
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Nabend,
Gibt etwas Fortschritt hier. Inzwischen ist das Wiki fast komplett und für so ziemlich jeden Knopf und Schieber im User Interface kann man sich einen QR Code anzeigen lassen, der direkt zum passenden Abschnitt im Wiki verlinkt. War ne scheiß arbeit und wird wahrscheinlich nie jemand nutzen, aaaaber es kann sich keiner beschweren. Ist doch auch was. Die Links habe ich nicht manuell gesammelt, sondern automatisiert, und gleich auch gekürzt. Skript dafür hab ich ebenfalls veröffentlicht.
Um Rechenzeit zu sparen hab ich die "korrekte" Berechnung der Frequenz bei Pitch Bend rausgeschmissen und durch ne lineare Interpolation ersetzt (LUT mit den genauen Frequenzen aller Halbtöne). Tatsächlich ist die Abweichung mit <1 Cent zu gering um hörbar zu sein.
Darüber hinaus hab ich die Farben im Dark Mode angepasst. War vorher noch nicht sooo überzeugend; vor allem der Kontrast. Jetzt gefällt's mir viel besser
Dönlöd und Details zur neuen v4.1.0: https://github.com/MMMZZZZ/Syntherrupte ... tag/v4.1.0
So nebenbei überlege ich, wie das Projekt weitergehen soll. Langfristig will ich auf ne leistungsstärkere Plattform umsteigen, um die teuren und beschränkten Nextion Displays los zu werden. Ziel ist es, nicht nur ne bessere UI un mehr Funktionen hinzubekommen, sondern auch die BOM-Kosten ohne Gehäuse und LWL Module auf <50€ zu drücken. Ich denke da an nen Teensy 4.1 (600MHz Cortex M7) oder sogar nen Raspberry Pi (Zero). Falls ihr noch Ideen habt, immer her damit.
Oh, und nee, selbst blitzen konnte und kann ich immer noch nicht
Liebe Grüße,
Max
Gibt etwas Fortschritt hier. Inzwischen ist das Wiki fast komplett und für so ziemlich jeden Knopf und Schieber im User Interface kann man sich einen QR Code anzeigen lassen, der direkt zum passenden Abschnitt im Wiki verlinkt. War ne scheiß arbeit und wird wahrscheinlich nie jemand nutzen, aaaaber es kann sich keiner beschweren. Ist doch auch was. Die Links habe ich nicht manuell gesammelt, sondern automatisiert, und gleich auch gekürzt. Skript dafür hab ich ebenfalls veröffentlicht.
Um Rechenzeit zu sparen hab ich die "korrekte" Berechnung der Frequenz bei Pitch Bend rausgeschmissen und durch ne lineare Interpolation ersetzt (LUT mit den genauen Frequenzen aller Halbtöne). Tatsächlich ist die Abweichung mit <1 Cent zu gering um hörbar zu sein.
Darüber hinaus hab ich die Farben im Dark Mode angepasst. War vorher noch nicht sooo überzeugend; vor allem der Kontrast. Jetzt gefällt's mir viel besser
Dönlöd und Details zur neuen v4.1.0: https://github.com/MMMZZZZ/Syntherrupte ... tag/v4.1.0
So nebenbei überlege ich, wie das Projekt weitergehen soll. Langfristig will ich auf ne leistungsstärkere Plattform umsteigen, um die teuren und beschränkten Nextion Displays los zu werden. Ziel ist es, nicht nur ne bessere UI un mehr Funktionen hinzubekommen, sondern auch die BOM-Kosten ohne Gehäuse und LWL Module auf <50€ zu drücken. Ich denke da an nen Teensy 4.1 (600MHz Cortex M7) oder sogar nen Raspberry Pi (Zero). Falls ihr noch Ideen habt, immer her damit.
Oh, und nee, selbst blitzen konnte und kann ich immer noch nicht
Liebe Grüße,
Max
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Inzwischen hat endlich jemand eine halbwegs interessante MIDI Datei mit meinem Interrupter abgespielt. Möchte ich euch natürlich nicht vorenthalten
Gibt noch zwei weitere Videos, die am Ende des Tages aber "nur" einfache 2-3 stimmige MIDIs sind:
Liebe Grüße,
Max
Gibt noch zwei weitere Videos, die am Ende des Tages aber "nur" einfache 2-3 stimmige MIDIs sind:
Liebe Grüße,
Max
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Moin zusammen,
Auch hier macht der Fortschritt nicht halt. Die wohl interessanteste Neuigkeit: anders als letztes Jahr fällt meine alljährliche Demo dieses Jahr nicht aus. Das heißt nach anderthalb Jahren Entwicklung kann ich meinen Interrupter endlich richtig selbst austesten.
Seit dem letzten Update hier hat sich unter der Haube natürlich ebenfalls einiges getan. Ein sehr alter Punkt auf meiner Todo Liste, nämlich Sysex-Befehle, ist größtenteils abgehakt. Sysex Befehle ("midi SYStem EXclusive messages") sind im MIDI Standard vorgesehen um Herstellern zu erlauben, beliebige Befehle in MIDI (Dateien oder Datenströme) einzubetten. Wird hauptsächlich für die Konfiguration von Synths verwendet, die natürlich weitaus mehr Parameter zum Rumfummeln haben, als das, was im MIDI Standard vorgesehen ist.
So ist es auch hier. Bildschirmhelligkeit, Ontime, Tastgrad - so ziemlich alles kann jetzt über diese Befehle gesteuert werden. Natürlich alles ordentlich dokumentiert
Für die, die mehr über das Sysex Format wissen wollen, die Doku enthält alle nötigen Infos und weiterführende Links.
Solche Befehle sind zwar schön und gut aber das schreibt niemand von Hand - sprich das alleine reicht noch nicht um nützlich zu sein. Wär doch viel besser, wenn man das Ding mit Sätzen wie ansprechen könnte. Gesagt, getan. Ein Python Skript namens Syfoh übersetzt derartige Sätze in die zugehörigen Sysex Befehle. Das genannte Beispiel wird z.B. zu
Insbesondere kann das Skript auch Textdateien verarbeiten und so z.B. ganze Blöcke von Befehlen auf einmal verarbeiten. Natürlich könnte man auch auf dem Skript aufbauend weitere Tools erstellen. Aber so groß ist meine Community dann doch nicht Und wer sich jetzt fragt: basierend auf den Download Statistiken und dem was ich so von Feedback bekomme, dürften Pi mal Daumen ein Dutzend Syntherrupter-Nutzer da draußen sein. Mehr als ich erwartet hätte beim Veröffentlichen von v1.0.
Ausgegeben werden die Befehle dann entweder als hex in der Konsole oder als Binärdatei, die auch von anderen Sysex-Tools geöffnet werden kann. Weiterhin können sie an einen seriellen Port oder einen MIDI Port gesendet werden.
Wer braucht das? Nun, wenn man eine Vorführung macht, ist es total doof, nach jedem Lied alle Einstellungen (z.B. Stereo Platzierungen) anzupassen. Mit diesem Tool kann zu jedem Lied eine Einstellungsdatei angelegt werden, die mit einem Befehl angewendet wird.
Was mich anbelangt, ich nutze es andauernd. Beim Testen und Debuggen starte ich die Kiste naturgemäß häufig neu. Statt dabei jedes mal wieder von Hand alles so einzustellen wie ich es brauche, geht das jetzt (fast) von alleine.
Die zweite große Neuerung betrifft die Signalerzeugung. Das Prinzip dahinter war bisher folgendes: für jeden Ton schaut das Programm, wann er zuletzt eine Ontime generiert hat. Ist das länger als seine Periodendauer her, so wird eine neue Ontime generiert. Soweit so logisch. Und für einfach gestrickte Interrupter funktioniert das auch super. Der Haken bei mir ist, dass das nicht die einzige Aufgabe vom Mikrocontroller ist. Hüllkurven, UI, Sysex, (in Zukunft SD Karte), ... Es gibt jede Menge anderer Aufgaben - und natürlich kommt die schiere Menge an Töne dazu, die der Interrupter verwalten muss. 6*16 Töne, die in Echtzeit ausgewertet werden wollen ist ein ordentlicher Batzen Arbeit.
Der langen Rede kurzer Sinn: Weil die Generierung der Ontimes in Echtzeit geschieht, schlagen sich alle anderen Aufgaben direkt auf die Qualität des Ausgangssignales nieder. Je nachdem wie fällt das gar nicht auf; aber bei bestimmten Klängen kommt es zu deutlich hörbaren Störungen. Wir reden btw. nicht von Millisekunden Verzögerungen. Wir reden von Störungen in der Größenordnung von 30us (!), die die Qualität mancher Klänge bereits dramatisch verschlechtert. Ja, unsere Ohren sind verdammt gut.
30us ist jenseits dessen was jede Form von RTOS, Taskmanager, etc. hinbekommen könnte. Diese arbeiten fast durchwegs mit Auflösungen von >=1ms. Also ein einfacher Taskmanager reicht nicht. Interrupts mit hoher Abtastfrequenz sind auch nicht hilfreich, da der Overhead viel zu groß ist. Denn, bei 10% Tastgrad ist - unabhängig von der Signalkomplexität - 90% der Zeit nix los.
Schon lange hatte ich daher vor, die Ausgänge zu puffern. Klingt leicht aber ist gar nicht so leicht. Haben angeblich auch schon andere probiert, jedoch ohne (zufriedenstellenden) Erfolg. Um insgesamt einen Monat Entwicklung (verteilt über Mai, Juni, Juli, August) zusammenzufassen, es funktioniert - und zwar gut. Der Puffer kann konfiguriert werden auf eine Dauer von 1ms bis 100ms, wobei 5ms die Voreinstellung ist (kurz genug um nicht hörbar zu sein).
Dank dieses Puffers habe ich also <5ms Spielraum bevor sich eine Verzögerung auf die Ausgänge durchschlägt - und das reicht für so ziemlich alles. Insbesondere ist damit (endlich) der Grundstein gelegt, der es erlaubt, auf FreeRTOS (o.ä.) umzusatteln und Dinge wie SD-Karten-Unterstützung einzubauen. Bisher war jede Änderung, jede Erweiterung immer begrenzt durch den Blick auf die mögliche Verschlechterung der Signalqualität. Insofern kann ich gar nicht genug betonen, wie froh ich bin, dass die Puffer funktionieren.
Ich möchte nicht zu sehr in die Details der Implementierung gehen - der Beitrag ist schon lang genug - aber zwei Dinge möchte ich hervorheben. Zum einen steckt wie so oft auch hier der Teufel im Detail. Zum anderen: Obwohl ich mit den Puffern mehr Zeit und Flexibilität für andere Aufgaben habe, steigt die CPU Belastung ein gutes Stück. Die Verwaltung der Puffer ist um ein vielfaches komplexer als die vorherige Lösung (die mehr oder weniger aus einer Schleife und einem Vergleich bestanden hat). In meinem Fall hat sich die Rechnung gelohnt; das Ausgangssignal ist in allen Fällen makellos. Vor allem können jetzt auch irrwitzig hohe Frequenzen (10kHz z.B.) ausgegeben werden, was vorher nicht möglich war.
Eine kleine Demo-Aufnahme mit einer der furiosesten MIDI Dateien, die ich habe, gibt es hier. Es wurde zwar nur ein Ausgang aufgezeichnet, tatsächlich aber wurde das gleichzeitig auf allen 6 Ausgängen abgespielt - mit jeweils 16 Tönen. Für DRSSTCs etwas zu viel aber eine SSTC hätte das noch durchaus mitmachen können. https://soundcloud.com/user-754038701/p ... v420-beta4
Die Original-Performance (mMn die beste Klavierversion dieses Stücks; hab ich auch selbst mal gespielt): https://www.youtube.com/watch?v=n4JD-3-UAzM
Falls Interesse besteht, kann ich gerne etwas mehr über die Fallstricke und meine Lösungen erzählen. Und falls jemand konstruktives Feedback hat, ist das natürlich sehr erwünscht!
Btw. Ich bin sicherlich kein Git-Profi, aber selbst grundlegende Commits und Branches sind schon eine unglaubliche Hilfe. Vor allem bereue ich keine Sekunde, dass ich von Tag 1 an eine gepflegte Commit-History habe und quasi jede Änderung darin wiederfinde. Bei der Entwicklung und der Fehlersuche ist das von unschätzbarem Wert. Insbesondere auch wenn mal längere Pausen (Klausurenphasen) dazwischenliegen und man später versucht wieder in die angefangene Arbeit reinzukommen.
Edit: Wie immer gibt's die aktuelle Version (zu diesem Zeitpunkt v4.2.0-beta.4) mit ausführlichen Release Notes hier: https://github.com/MMMZZZZ/Syntherrupter/releases
Liebe Grüße,
Max
Auch hier macht der Fortschritt nicht halt. Die wohl interessanteste Neuigkeit: anders als letztes Jahr fällt meine alljährliche Demo dieses Jahr nicht aus. Das heißt nach anderthalb Jahren Entwicklung kann ich meinen Interrupter endlich richtig selbst austesten.
Seit dem letzten Update hier hat sich unter der Haube natürlich ebenfalls einiges getan. Ein sehr alter Punkt auf meiner Todo Liste, nämlich Sysex-Befehle, ist größtenteils abgehakt. Sysex Befehle ("midi SYStem EXclusive messages") sind im MIDI Standard vorgesehen um Herstellern zu erlauben, beliebige Befehle in MIDI (Dateien oder Datenströme) einzubetten. Wird hauptsächlich für die Konfiguration von Synths verwendet, die natürlich weitaus mehr Parameter zum Rumfummeln haben, als das, was im MIDI Standard vorgesehen ist.
So ist es auch hier. Bildschirmhelligkeit, Ontime, Tastgrad - so ziemlich alles kann jetzt über diese Befehle gesteuert werden. Natürlich alles ordentlich dokumentiert
Für die, die mehr über das Sysex Format wissen wollen, die Doku enthält alle nötigen Infos und weiterführende Links.
Solche Befehle sind zwar schön und gut aber das schreibt niemand von Hand - sprich das alleine reicht noch nicht um nützlich zu sein. Wär doch viel besser, wenn man das Ding mit Sätzen wie
Code: Alles auswählen
set ontime for mode simple and coil 2 to 100
Code: Alles auswählen
f0 00 26 05 01 7f 21 00 02 01 64 00 00 00 00 f7
Ausgegeben werden die Befehle dann entweder als hex in der Konsole oder als Binärdatei, die auch von anderen Sysex-Tools geöffnet werden kann. Weiterhin können sie an einen seriellen Port oder einen MIDI Port gesendet werden.
Wer braucht das? Nun, wenn man eine Vorführung macht, ist es total doof, nach jedem Lied alle Einstellungen (z.B. Stereo Platzierungen) anzupassen. Mit diesem Tool kann zu jedem Lied eine Einstellungsdatei angelegt werden, die mit einem Befehl angewendet wird.
Was mich anbelangt, ich nutze es andauernd. Beim Testen und Debuggen starte ich die Kiste naturgemäß häufig neu. Statt dabei jedes mal wieder von Hand alles so einzustellen wie ich es brauche, geht das jetzt (fast) von alleine.
Die zweite große Neuerung betrifft die Signalerzeugung. Das Prinzip dahinter war bisher folgendes: für jeden Ton schaut das Programm, wann er zuletzt eine Ontime generiert hat. Ist das länger als seine Periodendauer her, so wird eine neue Ontime generiert. Soweit so logisch. Und für einfach gestrickte Interrupter funktioniert das auch super. Der Haken bei mir ist, dass das nicht die einzige Aufgabe vom Mikrocontroller ist. Hüllkurven, UI, Sysex, (in Zukunft SD Karte), ... Es gibt jede Menge anderer Aufgaben - und natürlich kommt die schiere Menge an Töne dazu, die der Interrupter verwalten muss. 6*16 Töne, die in Echtzeit ausgewertet werden wollen ist ein ordentlicher Batzen Arbeit.
Der langen Rede kurzer Sinn: Weil die Generierung der Ontimes in Echtzeit geschieht, schlagen sich alle anderen Aufgaben direkt auf die Qualität des Ausgangssignales nieder. Je nachdem wie fällt das gar nicht auf; aber bei bestimmten Klängen kommt es zu deutlich hörbaren Störungen. Wir reden btw. nicht von Millisekunden Verzögerungen. Wir reden von Störungen in der Größenordnung von 30us (!), die die Qualität mancher Klänge bereits dramatisch verschlechtert. Ja, unsere Ohren sind verdammt gut.
30us ist jenseits dessen was jede Form von RTOS, Taskmanager, etc. hinbekommen könnte. Diese arbeiten fast durchwegs mit Auflösungen von >=1ms. Also ein einfacher Taskmanager reicht nicht. Interrupts mit hoher Abtastfrequenz sind auch nicht hilfreich, da der Overhead viel zu groß ist. Denn, bei 10% Tastgrad ist - unabhängig von der Signalkomplexität - 90% der Zeit nix los.
Schon lange hatte ich daher vor, die Ausgänge zu puffern. Klingt leicht aber ist gar nicht so leicht. Haben angeblich auch schon andere probiert, jedoch ohne (zufriedenstellenden) Erfolg. Um insgesamt einen Monat Entwicklung (verteilt über Mai, Juni, Juli, August) zusammenzufassen, es funktioniert - und zwar gut. Der Puffer kann konfiguriert werden auf eine Dauer von 1ms bis 100ms, wobei 5ms die Voreinstellung ist (kurz genug um nicht hörbar zu sein).
Dank dieses Puffers habe ich also <5ms Spielraum bevor sich eine Verzögerung auf die Ausgänge durchschlägt - und das reicht für so ziemlich alles. Insbesondere ist damit (endlich) der Grundstein gelegt, der es erlaubt, auf FreeRTOS (o.ä.) umzusatteln und Dinge wie SD-Karten-Unterstützung einzubauen. Bisher war jede Änderung, jede Erweiterung immer begrenzt durch den Blick auf die mögliche Verschlechterung der Signalqualität. Insofern kann ich gar nicht genug betonen, wie froh ich bin, dass die Puffer funktionieren.
Ich möchte nicht zu sehr in die Details der Implementierung gehen - der Beitrag ist schon lang genug - aber zwei Dinge möchte ich hervorheben. Zum einen steckt wie so oft auch hier der Teufel im Detail. Zum anderen: Obwohl ich mit den Puffern mehr Zeit und Flexibilität für andere Aufgaben habe, steigt die CPU Belastung ein gutes Stück. Die Verwaltung der Puffer ist um ein vielfaches komplexer als die vorherige Lösung (die mehr oder weniger aus einer Schleife und einem Vergleich bestanden hat). In meinem Fall hat sich die Rechnung gelohnt; das Ausgangssignal ist in allen Fällen makellos. Vor allem können jetzt auch irrwitzig hohe Frequenzen (10kHz z.B.) ausgegeben werden, was vorher nicht möglich war.
Eine kleine Demo-Aufnahme mit einer der furiosesten MIDI Dateien, die ich habe, gibt es hier. Es wurde zwar nur ein Ausgang aufgezeichnet, tatsächlich aber wurde das gleichzeitig auf allen 6 Ausgängen abgespielt - mit jeweils 16 Tönen. Für DRSSTCs etwas zu viel aber eine SSTC hätte das noch durchaus mitmachen können. https://soundcloud.com/user-754038701/p ... v420-beta4
Die Original-Performance (mMn die beste Klavierversion dieses Stücks; hab ich auch selbst mal gespielt): https://www.youtube.com/watch?v=n4JD-3-UAzM
Falls Interesse besteht, kann ich gerne etwas mehr über die Fallstricke und meine Lösungen erzählen. Und falls jemand konstruktives Feedback hat, ist das natürlich sehr erwünscht!
Btw. Ich bin sicherlich kein Git-Profi, aber selbst grundlegende Commits und Branches sind schon eine unglaubliche Hilfe. Vor allem bereue ich keine Sekunde, dass ich von Tag 1 an eine gepflegte Commit-History habe und quasi jede Änderung darin wiederfinde. Bei der Entwicklung und der Fehlersuche ist das von unschätzbarem Wert. Insbesondere auch wenn mal längere Pausen (Klausurenphasen) dazwischenliegen und man später versucht wieder in die angefangene Arbeit reinzukommen.
Edit: Wie immer gibt's die aktuelle Version (zu diesem Zeitpunkt v4.2.0-beta.4) mit ausführlichen Release Notes hier: https://github.com/MMMZZZZ/Syntherrupter/releases
Liebe Grüße,
Max
-
- Beiträge: 1168
- Registriert: So 28. Jun 2015, 10:20
- Schule/Uni/Arbeit: Mechatronik, Karlsruher Institut für Technologie
- Wohnort: Luxemburg / Karlsruhe
- Hat sich bedankt: 261 Mal
- Danksagung erhalten: 162 Mal
- Kontaktdaten:
Re: Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Kleiner Nachtrag: Falls sich mal einer gewundert hat, wozu ein MIDI Interrupter nen Touchscreen Hüllkurven (ADSR) benötigt, hier einfach mal zwei Aufnahmen, eine mit, eine ohne. Ich denke der Unterschied spricht für sich.
https://soundcloud.com/user-754038701/p ... v420-beta4
https://soundcloud.com/user-754038701/p ... v420-beta4
Für mehr Details siehe vorherigen Post. Btw falls wem der abgehakte Glissando bei 1:37 aufgefallen ist, mir auch. Ist vielleicht ein Bug…
Natürlich kann man auch an der MIDI Datei rumbasteln so dass es nicht ganz so arg klingt, der springende Punkt ist jedoch, dass es mit ordentlichen Hüllkurven ganz ohne zusätzliche Arbeit gut klingt.
Viele Grüße,
Max
https://soundcloud.com/user-754038701/p ... v420-beta4
https://soundcloud.com/user-754038701/p ... v420-beta4
Für mehr Details siehe vorherigen Post. Btw falls wem der abgehakte Glissando bei 1:37 aufgefallen ist, mir auch. Ist vielleicht ein Bug…
Natürlich kann man auch an der MIDI Datei rumbasteln so dass es nicht ganz so arg klingt, der springende Punkt ist jedoch, dass es mit ordentlichen Hüllkurven ganz ohne zusätzliche Arbeit gut klingt.
Viele Grüße,
Max
-
- Admin
- Beiträge: 3596
- Registriert: So 7. Aug 2005, 14:34
- Schule/Uni/Arbeit: HW/SW-Entwickler
- Wohnort: Braunschweig
- Hat sich bedankt: 638 Mal
- Danksagung erhalten: 210 Mal
- Kontaktdaten:
Re: Syntherrupter - Umfangreicher, Mehrstimmiger Interrupter
Moin Max,
klingt sehr geil, danke für das Update!
PS: Version 4.2.0. nicccce.
Gruß!
- Paul
klingt sehr geil, danke für das Update!
PS: Version 4.2.0. nicccce.
Gruß!
- Paul