Behringer Wave SysEx - PPG vs Behringer Wave (mit Excel etc) vergleichen

[microbug]

ok, wer schreibt Hermann an und fragt nach einer Doku oder einem C-Headerfile, falls vorhanden? Am Besten jemand, der ihn persönlich kennt.

 

[swissdoc]

Anfrage bei Virtual Music läuft schon. Ich melde mich wieder, wenn ich eine Antwort habe.

 

[microbug]

Die haben aber doch wahrscheinlich auch nur die Doku, die beim V8.x dabei ist und @qwave bereits vorliegt?

 

[micromoog]

Die haben aber doch wahrscheinlich auch nur die Doku, die beim V8.x dabei ist und @qwave bereits vorliegt?

F0
Die Austria PPG Connexxion hat evtl. untereinander Verbindungswege von denen wir nichts wissen
F7

 

[swissdoc]

Virtual Music hat keine solche Doku, aber nun hat Hermann eine Mail von mir.

 

[micromoog]

Virtual Music hat keine solche Doku, aber nun hat Hermann eine Mail von mir.

Na dann bin ich mal gespannt, ob wir als Dankeschön einen Schokoladen Osterhasen oder Nikolaus überreichen dürfen

 

[Makabäer]

Heute bin ich leider zu nichts gekommen. Das wird morgen und am Montag wahrscheinlich genauso sein. Vielleicht schaffe ich am WE was.

 

[Makabäer]

Ich will Euch aber meine Arbeit von gestern nicht vorenthalten. Es gibt jetzt ein zweites Tab, in das ein beliebiges SysExFile mit 20.000 Byte Länge importiert werden kann. Darin befindet sich zz. Cellos () PPG-Datei zur Analyse. Es können auch längere Dateien importiert werden aber nur die Zeilen bis 20.000 werden geleert, da es bei 100.000 einen Überlauf gab, und die PPG-Datei kleiner als 20.000 ist.

 

[Makabäer]

Im PPG Wave steckt eine Motorola CPU, daher gilt: Big Endian ist die Reihenfolge der Wahl.

Dann müssten die Werte aber zu finden sein. D.h. wenn im Bave-File 36 steht, müsste im PPG-File doch eigentlich 06 03 zu finden sein. Ist aber leider nicht so. Oder, wenn die Bytes zusammengehalten werden, müsste bei PPG 36 00 zu finden sein. Ist aber auch nicht der Fall.

 

[qwave]

Dann müssten die Werte aber zu finden sein. D.h. wenn im Bave-File 36 steht, müsste im PPG-File doch eigentlich 06 03 zu finden sein. Ist aber leider nicht so. Oder, wenn die Bytes zusammengehalten werden, müsste bei PPG 36 00 zu finden sein. Ist aber auch nicht der Fall.

Sind seine Zahlenangaben in Hexadezimal oder Decimal? In beiden stimmt es so nicht.
x36 (hexadezimal) = 54 (dezimal) = 0011 0110

Also die oberen vier Bits sind die ersten vier = (0000)0011 = x03
Die unteren Bits = (0000)0110 = x06
Bei Big Endian also erst x03 dann x06 im PPG Sysex.

Wenn du die 36 dezimal meinst, so wäre das binär = 0010 0100
Also (0000)0010 = x02
und (0000)0100 = x04
Also mit Big Endian als x02 x04 im PPG Sysex.

(0000) sind die für 4 Bit nicht genutzten Stellen im 8 Byte Sysex (das nur die unteren 7 Bit tatsächlich mit Daten nutzen kann, da das oberste Bit für MIDI wie xF0, xF7 und andere Satus Bytes reserviert ist).

 

[microbug]

Tip: Wer öfter Binärdaten am Mac analysieren muß, dem empfehle ich "Synalize It!" (gibts auch als Pro-Version). Dort kann man sogenannte Grammatiken definieren, also Strukturen definieren, die dann vom Programm erkannt werden. Sehr nützliches Tool. Hätte ich gerne in den 90ern gehbt, als ich regelmäßig Sysexdaten reverse engineeren mußte.

 

