Randomizer
Regarding a randomizer I started on one during christmas, that initially was intended for the Matrixbrute - but limited to the parameters controllable by midi CC. It was quite close to finished, when I discovered this project https://midi.guide/ which collects Midi CC for a lot of synths. I decided to make it more generic, so it could import synths from this library - but as usual spare time is limited in periods, and it’s been on pause for last couple of weeks (but with the intention of finishing it, hopefully soon!).
Here is a example of how it looks after importing the Microfreak definition from midiguide lib, and randomizing the Oscillator section (taking into account that the “Type” parameter should not be randomized). I discovered quickly that it is useful to be able to ignore some parameters, and also limit the range of other to get useful results.
I will make a post when v1 of the randomizer is ready for testing!
The matrixbrute patch format
I have documented much of the format, taken from mkoch’s program (*.mbpz reverse-engineered ), and decoding much of the data not included there - including the sequencer format for my MatrixBrute Patch Viewer (MBPV) as described in this post (and other posts in the old forume linked from this): https://forum.arturia.com/t/updated-matrixbrute-patch-viewer-now-available/2376
Unfortunately it seems to be not as good doc as I hoped, as the project was put “on hold” some years ago before I got to write the doc properly with it fresh in mind.
I have thought of expanding MBPV to randomize patches, but I decided to never change any data that could be uploaded to the MB as I do not know how MB handles bad data - f.ex can it be bricked by corrupt data? I have not found any indication of a check sum being present on these data either.
Here is some background info on probably why your AI project failed:
The AI is right in one thing: decoding the format is not a small, quick task! It requires lots of iterations of changing a few parameters in a controlled way, downloading the patch, comparing / diffing it to the previous to detect differences -which must be done on the data after converting to 8-bits as described below, so a custom tool is also useful.
The .mbprojz file is a zip containing 256 patches and 256 sequences split into 16 folders (1 per bank), so randomizing the actual .mbprojz doesn’t make sense as the zip format will be broken. You can open it with f.ex 7zip and look at the individual files (f.ex 01-DEVICE-A1.mbp which is the patch for slot A1) - I assume you did unpack and randomize the files inside.
This is a file containing all parameters for one patch (sequence in a separate, similar file with the same name but .mbs), and it looks like this:
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 … + a lot more - it contains ca. 1600 numbers.
This file seems to be the output from a serialization library for c++ called Boost, and the numbers you see does not correspond directly to a parameter. The list of numbers are 1600 7bit numbers, with to be useful must be decoded to 1400 8bit numbers this way:
* Input: 200 blocks x 8 bytes - each byte uses 7 bits,
* The first byte in each block holds all top-bits for the next 7 bytes
* Output: 200 blocks x 7 bytes - each byte uses 8 bits
*
* Data format of one data block - 8 bytes is 1 block of “7 bit” bytes
* Input: (bit 7 not used) Output:
* +0 = %0ABCDEFG
* +1 = %01111111 +0 = %A1111111 Top bit from input+0 bit #6
* +2 = %01111111 +1 = %B1111111 Top bit from input+0 bit #5
* …
* +7 = %01111111 +7 = %G1111111 Top bit from input+0 bit #0
When unpacked you will have a list of bytes representing a patch, but still some values have specific ranges of legal values, or might be 1 bit, 1 byte or 2 bytes likethis:
LFO1 Waveform (0=sinus,1=triangular,2=square,3=reverse sawtooth,4=sawtooth,5=sample&hold,6=random,7=custom)
Some parameters, like the matrix A1 is used is stored as 1 bit in a byte together with bits for A2-A8.
Some paramters, like mixers, vco etc are 2 bytes (16bit values)
There is also more than one format of this file, depending on the firmware version it was created with.
In older firmware some data was placed differently, f.ex before the matrix was expanded from 16x16 to 28x16, the “used” flag (0 or 1) was stored in 512 bytes (256 x 16bit numbers - big waste!), after it was stored as 32 bytes (using individual bits) - probably to make space for the extra 12*16 matrix values of 2 bytes each
Even if randomizing each “byte”, I assume the MB have checks on some parameters, to avoid a parameter like LFO1 waveform where only 0-7 is legal suddenly having a value of 25.
For randomizing all parameters (not just CC), the best way might be to analyze the sysex when MCC down/uploads 1 patch to see how that work. Again, probably lot of work, as for some reason sysex documentation seems to be treated as company secrets these days!
