Die MIDI Hall of Shame

Der Blödsinn geht weiter:

Die neuen Casio Digitalpianos PX-S1000 und PX-S3000 haben kein klassisches MIDI mehr, nur noch USB, wie auch schon die CT-X Modelle.
 
Macht es keinen Deut besser. Außerdem gibts mehr als nur zwei Varianten.
Ach, ich dachte tatsächlich es gäbe nur zwei Varianten.
Ist ja jetzt nicht das erste Produkt, bei dem das geht und bisher klang das immer so, als wäre damit alles abgedeckt. K.A. vielleicht hatte ich das auch nur so gelesen.
Ja, besser machts das nicht...

Gibt‘s eigentlich ne Midi Hall of Shame Website?
 
Der Blödsinn geht weiter:
Die neuen Casio Digitalpianos PX-S1000 und PX-S3000 haben kein klassisches MIDI mehr, nur noch USB, wie auch schon die CT-X Modelle.
als ich auf der Suche nach einem Keyboardcontroller war, ist mir erst mal aufgefallen wie viele Keys es eigentlich gibt, die nur USB haben.. wie ist das technisch, braucht MIDI andere Spannungen als die 5V bei USB? Dann könnte man das evtl. mit Kosteneinsparung erklären..
 
Und der nächste Blödsinn, mal wieder von Roland: TM-1 Trigger Module wieder nur USB und kein echtes MIDI.
 
Ja, absolut. Wobei ich den Beatstep/Pro oben weggelassen hatte, da dessen Gehäuse wenig Alternativen zuläßt, obwohl man, haben wir mal nachgemessen, mit 2-3mm mehr Höhe auch normale MIDI Buchsen von oben hätte einbauen können (so wie beim Behringer D).

Wenn man die Buchse horizontal einbaut, ist sogar ohne Gehäuseänderung genug Platz....
 
Wer als Besitzer von einem Betastep pro einmal spass haben möchte, der schraube ihn mal auf, und schaue sich an, wie die Miniklinkenbuchsen und auch die USB Buchsen auf der Platine befestigt sind. Zwei Lötpunkte von 1/4 mm Durchmesser... Damit gehe ich jederzeit auf die Bühne....
 
Prüfsummen für kurze Parameter Changes
Man überträgt so 5 Byte Nutzlast und muss über diese eine Prüfsumme rechnen. Damit bei der Übertragung nichts schief geht.
Ist der oberheim matrix 1000 nicht auch so ein Kandidat?
The general algorithm for transmission is:
1. Transmit header and message code(s). 2. Clear checksum.
3. Fetch next data byte to be transmitted.
4. Add byte to checksum.
5. Transmit (data & OFH).
6. Transmit (data/16 & OFH).
7. Repeat 3 -6 for all data bytes.
8. Transmit (checksum & 07FH).
9. Transmit F7H.

Der hat doch auch ansonsten komische midi Routinen oder?
 
Spontan würde mir noch der Roland JD-990 einfallen, welcher für Parameteränderungen Prüfsummen benötigt.

Roland hat seit dem S10 ein Standardformat für MIDI Sysex, welches auch beim JD990 angewendet wird, und das will für Parameterchanges immer eine Checksum haben. Liegt daran, daß ein Parameterchange bei Roland Sysex garkeiner ist, sondern der Dump/Send einer bestimmten Anzahl Speicherzellen, deren Adresse in der Nachricht spezifiziert wird.

Stimmt aber, das ist durchaus ein Thema für hier, Danke fürs Erinnern.
 
Also wenn jede kleine Unannehmlichkeit als Grund für Anprangern hergenommen wird, wird's lächerlich. Sysex-Nachrichten werden normalerweise von Software oder dazu programmierten Controllern gesendet. Die sollten in der Lage sein, die Prüfsumme zu generieren. Wenn nicht, ist die Software sch..., nicht die Sysex-Implementierung des Empfängers.
 
Zuletzt bearbeitet:
Mit MIDI CC Befehlen kann man nur 128 Parameter ansprechen und viele CC # sind schon für Standard-Controller (Modulation, Volume, Sustain, usw.) vergeben. Außerdem hat man entweder nur eine Auflösung von 128 Werten, oder muss mit High-Resolution Controllern (also zwei CC-Nachrichten) oder NRPNs arbeiten, was m.E. genauso kompliziert wie Sysex ist. Bei Sysex-Nachrichten kann der Implementor selbst festlegen, wie der Wertebereich und die Kodierung der Parameterwerte sind (MSB/LSB first, Nibbles oder höchstes Bit in MSB verschieben, usw.). Außerdem kann man Parameter in Gruppen strukturieren, nicht-numerische Werte versenden, z.B. Strings für Namen oder binäre Daten für Wavetables usw.

