Sysex Checksum

oove

oove

Registriert
10.08.10
Beiträge
2.843
Reaktionen
1.184
Punkte
6.627
Hallo Leute,

ein kontinuierlicher Controller soll in eine Sysex Format gewandelt werden.
Das Format sieht folgendermaßen aus:

F0 41 00 00 00 20 12 24 01 02 59 F7

Der blaue Wert ist ein Wert, der von einem Expression Pedal kontinuierlich verändert wird.
Der rote Wert ist eine veränderliche Checksumme.


Wenn ich in meinem Programmiertool (Event Processor plus von MIDI Solutions) für die blaue und die rote Zahl die Werte XX und YY eingebe, gibt es eine Warnung, dass er kein Event mit einem X Wert mappen kann, wenn er kein Event ohne X Wert bekommt.

Das ist auch logisch, denn der eingehende kontinuierliche Controller liefert ja nur einen beweglichen Wert, nämlich Y.

Die Checksumme im Sysex ist aber auch veränderlich.
Wie kriegt man das hin?

Bei der Eingabe des Sysex Signals darf ich auch noch Variablen V1 - V8 angeben.
Was immer ich dort programmiere, ich komme nicht zum Erfolg beim ausprobieren an den Endgeräten...

Weiß jemand bescheid?
 
Die Checksumme ist die Summe der Datenbytes ohne Header bzw. F7.

Eventuell berechnet der Event Processor diesen Wert automatisch? Oder Du musst ein Kürzel/Variablenbezeichnung wie CHK o.ä. eingeben?

Wenn nicht - hast Du mal die Funktion Trigger Midi Event ausprobiert? vielleicht geht es da?

Clemens
 
Die Checksumme im Sysex ist aber auch veränderlich.
Mal jetzt einfach nur irgendwo kopiert...ganz generell und nicht auf dein Programm bezogen:

1. Convert the hex values to decimal.
2. Add the values together, but if the answer to any sum exceeds 127 then subtract 128.
3. Subtract the final answer from 128.
4. Convert the resulting value back to hex and use as the checksum.

Macht das eigentlich Sinn nen veränderlichen Wert als Sysex zu verschicken? Sysex hab ich bisher immer nur als Mittel für "Grundeinstellungen" verstanden....die man am besten auch schon am Anfang eines Songs erledigt.
 
Danke Clemens.

Weglassen der Checksumme bringt nix.

Das Kürzel CHK bezeichnet er als "invalid".

Bei Verwendung von Trigger a MIDI Event steht mir nur noch die Eingabe einer Variablen zur Verfügung. Also oben beim Eingang gibt es zwar noch einen Y Wert, aber im SYSEX String kann ich den nicht mehr benutzen. Statt dessen habe ich mal V1 eingetragen. Hilft aber auch nicht.

Beim Eintrag eines festen Werts z.B: 02 passiert auch nichts.

Hallo Soundkraft:
Das Roland FC-300 Pedal liefert Sysex Signale, die ein Roland Klangerzeuger auch versteht.
Das Behringer kann aber nur Note, Prg Change und kontinuierliche Controller.

Der Event Prozessor kann das übersetzen. Ich weiß nur nicht, wie
Mit Trigger A Event kann ich bereits Noten erfolgreich in entsprechende Sysexes umwandeln. Da sind auch Checksummen enthalten, aber natürlich sind sie fix.

Beim Wandeln von kontinuierlichen Daten ändern diese sich aber auch mit jedem neuen Y Wert und ich begreife nicht, wo der herkommen soll oder wie er berechnet werden soll und der Prozessor weiß es auch nicht ;-)
 
Das Roland FC-300 Pedal liefert Sysex Signale, die ein Roland Klangerzeuger auch versteht.
Das Behringer kann aber nur Note, Prg Change und kontinuierliche Controller.

Ahso..hab übersehen, dass ich mir hier im DIY-Forum befinde.
Vllt ist es dann einfach so dass dieser Eventprozessor dass dann einfach nicht kann. In dem Fall müsste er ja die Checksumme auf jedenfall selber berechnen. Oder vllt gibt es Ausnahmen dass in so einem Fall die eigentliche Wert gar nicht in die Checksumme einbezogen wird...oder die CHecksumme einen festen Wert bekommt...edit: ok haste schon probiert...ich würds aber vllt mal mit 0 oder 128 (dez 80 oder -1 ) als Wert probieren.


