Ungewollte, zufällige sehr laute Töne

  • Ersteller hade0011
  • Erstellt am
hade0011
hade0011
Registrierter Benutzer
Zuletzt hier
01.12.18
Registriert
15.01.08
Beiträge
12
Kekse
0
Hallo,

ich übe Keys auf einem Roland MKB 200, es hängt über ein Midi-auf-USB-Kabel am PC, der Pianosound kommt von Ableton Live 8. Immer wieder kommen dabei zufällig ungewohnt sehr laute Töne zustande. Ich vermute dass diese Töne volle Velocity habe, da sie wesentlich lauter sind als der Rest(ich spiele eher leise). Ich habe den Eindruck, dass die Töne auftreten, wenn ich die entsprechende Taste loslasse, bin mir aber nicht sicher, da ich den Fehler leider nicht verlässlich reproduzieren kann.

Hat jemand eine Ahnung woran das liegen könnte?

Beste Grüße,
Dennis
 
Eigenschaft
 
Eventuell schickt das Keyboard eine Release-Velocity und das Softwareinstrument weiß damit nicht umzugehen. Das müsstest du dann vorher filtern.
 
Danke für den Tip. Wie bekomme ich raus, ob das Keyboard Release-Velocity schickt?
 
Du brauchst einen MIDI Monitor. Ich weiß nicht, ob Ableton das integriert hat.
Du musst nach schauen, ob das Keyboard bei Loslassen der Taste einen Note On mit dem Value 0 schickt oder einen Note off.
 
alles klar, Dankeschön
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Wer macht denn so einen Unfug? Wozu soll sowas gut sein? Da fällt mir eigentlich kein sinnvoller Anwendungsfall ein - nur Nachteile (z.B. externe Tonerzeuger, die einen Decay der Hüllkurve bei Note-off triggern etc).

Hallo Jens,

das ist doch MIDI-Standard. Der Tonerzeuger sollte das korrekterweise auch als Note-Off-Befehl interpretieren. Weil es gerade so gut passt ein Zitat aus dem Nachbarthread:

MIDI CLOCK würde ganz schön ins Hintertreffen geraten hätte man nicht den sogenannten Running Status eingeführt der das Datenvolumen
reduziert. Das war auch der Grund warum man einen MIDI NOTE OFF Befehl mit einem MIDI NOTE ON und der Velocity NULL gleichsetzt.
Hierdurch wird dann das Senden eines erneuten Statusbytes überflüssig

(https://www.musiker-board.de/threads/midi-signale-zusammenf%C3%BChren-y-kabel-ausreichend.589457/#post-7176585)

Viele Grüße, :)

Jo
 
Zuletzt bearbeitet:
Hab ich auch gerade gelesen. Nur will mir das nicht ganz einleuchten: Note-On und Note-Off sind doch nun erstmal gleichlang?!?

1000nnnn 0kkkkkkk 0vvvvvvv Note Off event.
1001nnnn 0kkkkkkk 0vvvvvvv Note On event.

Wo spare ich da was? Das kann doch höchstens dann was bringen, wenn garantiert außer Note-on und Note-off nichts anderes kommt (CC,... ).
Zumindest ist es eine Verletzung des Standards - denn offensichtlich können nicht alle Tonerzeuger mit sowas umgehen. z.B. ist für das GEM Micropiano, soweit ich weiß, Note-On mit Vel.0 einfach das Abheben des Dämpfers ohne Saitenanschlag - und Note-Off beendet einen Ton. Dito macht es einen Unterschied bei diversen VAs, ob ich mit Note-off eine Decayphase einleite oder mit Note-On und Velocity 0 sofort eine neue Hüllkurve triggere (die ja nicht zwingend mit Lautstärke 0 beginnen muss.
Wäre das wenigstens überall einheitlich, könnte ich das ja noch verstehen - aber so ist das doch Grütze. Mal ganz davon abgesehen, dass Release-Velocity mit dieser Krücke ja nun gar nicht möglich ist. *)

Wenn man schon so "intelligent" ist und sich bei mehreren gleichartigen Nachrichten die redundanten Statusbytes spart, dann doch bitte auch so, dass man nicht das Rad neu erfindet, sondern dann wirklich "intelligent" prozessiert, sprich nachschaut, was auf der Leitung los ist und nur beim Statuswechsel ein entspr. Byte sendet.

