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.
@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 ...
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.
