www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Midi - wir JEDESMAL erneut ein Statusbyte gesendet ?


Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das gibt es. Nennt sich Running Status.
http://www.borg.com/~jglatt/tech/midispec/run.htm

Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry vertan ... geht doch ...
habs nur nicht direkt bei midi.org gefunden ...
posting in den müll bitte :-)

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist mir im Datenblatt auch schon aufgefallen, Probleme hat es bisher 
keine gemacht. Werde das in der endgültigen Schaltung jedoch bedenken 
...

Autor: ben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: xyz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ?

Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ?

Autor: MAX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.