Das haben sich IMHO wieder Leute ausgedacht, für die sich MIDI nur im Kontext von voll ausgereizten Midi-Alleinunterhalter-Arrangements oder im Studio abspielt. Für einen Live-Keyboarder (oder beim Einspielen im Studio stellt das Datenvolumen der Note-On/Off-Befehle doch keinen Flaschenhals dar. Wenn es mal eng wird, dann in dem Moment, wo gleichzeitig zu den Noten noch CC-Messages in Massen generiert werden (Schweller/Expression z.B.) Und gerade dann spare ich mit dieser eigenartigen Neudefinition gar nichts an Statusbytes (weil sich die Noten - egal ob on oder off - sowieso zwischen die CC-Befehle quetschen müssen und dazu den Status senden müssen).

Oder kann mich jemand darüber aufklären, was ich da übersehe?

*) Und wenn ich die Release-Velocity schon opfere, wäre ein Weglassen der Velocity beim Note-off deutlich sinnvoller als das Umdefinieren eines Befehls, für den es aus gutem Grund zwei unterschiedliche Messages gibt.
 
  • Gefällt mir
Reaktionen: 1 Benutzer
hi
Also wenn eine NOTE ON mit Velocity NULL auschaltet sieht eine Bytefolge

1000nnnn 0kkkkkkk 0vvvvvvv Note Off event.
1001nnnn 0kkkkkkk 0vvvvvvv Note On event.

dann so aus : nnnn = Kanal ; kkkkkkk Tastennummer ; vvvvvvv = Velocitiy

1001nnnn 0kkkkkkk 00001111 0kkkkkkk 00000000

Note ON.............................. /....Note ON
Velocity 00001111......................Velocity 00000000 = NOTE OFF

gespart wird nur das Statusbyte 1000nnnn
Hört sich wenig an aber wenn 10 Tasten gedrückt waren und dann losgelassen werden sind das schonmal 10 Bytes die nicht gesendet werden müssen
Besseres Beispiel ein FADER der Midisignale sendet.
Für jede Position des Faders müßte dann ein Statusbyte plus Datenbytes gesendet werden was zuvor per AD Wandlung in digitale Form umgesetzt wurde.
Gerade bei Fadern ist das Datenaufkommen sehr groß und hier wird dann so richtig an zu sendenden Bytes gespart , was letztlich einer
ECHTZEIT zu gute kommt

Sobald also auf ein Statusbyte mehr als 2 Datenbytes folgen nennt man dies : RUNNING STATUS
Das Statusbyte wird zwischengespeichert und ist solange aktuell bis ein neues ( anderes ) Statusbyte eintrifft

In der MIDI Association ist dieses Verfahren dokumentiert

@jens
was Dein Micropiano angeht so gibt es noch ärgere Verfahren MIDI Daten zu senden.
Dämpferpedale hat man vielleicht früher so gehandhabt, heute gibt es dafür die CONTROLLER Befehle mit eigenen Statusbytes wie zB
Pitchwheels etc. Reichen die normalen verschiedenen ZUordnungen nicht aus so bedient man sich der vorgeschalteten Bankbefehle
die eine weitausgrößere Anzahl bereitstellen.

So ist mir ein älteres Yamaha Key bekannt was nach loslassen der letzten Taste eines Manual zusätzlich ein NOTE OFF für alle Tastennummern aller Kanäle !!!! sendet, also nach einem Note OFF der letzten Tasten dann dieser generelle NOTE OFF zusätzlich
auch wenn im anderen (evtl garnicht vorhandenen) Manual schon lange keine Taste mehr gedrückt wurde.

Dies war seitens Yamaha vielleicht gut gemeint aber halt des guten zuviel, weil der MIDI Empfänger damit nun garnichts
anfangen konnte.

So muß man halt mit leben daß es immer wieder Exoten gibt die sich nicht an den MIDI Standard halten.
 
hi
Also wenn eine NOTE ON mit Velocity NULL auschaltet sieht eine Bytefolge

1000nnnn 0kkkkkkk 0vvvvvvv Note Off event.
1001nnnn 0kkkkkkk 0vvvvvvv Note On event.

dann so aus : nnnn = Kanal ; kkkkkkk Tastennummer ; vvvvvvv = Velocitiy

1001nnnn 0kkkkkkk 00001111 0kkkkkkk 00000000

