Ich wollte einfach mal in Erfahrung bringen ob es im Falles eines jeden Gerätes, dass Mididaten sendet, so ist, dass das Statusbyte mit jedem Befehl erneut gesendet wird. Beispielsweise besteht Note-On ja aus Statusbyte und 2 Wertebytes. Gibt es, wenn mehrere Noteons hintereinander gesendet werden, die Möglichkeit, dass ein Gerät nicht 2 sondern 4 oder mehr Wertebytes hintereinander überträgt ohne zwischendrin jedesmal ein Statusbyte einzufügen ? Ich hoffe die Frage ist halbwegs verständlich :)
Danke, dann müsste ich den Code wohl auf diese eventualität hin anpassen ... Mist - das bremst doch alles nur, langsam wird´s mit internen 1 MHz knapp G
@andreas bist du sicher das das teil der midi-spzifikation ist ? auf midi.org habe ich nichts zum thema running status gefunden. machbar/denkbar wäre es schon (zumindest um bytes zu sparen), aber es ist außerhalb der norm, vor allem bezweifel ich das alle MIDI-fähigen geräte (vor allem ältere geräte) damit klarkommen. das statusbyte (also mit gesetztem 7.bit) dient ja gleichzeitig auch als erkennung eines neuen befehls.
sorry vertan ... geht doch ... habs nur nicht direkt bei midi.org gefunden ... posting in den müll bitte :-)
@MAX Interner Oszillator und UART hört sich aber nicht gut an. Der ist nicht so genau und stark temperaturabhängig. Das kann unter Umständen noch Probleme machen.
wenn/falls du nen avr verwendest, warum lässt du ihn denn nicht schneller laufen, z.b. mit quarz auf 4 oder 8 mhz. kann mich dem posting von andreas aber nur anschließen : wenn du den internen rc verwendest : lass es. es bringt dir sehr schnell probleme die dich eher an deiner software zweifeln lassen obwohl es an einer schön/schlechtwetter periode oder schwankenden raumtemperaturen liegen kann ...
Ist mir im Datenblatt auch schon aufgefallen, Probleme hat es bisher keine gemacht. Werde das in der endgültigen Schaltung jedoch bedenken ...
die sache mit dem fehlenden statusbyte hat mich schon viel nerven gekostet (weil ich es am anfang nicht wusste) am besten du testest immer darauf, ob das empfangene byte ein statusbyte ist, wenn ja merkst du es dir, wenn nein, wird das gemerkte statusbyte verwendet. dieses vorgehen sollte deinen code nicht langsamer machen, als er ohnehin schon ist, dennoch rate auch ich davon ab den internen rc-oszillator zu verwenden, eine kleine temperaturschwankung und schon empfängst du nur noch die hälfte.
> am besten du testest immer darauf, ob das empfangene byte ein statusbyte > ist, wenn ja merkst du es dir, wenn nein, wird das gemerkte statusbyte > verwendet. Ganz so seinfach wird es nicht sein ... - Die Daten gehen in einen Puffer - Je nachdem, um welche Befehle es sich handelt, geht es gleich weiter in einen Ausgangspuffer oder in einen zweiten Puffer - Erst nach Empfang eines kompletten "Datensatzes" im zweiten Puffer können diese Daten weiterverarbeitet werden und landen danach ebenfalls im Ausgangspuffer. Wichtig dabei ist, noch zu beachten, dass die weiterverarbeiteten Daten erst in den Ausgangspuffer kommen, wenn ein kompletter Befehl des Eingangspuffers durch ist. Nicht dass zuerst ein Statusbyte für den Controller kommt, statt dem Wertebyte aber plötzlich ein Noteon-Statusbyte und anschließend das Wertebyte des Controllerwerts ... das gäbe ein ziehmliches Durcheinander Das alles verlangt aber unter Anderem die Analyse eines jeden Statusbytes, wie viele Wertebytes kommen, bis ein Befehl komplett gesendet ist, diverse Countdown-Timer und was auch immer ... Auf jeden Fall eine Menge Code nur deshalb, weil die Befehlslänge von Midi-Befehlen nicht immer gleich ist und weil es den Running Status gibt.
MAX wrote: > Nicht dass zuerst ein Statusbyte für den Controller kommt, statt dem > Wertebyte aber plötzlich ein Noteon-Statusbyte und anschließend das > Wertebyte des Controllerwerts ... das gäbe ein ziehmliches Durcheinander So etwas ist nicht möglich. Beim Running Status kann nur das Statusbyte bei gleichen Befehlen weggelassen werden. Zwischendurch kann dann kein anderer Befehl kommen. Daher ist das ganze auch nicht so kompliziert. Und wie weiter oben beschrieben, braucht man eigentlich nur einen Befehl abarbeiten und wenn das nächste Byte kein Statusbyte ist einfach den vorherigen Status nehmen...
>RealTime Category messages (ie, Status of 0xF8 to 0xFF) do not effect running >status in any way die können wohl schon dazwischen kommen Aber darum ging es mir nicht, sorry, ist etwas blöd auszudrücken, hat auch eigentlich nichts mit der Ursprungsfrage zu tun. Es geht darum, dass ich die Daten splitte, ein Teil landet direkt wieder im Ausgangspuffer, ein Anderer wird im Controller bearbeitet. Die bearbeiteten Messages müssen einfach an der richtigen Stelle wieder eingefügt werden, um nicht beispielsweise ein Control Change mittendrin zu unterbrechen. D.h. um bearbeitete Messages in den Ausgangspuffer zu schieben muss sichergestellt sein, dass die Daten nicht mitten in eine andere aus dem Eingangspuffer kommende Message reinfunken. Und da wird´s ekelig ... Wird jetzt klarer, was ich meine ?
>RealTime Category messages (ie, Status of 0xF8 to 0xFF) do not effect running >status in any way die können wohl schon dazwischen kommen Aber darum ging es mir nicht, sorry, ist etwas blöd auszudrücken, hat auch eigentlich nichts mit der Ursprungsfrage zu tun. Es geht darum, dass ich die Daten splitte, ein Teil landet direkt wieder im Ausgangspuffer, ein Anderer wird im Controller bearbeitet. Die bearbeiteten Messages müssen einfach an der richtigen Stelle wieder eingefügt werden, um nicht beispielsweise ein Control Change mittendrin zu unterbrechen. D.h. um bearbeitete Messages in den Ausgangspuffer zu schieben muss sichergestellt sein, dass die Daten nicht mitten in eine andere aus dem Eingangspuffer kommende Message reinfunken. Und da wird´s ekelig ... Wird jetzt klarer, was ich meine ?
Notiz auch für mich: Die wahrscheinlich schnellste Möglichkeit, die ich sehe, ist die Übertragung von Eingangspuffer in den Ausgangspuffer nach einer gefilterten Message zu unterbrechen. Nach Weiterbearbeitung der Message und Schreiben der neu generierten Messages in den Ausgangspuffer kann die normale Übertragung nicht zu filternder Messages aus dem Eingangspuffer in den Ausgangspuffer fortgesetzt werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.