[micromoog]

Dann müssten die Werte aber zu finden sein. D.h. wenn im Bave-File 36 steht, müsste im PPG-File doch eigentlich 06 03 zu finden sein. Ist aber leider nicht so. Oder, wenn die Bytes zusammengehalten werden, müsste bei PPG 36 00 zu finden sein. Ist aber auch nicht der Fall.

Schnellschuss Idee:
Evtl bei zB Wert 36 auch mal nach 72 suchen, nicht das hier auch die 0-127 ausgeschöpft werden.

 

[Makabäer]

Sind seine Zahlenangaben in Hexadezimal oder Decimal? In beiden stimmt es so nicht.
x36 (hexadezimal) = 54 (dezimal) = 0011 0110

Also die oberen vier Bits sind die ersten vier = (0000)0011 = x03
Die unteren Bits = (0000)0110 = x06
Bei Big Endian also erst x03 dann x06 im PPG Sysex.

Wenn du die 36 dezimal meinst, so wäre das binär = 0010 0100
Also (0000)0010 = x02
und (0000)0100 = x04
Also mit Big Endian als x02 x04 im PPG Sysex.

(0000) sind die für 4 Bit nicht genutzten Stellen im 8 Byte Sysex (das nur die unteren 7 Bit tatsächlich mit Daten nutzen kann, da das oberste Bit für MIDI wie xF0, xF7 und andere Satus Bytes reserviert ist).

Ich meine die 36 natürlich hexadezimal, da das die .syx-Datei binär ist also erst in Dezimalwerte umgewandelt werden muss.

Wenn, wie oben beschrieben, bei Big Endian die höherwertigen Bits am Schluss stehen, muss also bei 0x36 die 3 am Schluss stehen, also 06 03.

 

[Makabäer]

Schnellschuss Idee:
Evtl bei zB Wert 36 auch mal nach 72 suchen, nicht das hier auch die 0-127 ausgeschöpft werden.

Habe ich auch schon erfolglos versucht, bzw. nicht nach 72, das wäre dezimale Multiplikation, sondern 6C.

 

[qwave]

Ich meine die 36 natürlich hexadezimal, da das die .syx-Datei binär ist also erst in Dezimalwerte umgewandelt werden muss.

Wenn, wie oben beschrieben, bei Big Endian die höherwertigen Bits am Schluss stehen, muss also bei 0x36 die 3 am Schluss stehen, also 06 03.

Falsch.

• Beim big-endian (wörtlich etwa: „großendigen“, siehe auch Abschnitt „Etymologie“) Format wird das höchstwertige Byte zuerst gespeichert, d. h. an der kleinsten Speicheradresse. Allgemein bedeutet der Begriff, dass bei zusammengesetzten Daten die höchstwertige (höchstrangige) Komponente zuerst genannt wird, wie etwa bei der deutschen Schreibweise der Uhrzeit: Stunde:Minute:Sekunde.
• Beim little-endian (wörtlich etwa: „kleinendigen“) Format wird dagegen das niedrigstwertige Byte an der Anfangsadresse gespeichert, also die niedrigstwertige Komponente zuerst genannt, wie bei der herkömmlichen deutschen Datumsschreibweise: Tag.Monat.Jahr.

 

[Makabäer]

Falsch.

Die englische Beschreibung weiter oben sagt genau das Gegenteil. Ist aber auch vollkommen egal, da weder so oder so eine Übereinstimmung gefunden wird.

 

[qwave]

Die englische Beschreibung weiter oben sagt genau das Gegenteil. Ist aber auch vollkommen egal, da weder so oder so eine Übereinstimmung gefunden wird.

Welche meinst du? Oben bei Wikipedia? Oder das hier?
Beim letzteren wird bei Nibble HL auch erst die höherwertigeren Bits geschrieben. Deshalb HL = high to low.
Mit "ist egal" werden wir das bestimmt nicht knacken.

 

[Makabäer]

