Erneuerbare Tonerzeugung

  • Ersteller Emony von Arwed
  • Erstellt am
Noch ein kurzer Nachtrag ...

... ich habe eben mal recherchiert, was Airflow Sensoren zur Messung der Luftgeschwindigkeit kosten. Diese wären zusätzlich zu den günstigeren Drucksensoren notwendig um Bending zu ermöglichen. Da sind wir pro Stück bei 55 - 80 Euro + Mehrwertsteuer.

Schon allein die Sensoren würden in einer Konstruktion wie Du sie vorschlägst ein kleines Vermögen kosten. Eine kommerzielle Version des Instrumentes wäre nicht unter 2.000 - 3.000 Euro VK herzustellen - wenn das überhaupt reicht. Es kommen ja noch weitere Bauteile, Herstellungskosten, Entwicklungskosten, Vertriebskosten, Werbung, etc. hinzu. Das ganze natürlich ohne Soundmodul!

Ein weiteres Problem wäre die benötigte Größe. Um solch einen Kontroller zu fertigen müsste man eine sehr durchdachte Konstruktion bauen, um den Luftdurchsatz über nur wenige zusammengeführte Sensoren zu messen. Ob sich durch die Veränderungen in den Luftkammernwegen Messungenauigkeiten einstellen, die die Intonation unbrauchbar machen, wäre noch abzuwarten.
Die Druckschwankungen beim Wechsel von einstimmigen zu mehrstimmigen Spiel sind mit Sicherheit auf nicht ohne.

Ein traditioneller Wind Controller Aufbau mit nur einem Blassensor ist deutlich einfacher in den Griff zu bekommen. So etwas kann man sich mit einem Arduino Board - wie Nyle Steiner das bereits vorgemacht hat - innerhalb von einem Tag in EWI-Qualität bauen.