Bei seriellen Datenübertragungen Checksummen zu verwenden ist einfach gute Ingenieurspraxis, insbesondere wenn die Leitungen, wie bei MIDI länger sind. Und dass ein Synth, wenn man ihm falsche Parameter schickt, nicht reagiert, ist m.E. auch sinnvolles Verhalten. MIDI ist halt nicht transaktionsbasiert und es ist nicht garantiert, ob ein Rückkanal überhaupt vorhanden / angeschlossen ist, da ist es sehr schwer, Nachrichten zuverlässig zu bestätigen. Oder meinst du, dass es manche Synths gibt, die sich aufhängen, wenn man ihnen falsche / zu viele Sysex-Nachrichten schickt? Das ist dann natürlich wieder Sch...programmierung und gehört hierher. Aber man sollte fehlerhaftes Verhalten und Komplexität nicht in einen Topf werfen.
 
Zuletzt bearbeitet:
Also wenn jede kleine Unannehmlichkeit als Grund für Anprangern hergenommen wird, wird's lächerlich. Sysex-Nachrichten werden normalerweise von Software oder dazu programmierten Controllern gesendet. Die sollten in der Lage sein, die Prüfsumme zu generieren. Wenn nicht, ist die Software sch..., nicht die Sysex-Implementierung des Empfängers.

Sorry, nein. Eine Prüfsumme bei einer Parameter Change Nachricht ist völlig überflüssig, weil es bei Hardware-Controllern unnötigen Programmieraufwand erzeugt, zumal es ja verschiedene Arten von Prüfsummen gibt und die auch unterschiedlich generiert werden, also zB ab wann summiert wird (siehe Sounddiver Programming Manual). Außer Roland macht das auch sonst keiner, und dort funktioniert das auch seit Anbeginn ohne Probleme. Deren eigene Programmer benutzen ja auch MIDI als Übertragungsprotokoll, zumindest von den Daten her, und ebenfalls ohne Prüfsumme.
 
Novation Circuit
Die Synths und die Drums geben ihre Noten auf fest eingestellten Kanälen (1 und 2 für die Synths und 10 für die Drums) aus die sich nicht ändern lassen.

Das ist mit der gerade erschienenen Firmwareversion 1.8 nun behoben, d.h. man kann die Kanäle einstellen.

Sorry, nein. Eine Prüfsumme bei einer Parameter Change Nachricht ist völlig überflüssig, weil es bei Hardware-Controllern unnötigen Programmieraufwand erzeugt, zumal es ja verschiedene Arten von Prüfsummen gibt und die auch unterschiedlich generiert werden.

Wir sind uns also einig, dass wir anderer Meinung sind. Du findest das überflüssig und umständlich, ich finde, das ist normale defensive Programmierung und legt niemand unnötig viele Steine in den Weg. Auf jeden Fall ist das ein anderes Kaliber als irgendwelche Standards gar nicht oder fehlerhaft zu implementieren.

Wenn man da mit dem Finger auf jemand zeigen will, dann sollte es mMn die MIDI Association sein, die es versäumt hat, das Format von SysEx-Nachrichten näher zu standardisieren. Außer Start/End-of-Sysex und dazwischen eine beliebige Anzahl von Bytes mit Wert > 128 ist ja nur noch Wert und Position der Manufacturer ID und Device ID festgelegt (und das Format einiger Universal SysEx Messages). Man hätte z.B. auch die Kodierung von Werten mit mehr als 7bit, das Vorhandensein und Position von Model ID, Parameter(-gruppen)nummer, Bank- und Patchnummer, Nachrichten-ID und die Position und Berechnung der Checksumme und einiges mehr festlegen können. Dann wäre vielleicht einiges Kuddelmuddel erspart geblieben. MIDI 2.0 scheint ja in die gleiche Kerbe zu hauen.
 
Prüfsummen sind generell schon sinnvoll, aber eben nicht bei 1-2 Byte Daten wie Parameter Changes, da bläht es das Ganze nur unnötig auf und bringt keinerlei Vorteile.

Was Du in Puncto Sysex sagst, unterstreiche ich absolut. Dort hat man den Herstellern leider zuviel Freiheiten gelassen, und bei den Formaten herrscht daher auch ein übelster Wildwuchs. Roland waren die ersten, die bei ihren Geräten ein einheitliches Format einführten, Yamaha hat es inzwischen auch, iirc seit der Motif Serie. Als Polyframe und später Sounddiver erschien, haben sowohl Michael Haydn als auch einer der Programmierer von UniSyn eine Art Petition an die Hersteller zur Vereinheitlichung des Sysex Transfers geschrieben, die müßte sogar noch im Archiv der MMA zu finden sein. Leider hat es keinen interessiert und die MMA offenbar auch nicht.
 
