Benötige Hilfe bei der Erstellung von Casio MZX500 SysEx Strings auf Basis der Casio SysEx Dokumentation

[Popsel]

Scheinbar lässt sich das Ergebnis nicht reproduzieren.
Nun versuchte ich die ASCII-Zeichen des empfangenen Strings zu verändern und den Name-String zurückzusenden.
Es gab auf allen 3 Ports keine sichtbare Änderung.
Normalerweise muss man bei Änderungen an "TONEs" danach "Write" ausführen, um die Änderungen im Flash-Speicher zu sichern.
So etwas ist aber in der MIDI Implementation nicht vorhanden.
Also werden sich Änderungen auf das RAM (Edit Puffer) beziehen, weshalb die Parameter auch in Realtime änderbar sind.
Habe ich aber Daten im Edit Puffer und schalte dann auf einen anderen Screen um, werden die Daten im Edit Puffer aus dem Flash Speicher geholt und der Edit Puffer im RAM damit überschrieben.
Es muss einen Parameter-Offset geben, der zurzeit noch unbekannt ist, um auf den Edit-Puffer im RAM zuzugreifen.
Um bei gleichen Parametern, wie z.B. "Octave Shift" die 16 Parts zu unterscheiden, dient anscheinend der "Block" Parameter.
Es gibt also eine Basis-Adresse (Parameter ID) für den Parameter, aber Auswahl des Parts muss dann im Block-Parameter (welcher 8 Bytes lang ist) erfolgen. So funktioniert es ja auch im WK6600. Es ist also wahrscheinlich, dass es auch beim MZX500 in ähnlicher Weise funktionieren müsste.

Edit Buffer

 

[Scenturio]

ich lese hier nur interessiert mit ... frage mich aber immer wieder, wer sich diese Strukturen ausdenkt? Als Entwickler würde ich ja immer versuchen, mich möglichst nahe an bestehenden Standards zu orientieren (schon, um den Supportaufwand niedrig zu halten), verständlich (und vollständig) zu dokumentieren, und das Ding möglichst SIMPLE zu halten.

 

[Popsel]

ich lese hier nur interessiert mit ... frage mich aber immer wieder, wer sich diese Strukturen ausdenkt? Als Entwickler würde ich ja immer versuchen, mich möglichst nahe an bestehenden Standards zu orientieren (schon, um den Supportaufwand niedrig zu halten), verständlich (und vollständig) zu dokumentieren, und das Ding möglichst SIMPLE zu halten.

Der ganze SysEx Kram brasiert auf dem MZ2000 aus dem Jahr 2000. Seither wurde das immer wieder an neuere Modelle angepasst und wohl um Kosten zu sparen nicht neu entwickelt. Support gibt es von Casio keinen. Man kann nur hoffen, dass ein User schon was rausgefunden hat und seine Erkenntnisse teilt.

 

[2bit]

Okay, ich hab mal eben den IPR zu reproduzieren und beschriften versucht, von den Screenshots und handschriftlichen Notizen krieg ich Kopfschmerzen.

IPR:

1: f0 - syx-start
2: 44 - manufacturer-id
3: 17 02 - modell [!: MSB, LSB]
4: 7f - device no.
5: 00 - act (IPS: 01)
6: 03 - cat
7: 01 - mem
8: 00 00 - pset [?: MSB, LSB]
9: 00 00 - blk 3 [?: MSB, LSB]
10: 00 00 - blk 2 [?: MSB, LSB]
11: 00 00 - blk 1 [?: MSB, LSB]
12: 00 00 - blk 0 [?: MSB, LSB]
13: 00 00 - prm [?: MSB, LSB]
14: 00 00 - idx [?: MSB, LSB]
15: 0f 00 - len [?: MSB, LSB]
16: (IPS: 47 72 50 6e 6f 43 6f 6e 63 65 72 74 20 20 20 20 ) - response
17: f7 - syx-end

-------------------------------
!: sicher
?: fraglich