Note ON.............................. /....Note ON
Velocity 00001111......................Velocity 00000000 = NOTE OFF

gespart wird nur das Statusbyte 1000nnnn

Soweit klar. Das gilt aber nur, wenn zwischen dem Note-On und dem Note-Off keine anderen Daten (CC, Clock/Timecode, etc. gesendet werden).

Hört sich wenig an aber wenn 10 Tasten gedrückt waren und dann losgelassen werden sind das schonmal 10 Bytes die nicht gesendet werden müssen
Besseres Beispiel ein FADER der Midisignale sendet.
Für jede Position des Faders müßte dann ein Statusbyte plus Datenbytes gesendet werden was zuvor per AD Wandlung in digitale Form umgesetzt wurde.
Gerade bei Fadern ist das Datenaufkommen sehr groß und hier wird dann so richtig an zu sendenden Bytes gespart , was letztlich einer
ECHTZEIT zu gute kommt
Das Konzept "Running Status" an sich stelle ich auch gar nicht in Frage - das ist durchaus sinnvoll (gerade bei Controller-Messages). Es ist auch OK, bei mehreren Note-On-Befehlen die Status-Messages zu sparen. Wenn man dann allerdings, um noch ein paar winzige Bytes zu sparen, auch noch Note-Off-Befehle durch "kastrierte" Note-Ons ersetzt (wie gesagt, und dabei gleichzeitig Release-Velocity und die Möglichkeit, zwischen seeeehr langsamen (lautlosen) Drücken der Taste und dem Loslassen unterscheiden zu können, opfert!) halte ich das für am falschen Ende gespart.

In der MIDI Association ist dieses Verfahren dokumentiert
Running Status - ja. Velocity = 0 als Note-Off zu interpretieren anscheinend auch, wie ich seit eben weiß. Ersteres ist sinnvoll, letzteres ist nochmal später da reingewürgt worden, und zwar IMHO ohne Sinn und Verstand. Wenn man sich mal anschaut, wieviel % eines durchschnittlichen Midi-Stroms (zumal live gespielt) tatsächlich Noten-Events sind, ist das verschwindend gering (zumindest in den Fällen, wo die schiere Datenmenge kritisch wird).

was Dein Micropiano angeht so gibt es noch ärgere Verfahren MIDI Daten zu senden.
Dämpferpedale hat man vielleicht früher so gehandhabt, heute gibt es dafür die CONTROLLER Befehle mit eigenen Statusbytes wie zB
Pitchwheels etc.
Ich meinte das RPX-1 (Real- nicht Micropiano, sorry). Das ist kein Controller, sondern ein Piano-Expander (also Midi-Empfänger). Und der ersetzt keineswegs das Dämpferpedal durch Note-Offs - das hast du falsch verstanden. Das Ding kann Einzelsaitenresonanzen simulieren, und Velocity = 0 heißt in Analogie zum Klavier, dass die Taste so langsam gedrückt wird, dass der Hammer die Saite nicht erreicht. D.h. der (virtuelle) "Dämpfer" - nur dieser einen Taste! - wird abgehoben und die Saite kann (mit-)schwingen - aber sie wird nicht angeschlagen. Das Dämpferpedal, was die Dämpfer aller Tasten bedient, läuft selbstverständlich über CC.
Das hat also mit "früher" nichts zu tun - sondern das ist eigentlich GENAU DAS, wofür man (neben Release-Velocity) die Unterscheidung Note-off und note-on eingeführt hat. Ich kritisiere, dass das nachträglich aufgeweicht wurde und jetzt im Nachhinein auch noch zum "Standard" erklärt wurde. Wieviele ältere Synths ignorieren die Velocity komplett, weil sie das gar nicht umsetzen konnten? Die wären so unspielbar. Inzwischen gibt es endlich Tonerzeuger, bei denen sich Release-Velocity sinnvoll nutzen lässt - und dann wird eine Krücke erzeugt, bei der dann eine Release-Velocity nicht funktioniert.

So muß man halt mit leben daß es immer wieder Exoten gibt die sich nicht an den MIDI Standard halten.
Gerade das kann man nun dem GEM sicher nicht vorwerfen - im Gegenteil. Standards werden nicht besser dadurch, dass man Features unter Aufgabe der Abwärtskompatibilität hinzufügt, wo es nicht nötig ist.
 
