Roland System-8 owners: an attempt to reverse engineer its SysEx

[Electrolove]

I always wondered, can Roland System-8 handle sysex? The short answer is yes.

I started by sending a patch from the Roland System-8 VST editor to the System-8 hardware and at the same time I recorded all the messages with a MIDI Monitor. When you look in the MIDI Monitor, you see that there is a lot of handshake from the beginning. It stops after a while. There are a total of 111 (small) sysex messages to be sent for a patch. Once I had saved all the messages to be sent, I sent these messages back with SysEx Librarian. It works! The patch is sent to the System-8. I tried several times to change the patch on the hardware and then I sent. The patch name changes in the display. SUCCESS!

So what can be concluded from this? Yes System-8 can handle sysex but Roland won’t tell you how to do it. Roland should be ashamed. System-8 can do the same if you send a whole bank of 64 patches. The difference is that when the transfer is complete, System-8 starts a write process. If you just send one patch like I did now, it ends up in the edit buffer and disappears when you turn off the power. Much like most synths work.

I don’t know what all the sysex messages mean yet. Reverse engineering and plenty of time is required for that but… It’s nice to know that System-8 can actually handle sysex. Now you can save all your patches in a library and send them to System-8 when you need them and forget the SD card.

[NewIgnis]

can you find the very first message that asks the system-8 to send a patch ? Or the message the system-8 sends to the VST to request a patch?

[NewIgnis]

Forget my question: it rather looks there is no exchange of a program dump or program dump requests; but rather parameter changes are sent.

Let’s dive in a bit and like at hte first line

F0 41 10 00 00 7E 12 70 00 02 00 00 0E F7 look like a data transmission.
Here’s my first guess:

F0 sysex status
41 Roland
10 Device ID (changeable on the Sys8?)
00 model ID1
00 model ID2
7E model ID2
12 data set (= instruction)
70 MSB of requested parameter
00 middle 1 of requested parameter
02 middle 2 of requested parameter
00 LSB of requested parameter
00 data
0E checksum
F7

It doesn’t look good though only one byte is used for data. Perhaps the 70H is a format indicator: informing the format is “address + data”, whereas in other messages 03H appears which may indicate “start address + length + data”
In such case the address may only be 2 bytes, instead of 4:

F0 sysex status
41 Roland
10 Device ID (changeable on the Sys8?)
00 model ID1
00 model ID2
7E model ID2
12 data sent
70 data format type
00 MSB of requested parameter
02 LSB of requested parameter
00 data MSB
00 data LSB
0E checksum
F7

