Arturia Forums
Hardware Instruments => MatrixBrute => MatrixBrute - Presets & Media => Topic started by: mkoch on May 31, 2020, 09:39:20 pm
-
Hello,
after a few days of programming I now have a program for analyzing a preset.
The program can be downloaded here: www.astro-electronic.de/MatrixBrute.exe
If you don't want to download a *.exe file, you can compile the C# code yourself, here is the whole C# project:
www.astro-electronic.de/source/MatrixBrute.zip
It works as follows:
1. Copy MatrixBrute.exe in a new and empty folder.
2. With Midi Control Center, create a file which contains _one_ preset. Only one. The filename must be test.mbpz
3. Save this file in the same folder as above and start MatrixBrute.exe
4. The program will rename the input file to test.zip and extract two files. The first one is 0_nameOfThePreset and the other is 1_sequence . Only the first one will be analyzed. Warning: The program will delete all files beginning with "0_" and "1_" before it extracts the files. That's why you should run this program only in a new (and almost empty) folder!
5. In the left half of the window you see a comparison of the input file against the "Init" preset, along with many comments. This is automatically saved as "diff.txt" in the same folder.
6. In the right half you see a nice printout of all prameters of the preset. This is automatically saved as "printout.txt" in the same folder.
Below is a sample printout. Maybe someone else wants to reverse-engineer the sequence file? Reverse-Engineering wasn't difficult once I had figured out the tricky 7-bit to 8-bit conversion.
Michael
************* MatrixBrute Analyzer V1.0 by Michael Koch 2020 ************** Page 1 *****
Name of this preset: Mysterious
VCO1: VCO2: VCO3-LFO3:
Fine 0% Fine 0%
Coarse -50% Coarse 12% Coarse 75%
Sin/Squ 0% Sin/Squ 0% Wave Triangular
Sub Level 67% Sub Level 0% LFO Div 16
Ultrasaw 0% Ultrasaw 0% Kbd Track On
Saw Level 49% Saw Level 70%
Pulse Width 0% Pulse Width 0%
Square Level 0% Square Level 0% NOISE:
Metalizer 100% Metalizer 100% Type White
Tri Level 100% Tri Level 100%
AUDIO MOD: VCO SYNC: WHEELS:
VCO1>VCO2 0% VCO2>VCO1 Off Mod Wheel Matrix
VCO1<VCO3>VCO2 0% Bend Range 8%
VCF1<VCO3>VCF2 0% VOICE:
VCO1<Noise>VCF1 0% Mode Monophonic
KEYBOARD: GLIDE: PLAY CONTROL:
Octave 0 Glide 57% Key Hold Off
Glide On/Off On Note Priority Last
Legato Glide
MIXER:
VCO1 Level 100% Filter Both
VCO2 Level 100% Filter Steiner
VCO3 Level 88% Filter Steiner
Noise Level 0% Filter None
Ext. Level 0% Filter None
LFO1: LFO2:
Phase 0% Delay 0%
Seg-Sync Off Seg-Sync Off
Rate 33% Rate 34%
Wave Sinus Wave Sinus
Retrig Off Retrig Off
VCF1 STEINER: VCF2 LADDER: FILTER ROUTING:
Mode LP Mode LP Parallel
Slope 24dB Slope 24dB
Drive 0% Drive 0%
Brute Factor 0% Brute Factor 0%
Cutoff 59% Cutoff 88%
Env Amt -41% Env Amt -50%
Resonance 36% Resonance 63%
Steiner Out 93% Ladder Out 100%
ENV1 (VCF): ENV2 (VCA): ENV3:
Velo / VCF 0% Velo / VCF 0% Delay 0%
Attack 72% Attack 45% Attack 72%
Decay 83% Decay 0% Decay 82%
Sustain 0% Sustain 100% Sustain 0%
Release 53% Release 69% Release 42%
ANALOG EFFECTS:
Delay Time 100% Sync Off
Regeneration 80% Mode Stereo Delay
Tone/Rate 46%
Width/Depth 100%
Dry/Wet 52%
************* MatrixBrute Analyzer V1.0 by Michael Koch 2020 ************** Page 2 *****
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
A - - - - - - - - - - - - - - - - - - - - - - - - - - - - A
B - - - - - - - - - - - - - - - - - - - - - - - - - - - - B
C - - - - - - - - - - - - - - M M - - - - - - - - - - - - C
D - - - - - - - - - - - - - - - - - - - - - - - - - - - - D
E M - - - M - - - - - - - - M - - - - - - - - - - - - - - E
F - - - - - - - - - M - - - - - - - - - - - - - - - - - - F
G - - - - - - - - - - - - - - - - - - - - - - - - - - - - G
H - - - - - - - - - - M - M M - - - - - - - - - - - - - - H
I - - - - - - - - - - - - - - - - - - - - - - - - - - - - I
J M - - - M - - - - - - - - M - - - - - - - - - - - - - - J
K - - - - - - - - - - - - - - - - - - - - - - - - - - - - K
L - - - - - - - - - - - - - - - - - - - - - - - - - - - - L
M - - - - - - - - M M - - - - - - - - - - - - - - - - - - M
N - - - - - - - - - - M - - - - - - - - - - - - - - - - - N
O - - - - - - - - - - - - - - - M - - - - - - - - - - - - O
P - - - M - - - M - - - - - - M - - - - - - - - - - - - - P
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Column 1 has destination [VCO1 Pitch] and depends on:
6% Row E [LFO1]
2% Row J [Aftertouch]
Column 4 has destination [VCO1 Metal] and depends on:
-75% Row P [Exp2/M4]
Column 5 has destination [VCO2 Pitch] and depends on:
6% Row E [LFO1]
2% Row J [Aftertouch]
Column 8 has destination [VCO2 Metal] and depends on:
-61% Row P [Exp2/M4]
Column 9 has destination [Steiner Cutoff] and depends on:
60% Row M [M1]
Column 10 has destination [Ladder Cutoff] and depends on:
0% Row F [LFO2]
60% Row M [M1]
Column 11 has destination [LFO1 AMT] and depends on:
-34% Row H [Mod Wheel]
-100% Row N [M2]
Column 13 has destination [LFO1 Rate] and depends on:
54% Row H [Mod Wheel]
Column 14 has destination [VCO3 Coarse] and depends on:
16% Row E [LFO1]
19% Row H [Mod Wheel]
6% Row J [Aftertouch]
Column 15 has destination [ModAmount F10] and depends on:
38% Row C [ENV3]
100% Row P [Exp2/M4]
Column 16 has destination [LFO2 Rate] and depends on:
60% Row C [ENV3]
49% Row O [Exp1/M3]
-
Wow! Thanks for sharing that!
-
Known bug: It crashes if the name of the preset contains space characters.
Workaround: Use the Midi Control Center to change the name, just replace the spaces by underlines.
Michael
-
Wow. Are these rounded values? Or is everything stored as integers?
-
Wow. Are these rounded values? Or is everything stored as integers?
Everything is stored as 16-bit integers. The percent values in my printout file are rounded.
Michael
-
In Midi Control Center most presets are shown blue, but some are orange-brown. What's the meaning of the different colors? I can't find it in the manual.
"S" means there is a sequence, right?
Michael
-
Great! Thanks for your efforts!
-
Good job, Michael! :)
As we know the MCC can transfer single patches over USB MIDI - I'd think those patches will be in the same format, including the 7 + 1 bit packing. The MIDI monitor shows the sysex traffic.
And yes, an "S" mean there's a sequence, and if it's orange that means the Sequencer button is On. However I'm not sure about what the criteria for "No sequence" (no "S") are. Some of the "S" patches have no sequence (i.e. no sequencer buttons lit). Could be that only a fresh Init patch or a patch where the sequencer has been reset (Panel + SEQ) is reported as "no sequence"(?)
-
Some more explanations about the file format. The *.mbpz file is a *.zip file with wrong extension. It contains two files, 0_NameOfThePreset and 1_sequence. The beginning of the 0_Init file looks like this:
22 serialization::archive 10 0 4 4 1538 4 Init 5 0 0 18 000000100100100000 0 0 32 1600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...
22 is the length of the following string "serialization::archive"
10 might be the length of the following string "0 4 4 1538" but I don't know the meaning of these numbers
4 is the length of the string "Init", this is of course the name of the preset
5 0 0 18 000000100100100000 0 0 32 I don't know what this is, and it changes sometimes
1600 is the number of the following 7-bit values.
These 1600 7-bit values must be converted to 1400 Bytes. Look in the source code how the conversion is done. The meaning of the 1400 bytes is described in helpText[] in the source code. There are a few bytes that are still unknown.
Michael
-
Thanks Michael!
-
I have uploaded a new version, same links as above. Three small improvements:
1. The name of the preset may now contain space characters.
2. The "Coarse" values of the three VCO's are also shown in semitone steps.
3. The output format of the printout is now Rich Text Format.
If you find out the meaning of any of those bytes that are still marked as "unknown" in the diff.txt file, please let me know.
Michael
-
... Look in the source code how the conversion is done. The meaning of the 1400 bytes is described in helpText[] in the source code.
Is the actual source code posted online or are you just scraping readable text from FW image, (e.g. od -c)?
-
... Look in the source code how the conversion is done. The meaning of the 1400 bytes is described in helpText[] in the source code.
Is the actual source code posted online or are you just scraping readable text from FW image, (e.g. od -c)?
I don't understand your question. The posted source code was written by me.
Michael
-
Yea, I understand. At first I thought you were making reference to MCC source. And I'd be shocked, albeit pleasantly surprised, if Arturia actually released the code to the GP.
-
When you analyze an unknown preset, it's also good to know which modules are used and which are not used. I'd like to add this info to my software. The question is how to decide if a module of the MatrixBrute is actually used. Please let me know if you agree to the following logic:
(http://www.astro-electronic.de/MatrixBrute_Modules.jpg)
Thanks,
Michael
-
The only thing I could find after staring at this for 5 minutes, was the fact, that LFO 1 might also be used if the "Mod Wheel" Button in the "WHEELS" section is set to "LFO 1 Vib".
-
I have uploaded version 1.2 of my software, same link as above. These things have changed:
-- You can start the software and use the "Open File" button to load any *.mbpz file. It's no longer required that the filename must be test.mbpz
-- You can also start the program by dropping a file on it.
-- The 0_*.* and 1_*.* files are automatically extracted to a temporary folder. This folder is deleted later. The program does no longer delete all 0_*.* and 1_*.* files in it's folder. It's now safe to use the program in any folder.
-- In the printout file is now indicated which modules are not used by this preset. The filename is printout.rtf
Michael
-
Excellent work, kudos for supplying the source! Will test it soon.
This could be combined with https://forum.arturia.com/index.php?topic=92104.0 to automatically create patch sheets for existing patches, which might be useful to see how a patch is build.
It's a shame the community has to reverse engineer this (even if rev-eng is a fun activity!) - this should be info made available by Arturia, ideally by storing the preset as a readable xml instead of a obscure serialized string (which might/will change between firmware updates).
This does not make much sense
"22 serialization::archive 10 0 4 4 1600 12 FallingFifth 5 0 0 18 000000100100100000 0 0 16 1536 21 47 70 127 79 127 127 127 43 79"
compared to
...<VCOS><VCO1><FINE>30</FINE><SUBLEVEL>64</SUBLEVEL>....etc
I can see arguments for making it hard to put data into the brute (my manipulating/creating mpb-files), but parse & display them should be documented/self explanatory.
-
That is great work Michael, thank you. Can you give an example on how this can be useful, maybe I am missing it. Keep in mind that MatrixBrute allows you to determine knob/slider position for any preset by pressing PRESET and moving the sliders and knobs.
-
The use would be to quickly get a overview of a patch (as if the knobs could be automatically set to the right value after a patch change)
I think the 2-hand operation of preset+turning knob far from optimal. A better solution would be to show the value when turning (as the display has no useful info anyway, just the patch number).
Anyway, the need to turn all knobs to see the patch is not very user friendly either.
I have just started on a program to visually show the complete patch, based on the excellent decoding work of Michael. Still very early version, all it can do now is open a .mbpz or a .mbprojz and list the patch names and indicate if a sequence exists for the patch (but I'm coding on it now!)
(It's in java, not c# so i must re-implement parts of Michaels code)
The plan is to make a electronic version of this one https://forum.arturia.com/index.php?topic=92104.0 , where you can load a complete 256 patch file (or one single patch) and quickly select & show the patch you want. At the moment based on the exported file from MCC, but with some more work it could be possible to also get the patch data from the sysex dump in the "midi debug" section of MCC (=quicker work flow) - I have not looked a lot at the sysex yet (just made a small "sysex diff" util just for this purpose), but after a quick look it seems like the sysex does not match the data in the exported files, so probably MCC decodes the sysex, and rearrange the data somehow before exporting to file (probably they must have some mechanism for handling changes in sysex / MCC patch data after new functionality is introduced f.ex should new patches have space for custom LFO's -but old not).
It should also be possible to easily make a "create patch sheets" button to generate sheets for all 256 patches (or a selection).
I have also started to decode sequences (far from finished, very strange layout there...some notes uses 5 values and some 4, with no clue of why!)
With some luck/work details of sequences can be visualized also.
If anyone has any good ideas for this program, please add a post here.
If someone already started on decoding sequences, or have more information than given in this thread / Michaels code I would appreciate cooperation :)
When (and if...) I get something usable runningI will create a new post.
-
Great effort and I applaud you for that, but remember this is a modular synth, even if all VCO1 (for example) levels, mixer, etc. are set to 0, there may be modulation settings in the matrix that would change that value, which means that even if the program detects 0 values at one point, these values may change due to modulation. Your program would need to also detect any VCO1 (in this example) modulation settings in the matrix. You're almost there, take a deep breath, recharge and finish your work. You can do it.
Best Regards
-
Remember: if the knob is at "50", and the matrix modulates it down to 10 - the knob is still at 50! If the knob was at 100 it would be modulated down to 60 (which might be a function of time also). Conclusion: it is relevant to show the position of the knobs even if the matrix modulates it - but in case of modulation that must also be shown!
Michael has also decoded the matrix, so it will be accounted for.
At least by listing out each matrix connection like this (don't know any better way to do that (might mark knobs modulated in some way), as it can be from 0->a lot of lines):
Column 9 has destination [Steiner Cutoff] and depends on:
-21% Row E [LFO1]
-56% Row H [Mod Wheel]
83% Row J [Aftertouch]
Column 10 has destination [Ladder Cutoff] and depends on:
16% Row E [LFO1]
100% Row H [Mod Wheel]
100% Row J [Aftertouch]
But remember: the position of all knobs will be shown correct according the the knob setting in the patch - for the same sound to be produced the knob will need to have that setting - and that is not depending on the matrix (but of course the matrix will influence - you will need to configure the same in the matrix as the patch you copy).
The configuration of the matrix is a very relevant part of the patch.
To sum up: You need to know that "VCO1 - saw = 75" and that the matrix modulates that knob with XXX.
The aim for me is to show all (or as much as possible) of the parameters saved from MCC so you can (in theory) recreate the patch from the patch sheet (my main goal is to quickly get a overview of as much as possible of a patch) - and as long as I can export a patch from MCC, and you can import it and it sounds the same this should work - the theory is that you can get exact the same sound by punching my patch sheet manually (but a lot more work :-))
What is not accounted for is if you use CV in/out to modify - but that is not reflected in the MCC-data either.
And to clearify - I do this project because it's fun to program and fun to decode this type of data - not because i really need it :-)
(but it would be nice to have something, as Arturia strangely enough ignore the need of a VST-editor with real time update of MB knob movement etc. That should be the default now, if you make a synth you include a VST editor for it (if possible - for MB it is, for the behringer analougs like neutron maybe not...)
And they also refuse to share the sysex documentation, which makes it harder to secure us users full access in the "far" future (when MCC is no longer compatible with the current OS).