What the heck happened to Vintagesynth?

It returns a message from the ISP saying the site has been suspended. Investigating...

EDIT: They had some kind of problem with their hosting service.  It's fixed now.

Rack rearrangement

I decided last weekend to rearrange some of the contents of my two 19" racks.  I have two, a rack that I built myself which is about 25 units tall, and a tabletop rack which has a tilt-up top for the mixer, plus 6U of space underneath.  My main goal was to clean up my MIDI routing by swapping some things around.  The tall rack contains a MOTU MIDI Express USB interface which handles all of the MIDI for the rack and both of the keyboard stands.  The tabletop rack contains an Edirol UM-2 for the synths in that rack.  All of the I/O (8x8 in the MOTU, 2x2 in the Edirol) is pretty well spoken for.  

Here is a photo of the tall rack from several months ago:

Among the items in this rack are a Yamaha TG33, which is the black thing protruding out the front just under the patch bay at the top, and an Oberheim Matrix-1000 and a Kawai K5M, which are the bottom two items in the photo.  You can just see a bit of the amp underneath the K5M; the amp sits at the bottom of the rack.  The MIDI interface is in the middle; it's the unit under the one where the headphone cord is plugged in.  

Here's the tabletop rack, visible at the left of the photo:

This photo was taken while I was setting up the studio, and only the Oberheim Matrix-6R was installed at the bottom of the rack.  Since this photo was taken, I had added a Roland JD990.  The immediate motivation for all this was to get the JD990 into the other rack so that I could use the routing capabilities of the MOTU MIDI interface to route sysex from the JD800 directly to the JD990, which allows the 990 to be programmed using the 800's panel controls.  I couldn't do that when they were on different MIDI interfaces, without having to bring up the computer.  A secondary motivation was to get the 990 into a place where the screen would be easier to read.  

Towards that end, I decided to put the 990 near the top of the tall rack, which meant moving the TG33.  The obvious target for removal to make room was the 4U high Kawai K5m.  Here, I have removed them from the rack and both out on the floor:

The empty spaces in the rack where they were:

The K5M went to the tabletop rack.  To make room for it, both the JD990 and the Matrix-6R had to come out; the K5M and the Matrix-6R together were 1U taller than the rack.  I decided to gain space by swapping the two Oberheims.  Here's both of the Oberheims out of their respective places:

And the tabletop rack emptied out.  The Edirol is the small box in the back:

The K5m and the Matrix-1000 went into the tabletop rack, with space for the Edirol at the bottom:

And from the back.  I realized after mounting them up that the Matrix-1000's case was sagging.  A block of wood fixed that.  You can see in the foreground the Edirol, which after taking this photo, I slid under the Matrix-1000 to the front right:

The JD990 went into the top of the tall rack without any problem:

But the Matrix-6R ran into problems.  It's very wide; it just barely fits in a standard rack.  The space it, and the TG33, were to go into, with an old Furman parametric EQ above, and the amp below:

First problem: The power strips mounted on the rack rail braces were intruding into the space.  It was never a problem before, because the K5m isn't nearly as deep as the Matrix-6 is.

I moved the power strips and fixed that.  Second problem: Because the rack is homemade, I didn't get all of the dimensions quite as exactly as I should have.  It turned out to be about 3/32" too narrow to clear the Matrix-6R's rack ears, where they mount to the sides of the case.  But one of the advantages of a wood rack is you can fix stuff like that.  So out came the Dremel and the shop vac:  

I took about 1/16" off of each side, to about 3/4" deep from the front, and that created clearance for the rack ears.  After that, it mounted up nicely:

Would you be willing to stick your hand in here?  The bottom of the rear of the rack is rather busy, with the Matrix-6R taking up formerly empty space.  Getting it hooked up involved a bit of fishing:

Last item to take care of was the TG33.  I had thought at first that I would mount it at the bottom of the rack the way I had it at the top, using the unusual extending rack ears that came with it.  But then I realized that it was easier to simply set it on top of the amp; the rack doesn't go anywhere, so there was no real need to mount it.  (The amp isn't mounted; it simply sits on the rack base.)  However, the amp did need some clearance at the top for ventilation.  To provide that, I cut a couple of spacers from a piece of scrap wood.  With a couple of dabs of Permatex blue RTV silicone, they stuck to the bottom of the TG33 case nicely, but they can still be removed if need be:

With them attached, the TG33 gains about 5/8" clearance at the bottom:

This worked out nicely.  The TG33 pushes back into the rack, and can be pulled out to work with it.  In fact, with a little slack on the cables, I can pull it out and put it in my lap.  

The completed tall rack, with the JD990 underneath the patch bay at the top, and the Matrix-6R and the TG33 at the bottom:

And the TG33, ready for action:

