*.mbpz reverse-engineered

[Lunatic Sound]

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".

[mkoch]

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

[Brutefactor]

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.

[knasser]

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.

[Brutefactor]

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.

[knasser]

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

[Brutefactor]

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).