Die Aufgabe ist nun, diesen Request so zu ändern, dass man gezielt die Namen der Parts 1-16 in Port A zurückbekommt und nicht IRGENDEINEN Namen an einer wilden Stelle des Speichers. Die grundsätzliche Länge des gesamten IPR-Sysex-Strings kann man mit 25 Bytes wohl einstweilen abhaken. Die Dataresponse (Zeile 16) ist auch in sich schlüssig, da sie mittels Hex-Converters direkt in eine ordentlich lesbare Zeichenkette übersetzen lässt.

Nacheinander und nicht auf einmal (!) würde ich mal folgende Testballons ausführen:

1. In Zeile 15 mal MSB und LSB mal gegeneinander austauschen und schauen, ob was dabei raus kommt.
2. In Zeile 15 die Zahl mal reduzieren, also kleiner 0x0f setzen.
3. In Zeile 8 wechselnd MSB und LSB mal mit 0x01 füllen.
4. In Zeile 12 wechselnd MSB und LSB mal mit 0x01 füllen.
5. In Zeile 13 wechselnd MSB und LSB mal mit 0x01 füllen.
6. In Zeile 14 wechselnd MSB und LSB mal mit 0x01 füllen.
7. Wenn sich bei den Schritten 3-6 unterschiedliche Ergebnisse auftun, dann mal vorsichtig um kleine Schritte (z.B. 1, 5, 10 bis max. 0x7f) erhöhen.

Wovon ich auf jeden Fall erst mal die Finger lassen würde, ist, schreibend mit IPS auf den Synth zuzugreifen. Solange du nicht zweifelsfrei weißt, was du da machst, ist das auf keinen Fall das Risiko wert, den Userspeicher an unsichtbaren Stellen mit Gibberish zu befüllen.

 

[microbug]

ich habe mich mit den aktuellen Erkenntnissen noch einmal mit dem "NAME" Parameter befasst und dieses Ergebnis erhalten:

Tu Dir selbst einen Gefallen und lade den empfangenen Sysex String in einen Hexeditor, denn offenbar kann SendSX keine solche Darstellung. Macht vieles einfacher.

Als Entwickler würde ich ja immer versuchen, mich möglichst nahe an bestehenden Standards zu orientieren

Bei Sysex gibts halt keine Standards und zudem scheinen insbesondere japanische Entwickler sehr isoliert von der Welt zu sein ... oder Leute, die mit Sysex keinerlei Erfahrung haben. Wenn Seitens der Firma dann keine Standards, so wie bei Roland seit dem S-10, vorgegeben werden, um das Format einheitlich zu halten, kommt halt so eine Grütze dabei heraus.
Yamaha hatte auch sehr lange kein Standardformat und sich bei jeder neuen Serie was Neues ausgedacht, ein absoluter Albtraum. Michael Haydn hat sich mit einem anderen Entwickler eines Multieditors damals hingesetzt und eine Empfehlung für nutzbare Sysex-Formate geschrieben, das sollte noch in der Datenbank der MMA existieren, gehalten hat sich da leider keiner dran. Siehe Abschnitt "Poetry and truth" im SD Programming manual.

 

[Popsel]

Inzwischen habe ich neue Erkenntnisse, wozu der "pset" Parameter dient.
In der MIDI Implementation zum Casio PX5 war eine Übersicht. Daraus geht hervor, dass es sich um ein Auswahlverfahren zur Abfrage von Preset / User-Soundnamen Namen handelt.
Natürlich stimmen die dort angegeben Daten nicht mit dem MZX500 überein. Aber die Tone-Kategorien sind dieselben.
Wenn ich diesen Parameter ändere, erhalte ich sogar Preset-Namen, die es im MZX500 gar nicht gibt.
In Verbindung mit der Namen-Abfrage erhalte ich alle möglichen Preset-Namen aus dem ROM, und zwar auch solche, die gar nicht aktuell in einem Part zugewiesen sind. So habe ich z.B. den Namen eines selbst gesampelten "TONES", der sich "Ice Man" nennt, zufällig gefunden.
Dieser Sound befindet sich in der Kategorie "Piano" und User Sound #2.
Zusammenfassend bedeutet dies, die gelieferten Namen haben nichts mit dem Edit Buffer zu tun, auf den ich zugreifen möchte.

 