Ich versteh zwar immer noch nicht warum für eine Expressionänderung SysEx nötig sein sollte...ein normales Expressionpedal (wie zb mein EV-5 von Roland am Roland A800) liefert laut Midimonitor in Reaper CC11 und das höherwertige Byte (MSB) des eigentlichen Wertes. Vllt wird auch zusätzlich noch das LSB (CC42) erwartet. DAs FC300 scheint ja eh etwas komplexer aufgebaut....das hast du aber nicht zufällig umd einfach nachzuschauen was es sendet nehme ich an....vllt hat das ja jemand und kann mal posten was genau das sendet bei Änderung...weiss jetz aber nicht ob Header und Checksumme da überhaupt angezeigt werden....

Ist jetzt aber nur ganz wildes spekulieren...evtl in der Hoffung, dass es dich auf Umwegen auf die richtige Idee bringt...da ich ja weder das Programm kenne noch bei der SYSEX-Spezifikation so firm bin.

Ich erkenne zwar immer noch nicht die Notwendigkeit von SysEx für Expressionbefehle aber ist ja deine Sache;)
 
Wie der Befehl aufgebaut ist, weiß ich ja. Dad habe ich oben ja geschrieben. Ich habe auch eine andere Übersetzungsbox, an der ich genau ablesen kann, wie sich die Werte ändern. Ich weiß nur nicht, wie ich sie mit dem Eventprocessor erzeugen kann.

Ich bin ziemlich sicher dass es geht - nur wie?
 
Da meine Frau verreist ist und mir langweilig ist und mich das Thema interessiert hab ich mal "Trockenübungen" mit dem Programm gemacht, weil ich die Hardware dazu ja nicht hab. Scheint so zu sein dass eine Checksumme tatsächlich NICHT automatisch erzeugt wird. Allerdings braucht man diese Checksumme wohl nur bei Roland Synthesizern soweit ich das ergooglen konnte...ansonsten lässt man die einfach weg und F7 folgt direkt hinter dem Wert...und den gibt man nicht etwa als Zahl an sondern tatsächlich als "YY" oder "V1" im SysEx-String....weisst du sicher aber ich schreibs mal trotzdem :)

Das sieht dann ungefähr so aus wie im Anhang....Geräte- und Hersteller ID und so ist dir ja sicher ein Begriff und müssten natürlich noch richtig eingetragen werden.

(Nein ich halte dich nicht für blöd..und bin sicher wer soviel Geld für so ne Midibox ausgibt hat auch halbwegs Ahnung davon (sicher mehr als ich) ...vllt liest hier aber auch mal jemand anders, den das interessiert ;) )

Also wenn du nicht grad nen Roland-Synthi anzusteuern hast (was ich fast befürchte...oder ist mit "Behringer" etwa ein Synthi gemeint?), die die Checksumme brauchen, dann kannste SysEx automatisieren...ansonsten gibts vllt andere Boxen oder Software die das können...diese hier kann es wohl wirklich nicht. das SysEX-Format ist ja nicht wirklich durch und durch standardisiert...jedenfalls nicht das was zwischen Header und Schlussbyte steht...daher müsste so eine Box speziell für Roland einen Modus haben, der die Checksumme berücksichtigt und selbst einträgt.

Aber wie gesagt...solange es kein Rolandsynthi ist kannste mit der Box mit Sysex arbeiten, so wie ich das sehe, da sich wohl wirklich nur die eine Variable ändern muss und das tut sie ja anscheinend.

Wie das andersrum ist (also mit Rolandcontroller per SysEx an einem NIchtrolandsynthi) weiss ich nicht...evtl wird da die Checksumme einfach ignoriert...vlt aber auch bei Überschreiten eines bestimmten Wertes als neuer Befehl missverstanden der aber wegen dem "F7" dann unvollständig bleibt bzw nen illegalen Wert liefert.

