Fizmo Project progress report

About two years ago, I launched something called the Fizmo Project, which was an attempt to decode the Ensoniq Fizmo's patch dump format and identify where all of the parameters are. I've posted on it here before, but after working on it for a while, I gave up in frustration because identifying individual parameters in the 3097-byte-long patch dump proved to be quite a challenge. However, that wasn't the only problem; the other issue was that none of the changes that I could see in the patch dumps seemed to correlate to the actual values of the parameters in any way that made sense.

Well, last summer I finally devised a way to partially automate the process, using the Unix "tr" and "diff" tools in Mac OSX. With this, I can now compare two dumps and it will find all the differences and list them out for me. And the mystery started unraveling. Some info: The patch memory structure on the Fizmo is a bit unorthodox. It stores 64 "sounds", each of which consists of two layers. Each layer is basically one complete sound path, with a Transwave oscillator, a filter, a VCA, three envelope generators, an LFO, and some other modifier sources. Within a sound, the two layers can be overlaid or split across the keyboard. Each sound has its own name.

The Fizmo also stores 64 patches, each of which consists of a combination of the 64 sounds, plus a few other parameters. A sound can appear in more than one patch. Each patch has its own name, in addition to the names of the four sounds selected in the patch. A patch also contains a global effect; it can choose one of about 20 available effects, and each effect has its own set of parameters.

When you do a patch dump, you get a big ugly lump of 3097 bytes. There's a header area, followed by four blocks of 640 bytes, one for each sound loaded into the patch. All four sound blocks have the same layout. The parameter layout is really, really ugly. Don't listen to anybody who tells you that it is similar to the layout used by the Ensoniq MR and ZR models. Not even close. Very few parameters start or end on a byte boundary; most span across bytes, and most bytes that contain any data at all contain pieces of two parameters. There seem to be unused bits and bytes scattered about everywhere at random. Some parameters which take up seven bits go from 0-127, like you'd expect, but others only range from 0-100. The character strings which contain the patch and sound names appear to be stored in reverse order, last character first. There's a lot of dead space. I haven't yet made any effort to identify where the effects parameters are, so it's possible that a lot of the apparent dead air is taken up by them, but we'll see.

Following is a screen shot of a file that I'm building to describe the dump layout in detail:



This file is available on my Web site here. It's an Open Office spreadsheet. Open Office is support on both Windows and Mac OSX platforms; you can download it for free from openoffice.org. The row number is the number of the byte in the dump, where the sysex beginning-of-exclusive byte (F0) is byte 1. Column A lists which of the four sounds the parameter belongs to, if it is specific to a sound. Column B shows which parameter or parameters appear in the byte, and which bits. The rightmost bit is bit 0, and the leftmost bit is bit 6 (remember, only 7 bits are available in a MIDI data byte). Column C provides any additional notes, such as parameter range or bit encoding. The next seven columns with the color-coded blocks will match up (in most cases) with the colors used in the text, to show which bits in the byte each parameter is using. Looking at the screen grab above, you can see how much empty space there is, and how many parameters wrap across the byte boundaries.

For those who didn't know, the Fizmo has a huge number of parameters which are not editable (or even viewable) from its own panel; you have to use an external editing device to see or change them. Given that there are about 200 parameters for each sound, the only practical way to do this is to use a computer editor. However, the only editor that has ever been available for the Fizmo is a bastardized version of Sounddiver that Ensoniq made available to Fizmo buyers, before Creative Labs (the company that bought out Ensoniq) shut them down. My experience has been that this version of Sounddiver is incredibly buggy; it never quite does the same thing twice, and nearly every time I run it, I have to try to figure out what set of magic incantations is required that day in order to get it to basically work. The librarian features are untrustworthy and I've trashed many of the patches on my Fizmo in the process of doing this investigation (fortunately, I didn't have anything on it that I particularly wanted to keep).

Given all this, there is strong motivation to work towards creating an open-source editor. That's one reason I'm doing this project. The Fizmo has the potential to be a very powerful synth, but most of its power can't be unlocked until there is a reliable and supported patch editor for it. I'm maintaining a thread concerning the project on VSE; I'd like to get some people interested in starting to write some code.

The main things remaining to do with the patch dump are: (1) figure out how the parameter values work for the parameters that specify wave selecting and offsets into the wave table (they appear to be memory addresses, but I haven't poked at it much yet), and (2) start working out the locations of the effects parameters. After that, although it isn't an absolute necessity for a basic patch editor, I'd like to start documenting the single-parameter sysex messages that Sounddiver uses to transmit individual parameter edits to the synth.