[Scenturio]

Bei Sysex gibts halt keine Standards

das liegt in der Natur der Sache, aber man kann ja versuchen, es möglichst straight forward zu halten. Und es ging mir auch um den generellen (Software-)Aufbau der Klangerzeugung. Gerade Yamaha hat sich da m.E. zeitweise nicht gerade mit Ruhm bekleckert. Generell hätte man sich da imho etwas besser absprechen können, viele Einstellungen und Parameter ähneln sich ja doch irgendwie ...

 

[Popsel]

Okay, ich hab mal eben den IPR zu reproduzieren und beschriften versucht, von den Screenshots und handschriftlichen Notizen krieg ich Kopfschmerzen.

IPR:

1: f0 - syx-start
2: 44 - manufacturer-id
3: 17 02 - modell [!: MSB, LSB]
4: 7f - device no.
5: 00 - act (IPS: 01)
6: 03 - cat
7: 01 - mem
8: 00 00 - pset [?: MSB, LSB]
9: 00 00 - blk 3 [?: MSB, LSB]
10: 00 00 - blk 2 [?: MSB, LSB]
11: 00 00 - blk 1 [?: MSB, LSB]
12: 00 00 - blk 0 [?: MSB, LSB]
13: 00 00 - prm [?: MSB, LSB]
14: 00 00 - idx [?: MSB, LSB]
15: 0f 00 - len [?: MSB, LSB]
16: (IPS: 47 72 50 6e 6f 43 6f 6e 63 65 72 74 20 20 20 20 ) - response
17: f7 - syx-end

-------------------------------
!: sicher
?: fraglich

Die Aufgabe ist nun, diesen Request so zu ändern, dass man gezielt die Namen der Parts 1-16 in Port A zurückbekommt und nicht IRGENDEINEN Namen an einer wilden Stelle des Speichers. Die grundsätzliche Länge des gesamten IPR-Sysex-Strings kann man mit 25 Bytes wohl einstweilen abhaken. Die Dataresponse (Zeile 16) ist auch in sich schlüssig, da sie mittels Hex-Converters direkt in eine ordentlich lesbare Zeichenkette übersetzen lässt.

Nacheinander und nicht auf einmal (!) würde ich mal folgende Testballons ausführen:

1. In Zeile 15 mal MSB und LSB mal gegeneinander austauschen und schauen, ob was dabei raus kommt.

Keine Antwort erhalten.

2. In Zeile 15 die Zahl mal reduzieren, also kleiner 0x0f setzen.

Es wird nur ein Teil des Namens übertragen wenn "len" < $0f

3. In Zeile 8 wechselnd MSB und LSB mal mit 0x01 füllen.

MSB: Antwort im Bereich 0...5, LSB Antwort im Bereich 0...$7F gibt Preset und User Tone Namen aus dem ROM zuück (nicht aus dem Edit Buffer).

4. In Zeile 12 wechselnd MSB und LSB mal mit 0x01 füllen.

Antwort ohne Änderung

5. In Zeile 13 wechselnd MSB und LSB mal mit 0x01 füllen.

Keine Antwort

6. In Zeile 14 wechselnd MSB und LSB mal mit 0x01 füllen.

Keine Antwort

 

[einseinsnull]

Bei manchen Funktionen sendet das MZX500 bei Parameter-Änderungen SysEx-Daten, die ich mit dem MidiOX Tool am PC ansehen kann.

daraus kann man oft genau nicht schließen, was man hinzusenden hat, jedenfalls bin ich schon mal daran gescheitert.

habe die sniffing aktion dann vom gerät zu einem *hust* anderen, bereits bestehenden editor verlegt.

 

