Roland checksum – how to

[dnaldoog]

Hi Human Fly,

Me too – have been away from ctrlr for a bit. Using the quote tag makes it look like you wrote that, but of course it was a quote from that website, but I had based my original code on that website’s explanation. I’ve looked at the explanation of checksums in three manuals and none mention that adjustment. So if you are still working on the D-110 it will help you.

Regards.

[human fly]

i’m going to try out your checksummer.
warm-up session, to get started again. need to have
another look at that D-110 again…

i took what you taught me a few months back with
_G[ (blabla) ] and other stuff quite long way with
a subsequent project, where i wanted to try something
different: have a look at the most recent RX7 pAnel,
WhICh (sorry got something weird with keyboard going on)
re-uses the same modulators for many instances of the
same thing (all 99 drum voices, all 240 key assignments).
a lot of bodged ideas going on there, nearly knocked into
shape, not yet reached sending a sysex message to the unit
(which isn’t here now atm…).

ha: i want to claim it’s ‘innovative’, in terms of Ctrlr use
hitherto !! (lol..) -and it does sort of work, which is the
crazy thing… next step is going to be quite tricky and
need a workaround that i haven’t thought of anything for yet.
had some life complications recently so i had to set it aside.

[dnaldoog]

life complications – yes! Know the feeling as do we all I suppose.

So I think that a checksum is the inverse of a number between 0-127 (which is 128 numbers)
(Second Hex is Checksum)

0x00 = 00
0x01 = 7F**
0x02 = 7E
0x40 = 40 64 dec = 128/2
0x41 = 3F 63 dec
0x7F = 01 127 dec ** so we are back to the beginning
0x80 = 00 not checksum 128 (0x80) 128 dec (if this was 0x80 it would be strange)
0x81 = 7F 129 dec and so the cycle repeats
0xC0 = 40 192 dec which is 128+64

so you can see 128 cannot have 128 (0x80) as a checksum

I think I finally get it!

[human fly]

umm … where does that hex come from?
you can’t have 80h, it stops at 7F and then the MSB changes. 😉
(i remember making this mistake at some point)

checksums aren’t actually that horrifying. i think the 2nd eddie lotter
method is by far the easiest. one to go for. in context of Ctrlr, yes
it’s more difficult perhaps, if you’re building the message on the fly.

but essentially, if you’re making a mixer map or whatever, you just figure
out the first checksum in a series, at midi value ‘0’, and then the checksum
decrements (in hex, hence the old adage about the joys of ‘counting backwards
in hex’) as either parameter number or value increment.

if you see what i mean:
-say you have a list of your parameters, all set to midi value ‘0’:
you figure out the checksum of parameter #1, and that’s the only one
you have to calculate, because you can now zoom down the list filling
in all the follwing checksums sequentially.

same thing if it’s just one parameter, and you go through the value from
zero upwards.

*obvious really* – and you can cheat with midiox like that too, if you’re
feeling stuck, and are getting something wrong, such as when you have to
addition addresses for a roland multitimbral unit. – the D-110, for example
is terribly opaque about its different memory areas(see manual) and at times
it’s hard to know whether to be using the 02h or 04h prefixed address (can’t
exactly remember what it was) – so i did cheat by getting the unit to send
a message, and working it out from that.

little anecdotal aside: the D-110 is quite interesting in that it has (i’ve
said this before) separate memory areas for each part, for both ‘tone'(preset)
and ‘timbre'(..’performance envelope?’), and then also for the patch. meaning
that you can put edits onto all parts without saving, and all remain active.
you can even switch the unit off and back on again, and your edits will be
unchanged. it does however mean that any time you want to hard-save your
multi setup, you have to do all the saves: one for each tone edited, one for
each timbre edited, and then the patch(multi). (can this be true? i have not put it
to the test. i’m realising it might not be possible from the panel. but i’m pretty
sure it could be via software)

[Quimquim]

human fly is the calculation is for sending a message? If so ctrlr can do it automaticly by using Zy in the message.
y = the number of bytes before Z to include in the calculation. Here below the 5 bytes
(18 00 2A 4A and the xx value) will be included in the calculation.
xx = is the modulator value if it’s not a fixed message

SysEx,Direct,Direct,-1,-1,F0 41 10 00 00 54 12 18 00 2A 4A xx z5 F7

Found that trick by digging in a panel.

(Another example of things to put in a tutorial section, like suggested else where!!!)

Stay tuned. Quimquim

[human fly]

tuned in, quimquim 😉
yep am onto that one.

i will be confronted with an interesting situation if
i persevere with current project where sysex messages
will have to be composed on the fly – so it won’t be
able to use that box or the built-in checksum calculator.

hey, i can’t code and don’t know wtf i’m doing 🙂 but it
has been interesting to try to build the RX7 panel using
one set of modulators for many parameters. which sort-of
works with some reliability now.

you guys are welcome to help out with ideas if you want,
i don’t feel at all ‘proprietary’ on this, as it is
experimental. the code is.. a bit messy on first view,
but in fact it is fairly ‘rigourously'(…) ordered, and i’m
happy to give pointers on how it hangs together.

um but the machine in question doesn’t need a checksum.
*however*: if it did, or if i try the same technique
to do an 8 part multitimbral module – such as the D-110 –
then it would be necessary to build the sysex message
without the onboard Ctrlr sysex box (where zY -zn?- happens)

now i’m curious as to how dasfaker did his latest JV
editor…

[dnaldoog]

Hi Quimquim,

Quimquim wrote:

…If so ctrlr can do it automaticly by using Zy in the message.

…except when you need to build a sysex string dynamically then you need your own function to create the checksum…but wait!! you can in fact create a sysex message with xx Z5 dynamically and write it to the modulator by writing to “midiMessageSysExFormula“:

valA=1
valB=76
myMess=”F0 41 10 6A 12 03 00 “..string.format(“%02X”,valA)..” “..string.format(“%02X”,valB)..” xx z5 F7″
x=panel:getModulatorByName(“SLIDER1”):getComponent()
x:getMidiMessage():setPropertyString(“midiMessageSysExFormula”,myMess)

[Quimquim]

The advantage of the xx Zy formula is that you can put it in a controler ( ex: my keyboard equaliser gain value ) I put it in a slider and when the keyboard send the controler change, the slider react to it exactly like any other CC controler and I also can control this parameter dynamically whit the slider.

Naturally it work with only one variable value in the message. For multiple variables we’ll have to proceed the dnal’s way or, If what we want to modify is not a continuous controler it would be possible to put the different combination of values in a combo to select the ones to be included in the message. A bit like I do to send multi messages tone change to my keyboard. I put the values in a combo and then build the msb lsb pc messages from the values in the combo as…
NaturalPiano = 000400
SuperiorPian = 2F0400
ClassicPiano = 000401
I display the left part to a display on my panel and use the xxyyzz after the = to build the msb lsb pc tone change messages. Then just have to select the to send in the combo list.

Possible to process the same way to build multi variables Sysex messages.

The my send tone change method attached.

Have fun!!!!

Attachments:

You must be logged in to view attached files.

Stay tuned. Quimquim

[Author]

Posts