Note Offs als Note Ons mit Velocity 0 zu senden ist weit verbreitet. Wenn ein Gerät nicht damit umgehen kann, ist es nicht standardkonform und m.E. auch nicht praxisgeignet. Auch wenn das deiner Meinung nach "reingewürgt" wurde, ist das fester Bestandteil von MIDI und spart u.U. (bei schnellen Notenfolgen) einiges an Daten ein und kann zu besserem Timing führen.
 
  • Gefällt mir
Reaktionen: 1 Benutzer
Das mag sein. Es ist und bleibt allerdings eine Krücke in meinen Augen. Warum gibt es dann überhaupt einen eigenen Note-off-Befehl? Mehrdeutigkeiten sind immer schlecht bei Standards. Wenn man durch den Running Status bzw. Vel. 0 = off doch ohnehin die Release-Velocity opfert, dann hätte man noch um einiges mehr an Daten sparen können, wenn man einfach das Byte für die Release-Velocity "wegdefiniert" hätte.

Das Problem, was ich da sehe, ist folgendes: ich kann mich so eben nicht drauf verlassen, dass ein Gerät, das dem Midi-Standard folgt, auch kompatibel ist. Wenn ein Masterkey Release-Velocity sendet, der Empfänger damit umgehen kann - aber blöderweise ein Merger oder Midi-Prozessor dazwischen der Meinung ist, die Note-Offs als On mit Velocity 0 rauszugeben, steht man schön blöd da.
D.h. dann eben doch wieder Implementation Charts aller Geräte im Detail lesen müssen - nicht der Sinn eines Standards.

Btw. ist mir noch kein Gerät untergekommen, was Vel 0 als off sendet (zumindest glaube ich, ich wäre da stutzig geworden). Jetzt nach der Diskussion habe ich wohl gesehen, dass das in Midi-Files wohl öfter vorkommt. Andersrum scheint es doch einige Geräte / Plugins zu geben, die damit - sagen wir mal - eigenartig reagieren. Ob jetzt Standardkonform oder nicht. Jedenfalls scheint das nicht nur "Exoten" zu betreffen.

Wie auch immer - wieder was gelernt und festgestellt, dass offenbar auch Leute, die Standards schreiben, nicht unbedingt immer Entscheidungen treffen, die für jeden nachvollziehbar sind. ;)
 
@jens
Weder ich noch andere können daran etwas ändern. Es gibt eben MIDI Standards an die sich die Hersteller halten sollten ob sie es tun steht auf einem anderen Blatt.
Als der GS / GM Standard eingeführt wurde zogen die Hersteller auch zögerlich nach. Mit Einführung der neuen Bank und Controller war es genauso.
Als normaler User bekommt man von dem ganzen so gut wie nichts mit, aber wehe man schreibt mal ein Programm um irgendwelche
Midi Daten auszuwerten oder zu verändern. Man kommt da aus dem Staunen nicht heraus was es alles gibt und wo mit man bei der Software IMMER rechnen muß.
MIDI betrifft ja nicht nur Musikinstrumente , nein alles was mit Lichttechnik zu tun hat bedient sich mitlerweile auch der MIDI Steuerung.

Bleiben wir mal bei dem Velocity Byte
In der Tastatur haben wir pro Taste zwei Kontakte die nacheinander schließen
Für einen Dynamikwert wird die Zeit vom Schließen des ersten Kontaktes bis zum Schließen des zweiten gemessen.
Je kürzer die Zeit desto höher der Dynamikwert.
Jetzt lassen wir die Taste mal los : wir heben den Finger einfach dabei ab ! kein mechnischer Kontakt des Fingers mehr zur Taste !
Der (zweite) Kontakt wird nun als erster geöffnet ---> der Ton schaltet ab und folgt damit seiner ( soundmäßig ) einprogrammierten
ADSR Kurve , hier die Release Phase
Die Taste selbst bleibt nach Abheben des Fingers sich selbst überlassen und geht gem der Rückholfederkonstante in ihre Ruhelage zurück.

Welchen Sinn macht dann hier ein Velocity Wert ????
Wenn dem wirklich Bedeutung beigemessen werden sollte so muß beim Loslassen der Taste so gespielt werden, daß der Finger während dieser Zeit immer noch auf der Taste liegt und sie behutsam in die Ruhelage zurückführt.
Bei allem Verständnis : so spielt niemand

