Look here Roland System-8 owners! An attempt to reverse engineer unknown SysEx communication

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.

1 Like

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?

1 Like

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…

1 Like

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

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

Result for Resonance

Result for Cutoff

The way you showed the transmissions in the first post is far more readable than in your last :slight_smile: .
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).

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

1 Like

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.

1 Like

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

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.

2 Likes

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?

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.

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

2 Likes

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).