Es ist aber wirklich egal. Ich habe, wie weiter oben bereits erwähnt, beide Reihenfolgen versucht und sogar Abstände zwischen den beiden zugelassen, bei denen aus 0x36 z.B. 03 00 06 oder 06 00 00 03 wurde. Nichts hat zum Erfolg geführt. Ich habe weiterhin den Verdacht, dass die Werte bitweise positionsabhängig gespeichert sind, was nur mit einer Anleitung der Herren Palm oder Seib zu lösen wäre.

 

[micromoog]

Ohne Doku oder zumindest einen „Hint“ von Herrmann ist es wirklich die Suche nach der Stecknadel im Heuhaufen.

Noch eine absolute Laienidee (Habe von den Nibbels, HLs etc null Ahnung)

Wie verhält sich das File wenn man einen einzigen Parameter im PPG um Wert 1 erhöht. Das bringt natürlich noch keine brauchbare Lösung für das Gesamte, man hätte zumindest mal eine Position wo evtl was „passiert“.

 

[Makabäer]

Das herauszufinden ist mein Plan, falls wir keine Hilfe von außen bekommen.

 

[qwave]

Wenn viele PPG Parameter nur in 1 Bit sind (beim Behringer teilweise mit mehr Möglichkeiten erweitert), warum ist dann für 105 zu speichernde Werte der Data-Teil eines einzelnen Sounds (mit A & B) insgesamt 204 Bytes lang?

1 Bit Parameter des PPG waves 2.2/2.3:
Tuning Page: MO, MS, EO, ES
Digital Page: UW, MW, MF, ML, TW, TF, TL, TM, VF, VL
= 14 Parameter mit 1 Bit

Und die Attack-Werte des Envelopes 1 und 2 sind z.B. nur in 4 Bit Auflösung gespeichert (mögliche gespeicherte Werte: 0, 4, 8, 16, …).
Andere Parameter haben nur 2 Bit nötig (SW), andere 3 Bit (BD, BI, KW, KF, KL)

Vielleicht hat man die einzelnen Bits der ganzen Daten einfach irgendwie hintereinander mit 4 Bits per Sysex Byte als Dump? Hinten vielleicht mit Nullen aufgefüllt (sind ja auch bisher immer viele Nullen bei einzelnen PPG wave Sysex Dumps).

Und dann stellt sich die Frage, ob ich bei den Dumps den gespeicherten Klang oder den Edit Buffer Inhalt bekomme?
Ich habe bei meinen Keyboards leider keinen PC Arbeitsplatz in der Nähe (arbeite ohne DAWs). Und den PPG wave werde ich nicht transportieren.

Da die Länge des Bank Dumps des PPG waves pro Klang offensichtlich nur halb so viel Bytes braucht, ist da wirklich ein hoher Palm Konfuzius Faktor™ enthalten.

Ich werde daher in der Zeit, statt im dunklen zu stochern, lieber Sounds abtippen.
111110111

 

[Makabäer]

Wenn viele PPG Parameter nur in 1 Bit sind (beim Behringer teilweise mit mehr Möglichkeiten erweitert), warum ist dann für 105 zu speichernde Werte der Data-Teil eines einzelnen Sounds (mit A & B) insgesamt 204 Bytes lang?

Eine berechtigte Frage.

Möglicherweise enthält jedes Byte oder auch jeder Parameter ein Prüfbit. Wobei Prüfbits bei Ein-Bit-Parametern denkbar unsinnig sind.

 

[micromoog]

Es ist und bleibt HEXerei!

Wenn viele PPG Parameter nur in 1 Bit sind (beim Behringer teilweise mit mehr Möglichkeiten erweitert), warum ist dann für 105 zu speichernde Werte der Data-Teil eines einzelnen Sounds (mit A & B) insgesamt 204 Bytes lang?

Als ob die Daten in einer Matrix kodiert werden um (Speicher-)Platz zu sparen.

So in etwa wie ein QR-Code.

Natürlich nur Laien VT meinerseits.

 

[Makabäer]

Es ist und bleibt HEXerei!

Jap.

Als ob die Daten in einer Matrix kodiert werden um (Speicher-)Platz zu sparen.

Und den gesparten Platz dann doppelt zu verschwenden, indem man jeweils vier Bit nicht nutzt. Es ist ein Rätsel.

 