Das Programm ist eigentlich so simpel gestrickt, dass ich kaum denke da was übersehen zu haben ;)
Einen "Code" (sowas wie "CHK" oder "CHS"), der für das Berechnen der Checksumme stehen würde. gibt es nicht....und der wäre zwingend notwendig.

Probier es ohne Checksumme (hast du zwar schon probiert aber vllt nur an einem Rolandsynthi) und mal sehn was passiert. :)

Wer weiss...vllt wird die Checksumme sogar automatisch generiert, wenn sie fehlt, auch wenn das Handbuch sagt, dass Daten nie "rückblickend" behandelt werden können sondern nur in Echtzeit.

alle Angaben ohne Gewähr, weil ja keine Möglichkeit zum testen ;)

Und wenn das auch nicht geht...dann gib mal eine dienen Konkreten String hier an den du verschickst....also die echten Werte die du da eingetragen hast und nicht nur Beispiele mit Fantasiezahlen und das konkrete Gerät dazu. Vllt ist da irgendwo ein Fehler drin.

PS: Wenn man 127 Settings hätte, könnte man jedem möglichen Wert seinen eigenen SysEx-Befehl samt richtiger Checksum zuordnen.....naja..Spass muss sein :D
 

Anhänge

  • Sysex.jpg
    Sysex.jpg
    61,3 KB · Aufrufe: 184
Wenn ich genau wüsste wie der Sequenzer vom Eventprozessor arbeitet (also ob der einen reinkommenden Wert 2 mal auswertet wenn er 2 Schritte macht oder ob der nur beim ersten Step auswertet) würde ich sagen man kann das auch irgendwie mit zwischenspeichern von Value Y in V1 (Store Value) und anschliesssendem skalieren von Value y erledigen, weil die Checksum ja immer genau um 1 grösser wird, wenn der Expressionwert um 1 grösser wird, da sich ja sonst nix im SysEx-Befehl ändert und das ganze Checksumgedöns nur einfache Addition ist.

Dann wäre im letzten Schritt V1 als Wert (denn den hat sie ja durch value y vor dem skalieren bekommen) und YY (Value Y nach dem Skalieren) als Checksum einzutragen...das funktioniert aber nur wenn wirklich der reinkommende Wert nur beim ersten Step ausgewertet wird und die nächsten Schritte sich nicht nochmal darauf beziehen sondern einfach "weiterrechnen"...sonst hab ich schon den nächsten Wert der nicht mehr zu dem passt was ich als Checksum grade in YY stehen habe.

Und man müsste evtl 2 solcher Sequenzen mit verschiedenen Ranges und Skalierungen machen, da die Checksum ja nicht grösser als 127 werden darf, wenn ich das richtig verstehe und der Eventprozessor ja nicht "rechnen" kann

Zunächst müsstest du mal nen funktionierenden SYExbefehl erstellen inkl Checksum. Dann weisst du im wieviel kleiner oder grösser die Checksum gegenüber dem Expressionwert sein muss...damit lassen sich dann die Skalierungen einstellen.

Klingt jetzt kompliziert aber isses eigentlich nicht....solange der Seqenzer so arbeitet wie ich mir das vorstelle.

so..ich denke jetzt geh ich mal schlafen :D
 
Wow!
Ich denke die Idee in der zweiten Mail könnte brauchbar sein.
Leider hab ich heute schon wieder ein Konzert und weiß noch nicht, wie lang ich mich damit beschäftigen kann. Aber ich probiere nachher noch ein bischen herum und filme das Ergebnis.

Danke schonmal!
 
Folgendes war herauszufinden:

Bei YY = 7F ist die Checksumme 5C
Bei YY = 7E ist die Checksumme 5D
Bei YY = 7D ist die Checksumme 5F
.
.
.
Bei YY = 79 ist die Checksumme 62
Bei YY = 77 ist die Checksumme 64
Bei YY = 76 ist die Checksumme 65
.
Bei YY = 74 ist die Checksumme 67
.
Bei YY = 72 ist die Checksumme 69
.
Bei YY = 70 ist die Checksumme 6B
Bei YY = 6F ist die Checksumme 6C
.
.
Bei YY = 6C ist die Checksumme 6F
Bei YY = 6B ist die Checksumme 70