[einseinsnull]

Als Entwickler würde ich ja immer versuchen, mich möglichst nahe an bestehenden Standards zu orientieren

ich sehe das exakt genauso, aber der standard von sysex ist eben "mach wie du denkst".

 

[microbug]

Generell hätte man sich da imho etwas besser absprechen können, viele Einstellungen und Parameter ähneln sich ja doch irgendwie ...

Genau das war der Gedanke hinter dem schon besagten Dokument im Archiv der MMA.

 

[swissdoc]

Bei Waldorf ist es i.d.R. recht einfach, wobei hier manche an der Checksum scheitern. Dort beschränkt man sich aber auf 7-Bit und packt auch keine Parameter zusammen. Bei Moog habe ich mal ein Bitfeld gesehen, das sah ekelig aus. Alesis macht 8 zu 7 Packing, Kawai beim K3 packt Parameter in ein Byte zusammen, um Speicher zu sparen. Casio beim CZ1000 nutzt Mapping Tabellen von 0..127 zu 0..100, davon aber 2-3, die jeweils unterschiedlich sind.

Ich vergleiche das immer mit dem Bulk Parameter Export der gängigen Management Systeme im Mobilfunk. Da kann man auch viel Spass haben. Von CSV über XML bis zu Corba IRP geht da so manches. Nun kommt SOAP, JSON und Kafka ins spiel. Es wird einem einfach nicht langweilig.

Ach ja, manch ein Parameter kommt dann nicht mit und den bekommt man dann nur via MML oder was der Hersteller gerade nutz. Die Dokumentation ist i.d.R. auch Mist. Das sind aber so richtig kommerzielle Sachen, richtig teuer und mit S&M Vertrag und Tech Support.

 

[einseinsnull]

bei den handys von waldorf is das einfacher.

 

[microbug]

wobei hier manche an der Checksum scheitern.

Die wird ja nur beim Dump vom Gerät erzeugt, beim Senden kann man sie durch 0x7F ersetzen.

 

[Popsel]

Hallo Mitmusiker,
heute habe ich per SysEx den Namen meines gesampelten "Tones" "Ice Man" geändert.
Nach der Änderung blieb die Anzeige im Display zunächst wie zuvor.
Nach dem Wechsel am MZX500 auf einen anderen "Tone" und wieder zurück, zeigte das Display den veränderten Namen an.
Dann schaltete ich das MZX500 aus und wieder ein und rief den "Tone" "Ice Man" erneut auf.
Jetzt bekomme ich wieder den ursprünglichen Namen, also vor der Änderung per SysEx, angezeigt.
Somit ist klar, dass sich diese Änderungen auf das RAM und nicht auf das ROM bzw. FLash Speicher beziehen.

Der Programmierer der (oben genannten) Software "ToneTyrant" für CASIO CTX5000 war so freundlich mir zu antworten, um zu klären, was / wie die immer noch
unklaren Parameter bedeuten. Ich stelle seine Antwort mal hier rein. Allerdings ist das CTX5000 ein Nachfolgemodell des MZX500 und weit weniger komplex.
Meine Bemühungen, seine Erkenntnisse für das MZX500 zu übersetzen, haben leider bislang nichts gebracht.
Das Problem ist meines Erachtens die Funktion des 8 Bytes langen "Block" Parameters, der anscheinend zur Unter-Adressierung von Part-Parametern benötigt wird.
Der "Name" Parameter hat ja den Parameter Index 00 00. Wie man von dort aus die nachfolgenden Parameter adressiert, ist unklar.