[microbug]

Und den gesparten Platz dann doppelt zu verschwenden, indem man jeweils vier Bit nicht nutzt.

Moment. Das mit den Nibbles gilt nur für den Datentransfer über MIDI, weil sonst nur 7bit gingen. Intern wird das Ganze natürlich 8 oder 16 Bit gespeichert. Nibbleweiser Transfer ist natürlich so ziemlich das ineffizienteste, aber einfacher zu implementieren als alle anderen Methoden, die ich weiter vorne anhand eines Screenshots aus dem SoundDiver Handbuch aufgezeigt habe.
Sequential zB nutzt zumindest beim Pro2 Packed 7 Bit, ich weiß nur nimmer ob das Byte mit den höchstwertigen Bits als erstes oder letztes gesendet wird, das müßte ich in meiner SoundDiver Adaption nachschauen, ist aber eher unwichtig.
Dieses Format wird übrigens beim Behringer Wave ebenfalls benutzt, und zwar zum Transfer von Wavetables.

 

[Makabäer]

Moment. Das mit den Nibbles gilt nur für den Datentransfer über MIDI

Theoretisch, aber im PPG-SysEx-File sind in jedem Byte ja immer nur die unteren vier Bit gespeichert.

 

[qwave]

8 Bit Werte, aus Parametern die max. 6 Bit sind, in 4 Bit Werten des Sysex zu Packen ist schon irgendwie komisch.
Und warum hat man überhaupt die Parameter auf max. 6 Bit begrenzt, wenn man dadurch auch im RAM des PPG waves nichts sparen würde?

 

[microbug]

8 Bit Werte, aus Parametern die max. 6 Bit sind, in 4 Bit Werten des Sysex zu Packen ist schon irgendwie komisch.

Wurde aber bei einigen Geräten so gehandhabt, weil man einfach alles was aus dem Speicher kam konvertiert hat und nicht erst schaute, wieviel Bits da genutzt werden. Machte es auch für Universaleditoren einfacher. Man konnte damals deutlich sehen, daß beim Wechsel auf 16Bit CPUs beim Datentransfer eine Zeitlang Verschwendung herrschte Im Screenshot aus dem Sounddiver-Handbuch sind auch ein paar Geräte genannt, die das mit dem Nibble-Transfer veranstalteten - ich meine, daß die EMU Proteus der 2. Generation, zu denen auch der Vintage Keys gehörte, das so betrieben, da hatte ich damals die erste Adaption dafür gebaut.

 

[micromoog]

8 Bit Werte, aus Parametern die max. 6 Bit sind, in 4 Bit Werten des Sysex zu Packen ist schon irgendwie komisch.
Und warum hat man überhaupt die Parameter auf max. 6 Bit begrenzt, wenn man dadurch auch im RAM des PPG waves nichts sparen würde?

Das Zeug was man in den 80ern geraucht hat, strotzte wohl nur so an Nebenwirkungen - anders kann man sich das nicht erklären.

 

[microbug]

Das Zeug was man in den 80ern geraucht hat, strotzte wohl nur so an Nebenwirkungen - anders kann man sich das nicht erklären.

Das Problem bei Sysex ist, daß man an dieser Stelle außer dem Rahmenformat (max. 7Bit, F0 <>7E als Vorspann und F7 als Ende) keinerlei Vorgaben gemacht hat,w as die Hersteller dann auch, teils sehr kreativ, ausnutzten und sich immer neue Methoden ausdachten, die teils sogar innerhalb der eigenen Firma von Gerät zu Gerät variierten. Rühmliche Ausnahme war Yamaha mit seinem Standardformat für alle 6OP FM Synths und alle 4OP FM Synths (was sie beim DX9 und FB01 prompt selbst unterliefen) und Roland mit ab dem S-10 eingeführen Standardformat, was auch heute noch gilt, wenn auch die Model ID inzwischen auf 4 Byte angewachsen ist. Yamaha hat IIRC seit dem Motif auch ein Standardformat, vorher war alles ein einziges Durcheinander.