Everything's up and running, and with all the equipment in the tall rack on the MOTU MIDI interface, I can now use the MOTU to do the following MIDI routings without needing the computer:

• Route panel control sysex from the JD800 to the JD990
• Route sysex from the MOTU's front panel ports to the Fizmo
• Route the bass pedals to the JD990
• Route the bass pedals out of the front panel port to the modular or the EML

Now, back to the Fizmo wars.

The ongoing Fizmo project

I've done a bunch more work on identifying how to edit Fizmo patches via MIDI. I've got the NRPNs worked out for about half of the sound parameters, including some of the ones not accessible from the panel. I'll post an update in a few days with all of the ones I've managed to identify. The internal architecture turns out to have some similarities to the Ensoniq MR series. The envelopes are six-segment types. You can set time and ending level for segments 1-4, level for segment 5 (which is sustain) and time for segment 6 (which is of course release). The filter is actually a lot more complex than the simple LPF that the panel allows you to access. There are a bunch of modulation routings that aren't accessible from the panel, nor does the manual even hint at them.

And some of these parameters, once set via MIDI access, aren't even reinitializable from the panel. For instance, the filter is actually two filters in series, and the four elements (poles) can be arranged in different combinations. There is a "link" parameter that ties the filter 2 settings to filter 1, but if it's off in a given patch, you can't turn it on from the panel, and you can't do anything that causes the filter 2 settings to change. I found this out when I was experimenting with NRPNs, and I managed to accidentally switch the link off, and all of a sudden I had a modulation on the filter that I couldn't get rid of. The modulation was on filter 2, and the panel controls only access filter 1. The same sort of thing can happen if you use a factory patch as a starting point for something.

Several things that appear to be simple on/off parameters from the panel are actually variable. One example is the envelope velocity scaling. There are actually two parameters associated with it. One is the active value; the other is a "save" location. The active value determines how much velocity modifies the attack time (actually all of the segment 1-4 times) of the given envelope. When you press the button on the panel to turn velocity off, it sets this parameter to 0. When you turn it back on, it actually sets the active value to the save value, which is not necessarily the maximum value. If you only set the active value via MIDI, then turn velocity off and back on at the panel, it will return to the save value, not the active value that was set. To make a change "stick", you have to set both the active and save values.

Patches actually do have names on the Fizmo. You can't see them from the panel (why oh why didn't they include a real display on the Fizmo?), but you can see and set them in Sounddiver. Oddly, the implementation makes every individual character in the name its own parameter. So, in Sounddiver, clicking in the patch name field and typing a single character results in a sysex exchange with the synth. A bunch of data flying back and forth to change one character. Individual sounds have names too, independent of the patch name. (If you read the Fizmo manual carefully, you will see that by playing games with MIDI Bank Switch and program changes, you can yank individual sounds from a stored patch into the active area, without actually changing the current patch.) Waveforms have names in Sounddiver too, although I'm not sure if it is actually retrieving these from the synth, or if it just has these hard coded.

Parameters are accessible via both NRPN and sysex. I got a tip from the Vintagesynth forum to look at the MR series sysex documentation for some tips. It turns out that the sysex that edits a single parameter is similar. It uses parameter numbers which are mostly the same as the ones the MR uses for its "sound" block of parameters. (The Fizmo, unlike the MR, doesn't group sounds into performances. Some of the things that are performance parameters on the MR are system parameters on the Fizmo. I haven't explored that yet.) Unfortunately, these numbers aren't all the same as the NRPN parameter numbers, but I'm gradually getting all that sorted. One odd thing I've noticed: Ensoniq, like most other manufacturers, transmits "large" numeric parameters (more than one byte) by spreading 32 bits of data over five bytes, owing to not being able to use the high bit in each byte on account of the way the MIDI protocol works. However, it appears that the Fizmo shifts most parameter values three bits to the left prior to encoding them for sysex transmission, and it expects to receive them the same way.

The bulk patch transfer sysexes bear no resemblence to the documented MR sequences as near as I can tell. In fact, the paranoid in me insists that Ensoniq deliberately tried to obscure the data. The MR documentation lays out a nice data structure format which includes, among other things, four-character ASCII sequences that identify the type of each block. In the Fizmo patch dumps, I don't see these. In fact, I don't see any recognizable ASCII strings at all: no patch names or anything. I did some experiments last night, changing one character in the patch name, dumping it, and comparing the MIDI dumps. The characters are there, but they are all shifted at weird offsets across bytes. Why? It certainly makes it harder to make any sense of a MIDI dump. Perhaps they wanted to allow for eight-bit ISO Latin-1 characters, or even Unicode, and so they worked out some means of packing the characters across bytes. As for the other parameters, I have no clue what order they are in, and a few experiments indicate that the MR documentation isn't going to be any help. I'll have to isolate them all, one at a time.