Ich verstehe auch, dass es kaum möglich ist, ohne MZX500 zu helfen.
Zur Erinnerung:
Meine Absicht ist es, einen Hardware Midi-Controller für das MZX500 zu entwickeln. Bei solch komplexen Geräten macht es keinen Sinn, alle verfügbaren Parameter über einen Hardware-MIDI-Controller anzusteuern. Wie anfangs erwähnt, kann ich die meisten für mich interessanten Parameter schon über RPN / NRPN und die kürzeren SysEx Befehle, die das MZX500 selbst sendet, ansteuern. Da gibt es noch eine Besonderheit der String-Länge, wenn ein Parameter einen bestimmten Wert übersteigt. Dann wird ein zusätzliches Byte benötigt. Da war was, wenn das Bit #6 gesetzt ist, wird der Parameter auf zwei Bytes aufgeteilt. Das muss ich mit noch einmal genauer ansehen und vertiefen. Ich habe kürzlich ein altes M-Audio Oxygen 8 V2 Midi Master-Keyboard gekauft. Es kann RPN und NRPN Parameter senden und hat auch noch den klassischen 5-PIN MIDI-OUT, den ich für das CASIO MZX500 benötige. Ein Anschluss über USB scheidet aus, weil das MZX500 keine Class Complient MIDI Controller (die am PC ohne Treibe-Installation auskommen) erkennt.

Hier ist die Antwort des freundlichen Programmierers der "ToneTyrant" Software.
Hinweis: Die Informationen beziehen sich auf das Casio CTX5000 und nicht das hier behandelte Casio MZX500:

Yes I agree it's not clear. Based on my experience with the CT-X:

Data Index number: (1 byte) always 0x00.

Octave Shift: value of 0x02 = octave shift -2. value of 0x04 = octave shift +0. value of 0x06 = octave shift +2

Parameter Set: (2 bytes) if category is "Tone", this is the number of tone that is changed. On CT-X (where user tones start at number #801), 03 00 means TONE #804. 62 00 means TONE #899. If category is "Rhythm", it's the number of the rhythm that is changed, etc.

Blocks: There are 8 bytes (4x14 bits). An example would be helpful: see https://github.com/michgz/ac7maker/blob/master/Documentation of Casio formats/Tone definition format.txt (this is for CT-X3000/X5000).

F0 44 19 01 7F 01 03 03 00 00 00 00 00 00 00 00 06 00 0B 00 00 00 00 00 00 04 F7

Decoding:
--------------
Memory=3
Category=3 (Tones)
Block[3] = 0 (unused)
Block[2] = 0 (unused)
Block[1] = 0 (unused)
Block[0] = 6

Parameter = 11 (Detune envelope value setting)
Parameter set = 0
Index = 0 (always)
Length = 0 (1 byte)
Value = 4


The detune envelope has 7 stages, and Block[0] specifies which one to change. In this case it's stage 6 (the last one, "Release")


For an example where Block[1] is used, see https://github.com/michgz/ac7maker/blob/master/Documentation of Casio formats/Drum kit definition format.txt. In the DrumSet category, Parameter 32 (volume) is indexed by both Block[0] (selects MIDI note) and Block[1] (selects sound layer, e.g. left/right stereo or layered sounds).

I hope those are some clues. I don't really know what 55:0-0 means either.

Ich lasse das erst einmal so stehen und habe vor, mich um Tests mit den als funktionierend bekannten Parametern zu befassen, bevor ich das dann in Hardware nachbilde.
Mir gehen langsam die Ideen aus und weitere Hinweise konnte ich auch keine mehr finden.
Es mag wohl daran liegen, dass der durchschnittliche Anwender lieber Musik macht, als sich mit unklaren SysEx-Dokumentationen zu "vergnügen".

Falls es noch jemand mit einem MZX500 gibt, der Interesse hat, die SysEx-Rätsel zu lösen, dann ist das, was ich inzwischen recherchiert habe, bestimmt eine gute Ausgangsbasis.

Ich bedanke mich bei allen, die versucht haben, mir zu helfen.

Weiterhin viel Spass mit der Musik

Freundliche Grüße
Popsel

 

[Popsel]

Hallo,
anbei habe ich meine Dokumentation der bislang ermittelten Casio MZX500 Remote Befehle angefügt:
AETEK MIDI Remote Control Commands for Casio MZX 500