usw.

Bei YY = 4B ist die Checksumme 10

usw.

Bei YY = 30 ist die Checksumme 2B
Bei YY = 2F ist die Checksumme 2C
.
Bei YY = 2D ist die Checksumme 2E
Bei YY = 2C ist die Checksumme 2F
Bei YY = 2A ist die Checksumme 31

viel kleiner kann ich die Werte gerade nicht erzeugen, weil das Behringer Pedale nach über 10 Jahren mechanisch nicht mehr ganz einwandfrei funktioniert.

Scheint irgendwie Rückwärts zu zählen, aber nicht logisch. Oder doch?
Das gleiche scheint mir auch bei den Tastern so zu sein.

Das mit der Variablen ist echt eine gute Idee, kann mir aber gerade trotzdem nicht vorstellen, wie ich das anfangen kann.

Hier ist ein Video mit einigen Erklärungen (72 MB / 9 min)
https://dl.dropboxusercontent.com/u/13754833/sxsex1.flv

Hast Du das MIDI Solution Programiertool geladen?
 
viel kleiner kann ich die Werte gerade nicht erzeugen,

Eigentlich solltest du nur einen Wert oder 2 per Hand ausrechnen...aber es einfach vom MIDImonitor abzulesen is natürlich auch ne Idee :D

Scheint irgendwie Rückwärts zu zählen, aber nicht logisch. Oder doch?

Doch denke schon.

3. Subtract the final answer from 128.
Hab ich in Post 3 ja schon gepostet....D.h. die CHecksumme ist ist 128 - Expressionwert +/- Offset (der sich durch die anderen Zahlen davor ergibt....der aber praktischerweie immer gleich ist)
Das könnte man glaub ich dadurch lösen, dass man den eingehenden Wert (0-127) in eine Range von 127 - 0 umwandelt. Das würde glaube ich schon mal dasselbe bewirken, wie das abziehen von 128. Ganz so einfach ist es aber dann doch nicht, da ja noch der Offset mitberechnet werden muss...und da ist dann der Punkt weshalb ich geschrieben hatte dass man wohl 2 Wertebereiche und daher auch 2 Sequenzen...weil die Range von Eingangs- und Ausgangswert immer den genau selben Umfamg haben muss damit sich das eine immer genau um 1 ändert wenn dich das andere um 1 ändert. Leider entstehen ja auch Werte über 127 beim zusammenzählen...die Ranges kann man aber nur bis 127 angeben...irgendwann wird das Verhältnis von Wert zu Checksumme "kippen" Also muss ein Offset her bzw 2 Offsets in jeweils ihrer eigenen Sequenz, die jeweils nur bis zu diesem Kippbereich arbeiten.
Also sagen wir mal eine eine eingehend Range von 0-30 wird in eine ausgehende von 110-80 (sowas erlaubt der Eventprocessor ja) umgewandelt. Der Umfang entspricht bei beiden genau 31 Werte und der Offset ist 80. Je grösser ein Eingansgwert (im Bereich von 0-30) ist desto kleiner wir der Ausgangswert. (so zumindest mein theoretischer Gedankengang)

Ich bin kein Mathegenie....und ich hab nur das Programmiertool (is ja free daonloadbar) um zu gucken was sich prinzipiell machen lässt und kann daher nicht prüfen was genau passiert und ob ich irgendwo nen Denkfehler habe...es schwirrt halt ein bisschen diffus im Kopf rum. Vor allem ob es wirklich nötig ist 2 Sequenzen anzulegen die jeweils nur in einer bestimmten Range arbeiten ist mir grad selber nicht ganz klar und müsste man ausprobieren. Und wahrscheinlich muss man dann vorher auch noch das MIDi-Event filtern und irgendwie ne Verzweigung erstellen je nach Grösse des Eingangswertes.

Inwieweit das Programmiertoll das mitspielt und sich so verhält wie geplant ist dann auch noch ne Sache.