... und legt niemand unnötig viele Steine in den Weg
Doch, das ist doch eben der Punkt. Aber eben so wie microbug das schreibt bezogen auf den Nachrichtentyp. Wichtige Briefe sollte man natürlich per Einschreiben schicken, aber das muss man nicht bei jeder Postkarte machen.

Allerdings stimme ich zu dass das jetzt für mich auch kein Grund wäre etwas in die Hall of Shame zu stecken.
 
Novation Remote 25:
Eigentlich ein geniales Teil und der Start einer grossen Franchise. Dummerweise ist das Midi-Interface nicht SysEx-fest. Das hat mir beim versuchten Update meine Elektron SIDstation zerschossen. Das Einschicken und die Reparatur bei Elektron war ein sehr teurer Spass.

Kannst du erklären wie das passieren konnte? Ich lese mich grade ins Thema ein, soll bei sysex nicht die Hersteller ID verhindern das ein Gerät mit einer sysex message was macht die aber nicht für das Gerät bestimmt war?

Oder versteh ich den Fehler grade falsch und das Remote25 hat die sysex Nachricht verwurstelt anstatt sie sauber weiterzugeben?
 
Oder versteh ich den Fehler grade falsch und das Remote25 hat die sysex Nachricht verwurstelt anstatt sie sauber weiterzugeben?

Wenn dann dieses, denn oft ist der Speicher zu knapp bemessen für diese Zwecke.

Grundregel: für firmwareupdates IMMER ein MIDI Interface von Herstellern mit entsprechender Kernkompetenz (ESI, MOTU, iConnectivity oder die alten Emagics) nehmen oder direkt über USB gehen. Zugabe-Interfaces in Geräten würde ich da nie über den Weg trauen.
 
Grundregel: für firmwareupdates IMMER ein MIDI Interface von Herstellern mit entsprechender Kernkompetenz (ESI, MOTU, iConnectivity oder die alten Emagics) nehmen oder direkt über USB gehen. Zugabe-Interfaces in Geräten würde ich da nie über den Weg trauen.

Mit dem MIDI-Interface des RME Fireface UC hatte ich auch noch nie Probleme. Läuft nicht unzuverlässiger als früher meine Emagic AMT8. Ich denke RME hat den MIDI-Teil des Fireface gut umgesetzt. Kenne es von anderen Herstellern auch anders.
 
Der Blödsinn geht weiter, jetzt auch im Bereich DIY:

Der Syncussion Clone SY-1M von Psycox hat MIDI als Minikinke, wo Platz für eine echte Buchse gewesen wäre, und ob diese Buchse vom Metallgehäuse isoliert ist, müßte ich nachschauen.
 
Und der nächste Blödsinn, wieder DIY, zumindest halbwegs: Dinopark, die Wiedergeburt der Creamware ASB Hardwarebasis, wurde mit Miniklinke ausgestattet, statt einfach Platz für normale Buchsen zu schaffen.

Gleiches gilt für die Blackbox von 1010 Music: so ein Ding kann man auch ein klein wenig größer bauen, ist immer noch kompakt genug und braucht keine wackeligen Adapter. Immerhin sind Kunstoffbuchsen verbaut, sodaß es an dieser Stelle wenigstens keine Probleme gibt.
 
Zuletzt bearbeitet:
MIDI Solutions:
Alle deren Modelle ohne externe Stromversorgung, die sich verbotenerweise aus MIDI versorgen, was dann auch nur bei bestimmten Geräten funktioniert
weil es gerade dazu eine Diskussion im Squarp-Forum gibt:
Wieso ist das verboten? Ist das irgendwo spezifiziert? Wofür ist der Strom in der Midi-leitung?
 
Der "Strom" ist für den Optokoppler gedacht.
Optokoppler = galvanische Trennung.
Benutzt man den Midiport als Spannungsversorgung entfällt bzw. hebt man die galvanische Trennung auf.
So richtig "verboten" ist das bestimmt nicht aber ist halt keine saubere Lösung.
 
Doch, es ist, und somit verletzten solche Geräte die MIDI Hardware Spec, genau wie die, die meinen, den Optokoppler weglassen zu müssen.
Was ist schlecht daran? Laut einer Erweiterung der MIDI-Spezifikation - festgelegt in der MIDI-1.0-Electrical-Specification-ca33 AMEI (Association of Musical Electronics Industry), datierend vom 16. September 2015 - sind nun auch MIDI-Ausgänge möglich, die auf einer 3,3 V-Spannungsversorgung beruhen. In diesem Fall werden Serienwiderstände von 33 Ohm und 10 Ohm an Pin 4 bzw. an Pin 5 eingesetzt.
 
Zuletzt bearbeitet:
Das ändert aber nichts daran, dass der Eingang über einen Optokoppler galvanisch getrennt wird. Nur die Spannungen ändern sich- und deswegen die Widerstände.
 


Neueste Beiträge

Zurück
Oben