Props to Ralf, who lent me his Matrix-1000 to do this video.
Just a teaser for a detailed description and an unbearably long video to go with it.
Props to Ralf, who lent me his Matrix-1000 to do this video.
Just a teaser for a detailed description and an unbearably long video to go with it.
Ah, yes, GAS, Gear Acquisition Syndrome. It happens to the best of us. So if the thought of a new hardware super-controller by Stereoping is giving you sweaty palms, especially as you learn that it will also be available for Microwave, MKS-80, and Rhodes Chroma, you’d better not read on. The specs I’ve got for you would only make you GAS much, much worse.
As teasers go, I’d give it only a 0.3 on the Behringer scale – but it’s for something that I am not directly involved in, so it’s a bit shameless from me. But Chris, who is working on this, has kindly allowed to use these screenshots from his upcoming editor/librarian/controller panel for Ctrlr, the open-source multi-controller. Available for Windows, Mac, and Linux (!)
Granted, there is already a Matrix editor panel, but it’s been in permanent Beta, and Chris’s panel simply looks great, from the layout of the controls, via the Matrix-movie branding, to the randomizer (brought up by clicking on the red pill, of course!). So: stay tuned!
Bob Grieb’s brilliant firmware rewrite for the Matrix-6 and Matrix-1000 machines has been in testing for some time. The code seems to be running fine and is definitely a huge improvement: Matrix-6 owners will gain a machine that is much more responsive, and has been ridded of a couple of nasty bugs. And even for Matrix-1000 owners that have been using GliGli’s v1.16 patches, the new software offers, in my humble and slightly biased opinion, great advantages.
Bob has started shipping EPROM chips containing the new code to people who do not have an EPROMMER available, and I’ve agreed to doing the same thing over in Europe. The price for the update is €25 plus shipping,this contains a payment to Bob as a recognition of the endless hours he spent in analysing and rewriting the code.
You can find a first batch of Matrix-1000 update PROMs on eBay, as well as update PROMS for the Matrix-6 and 6R – if they are gone, just follow one of the links below – there are order forms at the end of those pages.
03-2020: Two important updates: There is a much simpler way to reset the memory in the Matrix – just hold the ENTER key while switching it on. You may have to repeat that a couple of times to get a stuck Matrix unstuck. And if you consider changing the battery yourself, you can find a step-by-step description with video here.
Happy days! Bob Grieb just sent the newest iteration of his brilliant firmware rewrite for the Oberheim Matrix-1000 for testing – a firmware that breathes new life into the old 8-bit hardware by optimising critical routines for a couple of crucial parameters. Smooth real-time control, very musical; in my opinion, even better than GliGli’s great v1.16 hack – I’ve described the differences in this Gearslutz post – and, in the last couple of iterations, displaying the value of edited parameters.
Well, to change the firmware, you have to open the Matrix and exchange the firmware EPROM for a new one, and doing that, I’ve noticed that this machine was still equipped with its original battery. By lucky chance, I am the proud owner of two Matrixes, and the battery in this one has been doing fine – what kind of super battery did they use in these days, has been in service ever since 1989, and still producing fine 3.0 Volts of power – but I decided to exchange it anyway for a new CR-2032.
As you might know, the battery in the Matrix-1000 is soldered in with most machines, as it was customary with most synths from these days. I guess they never thought that they were building for the anoraks of the future. No problem, I came across battery holders with the same 20.5mm raster used in the Matrix – so no need for drilling, just a simple solder-and-replace job. While soldering, I bridged the backup battery voltage with an external power supply, and I even thought of desoldering the GND terminal first – the rationale behind this being that soldering pens are earthed, so by soldering the positive terminal first you might short out the battery. (Actually bollocks, but I did it anyway.) So I saved my precious memory settings while soldering in the battery holder.
Only to slide in the new battery the wrong way round.
You might not have realised – well, I never do – but the pad connector of a CR2032 is actually the GND terminal, and the housing is Vcc. And is labeled with a clearly visible “+” sign. Well, I put the battery in the wrong way round anyway, thereby effectively losing all my patch and memory settings.
This is, of course, no big deal. I keep moving sound banks between my two Matrixes anyway, so I have pretty recent Sysex backups. Unfortunately, the unbuffered RAM chip lost just enough memory to put the machine into an undefined state – it would no longer boot beyond the init routine displaying the firmware version.
I ran into this problem before when I equipped my other Matrix with a new CPU – as you can imagine, this gave me some really bad moments. But factory-resetting an M-1000 is simple:
Done. Now you may switch off the Matrix, or supply it with fresh patch data.
In case you may have wondered, there is a very simple and effective way to disconnect/reconnect the battery in a running machine: push a strip of paper between the battery and the battery holder’s terminal. Remove it to reconnect.
Looking to get the latest revision of Bob Grieb’s firmware rewrite mentioned below? Click here.
As you may have seen in this blog, I really care about my old Matrix-1000 rack synths. A wonderful piece of retro technology from the final, post-DX7 phase of classic analog synthesizers. There have been attempts to improve on the old 6809 firmware code, most notably by Gligli, a French hacker best known for his SCI Prophet 600 hardware/firmware retrofit. His improved firmware, known as V1.16, introduced a couple of tricks:
This is a huge improvement and makes the Matrix feel and behave almost like a modern instrument. But it gets even better.
Bob Grieb has been analyzing the Matrix-6/1000 code for months. I guess you can say that these days, not even Marcus Ryle does understand the code as well as Bob does. Here is his explanation why the Matrix-6/1000 machines are not real-time responsive to parameter changes in the first place – it is the downside for the immense amont of real-time modulations the Matrix is capable of – 22 fixed modulation paths, 10 matrix modulation slots, 3 envelopes, 2 LFOs and 2 ramps. To implement that in software the programmers used a special technique; a pre-calculated memory area for each voice called the voice update stack. Quote:
This stack contains pointers to code, ptrs to variables, and some pre-computed values. Only pointers to the code needed to handle the enabled features are placed on the stack… This is a very fast and efficient way to update the voice cv’s.
A downside of this approach is that when parameters change, the stacks need to be updated for all six voices. Some parameter changes just affect one number on the stack, so that number can simply be changed very quickly. But some parameters can change the size of the stack. This is a problem, as the update values for that parameter may be in the middle of the stack.
This means moving around chunks of memory to make room for the updated parameters, and it has to be done for all six voices, which takes the ancient 8-bit, 2-MHz CPU a couple of milliseconds. When you turn an external VCF controller, all these parameter changes add up, and the machine freezes for a long, terrible moment, until it catches up. (Read Bob’s full description of the issue here.)
GliGli’s main trick is to tell the machine to discard anything but the last Sysex command. He also noticed that sometimes the stack is rebuilt although this is not technically necessary. And this is the road that Bob has been following. He rewrote parts of the firmware to handle a set of about a third of the parameters much, much faster – including VCF frequency and resonance, DCO PW and LFO control, and VCA level. Changing these parameters with an external controller will be smoother than with older firmware, others – increasing the effect of a modulator in the mod matrix – will still cause the machine to glitch.
Update, 2016: Now that you’ve made it this far, you’ll be glad to learn that Bob made his revised code available for Matrix-1000s and Matrix 6/Rs. You can get a firmware EPROM from him or, if you are in Europe, from me – just follow the links above.
This was originally a project for the Matrix-6, but Bob ported it over to the Matrix-1000. In the process, he also redrew the schematics, so that after all these years, there is finally a legible circuit diagram for the M-1000 on the net. Incidentally, it prompted another guy to scan his printed schematic and send it to Bob, so that there are now not only one usable version but two. (Download link to ZIP archive here.)
If you have found this blog searching for the Oberheim Matrix-6/1000 synthesizer, you may already know that I still haven’t given up on breathing new life into hardware and software of this wonderful machine, and that I have made a controller template for the iPad. A controller, mind you, not a true editor – but a tool to control each parameter in a sound preset via a dedicated touch control, and pretty much without alternative.
No longer – there is a true Matrix editor app in the Store now, Patch Touch by Coffeeshopped, LLC. How does it compare? Is it worth the
15 30 Dollars or Euros? Chadwick, the guy behind Coffeeshopped, was so kind as to send me a download code for his app, and to comment on an early draft of my observations, so you’ll find my remarks updated with his comments here.
Update: Looking for the new, rewritten firmware? Info on how to get the latest version here.
There is some (potentially) very good news for Matrix-6/6R owners hoping to get a firmware update – it has come a huge step closer. An extremely experienced engineer has just decided to put his annotated source code file for the Matrix-6 online – you will find it on his page at Oberheim Matrix 6 Firmware. Not the original sources from Oberheim, mind you – they are rumoured to have been lost when someone accidentally dropped the master source disk – but a very carefully annotated listing, reverse-engineered. The engineer who did this even spent the time to mark code that has been re-used in the Matrix-1000 firmware.
So what does that mean to you as a (potential) M6 owner?
The engineer has decided to abandon the project – he thinks that the performance problems of the Matrixes are a result of fundamental design decisions and would need too much effort to get around properly. But his code definitely improves the chances of doing something useful for the code. Someone with skill and spare time might even backport the M1000’s NRPN and matrix modulation Sysex commands into the M6 code.
BTW: My attempts at starting a documented source code file for the Matrix-1000 can be found here, with a hardware and software primer here. If I can find the time, I’ll try to backport a few of Bob’s insights into the M-1000 code.
With the amount of work waiting for me with Jen, I’m glad I don’t own a M-6…
Dremeling and ripping out the brain of a 25-year old vintage machine – I was so Frankenstein yesterday. Luckily, it worked, being the first step to a much improved Oberheim Matrix-1000 running with – at least – doubled system clock, and patched firmware. This takes up the work of Gligli who was the first to hack a faster CPU into the Matrix, and tries to take it one step further.
Hacking a vintage instrument – my favourite guitar player calls this cruelty. Yet there are good reasons to do it: As I’ve mentioned before, the Matrix’ CPU is actually too slow for what it tries to achieve, but the 8-bit 6809 chip could only be clocked to 2 MHz in its fastest version, and this is it.
So Gligli, a hacker from France known for his Prophet-600 firmware rewrite/retrofit, had the idea of using a 6309 CPU, a chip from the same era that, while maintaining drop-in compatibitily, offered faster instructions and could be overclocked to 4 MHz. So he replaced the CPU and the main oscillator, patched the firmware and – it worked.
Yet there are some issues with Gligli’s solution, in my humble opinion. The Matrix’ peripheral chips are designed to work at 2 MHz; by doubling the CPU clock, they have only half the time to read or write data to the bus. Not all of the hardware is up to this; Gligli’s solution is simply writing everything twice, and that seems to work, but it’s not very trustworthy.
So I’m planning to install a CPU with a custom clock generator that is using asymmetrical cycles to give the peripherals more time to read and write. (I’ll have to build in new oscillator circuitry anyway, as I happened to buy 63C09E CPUs, which rely on external clock generation.) And there’s always the possibility to go even further and replace the CPU by a modern programmable logic chip, an FPGA, that can be loaded with a 6809-compatible core clocked even higher and has proper slowing-down logic to interface the old hardware. More on that later, suffice it to say that I simply want my Matrix’s CPU in a socket. And be it only to be able to revert to the original chip.
Remember what I wrote about my attempt to build an iPad editor for my vintage Matrix-1000 analog synth with TB Midi Stuff? That it’s a pity that, due to the rather eccentric MIDI implementation of the Oberheim machine, I couldn’t build a controller for the modulation matrix? Tell you what: it works now.
TB Midi Stuff – which is an absolutely great universal kit for building MIDI controllers, looking great and much cheaper than Lemur – has recently gained a feature that allows to send three-variable Sysex commands. And this is important – let me tell you why. (BTW, for those who can’t wait: Download links to the Matrix-1000 editor panels can be found in the TMBS forum.)
Let me explain the problem, and how to solve it with TBMS.
Unfortunately, this won’t work with Matrix-6s – they do not understand the sysex commands needed to program the mod matrix directly.
As I’ve written before, the Oberheim Matrix-1000 has a couple of quirks and issues, especially concerning the modulation matrix, the analog synth’s strongest asset. Almost any other sound parameter within this synth can be controlled individually with a tailored MIDI Sysex message (something like: F0 10 06 06 1A xx F7, translating as “Listen synth, control coming up, setting vcf, to VALUE, thatsit”); the matrix modulation paths are set by a command sequence like this: F0 10 06 0B 01 xx yy zz F7, translating to “Listen synth, modulation coming up, setting modulation path 1 now, FROM, BY, TO, thatsit.” What this means is: If you want to have full control over the modulation matrix, you have to be able to craft a Sysex message with at least three parameters.)
TBMS from version 2.2.4 on has a feature to achieve this: Masked variables – variables where you can set the bits you want to control. They can be up to 21 bits large – equalling three 7-bit MIDI values. So instead of sending three independent values, you tell TBMS how to craft a 21-bit variable containing the three parameters – and send this.
I guess there are not that many people who have followed my that far – but if you have, you may have noticed that the variable is supposed to transmit 3*7=21 bits of information, resulting in an integer range of 0 to 2,097,151. You can actually set that value in the Sysex range control setting,.
So whenever you tweak the controls for Matrix modulation path 0, TBMS constructs a three-byte, 21-bit message, which it then sends as part of a Sysex control message.
The most recent version can be found in the TBMS forum. Dropbox link to V0.4 here and here. Please remember that there are two nasty bugs in the Matrix-1000 firmware – you cannot control ENV2->VCA and ENV1 Sustain via TBMS in consequence -, and that the editor only sends Sysex, it does not receive and interpret it.