As I wrote on
VSE a few weeks ago, I have re-started my aborted project from a couple of years back to document the patch dump sysex format of the Ensoniq Fizmo. The first time around, I was trying to tweak patches and then manually examine sysex dumps for changes, and it became very frustrating. Changes were hard to find, and when I did find them, they seemed to make no sense.
A couple of months ago, out of the blue, I had an idea for how I could use Unix shell scripts in OSX to format dumps and find changes automatically. I put together a procedure that involves using Metro to capture the dumps and then a shell script to format and compare them. It compares two dumps, finds which bytes differ, and then lists the differences and where they are.
With this, I was finally able to get a start on the project. If you're not familiar with the Fizmo, it has a rather unusual patch structure. There are 64 memory slots for "sounds", each of which consists of two layers. Then, there are 64 "presets" (using the terminology from the user manual), which has four sound slots. Each one of the slots loads one of the 64 defined sounds. A preset also includes an insert effect and an arpeggiator setup.
So I set up a procedure for finding which bytes in a patch dump correspond with which parameters. Because there are so many parameters that you can't access from the panel, I'm using the Fizmo-specific version of Sounddiver that Ensoniq developed, running on an HP laptop. I have this connected to my MIDI network via a Turtle Beach 1x1 USB/MIDI interface. On my Mac, I'm using Metro to capture the patch dump sysex strings. The procedure steps go like this:
- Change a parameter in Sounddiver.
- Start Metro recording.
- At the Fizmo, save the current patch and then dump it.
- Stop recording.
- In Metro, view the sysex string (in hex) and copy it to a text file.
- Run my shell script to show me the differences between this dump and the previous dump.
- Copy the dump text file to the "old" file name, for comparison to the next dump.
Once I started working on this, I realized one reason why I could never make any sense of the dumps before. I had had several people advise me that the dump format is similar to the MR/ZR sysex format, which is documented. Hah... not even close. The Fizmo patch dump format is one of the craziest things I've ever seen. First, the basics: it's 3097 bytes long. The dump for each sound (two layers) is 640 bytes. Why so long? I wondered about that too. Each layer has about 100 parameters, so 640 bytes seems a bit much.
Well... one thing I'm finding out is that the way that the parameters are arranged in the dump is just insane. There are random filler bits and bytes all over the place. Hardly anything lines up on a byte boundary. Parameters don't appear to be in much of any particular order either. And some data fields are oversized for the minimum and maximum parameter values. (It doesn't help that there seem to be a huge number of different and seemingly arbitrary choices about what the minimum and maximum of each parameter should be. Some go from -64 or -128 to +64 or +128; some go from 0 to 100, some from 0 to 49, and some are just random.)
So far, I've managed to work out a lot of the parameters for layer 1 of sound 1 in the preset. I've got most of the oscillator, filter, and amp parameters, plus the parameters for keyboard splits, velocity mapping, volume and pan, tuning, and portamento. I've mapped out all of the parameters for envelope 1, including figuring out a few that aren't explained on the Sounddiver screen or in its help instructions. I'm hoping that the parameters for layer 2 of sound 1, and the layers for the other three sounds, use the same layout. So far, in the few that I've checked, this seems to be the case, but I need to do more to make sure.
I've also found where it saves the on/off and edit-enabled status of the four sounds, and the two layers of each sound. I've also found where it saves the patch name (the Fizmo can't of course display the names, but Sounddiver can), although I haven't decoded the format yet -- it's not anything as simple as plain old ASCII. I found something else, by accident: did you know that it saves the values of the F-I-Z-M-O real time controller knobs? I didn't realize that either, but it does.
Another bit that I haven't yet decoded is how the wave selection parameters work. I suspect that the parameter value may be, or contain, an actual memory address. Apparently there is a table in the OS ROM that tells it where the start address is for each waveform that you can select. Potential for sysex mischief there.
What I'm doing with all this info is putting it into a spreadsheet. I don't have MS Office at home, so I'm using the spreadsheet editor in Open Office. Here's a screen shot of what I've got so far:
The color-filled columns represent the bit patterns of the various parameters; there is no particular system other that the color matches the color of the corresponding text. Each column represents one bit and there are seven. (Since the leftmost bit of a data byte must always be 0 in the MIDI protocol, I left that out.) I number bits starting with bit 0 on the right, to bit 6 on the left. The un-colored columns represent bits that are filler, or whose function I haven't discovered yet. The row number is the byte number. The middle column documents parameter ranges and anything unusual about the parameter format.
This version of Sounddiver is very buggy. It has a lot of trouble remembering its configuration parameters. Nearly every time I start it up, I have to engage in some kind of software gymnastics to get it to communicate with the synth. About half the time, it will start up and then inexplicably lose track of the MIDI interface, and I have to either kill it and restart, or manually reconfigure it, or both. It never does the same thing twice. Now and then, all of the numeric parameter values will mysteriously blank out of the display. And periodically, it goes off on a mental vacation -- it consumes 100% of the CPU for about ten seconds, locking everything else out while it is doing so. I get the impression that it's a hack; it will claim that you're communicating with an MR series synth, and the Fizmo is hardly every referred to by name. Every now and then an error dialog pops up with a cryptic message and the developer's name, as if the developer was still in the process of debugging it when it was released.
Which may be true... between the condition of this version of Sounddiver and the peculiarities of the software in the synth itself, I'm getting the impression that the whole Fizmo project was a rush job. I picture Ensoniq, in financial trouble, trying desperately to crank out a product that might save the company, in a very short amount of time. Developers grabbing pieces of existing products and jamming them together with things from the lab, and rushing the whole thing out the door with minimal verification. And it never had a chance to find its niche before Ensoniq sold out to Creative Labs and production was abruptly terminated. And someone forget to check the current draw to see if it was within the voltage regulator's specs...
I'll post more on the sysex format as I get time to work on it; right now I'm only finding about 4 hours a week to give to this project. I think it's going to take about 40 hours to finish it, so that takes me about up to Christmas. At some point, once I've got the spreadsheet a bit more complete, I'll start posting the latest version to my Web site. You'll need Open Office to read the file; it's available for Windows, OSX, and Linux, and you can download it for free
here.
I'll finish this up with a screen shot of the Fizmo Sounddiver version. Shown is the patch editor window, with the parameters for layer 1 visible, and a piece of the effects parameters on the right. Note the rather primitive look and feel, and the amount of wasted space.