All I can think of for now it is : try to discover a parameter change; send the data, store the comms, then change 1 parameter and send the data again. Then have a program compare those 2 communications and check for differences. Once found try out the minimum and maximum of that parameter, and keep comparing so you see how the data changes… I’d say try filter freq and then filter resonance. Very often these ones are next to each other in a Sysex table, so it might help discover if the Sysex uses 2, 3 or 4 bytes for its address.
Also try changing the device ID on the system 8 (and in your VST, else they will not communicate-, and check if it is indeed the 3rd byte that changes.

Last: instead of 12H data set, I believe 11H = data request (roland standard). Data request messages seem to be always 17 bytes long. After 11H I assume the 4 first bytes is the starting address, and the next 4 bytes the length of the requested data. That seems to contradict my suggestion the addresses are only 2 bytes long…

[Electrolove]

Very interesting thoughts I will do some experiments as soon as I get time.

[Electrolove]

I have tested Cutoff and Resonance. More tests as soon as I have time.

Result for Resonance

Result for Cutoff

[NewIgnis]

The way you showed the transmissions in the first post is far more readable than in your last .
But anyways looks like the address in this case is 03 00 00 3A fgor the first parameter, and perhaps 03 00 00 3B for the second.

I believe a bit further on though you also see a checksum being changed. It’s followed by F7 what was to be expected.

By the way: also try intermediate values you you can compare if the hexa value corresponds to the one shown on the System-8. That way you’ll also know if the SysEx uses the same resolution as the synth in its user interface. Put the parameters on different values so you start recognizing fitler apart from resonance. Also try some other filter parameters, and check if they appear in the same SysEx message as the filter and resonance (then we’d know the sysex is not sending a parameter at a time but rather a set of parameters).

[Electrolove]

I just made a discovery. This sysex message is the only one needed to change the Cutoff and Resonance. In the top picture, the Cutoff value is 0. In the bottom picture, the Cutoff value is 59 decimal. The checksum is also different. It must be correctly calculated, otherwise the sysex message does not work, I have discovered. I do not know how to calculate the checksum yet.

As you can see in the lower picture, the Cutoff value is 03 0B. If you only use 3 and B = 3B, it will be 59 decimal.

It seems that System-8 can do a lot more than Roland wants to tell you.

Cutoff 0 and 59 decimal

Resonance 22 and 103 decimal

[Electrolove]

I’m starting to understand now how sysex works in System-8. There are 108 (maybe 109) sysex messages and a request for each. Each response can have multiple parameters. So in theory you could have all requests in Electra and receive the responses and map the parameters. But before that, I have to find out where all the parameters are. I already know that Filter Cutoff and Resonance are in message 17 of 108.

[Electrolove]

Here are all the sysex requests you need to get a patch from System-8. 108 requests (maybe 109).

[oldgearguy]

checksum appears to be: sum up all the bytes after the “7E 12” / “7E 11” AND it with 0x7F and subtract from 128
So in hex, take this chunk
7E 11 03 00 00 6C 00 00 00 14 7D F7

03h + 6Ch + 14h = 83h & 0x7F = 03h
3 + 108 + 20 = 131 AND’d with 127 = 3

Now take
80h - 03h = 7Dh
128 - 3 = 125

NOTE that this is my 30 second take on it. It would be wise to do some calculations on others strings to verify it.

[Electrolove]

Now I have made my first attempt to map the Cutoff parameter. If you look at the picture below, what I have done is correct. I set the Cutoff to 193 on System-8 and that’s the value I get when I request.

But my parameter is not set correctly. It’s not moving, right now the value is 0.

Can someone please tell me what I’m doing wrong?

[Foksadure]

Looks like the canonical SysEx checksum algorithm from Roland.

http://midi.teragonaudio.com/tutr/rolsysx.htm

When calculating the Checksum for a “Data Set 1”, you must add up the 4 address bytes and the data bytes. Then you divide by 128 and take the remainder. Finally, you subtract the remainder from 128. You should end up with a value of 128 or less if you did it correctly. This is the Checksum. If the Checksum is 128, then substitute a value of 0.

How to add Roland Checksum for a sendSysEx [Solved]

To actually calculate it, the standard is something like sum all the bytes in the array and truncate to 7 bits, or sum all the bytes and subtract from 256, or … The Roland manuals are usually pretty good about telling you somewhere how it’s done. Alternatively, if you have an editor like HexEdit, you can take a dump with a checksum and calculate various ways across the data bytes until you match what is there

It seems checksum value is ignored in more recent products (Jupiter-X/Xm Juno-X at least).

[NewIgnis]

You surely will not be able to send anything because the parameter is a #CC type. I rather expect it to be type SysEx or type Virtual (with SysEx commands behind it).

If the parameter is made to listen to a specific data set, then you must configure the header (ie the series of bytes after F0h) in the ‘Default Response’, for the E1 to be able to which of all those messages to listen. Looking at the screen, there is no header set yet. The header should at least contain everyting after F0h until (and including) the address of the data set it needs to find back. I think you’ll need byte 0 to 9 (as numbered in your screenshot).

[NewIgnis]

Hi Benny,

were you able to make some progress?

[Electrolove]

Hello. I haven’t had much time. Too much work taking up all my time right now. The last thing I’ve done is put all the patches into my own library program. From there I can send sysex to System-8. Works great.

[kris]

This looks like the standard Roland Sysex format. To decode, all we need is the list of submessages (their addresses and lengths) that the librarian needs to query from the device. the 0x11 is the request command, follwed by 3 byte address and 4 byte length IIRC. I am surprised your requests all have length 1 (0x00 0x00 0x00 0x01). You can query a whole block by putting in a different length value.

The generic Knobkraft Roland module I made should be able to deal with this - if we have a full patch download example from which we can peek the base addresses and their lengths.

[ambivalence]

hi there! have you made any progress? I think System-8 must have tons of similarities with TB-3 which is well known AIRA synth of the same era with many hidden controls. Maybe S8 also has a lot to offer.

Roland TB-3

Hi, I’m making a Roland TB-3 preset. I’ve got info on the unofficial SysEx for Firmware 1.1. However, if someone has the experience with using one of the existing editors for this Bass Synth, and got a feel for some of the more weird knobs what they actually seem to do or how they interact (like the Tune, Offset, Ring Mod, Cross Mod, certain FX parameters), let me know ! [image] [image]

By the way, I stumbled upon this project recently, maybe it will help:

GitHub - DrHardReset/RoMi: RoMi: Calculates SysEx MIDI messages for Roland...

[NewIgnis]

Hi I’m trying out some sysEx stuff, but I can’t get the System-8 to reply.

@Electrolove How was your System-8 connected when it replied you with sysEx ? USB or MIDI ? What SYSTEM or other settings did you have to make ?
I find it curious that your second byte seems to be 0x10 (so equalling 16), while my system-8 doesn’t allow me to set this value as deviceID. The range I get is 17-32, but whatever ID I try, I can’t get it to reply.
The checkSum equals the way I set it up in the TB-3 preset, so that looks the same as in your examples.

[NewIgnis]

@Electrolove can you publish your preset, so I can see what you did exactly in the tests?

[NewIgnis]

Success! I’ve managed to establish bidirectional communication with sysEx

What we learned so far:

SysEx works only on USB port-2 !
On the internet someone mentioned that the (also Aira based) TR-6S is only responding to sysEx on USB and only via the ctrl-port.
In case of System-8 there is only port 1 and 2, and I was connected via port 1. Sure enough, port 2 is replying to sysEx but it doesn’t transmit midi CC though. Via a MIO XL I can of course always merge the two USB ports, so that is an issue to resolve later on.

System-8 request command

• 41h (Roland)
• deviceID
• 0h, 0h, 7Eh (system-8)
• 11h (request)
• 4 bytes for start address
• 4 bytes for length
• Roland checksum

There is no need to request small chunks but System-8 may reply in smaller parts

Proof below : I requested a dump starting at 03h,0h,0h,0h and 3 groups of 256 long (0h;0h,03h,0h).

The system-8 responded with 12 answers. It looks like it doesn’t send back unused parts

What about parsing the responses?
For parsing effectively, I’ll have to first make a generic callback function that parses any answer of any length and stores it in an array. From that array I’ll make a ‘previous copy’ so the E1 can tell me where data changed by comparing. That way I can pinpoint what controls on the System-8 is stored in which bytes of the replies.
So that way byte detection and parsing can start.

Parameter changes
The same command structure can be used to sent parameter changes back.
I succesfully controlled Cutoff with a 0..255 value range, using the send command structure in sysEx:

• 41h (Roland)
• deviceID
• 0h, 0h, 7Eh (system-8)
• 12h (send)
• 4 bytes for start address (in this case 03h 0h 0h 3Ah)
• x bytes as payload (in this case 2 bytes , each 0..0F)
• Roland checksum

Not sure I’ll have time tomorrow, but indeed the System-8 may be giving up its secrets.

EDIT 30/3: I’ve been able to research all upper controls of the System-8 (from LFO to Effects). 64 parameters are identified. 2 controls as yet undiscovered.
EDIT 31/3 : some 25 parameters I can’t find yet, mainly the effects parameters from the menu, F velo sens and A velo sens. 119 other patch parameters are discovered.
EDIT 5/4 : I found the System-8 not always being responsive to parameter changes. For large continuous controls this is less of an issue, but for small range controls (like coarse tue), option lists or on/off buttons it is really annoying. Moreover I haven’t cracked the code on sending parameter changes outside the (in hex) 3,0,0,0 to 3,0,0,7F range. Fortunately most of the controls outside that range and most of the small range controls seems to have an alternative CC control number. I thus use SysEx wide range controls 0-255 whenever possible and CC for the rest…