Weiss nicht ob ich das grundsätzliche Prinzipmeiner Idee jetzt verständlich gemacht habe (würde mich fast wundern :D)...aber vllt bringts dir ja Denkanstösse...musst halt ein wenig "um die Ecke" denken...da der direkte Weg ja versperrt ist, bleibt einem ja eh nix anderes.
 
Zu deinem Video...ja is so wie ich mir das gedacht habe.
Das speichern von Y erfolgt in diesem "store" in Variable Menüpunkt...und sollte dann wohl auch gleich das erste sein, was du dann in einer Sequenz erledigst, denn nachgehend wird ja Y zur Bildung der Checksumme verändert.
Dass übrigens bei den Slots die Checksumme "unlogisch" erscheint ist deshalb, weil sich auch die Adresse ändert. In so einem Fall könnte man auch nix mehr "umwandeln" weil Rangeumwandlung (das ist eigentlich der ganze Grundgedanke meiner Idee) nur 1:1 eindeutig funktioniert .
Aber "pro Slot" sollte das trotzdem klappen, da dann ja auch die Adresse immer gleichbleibt.

Viel mehr kann ich jetzt glaub ich nicht zum Thema beitragen. Das musst du halt irgendwie alles mal ausprobieren und auch weiterdenken...ich kann das alles hier nur quasi "im Kopf" grob durchdenken und da is irgendwo ne Grenze, wo dann alles ein wenig verschwommen wird und der Denkfaden reisst ;)

Übrigens...eigentlich isses ne ganz dumme Idee eine kontinuierlich Änderung per SysEx druchzuführen...auch wenn das Rolanddingens das vllt so braucht. Denn das sind im Verhältnis zu nem normalen Controlchange ne Menge Bytes pro Änderung mehr (und da fallen ja ne Menge an Werten an, wenn man das Pedal tritt) und das kann im Extremfall dann auch locker zu Delays führen, da die MIDIübertragung ja nicht grad flott ist und SySEx höchste Priorität hat. Also grundsätzlich halte ich da SysEx dafür eher für suboptimal und würde daher eher versuchen ne andere Lösung (ohne SysEX) zu finden.


lch wollts nur mal sagen:altweise:


Is ja auf der anderen Seite aber mal ein schönes "Experiment" :D
So ne Box wär für mich wohl auch ein schönes Spielzeug..is mir aber zu teuer und das meiste kann ich auch per Software bzw DAW oder am Keyboard machen...nur bei Sysex wirds da eng..das könnte ich gut für meinen Integra 7 brauchen für einfache Änderungen ohne da immer den Editor bemühen zu müssen. und ganze Sets von Änderungen mit einem einzigen Controllertastendruck auszulösen.
Gibts da evtl was günstiges oder Free als Software? Evtl sogar als VST in die DAW einbindbar?
 
AAAlsoooo:

00 hat die Checksum 5B
01 hat die Checksum 5A

dann geht das tatsächlich kontinuierlich rückwärts bis 5B.
Der String mit dem YY Wert 5B hat ein byte weniger (Abschluss 7F kommt ein byte früher).
Dann geht es weiter

5C hat die Checksum 7F
5D hat die Checksum 7E

dann geht das tatsächlich kontinuierlich rückwärts bis

7F hat die Checksum 5C.

Damit ist die Reihe zwar klar, aber ich habe immernoch noch das Programmierproblem.
Ich schicke Dir mal die rtf Datei mit, die man in die Software laden kann.

Bis Setting 18 geht es nur um die Taster.
In 21 habe ich YY in V1 gespeichert von 0-90.
In 21 habe ich YY in V2 gespeichert von 91-127

Das dürfte vielleicht richtig sein. Aber nun?
Nun muß diese Variable invertiert werden.
Dann muß die invertierte Variable in den zu mappenden Sysex String eingefügt werden.

Man kann zwar Y invertieren, aber nicht die Variable selbst.
Heißt das, dass man zuerst Y invertieren muß ( in 2 Blöcken) und dann eine Abzweigung der Schritte vornimmt, die nur dazu dient, die richtigen Variablen zu erzeugen?
boah... keinen Schimmer.
 

Anhänge

  • uwe_FCB_1010_FR8X_variablen_test.rtf
    7,4 KB · Aufrufe: 154