Bei einem echten Piano haben wir eine ganz andere Tastenmechanik und die hat auch ganz andere Möglichkeiten, was so in der Art
nur Näherungsweise für eine Kontaksteuerung umgesetzt werden kann.

Etwaige mechanische Gewichte, die durch die Taste bewegt werden dienen nur der Immitation und einem Spielgefühl wie bei einer
Hammermechanik. Sie haben mit den beiden Tastenkontakten NICHTS zu tun

Ein elektrischer Tastenkontakt kennt nur zwei Zustände: EIN und AUS, alles andere wären kontinuierliche Regelmechanismen die will man es richtig machen auch analog/digital gewandelt werden müßten.
Hier wäre ein MIDI als Steuerung jedoch restlos überfordert weil dieses Datenvolumen nicht mehr zu handeln ist.

Somit war der Velocity Wert 0 als Note OFF verwendbar

Einfache Keys ohne Dynamik senden übrigens daher bei einem NOTE ON immer einen Velocty Wert von 64 = Mittelwert
 
Zur Release-Velocity: es wird ja selten unterstützt, stimmt. Aber wenn, macht das schon Sinn. Natürlich macht man das dann sinnigerweise genau wie bei der on-Velocity und wartet mit der Auswertung, bis beide Kontakte "durch" sind. Und von wegen "so spielt niemand": Es macht z.B. gerade bei Rhodes, Clavinet und manchen Pianosounds - und ganz besonders bei Cembali - einen ENORMEN Unterschied, ob ich das auf der internen Kronos-Tastatur (MIT Release-Velocity) spiele oder (ohne) von extern ansteuere.
Es ist nämlich im Regelfall eben nicht so, dass die Taste "langsamer" ist als der Finger und jedes Fingerabheben die Taste sich selbst überlässt. Bei moderaten Spielgeschwindigkeiten "klebt" die Taste bis zum Schluss am Finger und deren Geschwindigkeit wird in der Tat vom Finger bestimmt und nicht von deren Mechanik. Es gibt halt eine Maximalgeschwindigkeit, mit der die Taste höchstens zurückfedern kann - erst wenn der Finger schneller abgehoben wird, macht es keinen Unterschied mehr.

Ich habe darum tatsächlich einige Release-Samples deaktiviert, weil mein LMK leider keine Release-Vel. sendet. Auf der internen klingen sie toll, aber wenn die immer mit 64 angefeuert werden, ist das grausam.
 
Wenn ein Masterkey Release-Velocity sendet, der Empfänger damit umgehen kann - aber blöderweise ein Merger oder Midi-Prozessor dazwischen der Meinung ist, die Note-Offs als On mit Velocity 0 rauszugeben, steht man schön blöd da.

Dann ist der Merger nicht richtig implementiert. Der muss für jeden Input-Port und Channel den aktuellen Running Status speichern und ggf, z.B. wenn von einem anderen Input-Port eine MIDI-Message mit einem anderen Status dazwischen kam, das Statusbyte ergänzen, dass im Running Status gespeichert ist. Einfach die Note Offs in NoteOns mit Velocity 0 umwandeln sollte er nicht.

Wie der Kollege oben sagt, MIDI ist konzeptuell einfach, aber die Schwierigkeiten liegen im Detail. Leider ist es so, dass es wirklich viele Implementierungen gibt, die manche Details nicht richtig beachten. Das liegt m.E. auch daran, dass es kein wirklich offener Standard ist, d.h. dass man die offizielle Spezifikation nicht einfach kostenlos überall herunterladen kann. Da haben dann viele einfach sich was ausgedacht, wenn sie auf Unklarheiten gestoßen sind.
 
Es gibt halt eine Maximalgeschwindigkeit, mit der die Taste höchstens zurückfedern kann - erst wenn der Finger schneller abgehoben wird, macht es keinen Unterschied mehr.

Die Zeit beim Herunterdrücken wird nur die die Fingergeschwindigkeit bestimmt. Bei vielen Instrumenten ist die Dynamikkurve in ihrer mathematischen Funktion programmierbar, Maximalwert in jedem Fall 128.
Beim Loslassen bestimmt jedoch die Federkonstante die Dynamikkurve, was bedeutet, daß hier keine erzielbaren Werte ( auf die Zeit bezogen) erreicht werden können wie beim Niederdrücken.
Macht man die Feder straffer, reduziert sich möglicherweise der Anschlagsdynamikwert, weil mehr Kraft aufgewendet werden muß.

