[Preset ] Roland SE-02 (V2)

Instruments
7

worst case is someone takes the time to stick a MIDI Monitor in between the SE-02 editor and the hardware and captures/maps out everything being sent and received.

Roland in the past has been very helpful when I contacted their service centers for parts, manuals, etc. Not sure what they are like today though.

8

Wrote SE too, will let you know if I hear back!

1 Like
9

I have the SE-02 editor from Studio Electronics, so I thought it might be worthwhile monitoring the traffic going on between the two of them. The editor only finds the SE-02 via USB, any one has an idea how to intercept USB MIDI data from editor into SE-02 (MIDI thru won’t work, I tried that, but the editor won’t connect with the SE-02 if midi thru or MIDI echo is on)? I’m pretty sure it is MIDI !

The other way round is easier, by monitoring what came out of the DIN MIDI OUT of the SE-02.

Here’s what I found: if the editor requests a patch from the SE-2 , the SE-2 responds in 4 chunks:
3 times 78 Bytes, and one time 62.

image

The header starts as follows
F0
41 = Roland
10 = Device ID (if the SE-02 follows Roland standards)
00 00 00 44 will be the Model ID SE-02 (Roland typically adds one or more 00H’s in front of the Model ID to ‘differentiate various things’ (found in D-05 MIDI manual)
12 is usually a Roland command ID (DT1) for transfer while 11= RQ1 is the counterpartner for Request.
So my guess is where are indeed looking at a data transfer where shortly after 12 is the body , consisting of an address then data and it ends with a checksum.

When the SE02 editor is finding the SE-02 for the first time, this is what the SE-02 responds :
image

Last check: retrieving the first patch of the first bank, for which I know it is called INBOUND . I believe the names to be 16 digits long. The name is in the second to last row: 49 6E 62 6F 75 6E 64 and a bunch of zero’s stand for “Inbound”
image

Hope this has some value for someone somewhere :slight_smile:

10

Can you select the output in the editor?
Because then you can use loopbe midi as a virtual midi connection to route traffic thru midi-ox

2 Likes
11

Thanks. Ports can be selected.
I’ll try it out later in the week. I haven’t used loopbe yet, but I know more or less what it is, so this might work.

1 Like
12

The show can go on. The requests were intercepted.

These are the 2 requests the SE-02 editor asks the SE-02 when the software starts up:

image

I expect the answers at least contain the following data:

  • roland firmware version
  • midi channel
  • midi thru setting
    (in my case channel is 8, version = 1.11 and MIDI thru is off)

Whatever patch I ask the editor to retrieve it sends the same 4 commands, so it looks like it is indeed requesting the edit buffer of the SE-02.
Requests are:
F0 41 10 00 00 00 44 11 05 00 00 00 00 00 00 40 3B F7 (response = 78 bytes)
F0 41 10 00 00 00 44 11 05 00 00 40 00 00 00 40 7B F7 (response = 78 bytes)
F0 41 10 00 00 00 44 11 05 00 01 00 00 00 00 40 3A F7 (response = 78 bytes)
F0 41 10 00 00 00 44 11 05 00 01 40 00 00 00 30 0A F7 (response = 62 bytes)

In the response the first 12 bytes (including F0) are the same except 11 that turns into 12.
image

With this info, every one with an SE-2 might consider experimenting. Happy reverse engineering !

1 Like
13

I have a new challenge here: the transmission in the Roland SysEx does not correspond with the transmission of the CC changes.
An example: SysEx transmits VCO1 range as a value between 0 and 5. But the CC controller 16 for the same purpose transmits the values 0,25, 51, 76, 102 , 127. Is there a clever way I can have the SysEx values correspond with the order of the items in the control list, rather than with the value I gave to each list item?
Any other ideas?
How I can best correlate 0 into 0, 1 into 25, 2 into 51 using the patch editor?

14

Well, in LUA, a formula like:

ccnum = sysexnum × 25
if sysexnum > 1 then
ccnum = ccnum + 1
end

if sysexnum > 2 then
ccnum = ccnum + 1
end

Might work

15

Not there yet.

Imagine I built a function stretchValues() based on @oldgearguy 's formula.
It takes a value 0…5 and returns 0…127.

What I need, is to find a way to insert this function:

  {
    "type": "function",
    "name": "stretchValues"
  },

somewhere in the patch conversion of parameter 22:

        {
            "parameterNumber": 22,
            "type": "cc7",
            "byte": 62,
            "bitWidth": 3,
            "byteBitPosition": 0,
            "parameterBitPosition": 0
          },

In other words the received 0…5 from the 3 bits of byte 62 need to get converted via stretchValues() and the resulting 0…127 is to be stored in parameterNumber 22.

How do I construct such json syntax in the responses section?

(By the way @oldgearguy, thanks for the tip of monitoring the traffic between SE-02 and its editor. I overlooked it the first time you suggested it, but subconsciously I think you planted that idea in my head anyways)

16

Hi, I’ve just implemented patch parsing on the SE-02. It now should retrieve the settings from the SE-02 if you use the ‘patch request’ pad, or the left upper button of the E1. This is the “pick-up” mode you were looking for.

Be aware: only the fader controls should work fine for now. The list controls will change also but retrieve the wrong value from the patch request as yet. I need some more feedback from the guys on this forum before I can mend it.

@moullinex Can you try it out? It should drastically improve smooth sound transitions when playing live.

18

Hey @NewIgnis
Would you mind sharing your knowledge about SE-02 SysEx with the world? For posterity / in open source spirit.
This investigative thread of yours is probably the only real source of info about SE-02 specifics on the Internet.
I don’t own Electra One so can’t even download your work in order to try reverse-engineering it.
It would be great to document the meaning of various elements of SE-02 SysEx, especially the patch-related messages.

1 Like
19

No problem, but I’ve moved on to other synth investigations since. Tell me specifically what you are looking for. Also, you can actually check my work even if you do not have an Electra One. If you use the Electra One editor, you can ‘read’ my preset and check the SysEx in it yourself.

It’s the great thing about Electra One: the work we share is open to everyone.

1 Like
20

@NewIgnis I would like to document what do different parts of SE-02 SysEx mean.

Whatever patch I ask the editor to retrieve it sends the same 4 commands, so it looks like it is indeed requesting the edit buffer of the SE-02.

This part is of particular interest to me. Have you figured out the meaning of these 4 commands / responses?
Do you know on a byte-level how do these correspond to patch values (specific knobs/switches)?

21

I am not sure if @NewIgnis used that, but E1 allows users to reverse engineer the incoming SysEx messages quite easily. One can change the parameters on the synth and observe changes in the coming SysEx patch data.

22

Is there some quick instructions or video explaining this in more detail?

If it’s already in the docs somewhere, a link will be sufficient. :slight_smile:

I will be in need of this to reverse engineer some undocumented data/commands.

23

Do install the Electra One editor, so you can get to the details yourself.

Here’s some info:

Value conversion SysEx versus Midi CC

  • most parameters are CC controllable and they are straightforward
  • some selection lists receive their values via SysEx as between 0…x where x equals the amount of options minus 1. Between when sending them via CC, these values are spread over the entire CC range of 0…127. To resolve that , the preset uses the SysEx values (so they can be understood when received via SysEx) to store them, but then multiply the results when changed in real time on the Electra One. This is done with the lua functions in the preset, I called ‘choicen’.
  • there were some other particular conversions to do to keep this concept , i.e. storing values as received in SysEx, but send them converted into CC values when tweaking.
  • the other way around, when CC messages are received by the E1 I had to convert them back into the SysEx values before storing them in the parameterMap. I used “midi.onControlChange” for this purpose. In the preset editor you will find what controls needed what kind of conversion.

Patch Parsing

Each time a Program Change is executed , I sent 4 SysEx messages to collect the current patch dump

   midi.sendSysex (devPort, {0x41,  0x10, 0x00, 0x00, 0x00, 0x44, 0x11, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x3B})
   midi.sendSysex (devPort, {0x41,  0x10, 0x00, 0x00, 0x00, 0x44, 0x11, 0x05, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x40, 0x7B})
   midi.sendSysex (devPort, {0x41,  0x10, 0x00, 0x00, 0x00, 0x44, 0x11, 0x05, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x40, 0x3A})
   midi.sendSysex (devPort, {0x41,  0x10, 0x00, 0x00, 0x00, 0x44, 0x11, 0x05, 0x00, 0x01, 0x40, 0x00, 0x00, 0x00, 0x30, 0x0A})

The first three messages deliver a response in which parameters are found , necessary for the Patch. The fourth message was obsolote, I found afterwards. That may be for instance because it contained data for the sequencer which I didn’t parse.

The exact parsing can be found back in the json editor of the Electra 1.
Be careful: Roland did not implement anything simple like a 1 byte = 1 parameter philosophy. Very often 1 parameter was composed of bits from 2 different subsequent bytes.

Example: parameter 81 "Contour Sensitivity’

You will find it back as a composition of 7 bits, as a response against the first SysEx request:

  • the first 4 bits are found at position 0 in byte 9
  • the next 3 bits are found at position 0 in byte 8

image

image

Be mindful

  • page 2 “Modulation & FX” page has 4 (hidden) buttons: each of them fires one of the 4 SysEx requests separately. That made it easier during reverse engineering to perform the parse mapping.
  • page 3 “Transpose” of the preset : that is not a SE-02 specific thing, but an add-on to the SE-02 coming from the E1 itself , that controls the SE-02’s transpose setting.
24

The reverse engineering was done using three - four tools:

  • The SE-02 PC editor, which communicatis with the SE-02 via MIDI, so this had to contain the necessary SysEx and CC traffic. This was necessary to get to know the SysEx commands.
  • Midi-Ox as MIDI monitor tool on the PC so to monitor any in- or outbound traffic. This to make sure responses were indeed delivered, and transmissions were successful.
  • No sure about this one, but I might have used loopbe as well, to allow intercepting the traffic as a kind of man-in-the-middle witness.
  • Last but not least, @martin 's device editor tool inside the E1 editor, that allowed to detect changes on bit level in the SysEx reponses when using “MIDI-learn”. What I did to investigate usually is first request a SysEx response, then set 4 or 5 parameters to very specific settings, and re-request the SysEx response. The E1 editor then shows you what bits in the answers were changed. After a while you get to grasp the logic (if any) in the responses.
25

Thanks @NewIgnis this is great. I also managed to grab raw JSON from the online editor.

1 Like
26

That brings me onto an idea. I’m just on the verge of adding patch parsing to a preset (the Novation A-station).

We’ll do it in a separate topic as a kind of tutorial.

27

BTW the fourth response includes the patch name. When you convert from hex to ASCII letters you get the name.

1 Like