Nun muß diese Variable invertiert werden.
Dann muß die invertierte Variable in den zu mappenden Sysex String eingefügt werden.

YY soll die Checksumme werden.

Mit V1 oder V2 darf gar nix passieren, ausser dass sie zwischengespeichert werden, weil sie eben nicht manipulierbar sind,...die sichern nur den Wert der vom Controller kam...hatte ich ja schon geschrieben.

Also V1 oder V2 muss VOR YY im SysExstring kommen...anders kanns nicht gehen.

YY muss also als letztes Byte vor F7 stehen.

Übrigens...hab ganz vergessen dass man ja auch 2 Variablen nutzen kann wenn man sowieso auf 2 verschiedenen Wegen die Checksumme errechnen muss. Das könnte die Sache erleichtern.

Bist du sicher dass der Footcontroller der richtige CC ist? Ich hätte jetzt auf Expression gesetzt.

Naja..egal:


Der Weg müsste sein:

1.YY auslesen
Wenn yy 0-91 (91 erscheint mir die richtige Grenze zu sein) ist wird in V1 gespeichert (weiter mit Schritt 2A )...andernfalls in V2 (weiter mit Schritt 2B)

2A Die Range 0 - 91 für YY wird in die Range 91 - 0 umgewandelt...und SysEx mit V1 als Wert und yy als Ccheksumme ausgeführt.

2B Die Range 92-127 wird in die Range 127 - 92 umgewandelt ..und SysEx mit V2 als Wert und yy als CHecksumme ausgeführt.

Das müsste sich mithilfe der Sequenzen irgendwie machen lassen. Eine Sequenz wäre dann immer 2- stufig: Schritt 1 = speichern von yy in Variable und Ranges anpassen. Schritt 2 = Befehle auf sysex mappen und dort Variable (als Wert) und YY (als Checksum) eintragen.

Wichtig ist dass yy seinen Wert nicht verliert oder ändert zwischen Schritt 1 und Schritt 2 durch erneute Eingaben per Controller und genau da ist der Haken....wenn dem so sein sollte funzt das ganze nicht....oder nur teilweise....oder es wäre vllt nur möglich den Controller von Wert 0 -92 einzusetzen. Das kann man nur durch ausprobieren rausfinden.

Was mir nicht einleuchtet ist, dass bei Wert 5b bei dir anscheinend die Checksumme wegfällt? Also ne CHecksumme 0 gibt es nicht? Hmmm..vllt ist das nur optional, dass das weggelassen wird um das eine Byte zu sparen. Wenn nicht gibts ja die Möglichkeit diesen Sonderfall auch noch mit nem eigenen Sysexbefehl zu beglücken...die Ranges aus 2A müssten dann angepasst werden. Vllt wird aber eine Checksumme 0 trotzdem akzeptiert...oder der gesamte Befehl einfach nur ignoriert , was bedeuten würde dass dir nur dieser eine Wert durch die Lappen geht...was nicht weiter auffallen dürfte denke ich.
 
Ja, bei mir ist 4 (Foot) der richtige CC#.

Ja, mit den Variablen kann man nichts anstellen, das habe ich inzwischen auch schon gemerkt.
smil470009513826a.gif
Also ist schon klar, dass YY verbogen werden muß, um V1 und V2 zu erzeugen.
Nur, wird YY dann nicht auch invertiert ausgegeben? Das wäre fatal.

Außerdem, ich darf doch das Format des Sysex Strings nicht verändern, sonst kommt der Klangerzeuger nicht mehr damit klar. Oder meintest Du die Reihenfolge der Sequenzen (der Setting Nummer)?
 
Ich hab noch einiges nacheditiert oben....


Also ist schon klar, dass YY verbogen werden muß, um V1 und V2 zu erzeugen.

Falsch. YY darf eben nicht verbogen werden bevor es gespeichert ist. DIe Variablen werden aus genau dem Grund benutzt damit man sie später anstatt YY in den SysEXstring einsetzen kann und mit yy dann andere Dinge anstellen kann...zb. die Checksumme bilden.



Nur, wird YY dann nicht auch invertiert ausgegeben? Das wäre fatal.