... aber da sind wir ja wieder bei der Qualität der aktuellen Instrumente, die leider noch auf dem Stand der Technik von ca. 1980 sind. :-(

Grüße, Ingo
 
Zuletzt bearbeitet:
Hi Ingo,
die Sache mit dem Millioniser habe ich damals mitbekommen. Hielt aber eine 'richtige' Mundharmonika für vielversprechender hinsichtlich Ergonomie und tonale Effizienz. Und halte die noch immer für vielversprechender.


Früher dachte ich auch, die MIDI-Auflösung sei viel zu gering. Dem ist aber nicht so. Mit entsprechender Interpolation und gewissen Tricks bei den ganz niedrigen Dynamikbereichen kommt man sehr gut hin. Man benötigt mit Sicherheit keine Datenübertragung, die mehr als ein bis zwei Datenströme gleichzeitig übertragen kann. Wie willst Du in der Lage sein, drei unabhängige Luftströme gleichzeitig zu kontrollieren? Maximal hast Du ein Überblenden von einem Bereich in den nächsten. Und auch dieses Überblenden ließe sich mit minimaler Datenmenge übertragen.

Halten wir's mal quasi-gleichzeitig, weil ja alles mit serieller Datenübertragung zu steuern ist. Ich muss in der Lage sein (und bin es auch), mehrere unabhängige Luftströme (quasi)gleichzeitig zu kontrollieren. Genauer gesagt muss ich auch zwischen ihnen kontrollieren können.
Die Datenmenge ist für jeden Luftstrom die gleiche, nur die darin enthaltenen Werte sind immer unterschiedliche. Exakt genug funktioniert das in Analoggrößen, die auf getrennten Leitungen übertragen werden. So auch quasi-exakt via Multiplexer und Demultiplexer seriell auf einer Leitung. Die Digitalübertragung sollte einer Analogsteuerung möglichst entsprechen können.


Luftdruck, Luftgeschwindigkeit, (und bei Wind Controllern á la Holz / Blech) die Ansatzposition sowie der Mundinnenraum sollten idealerweise auch gemessen und gleichzeitig übertragen werden, um den Klang zu verändern und Dinge wie Bendings zu realisieren. Da kann's dann doch etwas eng werden mit MIDI.

Die 'Dinge' lassen sich allesamt von je einer einzigen Hüllkurve steuern, wenn man sie digital hoch genug auflöst und so Schwellwerte setzen kann, die zusätzliche Effekte ins dynamische Spektrum einbauen. Die Effekte sollen dem oberhalb des Schwellwertes weiteren Verlauf der Hüllkurve folgen und dazu ihrerseits noch hinreichend Auflösung nutzen können (6 ...8 Bit).


Daher habe ich vor, OSC über über Netzwerk oder USB zu benutzen, wenn ich demnächst mit meinem eigenen (Wind) Controller Prototypen für XPression beginne. OSC wird bereits von einigen neuen Herstellern, wie z.B. Eigenharp unterstütz. Die Netzwerkübertragung erlaubt theoretisch eine 30-fache Übertragungsgeschwindigkeit. Diese wird aber durch die Netzwerkprotokolle entsprechend reduziert, hauptsächlich zur Fehlerkorrektur. Hier gibt es allerdings keinen wirklichen Standard wie bei MIDI. Jeder macht da, was er will.

Es liegen ja die unterschiedlichsten Primär-Anwendungen vor, die auf einer gemeinsamen Basis nicht gleichermaßen optimal funktionieren können. Ich meine, für jede Instrument-Gattung sollte die Interface-Basis eine eigene spezifizierte sein. Ein universell verwendbares Soundmodul/-system sollte so konstruiert sein, dass man verschiedene Interfaces einsetzen kann. So bspw. wäre die Midi-Funktion als Einschubmodul sinnvoller. Kommt das Controller-Instrument mit einem anderen Interface daher, zieht man das Midi-Interface heraus und steckt das andere Interface rein. Das (Hardware-) Soundmodul ist so auch preiswerter herstellbar und das Interface wird einfach in die Kosten des jeweiligen Controller-Instruments eingepreist.


Das Problem, das ich bei Deinem Instrument sehe, ist dass Du nicht nur einen Harmonika-Controller konstruieren musst, sondern auch ein Soundmodul / virtuelles Instrument, das Deine Daten umsetzen kann. Ich arbeite jetzt schon 6 Jahre fulltime an XPression und bin immer noch nicht wirklich da, wo ich gerne sein möchte. Einen Tonerzeuger zu bauen, der auf die Nuancen, die Du ansprichst, korrekt reagiert, wird nicht einfach werden. Alles in allem kannst Du von 5-10 Jahren Entwicklungszeit für beides ausgehen, wenn Du Deinen Job jetzt kündigst. Ob's Dir gelingt, dass alles funktioniert, weiss man vorher nicht. Du wirst auf jeden Fall auf einen sehr kleinen Markt treffen, der die Entwicklungskosten in keinem Fall rechtfertigen wird :-(

Der (primäre) Harmonika-Controller ist bereits konstruiert. Jedwede Daten umsetzen kann potenziell jedes Soundmodul. Es bedarf hier lediglich des geeigneten Interfaces. In den bisher erhältlichen Tonerzeugungsgeräten ist leider kein Zugriff auf die eigentliche Tonerzeugung möglich, weil die mit dem Midi-Interface zusammen quasi monolithisch verbaut ist. Die getrennte Applikation der Funktionsabteilungen wäre das Maß der Dinge. Jede Funktionsabteilung ein autarkes Modul.
Nicht auf jeden Fall werde ich einen sehr kleinen Markt treffen. Nur schlimmstenfalls. Entwicklungskosten sind immer zu rechtfertigen, wenn daraus ein Gebrauchsprodukt entstehen soll. Wo immer man zuerst die Kosten sieht, kann man auch jede Idee vergessen und sich mit Däumchen drehen das Leben versüßen.


Es gibt etliche Threads mit Leuten, die Controller-Instrumente in irgend einer Form bauen wollen. Fast keiner schafft es, einen funktionierenden Prototypen herzustellen, geschweige denn, die Instrumente in Serie zu bringen.
Das ständige Polemisieren, dass alles was auf dem Markt ist nichts taugt, bringt nur was, wenn man tatsächlich etwas Besseres zustande bringt. Ich warte selbst schon seit etlichen Jahren darauf, dass sich etwas tut. Leider vergebens!

Neue Controller-Instrumente in Serie gehen mit der obligatorischen Orientierung am Midi-Standard einher. Die Industrie sagt nein, wo Midi nicht mitspielt. Marketing. Midi kann aber nicht alles, und so bleibt mancher auf seinen Projekten sitzen. Besseres zustande bringen lässt sich am ehesten, indem auch die Industrie Kompromisse eingeht und eine Möglichkeit gemäß meinem obigen Konzept annimmt.


In der Regel gehen die meisten, wie Du auch, von theoretischen Idealen aus, die weder technisch noch musikalisch sinnvoll sind. Geschwindigkeit bei der Datenübertragung wird völlig überschätzt. Das was zählt, ist die Qualität der Auswertung und das korrekte Mapping auf die Klangparameter des Tonerzeugers. Kaum ein aktuelles Instrument kann mit solchen Daten etwas anfangen.

Es geht mir nicht um theoretische Ideale, sondern um technisch realisierbare Möglichkeiten, die vor allem musikalisch sinnvoll sind. Das Gegenteil würde ich sofort verwerfen!
Die Geschwindigkeit der Datenübertragung muss so hoch sein, dass die Arbeitsfrequenz der stetigen Dynamik-Aktualisierung nicht aus den Tönen herausgehört werden kann. Es sei denn, eine Sample&Hold-Funktion pendelt die Aktualisierungen unter 20 Hz ein. Das bedeutet aber mindestens 50 ms Verzögerung; ob sich das evt. störend auswirkt, kann nur die Praxis herausstellen.


Noch ein kurzer Nachtrag ...

... ich habe eben mal recherchiert, was Airflow Sensoren zur Messung der Luftgeschwindigkeit kosten. Diese wären zusätzlich zu den günstigeren Drucksensoren notwendig um Bending zu ermöglichen. Da sind wir pro Stück bei 55 - 80 Euro + Mehrwertsteuer.

Schon allein die Sensoren würden in einer Konstruktion wie Du sie vorschlägst ein kleines Vermögen kosten. Eine kommerzielle Version des Instrumentes wäre nicht unter 2.000 - 3.000 Euro VK herzustellen - wenn das überhaupt reicht. Es kommen ja noch weitere Bauteile, Herstellungskosten, Entwicklungskosten, Vertriebskosten, Werbung, etc. hinzu. Das ganze natürlich ohne Soundmodul!

Mit 16 Sensoren je 30,- DM war ich auch nicht froh. Der Preis liegt heute noch immer um 15 Euro. Aber je größer die Stückzahl, desto günstiger der Einzelpreis. Für den Fall einer Serienfertigung habe ich mir ein anderes Konzept ausgedacht. Dieses Konzept umfasst die Sensorik für alle 16 Kanzellen und dürfte in Serienfertigung den Preis eines Einzelsensors nicht wesentlich übersteigen.


Ein weiteres Problem wäre die benötigte Größe. Um solch einen Kontroller zu fertigen müsste man eine sehr durchdachte Konstruktion bauen, um den Luftdurchsatz über nur wenige zusammengeführte Sensoren zu messen. Ob sich durch die Veränderungen in den Luftkammernwegen Messungenauigkeiten einstellen, die die Intonation unbrauchbar machen, wäre noch abzuwarten.

Das hast Du so nicht richtig rekonfiguriert: es gibt keine zusammengeführten Sensoren. Jeder Sensor steht in autarker Verbindung mit dem für ihn zuständigen Ton-Duo. Weil der Chromat hinzukommt, ist jeder Sensor für 4 Töne zuständig. Zwischen diesen 4 Tönen wird alterniert durch Drücken (Blasen), Ziehen (Saugen) und Chromat. Richtig erkannt hast Du, dass eine sehr durchdachte Konstruktion zu bauen ist. Das hat mich aber keineswegs in Verlegenheit gebracht. Denn nichts ist unmöglich, wenn es nur darum geht ...


Die Druckschwankungen beim Wechsel von einstimmigen zu mehrstimmigen Spiel sind mit Sicherheit auf nicht ohne.

Das hat man bisher mit der klassischen Mundharmonika im Griff gehabt. Und so wird man das auch mit der elektronischen Mundharmonika in den Griff bekommen. Mein Stadium von 1987 hat mich davon überzeugt, dass es bestens funktioniert.


Ein traditioneller Wind Controller Aufbau mit nur einem Blassensor ist deutlich einfacher in den Griff zu bekommen. So etwas kann man sich mit einem Arduino Board - wie Nyle Steiner das bereits vorgemacht hat - innerhalb von einem Tag in EWI-Qualität bauen.

Ich habe nicht die Absicht, mich auf die deutlich einfacheren Möglichkeiten zu beschränken. Denn ich will ein primär freihändig solierbares Universal-Musikinstrument realisieren. Mithin sekundär auch den Profi-Harpern die elektronische Tonerzeugung zugänglich machen. Das geht – wenn auch bisweilen nur undeutlich – einfach genug, um es ganz fest im Auge behalten zu können. Ein traditioneller 'Wind Controller Aufbau' darf mich einfach nicht interessieren. Weil das nur Ballast fortpflanzt, der auf dem Weg ins Geling-Ziel einer neuen Sache einfach nichts zu suchen hat.


... aber da sind wir ja wieder bei der Qualität der aktuellen Instrumente, die leider noch auf dem Stand der Technik von ca. 1980 sind. :-(

Genauer gesagt, 1983/84.
Und ich grüße Dich, Ingo, heute in 2013
Arwed
 
Ich habe nicht die Absicht, mich auf die deutlich einfacheren Möglichkeiten zu beschränken. Denn ich will ein primär freihändig solierbares Universal-Musikinstrument realisieren. Mithin sekundär auch den Profi-Harpern die elektronische Tonerzeugung zugänglich machen. Das geht - wenn auch bisweilen nur undeutlich - einfach genug, um es ganz fest im Auge behalten zu können.

Mit den gestellten Anforderungen denke ich, daß Du Deine anzustrebende Erfindung nicht mehr erleben wirst.
Ein telepathisch gesteuertes Instrument brächte vielleicht die Lösung.
Ich für meinen Teil nutze die restliche Zeit meines Lebens lieber, um einfach nur Musik zu machen...

Jürgen Hart hat mal gesungen: "Der schönste Platz den ich auf Erden hab, das ist der Schaukelstuhl vor meinem Grab."

Bei mir wäre es der Platz hinter meinem Schlagzeug :rolleyes:
 
Die 'Dinge' lassen sich allesamt von je einer einzigen Hüllkurve steuern, wenn man sie digital hoch genug auflöst und so Schwellwerte setzen kann, die zusätzliche Effekte ins dynamische Spektrum einbauen. Die Effekte sollen dem oberhalb des Schwellwertes weiteren Verlauf der Hüllkurve folgen und dazu ihrerseits noch hinreichend Auflösung nutzen können (6 ...8 Bit).

Das würde die Datenübertragung nicht optimieren, sondern vervielfachen. Du müsstest bei jeder Parameteränderung alle anderen Parameter mitübertragen, auch wenn sie sich gar nicht verändert haben.

Es liegen ja die unterschiedlichsten Primär-Anwendungen vor, die auf einer gemeinsamen Basis nicht gleichermaßen optimal funktionieren können. Ich meine, für jede Instrument-Gattung sollte die Interface-Basis eine eigene spezifizierte sein. Ein universell verwendbares Soundmodul/-system sollte so konstruiert sein, dass man verschiedene Interfaces einsetzen kann. So bspw. wäre die Midi-Funktion als Einschubmodul sinnvoller. Kommt das Controller-Instrument mit einem anderen Interface daher, zieht man das Midi-Interface heraus und steckt das andere Interface rein. Das (Hardware-) Soundmodul ist so auch preiswerter herstellbar und das Interface wird einfach in die Kosten des jeweiligen Controller-Instruments eingepreist.

Es würde nicht günstiger, sondern teuerer werden, wenn alle die Entwicklung für unzählige Module bezahlen müssten. Ein oder zwei Standardinterface(s) die für die Datenübertragung geignet sind fest eingebaut ist bei weitem die günstigste Lösung. Es besteht kein Bedarf für Sonderlösungen, wenn die Geschwindigkeit stimmt.

Besseres zustande bringen lässt sich am ehesten, indem auch die Industrie Kompromisse eingeht und eine Möglichkeit gemäß meinem obigen Konzept annimmt.

Die Industrie geht keine Kompromisse ein - sie will möglichst viel Geld mit möglichst wenig Aufwand verdienen. Punkt!

Die Geschwindigkeit der Datenübertragung muss so hoch sein, dass die Arbeitsfrequenz der stetigen Dynamik-Aktualisierung nicht aus den Tönen herausgehört werden kann. Es sei denn, eine Sample&Hold-Funktion pendelt die Aktualisierungen unter 20 Hz ein. Das bedeutet aber mindestens 50 ms Verzögerung; ob sich das evt. störend auswirkt, kann nur die Praxis herausstellen.

Wie kommst Du denn auf die Rechnung? Ein Blaswandler benötigt eine initiale Verzögerung von mindestens 15-20 ms um den Luftdruck aufzubauen, der nötig ist um eine exakte Anblasstärke auszugeben. Was dann kommt wird interpoliert. Die aktualisierung der Werte sollte zwischen 3-10 ms stattfinden.

Mit 16 Sensoren je 30,- DM war ich auch nicht froh. Der Preis liegt heute noch immer um 15 Euro. Aber je größer die Stückzahl, desto günstiger der Einzelpreis. Für den Fall einer Serienfertigung habe ich mir ein anderes Konzept ausgedacht. Dieses Konzept umfasst die Sensorik für alle 16 Kanzellen und dürfte in Serienfertigung den Preis eines Einzelsensors nicht wesentlich übersteigen.

Welche Latenzzeiten haben Deine 15,- EUR Airflow-Sensoren?
Und von welchen Stückzahlen gehst Du für den Bau neuer Kombi-Sensoren da aus?
10.000 oder 100.000?

Na, dann bin ich mal auf Deine Umsetzung gespannt. Wie bereits gesagt liegen zwischen der Theorie und der Praxis manchmal Welten ...

Ich wünsche Dir auf jeden Fall viel Glück, dass Du's in den Griff bekommst!

Grüße
Ingo
 
Zuletzt bearbeitet:
Hallo Ingo!

Wie ich auf die Rechnung komme, hast Du anscheinend noch nicht verstanden. Wenn die Aktualisierung der Werte zwischen 3 und 10 ms stattfinden soll, dann geht das mit einer Arbeitsfrequenz von 100 ...333 Hz einher. Aus dem Midi-Datenflow ergeben sich 65,1 Hz, wenn ihm die zyklische Abfrage aller 16 Kanzellen (je 3 Bytes) zugrunde liegt.
Mit dieser oder jener Frequenz werden dann alle Töne moduliert bzw. durchsetzt. Wenn ich mir das in Audio vorstelle, dann stelle ich mir einfach nur Super-Käse vor! Die Sensor-Latenzzeiten spielen dabei überhaupt keine Rolle. Sie betragen: primär überhaupt kein Problem. Und sekundär addieren sie sich zur Dauer zwischen Spielen und Feedback, womit wieder die Geschwindigkeit des Datenflows kritisch zu betrachten ist.

Das würde die Datenübertragung nicht optimieren, sondern vervielfachen. Du müsstest bei jeder Parameteränderung alle anderen Parameter mitübertragen, auch wenn sie sich gar nicht verändert haben.

Die Datenübertragung vervielfacht sich eben nicht. Ich wiederhole: Die Datenmenge ist für jeden Luftstrom (stets) die gleiche, nur die darin enthaltenen Werte sind (fast) immer unterschiedliche. Das hängt übrigens nicht davon ab, ob sich in der Kanzelle was tut oder nicht. Rein der Einfachheit halber favorisiere ich die dauernde zyklische Werte-Abfrage aller Kanzellen. Das jeweilige Digitalwort enthält eine Variable zwischen Null und Maximum plus den Adresscode des zugehörigen Tons.
Ich beharre auf Bedarf für Sonderlösungen, wenn die Geschwindigkeit nicht stimmt.
Außerdem beharre ich darauf, aus diesem Thread ab sofort herauszuhalten, wie das Ganze 'wirtschaftlich' funktionieren soll. Das ist eine andere Kategorie; hier geht es um die potenziellen Features und die dafür maßgeblichen technischen Bedingungen. Falls das nicht weiter interessant ist, werde ich diesen Thread schließen.

Grüße
Arwed
 
Außerdem beharre ich darauf, aus diesem Thread ab sofort herauszuhalten, wie das Ganze 'wirtschaftlich' funktionieren soll. Das ist eine andere Kategorie; hier geht es um die potenziellen Features und die dafür maßgeblichen technischen Bedingungen. Falls das nicht weiter interessant ist, werde ich diesen Thread schließen.
Grüße
Arwed

Also: so bitte nicht. Du kannst hier keine Diskussionsverläufe zulassen oder untersagen. Und eine Schließung des Threads können ausschließlich wir Moderatoren veranlassen, aber keine User. Du kannst höchstens an dieser Diskussion weiter teilnehmen oder es seinlassen, so wie jeder hier.

Harald
 
... Die Datenübertragung vervielfacht sich eben nicht. Ich wiederhole: Die Datenmenge ist für jeden Luftstrom (stets) die gleiche, nur die darin enthaltenen Werte sind (fast) immer unterschiedliche. Das hängt übrigens nicht davon ab, ob sich in der Kanzelle was tut oder nicht. Rein der Einfachheit halber favorisiere ich die dauernde zyklische Werte-Abfrage aller Kanzellen. Das jeweilige Digitalwort enthält eine Variable zwischen Null und Maximum plus den Adresscode des zugehörigen Tons.
Ich beharre auf Bedarf für Sonderlösungen, wenn die Geschwindigkeit nicht stimmt. ...
nun... vielleicht hilft eine Analogie aus dem Film weiter...
ein frühes Format war einfach das Abspielen von 25-50 jpeg Bildern pro Sekunde -> grosses Datenvolumen
nur durch eine andere Codiermethodik lässt sich das Datenaufkommen um Faktoren vermindern - bei identischer visueller Qualität
das 'Instrument' braucht nur Sensoren und Transmitter, dabei ist die Übertragungsgeschwindigkeit nahezu beliebig (hoch)
erst nach Dekodierung im 'Modul' greift das Midi-Zeitraster
(und auch nur für den Fall, dass klassische Midi-Peripherie genutzt werden soll)

cheers, Tom
 
Sorry Arwed,

mit Deinen technischen Vorstellungen wirst Du in den nächsten 20 Jahren kein funktionierendes Gerät bauen können - Wirtschaftlichkeit hin oder her. Du bräuchtest eine Bandbreite, die einem unkomprimierten Video ähnelt und würdest mindestens 99,9 % oder mehr der Daten verschwenden, weil sie nicht relevant sind.

Warum sollte ein Soundmodul 99% seiner Leistungsfähigkeit dazu verwenden, relevante von nicht relevanten Daten zu unterscheiden? Effektiv wäre, nur sich verändernde Daten darzustellen.

Wie Telefunky eben schon treffend erwähnt hatte, um einen schwarzen Bildschirm 3 Stunden lang darzustellen benötigst Du nur ein einziges Byte. Wenn er nach 3 Stunden dann für weitere 3 Stunden weiß wird benötigst Du ein weiteres Byte.
Mit Deiner Methode wären etliche Gigabyte nötig um tatsächlich zwei Bytes (0 0 0 und 1 1 1) zu übertragen.

Natürlich könntest Du ein 24 oder 32 bit Multichannel-Audioformat für die Übertragung benutzen. Aber wozu? ***

Das Prinzip von MIDI besteht darin, zu übertragen, dass, wenn eine Taste gedrückt wurde, ein gewisser Ton / Sample erklingen soll. Wenn die Taste losgelassen wird, wird dem Tonerzeuger mitgeteilt, dass er die Note nun beenden soll. Welche Verbesserung würde sich ergeben, wenn ich dem Soundmodul 44.100 mal pro Sekunde (während jedes Samples) sage, dass die Taste immer noch gedrückt ist?
Was genau bringt es zigtausendmal pro Sekunde zu übermittlen, welche Noten momentan die Lautstärke "0" haben, nicht im Pitchbend verändert wurden und auch kein Vibrato spielen?

Es hat nichts mit Sonderlösungen zu tun, den Datenstrom bereits bei der Auswertung der Sensoren zu optimieren.
Es ist normal, den Datenverkehr auf das absolute Minimum zu reduzieren. Dann hätte das Soundmodul auch Zeit sich mit seiner eigentlichen Aufgabe, der Tonerzeugung, zu beschäftigen.

Schade, aber ich sehe schon, dass dieser Thread leider zu nichts führen wird, warum ich mich dann auch ab jetzt wieder heraushalten werde ...

Es sei den, Du bringst demnächst einen funktionierenden Prototypen bei, der - auch in der Praxis - so funktioniert, wie Du es beschreibst ...

Ingo


*** bei der Übertragung über ein 24-bit SPDIF Audiosignal könnte übrigens durchaus das Signal in drei 8-bit Signale - wie Du es sagtest - aufgesplittet werden. Diese drei Bytes könnten ein Standard MIDI Protokoll benutzen, um eine fast 100-fach schnellere MIDI-Übertragung zu realisieren. Mit AES/EBU liessen sich auch entsprechende Kabellängen benutzen. Diese Technik wird gelegentlich verwendet, um in Programmen intern Daten blockweise schneller zu übertragen, als das mit der Control Rate mancher Programme möglich ist. Man muss bei der Übertragung dann aber die Audiolatenz des Sytems dazu addieren. D.h. bei externer SPDIF Übertragung die Latenz beider Systeme.
( ... sorry, das geht etwas an's programmiertechnisch Eingemachte.
)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 2 Benutzer
Hi Tom und Hi Ingo!

Tom:
Nein, nicht nach der, sondern vor der Dekodierung greift das Midi-Zeitraster. Wobei ich von den Vorgängen im Empfänger ('Modul') spreche. Im Midi-Zeitraster wird die Dekodierung getriggert. Daraufhin wird ein Prozess ausgeführt, dessen Wirkung auf den Ton sich unabhängig von diesem Zeitraster entfaltet. Aber wie lange entfaltet sich die? 200, 500, 1000 oder noch mehr Millisekunden? Davon hängt ab, ob mit EMH die Kontrolle verloren wird oder nicht. Lässt sich die Prozess-Wirkung gemäß dem Midi-Datenflow bei 65,1 Hz alle 15,3 ms aktualisieren, dann kann EMH – in diesem Punkt – beherrscht werden. Aber dann durchsetzt die Aktualisierungsfrequenz den Ton, wenigstens während der dynamisch bewegt wird. Deshalb hätte ich die oberhalb von 20 KHZ oder unterhalb von 20 Hz anzusiedeln. Unterhalb scheint mir kritisch.

Und was die fragliche Datenflut anbelangt:
Eine Digitalhüllkurve als Primär-Größe (11 Bit) kann im Empfänger so verwendet werden, dass sie mehrere Tonbearbeitungs-Controller (in Sekundär-Größe / 6 ...8 Bit) parallel steuert. Also mit ein und derselben digitalen Primär-Größe.

Natürlich könntest Du ein 24 oder 32 bit Multichannel-Audioformat für die Übertragung benutzen. Aber wozu? ***

Das Prinzip von MIDI besteht darin, zu übertragen, dass, wenn eine Taste gedrückt wurde, ein gewisser Ton / Sample erklingen soll. Wenn die Taste losgelassen wird, wird dem Tonerzeuger mitgeteilt, dass er die Note nun beenden soll. Welche Verbesserung würde sich ergeben, wenn ich dem Soundmodul 44.100 mal pro Sekunde (während jedes Samples) sage, dass die Taste immer noch gedrückt ist?
Was genau bringt es zigtausendmal pro Sekunde zu übermittlen, welche Noten momentan die Lautstärke "0" haben, nicht im Pitchbend verändert wurden und auch kein Vibrato spielen?

Da scheiden sich doch die Geister wohl immer. Ich will kein Multichannel-Audioformat benutzen. Denn richtig: WOZU? Das Prinzip von MIDI kenne ich. Und da kann mein Ding höchstens 65 mal pro Sekunde dem Soundmodul sagen, dass die „Taste gedrückt“ ist. Aber auch das wäre ja tatsächlich dummes Zeug. Nur via Midi bleibt mir ja gar nichts anderes übrig (Channel-Aftertouch polyfonisieren). Es geht hier nie um eine gedrückte Taste, sondern immer nur um einen Wert unter vielen. Und jeder Wert muss stets auch den richtigen Ton adressieren. Welche adressierten Töne dabei eingeschaltet oder ausgeschaltet werden, gibt der niedrigste Wert-Level vor. Kein höherer Wert darf das jemals tun!

Ingo:
Nein, ich brauche keine Bandbreite, die einem unkomprimierten Video ähnelt. Ich brauche nur einen kontinuierlichen Datenflow, der jederzeit 16 Messwerte und Adresscodes von 'A' nach 'B' überträgt. Im Empfänger ist der Wert Null genau so relevant wie jeder andere Wert. Du kannst von mir einfach nicht erwarten, die „Optimierung des Datenstroms“ von der Auswertung jedes Einzelsensors abzuleiten. Da kollidiere ich mit Trigger-Hysteresen und mein Instrument kollidiert mit der Wand, weil ich nicht mal eine Tonfolge durch dudeln kann, ohne dauernd falsche Töne zu „erwischen“. Oder die Prozesssteuerung wäre ungleich komplexer aufzubauen als die Loop-Manier (z. B. jede Kanzelle bräuchte einen eigenen A/D-Wandler).

Ich habe es mit einem polyfonen Gebläse zu tun, von dem allein die Tonsteuerung ausgehen muss.
Ein Gebläse ist nun mal datenintensiv. Und mit einem monofonen Gebläse ist niemand darauf angewiesen, einen „aalglatt“ sauberen Dynamikverlauf erzeugen zu können. Aber mit EMH wird das ganz schnell kritisch, weil ich bereits die Polyfonfunktion des Gebläses nur seriell übertragen kann. Und vor allem weil man auf dem engen Kanzellenraster musizieren und deshalb zwischen den Tönen sauber differenzieren können muss.

Die Soundabteilung hat dabei nicht mehr zu tun als in jeder anderen Anwendung auch. Sie wird lediglich von einem sinngemäß geeigneten Interface zwischen EMH und Tonerzeugung bedient. Und das Interface ist nicht aufwändiger oder komplexer als MIDI (eher sogar einfacher). Es hat nur eine davon abweichende Funktionshierarchie, um den Anforderungen des Mundharmonika Spielens genügen zu können. Allerdings versteht sich das ohne die üblichen Zusatzfunktionen wie z. B. 'Programm-Change', aber da kann die (periphere) Bedienung ganz separat auch Midi-kompatible Daten produzieren.

Der einzige Konflikt ist der, auf den Kern der eigentlichen Tonerzeugung bei Industriegeräten wegen der hohen Integrationsdichte nicht zugreifen zu können. Deshalb müsste ich auch den neu aufbauen. Aber bauen werde ich gar nichts mehr. Allenfalls ausführliche Konstruktions- Layout- und Schaltpläne zeichnen und damit die Entwicklungsabteilungen der Industrie konsultieren ...

Grüße Euch
Arwed
 
Hallo Leute,

ich habe gerade diesen, schon etwas älteren Thread, bei dem es um das Thema Mundharmonika ging, wieder entdeckt.

Da ich vor kurzem erst eine Mundharmonika für den XPression gesampelt (und u.a. für Wind Controller spielbar gemacht) habe, dachte ich sofort an diese zwei Videos "aus der Praxis", die zeigen, wie eine Mundharmonika auf dem EWI spielbar ist.

Der kompromisslose Blues-Harp Spieler wird vielleicht hier und da noch was auszusetzen haben, aber für mich ist das Ergebnis deutlich mehr als "nur" brauchbar.


Zuerst eine Blues-Harp, die man über den Bite Controller mehrstimmig spielen kann. Die Töne wurden auf das Richter Tuning begrenzt, um auch wirklich nur die "richtigen" Töne spielen zu können. Bestimmte Töne sind - wie bei der echten Blues-Harp - nur über Bending zu erreichen.

Durch die Einschränkung auf die Richter-Stimmung muss man das Instrument transponieren, um in allen Tonarten spielen zu können.

Die Distortion bringt noch ein gewisses Live-/ Bühnen-Feeling.


Danach eine chromatische, cleane Harmonika, eher für den Jazzer. Das Vibrato ist hier mit der Luft (Kehlkopf / Zwerchfell) wie auf der Harmonika (etwas à la Stevie Wonder) gespielt. Das geht aber auch genau so gut mit dem Bite Controller.


Im Übrigen habe ich beim Spielen nicht das Gefühl, durch die "langsame" MIDI-Übertragung behindert zu werden. :)

Noch zur Info: Die Samples wurden mit mehreren HOHNER "Marine Band DELUXE" erstellt.






Viel Spaß!
Ingo
 
Zuletzt bearbeitet:
Schöne Einspielungen - ich bin mal gespannt, wann ich auch nur annähernd das EWI so beherrsche, das ansatzweise was ähnliches rauskommt. :)