Speziell beim Rhodes sind gegenüber dem Original einige Punkte zu beachten.
Der charakteristische Klang eines Rhodes wird oft damit deutlich wenn eine Taste schnell gedrückt aber nicht mehr ganz in die Ausgangslage zurückgeführt wird und bereits aus einer mittleren Tastenposition wieder erneut gedrückt wird.
Das elektronisch umgesetzt heißt nichts anderes, daß beim Loslassen der Taste zwar der erste Kontakt geöffnet wird jedoch der zweite immer noch geschlossen ist. Wird jetzt erneut gedrückt fehlt die Startposition ( Schließen des ersten Kontaktes ) für eine Dynamikberechnung. Wird jetzt erneut gedrückt wird auch der Dynamikwert erreicht werden wie bei einer Taste aus der Ruhelage, da nur die halbe Strecke ( Tastenhub) zur Verfügung steht.
Man kann so etwas natürlich mit NOTE OFF Veloctiy besser umsetzen - keine Frage.
Nur in dem Fall wird die Tastatur nur speziell auf dieses Instrument bezogen sein.
In einem multifunktionalen Instrument zB Expander mit großen MIDI Datenströmen würden hier zwangsläufig Latenzen entstehen.
Dieses Problem haben sicherlich neuere Orgeln mit 88 Tasten Pianoklaviatur im Untermanual wenn diese primär für Pianoklang genutzt wird.
Für andere Instrumente ist es jedoch nicht relevant es sei denn der 88 Tasten Manualbereich wird gesplittet in mehreren Bereichen.

Eine Tastatur wie auch immer liefert schon diese Daten, die Frage ist nur wie der Rechner dies in MIDI Signale umformt bzw wie er sie verarbeitet und was dann letztlich am MIDI OUT erscheint.

Aber egal wie , in der MIDI Association und deren "Regeln" ist ein Running Status zugelassen und auch definiert wie dies auszusehen hat.
Darüber hinaus hat jeder renommierte Hersteller der mit MIDI arbeitet eine ID Nummer - die auch per MIDI gesendet werden kann -
was dies anderen Herstellern ermöglicht sich deren Interpretationsweise anzupassen und damit auch ob zB ein Expander diese Informationen akzeptiert oder nicht.
Sequenzerprogramme müssen zwangsläufig mit allem zurechtkommen wollen sie universell verwendbar sein
 
Klar, die Release-Velocity erreicht natürlich nicht das Dynamikspektrum wie die Anschlags-Velocity, sondern ist durch die maximale Eigengeschwindigkeit der Taste begrenzt. Du willst mir aber nicht weismachen, so etwas wie eine Release-Dynamik gebe es gar nicht!? Dann hast du noch nie (elektronische Emulationen von) Instrumenten gespielt, die das vernünftig umsetzen - was sehr wohl auch per Midi geht, nicht nur bei Spezialtastaturen für ganz spezifische Instrumente.

Dass es natürlich immer Kompromisse zu schließen gibt zwischen z.B. Repetition, "responsiveness", Haptik und Dynamikauflösung, das steht auf einem anderen Blatt. Und dass Tasten, die nur zwei Kontakte auswerten - insbesondere in Verbindung mit den Limitierungen des Midi-Protokolls (Datendurchsatz) - nicht jede Form von Spieldynamik akustischer oder elektromechanischer Instrumente abbilden können, ist auch klar. Das ist aber kein Grund, die Notwendigkeit oder Sinnhaftigkeit einer Release-Velocity generell in Frage zu stellen. Wie gesagt, es gibt durchaus Instrumente / Tonerzeuger, die das nutzen - und der Unterschied in der Spielbarkeit / im Klang ist vielleicht etwas geringer, aber ebenso deutlich wahrnehmbar wie mit / ohne Anschlagsdynamik.
 
@strogon14

Ein MERGER wird für jeden Eingang einen FIFO BUFFER haben, anders ist ein unbekanntes Datenaufkommen garnicht beherrschbar.
Wird zB eine SYSEX Datei gesendet und trifft auf den einen Eingang, so muß der andere warten bis da alles durch ist.
SYSEX hat ein Start Statusbyte und am Ende ein EOF Byte dazwischen nur Daten.