Yy soll die Checksumme werden..also MUSS der wert verbogen werden.

Das macht auch nix weil yy ja vorher gespeichert wurde...der Wert liegt also in einer Variablen auf Eis bis diese im SyExstring eingesetzt wird. Und zwar an der Stelle wo der Controllerwert einzutragen ist (also da wo du immer denkst das da unbedingt yy hin müsste...muss es aber nicht)...yy brauchst du für die Checksumme... mit dem Eingangswert hat YY nach der Umwandlung nichts mehr zu tun. Diese Zweckentfremdung ist gewollt und nötig wenn das alles klappen soll.

Das ist ja der ganze Zweck der Geschichte....wenn das aus irgendeinem Grund nicht geht ...oder nicht über 2 Schritte hinweg...dann isses ein Problem....aber bisher hängst du anscheinend noch in der Vorstellung fest dass yy immer nur als eigentlicher Controllerwert in den SysEX eingesetzt werden muss... und das seh ich anders. Probier es einfach aus und denk nicht soviel :D:D:D


Ist wichtig, dass du das verstehst, dass YY keine feste "Platzreservierung" im SysEx String hat. :)
 
Außerdem, ich darf doch das Format des Sysex Strings nicht verändern, sonst kommt der Klangerzeuger nicht mehr damit klar.

Wer sagt das? Eintragen kann ich es zumindest so ohne dass das Programm meckert.
Das steh nirgends dass YY immer nur den Wert repräsentieren darf der auch reingekommen ist....ansonsten wären die Variablen ja auch sinnlos. Der SysExbefehl weiss nix davon woher die Werte kommen...und der Eventprozessor ersetzt einfach nur einen Code (also "YY" oder "V1") durch Zahlen.
Die Verwendung des Platzhalters ändert nicht das Format des SysExStrings. Die Codes stehen an Stellen die änderbar sind (Wert und Checksumme)...und der Eventprocessor ist "dumm"...der weiss gar nicht was der SysEx tut..der macht nix gross anders als Suchen und ersetzen in ner Textverarbeitung.....genau das wäre auszunutzen.
 
Ahh,

Y wird in die V1 umgeleitet und kommt an die Position des ursprünglichen Y.
Y wird verbogen und taucht als Checksum im String auf.

Ja - das könnte gehen.
Du hast mir ein Y für ein V vorgemacht
smil451c757f8273e.gif
.

Probiere es morgen, jetzt habe ich zumindest eine Idee.
Danke Dir!
smil47c08a19019a4.gif
 
Du hast mir ein Y für ein V vorgemacht

Die ganze Zeit hab ich das schon versucht zu erklären...das dauert aber bei dir bis das durchkommt :D

Ja nee is klar...is ne ganz schön abstrakte Geschichte...ich hab hier mehrmals hier gesessen und war mir selber nicht mehr ganz klar was ich eigentlich wollte :)

Muss man halt so Stück für Stück verinnerlichen.
 
Die Grenze liegt übrigens doch bei 91...so wie du es schon geschrieben hattest..hab mich da verhaun...weiss auch nicht wie ich immer drauf komme dass B = 12 wäre:schaem:

Allerdings pack ich die 91 noch mit in die 1. Range

Also Ranges 0-91 auf 91-0
(wenn die 91 Ärger macht weil da ja bei deinem Versuch ein Byte verursacht ist müsste man evtl dafür nen Extra Sysex bauen und die Ranges dürfen dann nur bis 90 gehen..ich würds aber erstmal so versuchen)

und

92-127 auf 127-92 setzen.

Habs oben auch nochmal richtig nacheditiert damits nicht verwirrt.

Und ich denke eine Variable tuts auch...müssen nicht 2 verschiedene sein, da sowieso nur der Eingangswert gespeichert wird und der ja immer gleich bleibt....der Übersichtlichkeit halber machts vllt aber doch Sinn.
 

Ähnliche Themen

Can
    • Danke
  • Artikel
Antworten
11
Aufrufe
50K
oove
oove
Watteschaf
Antworten
6
Aufrufe
2K
Watteschaf
Watteschaf

Neue Antworten


Oft gelesene Themen

Zurück
Oben