Take the 2-minute tour ×
Sound Design Stack Exchange is a question and answer site for sound engineers, producers, editors, and enthusiasts. It's 100% free, no registration required.

I have recently put my old Yamaha CS1x back into service and realised that the world has moved on when it comes to the software support for this blue beast.

So I was thinking of writing a software tool for editing patches and I quickly ran into trouble. There is to my knowledge no documentation on the SysEx patch dump format available.

What is the most effective and least error prone way to reverse engineer the SysEx patch dump format?

Has anyone done something similar, and what approach worked best?

share|improve this question

migrated from avp.stackexchange.com Jan 24 at 18:30

This question came from our site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation.

2 Answers 2

up vote 2 down vote accepted

The short (painful) answer is to start with the default patch, change parameters one at a time, and look through the hex dumps to see what changed in the output. If you have a list of parameters that you care about editing most, start with those, because then you get something up and running quickly that has partial support. Then you can add more parameters over time as you identify them.

Specifically, to start:

  1. Dump out the default patch.
  2. Change a single parameter, then dump that out.
  3. Use the default patch as a template to create an editor that lets you select either the default value, or what you changed that value to.
  4. Change that parameter to its max/min values, and dump out patches for those. Hopefully that will give you enough insight to allow full editing of a single parameter.
  5. Repeat as needed.

Some parameters may be bit fields, some may be one or two bytes, etc. Having documentation for the general sysex format will be helpful, because some small parts will be dictated by that spec (as opposed to Yamaha specific). If you can find documentation for some other piece of Yamaha gear (esp. something released in the same time period), it may give you some insight into how they tend to design formats as a company. If you can't find something from Yamaha, even reading through documentation of the sysex format for some other company may help.

For example, taking a look at the hexdump of a couple patches from the Planet Groove archive, we can identify a few things just by inspection.

Yamaha Patch Hex Dump

From looking at the midi spec, and both of these patches, it looks like all the patches are going to begin with 0xf0, and end with 0xf7. In addition, the 0x43 (which follows the 0xf0) is Yamaha's Manufacturer ID.

Table 2: Expanded Status Bytes List

Binary |Hex| Dec    Function              2nd Byte   3rd Byte
11110000= F0= 240   System Exclusive      **         ** 
11110111= F7= 247   End of SysEx (EOX)    none       none

** Note: System Exclusive (data dump) 2nd byte= Vendor ID 
(or Universal Exclusive) followed by more data bytes and 
ending with EOX.

Even though this is only two example patches, there's a good chance that the patch format always has seven sysex messages in sequence (each starting/ending with 0xf0 0x43 0x00 0x4b 0x00 / 0xf7), that are always the same length. The task is just to follow the above procedure to reverse the individual parameters.

A few other observations:

  • It looks like the first couple bytes after each header are related to the length of each message (i.e.0x2e, 0x17, 0x09, 0x29, 0x29, 0x29, 0x29, each followed by 0x60), but I'm not sure exactly what the relationship is. If the fields always do stay the same length, the good news is that it doesn't really matter.

  • It looks like the patch name is always eight ASCII characters, and is always in the same place, so the first bare-bones version of the editor could just allow editing that.

  • One of the fields in each message may be a checksum for that message. If you try creating an editor for the patch name, and the resulting patch doesn't load, that may be what the issue is. If that happens, to test it further, try changing some binary parameter in the default patch (i.e. an on/off option), and see if only one localized bit/byte changes, or if two [non-localized] bytes change. If there is a checksum, finding Yamaha documentation for some other piece of gear is probably your best bet for figuring it out. Barring that, there's a description of a Roland checksum in this document [pdf], which at least will get you started on attempting to guess how it works.

The whole process could be relatively easy, or it could be brutal, but this is a good way to get started.

share|improve this answer
This may or may not have some useful info as well: search.cpan.org/~hayashi/Win32API-MIDI-0.05/MIDI/SysEX/… –  datageist Nov 14 '11 at 4:37
Very insightful post and loads of valuable information. Many thanks. –  Mats Wiklander Nov 14 '11 at 9:02

Don't bother reverse engineering. Just look at the end of your owners manual. It's all there.

That manual is a must-have if you plan on writing an editor. Google for "cs1x owners manual". I just did it, and this was the first that popped up: http://www.synthfool.com/docs/Yamaha/CS_Series/Yamaha%20CS-1X%20Owners%20Manual.pdf

Note: I don't own a cs1x, but I'm the author of editors for various Yamaha synths (YS100, B200, DX21, FS1-R). Yamaha always documents about every bit that can be controlled. You sometimes just need some minor reverse engineering to find out the exact meaning of values to convert them to values that are easy to understand for users (Hertz, Decibel, ...).

share|improve this answer
The manual is also available from Yamaha.com. –  ObscureRobot Apr 23 '12 at 4:38
I'm curious, though, where you found the Sysex documentation for the FS1R? The user's manual is unusually light for Yamaha, having even less technical information than the DX200's manual. –  ObscureRobot Apr 23 '12 at 4:42
I see that the sysex doc for the FS1R is available on yamaha.co.jp, but not the US site. –  ObscureRobot May 28 '12 at 2:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.