Wird wirklich alles zuviel ist evtl auch noch ein MIDI OUT FIFO vorhanden, aber das sind Extremfälle für Displayanwendungen zB

Ein aktuelles Statusbyte muß immer gespeichert sein, alles was darauf folgt sind Daten mit gleichem Statusbyte
Erst ein neues ( anderes) Statusbyte hebt dies auf und der Vorgang beginnt von vorn.
Evtl dazwischen empfangene ACTIVE SENSE Befehle haben damit nichts zu tun und es sind auch nur 1 Byte Befehle die einfach gecancelt oder durchgelassen werden.

In einem Programm fragt man zuerst nach ob es ein Active Sense Befehl ist , dann danach ob es sich um SYSEX Daten handelt und erst dann ob es sich um NOTE ON / OFF oder anderes handelt.

Die seriellen Eingänge werden meist im Interrupt Modus bedient, dh erst wenn ein Datenbyte komplett empfangen wurde und im BUffer der seriellen Schnittstelle steht wird der Interrrupt ausgelöst, der bisherige Programmteil unterbrochen und der Interrupt abgearbeitet. Danach kehrt das Programm an die Stelle vor dem Interrupt zurück und arbeitet dort weiter.

Eine " Bearbeitung" von MIDI Daten wird also immer im Hauptprogramm ablaufen und der Interrupt so kurz wie möglich gehalten werden:
Daten empfangen evtl ACTIVE SENSE und SYSEX bearbeiten der Rest in den FIFO speichern und fertig mit dem Interrupt.

Maßstab was nach Empfang eines MIDI Bytes an Zeit zur Verfügung steht für eine evtl sofortige Bearbeitung ist die Zeitspanne zwischen zwei MIDI Bytes.
Ist nicht viel zu machen kann ggf auch ein FIFO Speicher entfallen.

Für einen MERGER jedoch ist ein FIFO unabdingbar quasi ein MUSS.
IdR reichen 256 Byte für einen solchen Speicher als Größe aus--- Beiträge wurden zusammengefasst ---
@jens
Ich habe die MIDI IMPLEMANTATIONEN nicht verfaßt und muß genauso damit leben wie andere.
Wenn sich einige Hersteller halt nicht dran halten so ist das ihr Problem.

Es besteht auch keinerlei Zwang für einen Hersteller sich an das vorgegebene MIDI zu halten.
jeder kann etwas anderes machen wenn er will.
Nur wer weltweit verkaufen will muß sich dran halten ob er will oder nicht.
Einige Firmen haben leider das SAGEN was als STANDARD eingeführt wird und das sind genau diejenigen die den Markt beherrschen

Die Möglichkeit des Running Status ist ja nur geschaffen worden um dem LAHMEN MIDI mit 31250 Baud etwas auf die
Sprünge zu helfen.
MIDI ist im Jahre 1983 erfunden worden und die Rechner damals hatten schon Probleme damit zurechtzukommen.
Der ATARI hatte es serienmäßig drin ein PC träumte davon noch
Ein normales RS 232 Interface arbeite idR mit 9600 Baud
Nach heutigen Standards eine lahme Ente.
Wersi zB hat schon 1986 mit dem MK 1 Synthie bereits zwischen zwei identischen Geräten mit DOPPELTER MIDI Geschwindigkeit gearbeitet was durchaus funktioniert hat !
Stell den Antrag die Baudrate auf 62500 Baud zu erhöhen, dann fällt auch ein generelles MIDI OFF mit Velocity nicht mehr ins Gewicht.

Aber ich prophezeie Dir dann sofort, daß dann andere Hersteller dies für etwas ganz anderes nutzen werden und irgendwann kommt dann sicher wieder eine Änderung

Das was wir mit kleinen Gerätchen wie Mergern etc machen ist im Grunde Kinderkram.
Schau Dich mal in professionellen Studios um mit welchen Gerätschaften die mit MIDI arbeiten.
Davon können wir nur träumen ....
 
Zuletzt bearbeitet:
@happyfreddy Mir brauchst du das alles nicht erklären, ich habe schon selbst Merger (in Software auf Desktopsystemen) implementiert. :)
 

Ähnliche Themen


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

Musiker-Board Logo
Zurück
Oben