I haven't really gotten into the insert effect stuff yet. And then there's the arpeggiator, where the MR has no analagous feature. Much work to do yet.

MIDI Connectors and Cables

If you are building your own MIDI cables, or equipment that will connect to MIDI, here are some handy references:

Shavano Music Online has a handy page that explains how to wire MIDI cables. Note a few things: (1) The pins are numbered in a funny order. Pin 2 is in the middle, and pins 4 and 5 are adjacent to it. The outermost pins are numbered 1 and 3. (2) Cables are always wired straight through; there is no crossover. (3) Cables use male connectors on both ends. Equipment always uses female connectors. (4) Contrary to the instructions on the Shavano page, the shield in a cable should be connected to pin 2 at one end only, to avoid ground loops. Leave it unconnected at the other end.

Remember, when wiring MIDI connectors on equipment, that the pinout is the mirror image of the cable connectors.

Mouser part numbers for MIDI connectors:

• Switchcraft female panel mount connector, solder lugs: 502-57GB5FX
• Switchcraft male cable connector, crimp connection: 502-05BL5MX
• Deltron male cable connector, solder lugs (I haven't tried these): 174-2511

Gymnopedie #1

I've done a synth version of this well-known classical piece.  It's for a ballroom dance routine that my wife and I are doing in a showcase event on February 28.  Read more about it at the Source Code Web site.  

How many poles does the TB-303 filter have?

The VCF in the Roland TB-303 is nearly always described as being a 3-pole (18 dB/octave) filter. Many 303 aficianados claim that this is one of the things that gives the 303 its unique sound. However, Tim Stinchome says it's a 4-pole filter. And he's got the math and the SPICE simulations to prove it.

Matrix 1000 vs. Matrix 6 DCOs

A point of contention among Oberheim fans is what the differences, if any, are between the Matrix-1000 and the Matrix-6/6r.  Here is an interesting web site from an unnamed Matrix-1000 owner who has done some excellent analysis of the circuitry on the 1000 and several other synths.  Both the Matrix-1000 and the Matrix-6 are based on the CEM 3396 synth-on-a-chip, one of the last and most highly integrated of the Curtis synthesizer building-block IC designs.  Basically, a 3396 is a complete monosynth, or single voice of a polysynth, needing only control voltage sources and some support circuitry.  Among other things, the 3396 has onboard two digitally-controlled oscillators (DCOs); they derive their output from a high-frequency (well above audio range) master clock that must be supplied by external circuitry.  

The author of the Web site linked above writes that the Matrix-6 uses three high-frequency driving oscillators for the six 3396s in the synth.  It's a rather strange grouping: HF oscillator 1 drives VCO 1 of all six voices.  HF osc 2 drives VCO 2 for voices 1 and 2; HF osc 3 drives VCO 2 for the other four voices.  Why this particular division?  I can't think of any explanation.  However, it does assure that for all six voices, VCO 1 and VCO 2 are clocked to separate HF oscillators.  And since the HF oscillators in the Matrix-6 are basically Hartley LC circuits, they are subject to drift caused by temperature, electromagnetic interference, component aging, and a host of other factors.  So for any given voice, VCO 1 and VCO 2 are almost certain to not be precisely in tune to each other.  There is an onboard auto-tune routine for the HF oscillators, but on my Matrix-6r, it doesn't seem to make much difference.

The Matrix-100o goes with a simpler scheme: the HF source for all twelve VCOs is a divide-down of the 6809 CPU master clock.  This is a crystal-derived clock, so it can be expected to not drift much.  However, the point is that all of the VCOs are referenced to the same clock, so the differentials that exist between VCO 1 and VCO 2 in a voice of the 6/6r do not exist on the 1000.  There does appear to be some other source of injected phase variation, since the 1000 in unison mode doesn't suffer from the "phase lock" problem that, say, the Roland Juno-106 exhibits when in unison.  But the tuning drifts that are often credited as being the "sound" of analog VCOs are not present in the 1000.  Take that for what it's worth.  Actually, I think that there's very little difference in sound between the 6/6r and the 1000.  

Incidentally, the Web site linked to in the first paragraph is worth visiting for other reasons.  Among other things, the author of the site appears to have access to the Matrix-1000 firmware source code, and he points out a couple of bugs.  When I was writing M1000X, there were some funny things going on with the envelope settings that I never tracked down, and it bugged the heck out of me because I couldn't find anything wrong with my code or the MIDI data it was sending.  This page explains it: due to a firmware bug, you can't change the sustain level of envelope 1 using the parameter edit sysex.  Attempting to do so changes the initial level of envelope 2 instead.  Sigh.  At least now I know how to work around it.