Ich habe allerdings beim Rumspielen mit der Blues-Harp noch nicht so recht kapiert, wie ich - ähnlich wie auf der Mundharmonika - eine komplette Oktave ganz normal diatonisch gespielt bekomme. Irgendwie fehlen mir da einige Töne.

Oder bezog sich darauf dein Hinweis mit dem Bending? Ich habe das für mich ausgeschaltet, weil ich damit bislang nicht klargekommen bin und es für andere, klassisch gespielte Instrumente nicht brauche.

Tschüssi,

Petra
 
Zuletzt bearbeitet:
Moin Petra,

die nach Richter gestimmte Mundharmonika kann nur in der mittleren Oktave eine vollständige diatonische Tonleiter spielen.
In der darunterliegenden Oktave fehlen 2 Töne (F und A), in der obersten ein Ton (H) - alle Angaben in C-Dur. :confused:

(auf Grafik klicken)
BluesHarp_Notes_Layout.png

Für alle Töne würde ich Dir die chromatische Version (zweites Video) empfehlen. :great:


Die "abgespeckte" Richter-Version ist eher als Blues-Variante (wie im ersten Video oben) gedacht, kann aber in Norddeutschland auch zur Nachvertonung alter Seemanns Filme verwendet werden. :whistle:

Bei der Blues-Harp wird ein auf C-Dur gestimmtes Instrument in G gespielt (kleine Septime = mixolydisch), um näher an die Töne der Blues-Tonleiter zu gelangen. Das nennt sich dann "Cross Harp". Aber auch da sind alle benötigten Töne der Blues-Tonleiter (kleine Terz + verminderte Quinte) nur durch Pitchbending zu erreichen. :gruebel:

Interessant ist auch, dass zwistimmige Töne (auf dem EWI-USB erzeugt mit dem Bite-Controller) in den verschiedenen Oktaven unterschiedliche Intervalle aufgrund dieser Stimmung produzieren.
Bevor man eine gute Emulation einer Blues-Harp spielen kann, sollte man sich etwas in die Denkweise eines Mundharmonika-Spielers einarbeiten. :bang:

Grüße, Ingo :cool:
 
Zuletzt bearbeitet:

Unser weiteres Online-Angebot:
Bassic.de · Deejayforum.de · Sequencer.de · Clavio.de · Guitarworld.de · Recording.de

Musiker-Board Logo
Zurück
Oben