Enter the Matrix – finally the R/W decoder is legible.
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:
- It enabled NPRN control of the Matrix’ parameters by removing a small bug
- It sped up the VCF parameter control by skipping seemingly unnecessary calculations
- It told the synth to discard all parameter edits except the most recent one, thereby keeping the synth responsive.
This is a huge improvement and makes the Matrix feel and behave almost like a modern instrument. But it gets even better.
Matrix-6 project, Matrix-1000 upgrade
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.)
Verwandte Artikel:
- There is a true Oberheim Matrix editor for iPad now. And yes, it’s worth buying it. (Friday, 26. June 2015; Schlagworte: Editor, iPad, Matrix-1000, Matrix-6, Oberheim)
- Matrix Modulation control included: iPad editor for the Oberheim Matrix-6/1000 (Wednesday, 30. April 2014; Schlagworte: Controller, Editor, iPad, Matrix-1000, Matrix-6, modulation matrix, Oberheim, TB Midi Stuff)
- Reclaiming the Matrix: new life for an old beast via iPad control (Saturday, 29. March 2014; Schlagworte: Editor, iPad, Matrix-1000, Matrix-6, Oberheim, TB Midi Stuff)
Hi, I am trying to make a Ctrlr panel for the matrix1000. I have two things I don’t understand on the sysex dump: Checksum, how is it calculated? What are all the bytes for in the global-parameters dump called Group Enables (One bit per patch, LS bit first) / byte 36-161? If you know the answer I would be glad if you could post it here. Thanks
Hi Chris, isn’t there a Matrix-1000 panel for Ctrlr already?
Concerning the checksum: according to the patch dump documentation from the manual, it is a simple 7-bit sum of all the transmitted data.
The info concerning Group Enable is on page 31 of the manual: “For even greater flexibility, you can program each patch… to use or ignore Group Mode.” I.e. make use of the synth’s capabillity to function as a master/slave with other Matrixes for multiplying the voice count. I guess for most of us this may be safely ignored. (Hey: I’ve got two Matrixes, and I hardly ever use Group Mode.)
yes there is already a Ctrlr panel but it is a “forever beta” version. I would like to enhance it to cover all features of the Matrix1000. I used group mode too on my two matrixes, but the lag is quite important, so not extremely useful. Thanks for your (very fast) answer, but sorry I don’t get how you can make a sum out of many 6bit/7bit etc. values and cram them into one 7 bit value? Sorry if this is trivial. I know a “bit” or two about binary notation but never had to calc a checksum.
I googled about checksum addition, this is a Roland checksum but it must be something similar. I think I will find out by trial & error: Add each of the values, one by one. Each time the value exceeds 127 (7Fh) subtract 128 (80h) from it. Finally subtract the resultant value from 128 and you have your checksum!
Thanks for letting me know about the group mode. I didn’t think that it must be set for each patch.
Mathematically correct: Sum up all parameter values as a positive integer, checksum is the MODULO 128 value.
Even simpler checksum algorithm: Add every value to a positive-byte value. Ignore range overflow. AND mask with $7F. :)
Thanks untergeek, will try these out. They seem more plausible than the Roland checksum (applied to the Oberheim checksum).
Hi unty, my Ctrlr panel is almost finished. It features a librarian, full recall of parameters and a randomizer. It is a joy to use it with rom v1.20 (will definitely pay these 10$). But now I got a “problem” – though not sure if this is a feature: Is it normal that the M1k in unison mode makes a pitch rise on key release? It seems to be an even 12 halftone step… It sounds cool but I could find no way to change it (e.g. get rid of it). Thanks.
Ah sorry, this was a setting of my sequencer everything allright. It confused me that it does not happen in polymode.
Glad to hear that – I couldn’t explain that effect – and really looking forward to your panel! Once you put you work in public beta, give me a note.
I think it will just take a few days until I will release v1.0beta. I would be glad if you could betatest it. These days it is hard to find willing betatesters :) Thought I still have one big prob: when in group mode the M1k will send garbled data between sysex messages (starting with F0, sending a bunch of bytes and then starting the correct message with F0, so no F7 on garbled bytes). This confuses Ctrlr and it can’t receive the messages correctly. I’m afraid I won’t be able to fix this. What do you think, would Bob Grieb be willing to fix this in the firmware? Maybe I should ask him.
I haven’t tested group mode for some time (I gave up on the group mode and worked on other parts). I did test it again now and it seems to work! It just bothers me that the builtin midi-monitor of Ctrlr does not display it correctly. It looks like it looses half of the dump but this may be just the midi-monitor displaying it wrong. It is a fact that the M1k sends garbage when in group mode. I did test this with several midi-monitors that are showing the dumps correctly including the garbage in-between. Well, I will have to test this some more. Maybe I am lucky and it really works. There is no control in any way for midi-input behavior of Ctrlr. You just have to rely on it doing it right.
Btw. are you using group mode (having 2 or more M1k’s)? What pc system do you work on (Mac, Win, Linux)?
Ok, should have read the old messages above… you hardly use group mode… maybe I better send you emails instead of cluttering your blog – sorry.
Just in case anybody came here via Google: Chris’ Ctrlr panel for Matrix-1000 is available for download now, and I think it’s great.
I’ve been working on getting a Matrix 1000 back to life: replace a fully dead battery, new EEPROM, etc. One thing I’ve not been able to figure out is where I can obtain the factory original first 200 patches. Do you know of anyone or anywhere where these can be obtained? Pressing ENTER while power up, of course, does not restore them.