It was as the prophecy foretold. But at what cost?
2 Likes
Elektron won’t know what’s hit them
3 Likes
grim reality of course is you’d have your rasperry on the desk, and to start 16+ buttons and an LCD, couple of midi components, a soldering iron and a bottle of tequila.
I would estimate a few days of discussion with the bot - you might get a 16 step midi sequencer running.
Still, compared to never for a noob, that is still fun and the start of something more accessible
1 Like
The even grimmer reality is that behringer would’ve already cloned it before I got that far
there was a behringer groovebox ‘in the works’ at one point…
Haha, there’s a reason behringer isn’t really cloning complex digital stuff that isn’t already open source, too much of a black box.
1 Like
Uli on 24/7 suicide watch rn lmao
Will the AI write the manual too? Can’t do much worse than the OG Swedish human one…
Video or it didn’t happen
1 Like
instead for the curious minds among you, the firmware .syx file has the following structure:
an header std::vector<uint8_t> startingSequence = {0xf0, 0x00, 0x20, 0x3c, 0x0c, 0x00, 0x7f, 0x01}; that is followed by 8 bytes, the last one 0xf7 is closing the packet.
then follows 0x29a6 blocks of data encapsulated with the following header{0xf0, 0x00, 0x20, 0x3c, 0x0c, 0x00, 0x7f, 0x02};followed by 119 bytes of data and lastly with the usual 0xf7 byte.
At the end there is a closing footer, starting with {0xf0, 0x00, 0x20, 0x3c, 0x0c, 0x00, 0x7e, 0x00}, followed by 8 bytes and as usual the 8th is 0xf7.
the curious thing is that the first two bytes of the block of data are incremental over the blocks then jump to other values and then they increment again, for example the first fifteen blocks have values that go from 0172, 0173, 0174… to 017f. Then there is a jump to 0200 to 027f. these are other jumps to give you an idea:
block: 90 — from 027f to 0300
block: 111 — from 037f to 0400
block: 192 — from 047f to 0500
block: 213 — from 057f to 0600
block: 294 — from 067f to 0700
just logged when there are jumps this goes like that until block 29a6.
Isn’t that curious? I wonder if it’s part of the data or a progressive that is part of the message. I stripped the data from the block and streamed them into a file, but didn’t go further than that. I can’t see any strings on the file, i expected to find strings as when you look into .so object. I checked if the file was a zip file but it’s not. Suggestions? 
`
Edit: maybe the header contains some sort of version number and the footer a checksum?
A small coterie of wealthy hierarchals, robber barons and nepo-babies who need to find reasons to believe themselves better than the rest.
Hallucinating essential design steps and code because the LLM doesn’t actually know anything beyond saying things plausible enough that people who don’t know the topic end up impressed with a skim, that’s not only “never for a noob” but could likely dissuade them from completing any project after being gaslit by constructed gibberish.
Much better to just start off with some Adafruit project or build a M8 Headless to get knowledge than have to spend much more time debugging than actually learning the process!
That’s the thing, people skim and say “cool” because it looks cool but don’t spend enough time to know the fairly extreme limitations over the Clever Hans - Wikipedia style parlor tricks.
Design of digital circuits is also likely to get him successfully sued in ways that analog layouts would not.
3 Likes
I got two boards from ST with STM32, you know what these guys do? No, I have to show you.
They made an Ide called STM32CubeIDE, based on eclipse if I remember well.
int main(void)
{
/* USER CODE BEGIN 1 /
Logger L(“main”);
/ USER CODE END 1 *//* MPU Configuration--------------------------------------------------------*/
MPU_Config();/* Enable I-Cache---------------------------------------------------------*/
SCB_EnableICache();/* Enable D-Cache---------------------------------------------------------*/
SCB_EnableDCache();/* MCU Configuration--------------------------------------------------------*/
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();/* USER CODE BEGIN Init */
/* USER CODE END Init */
so basically you are supposed to write your code inside the right comments cause if you do not and the project is regenerated your code is basically deleted. how reliable can it be? I mean, seriously…
I think that understanding the project file is much easier than what you could expect
It should be simple to code!
look at this:
00000000: 504b 0304 0a00 0008 0800 5206 2157 fe07 PK…R.!W…
00000010: c647 6b00 0000 9e00 0000 0d00 0000 6d61 .Gk…ma
00000020: 6e69 6665 7374 2e6a 736f 6eab e6e5 5250 nifest.json…RP
00000030: 5072 cb2f ca4d 2c09 4b2d 2ace cccf 53b2 Pr./.M,.K-*…S.
00000040: 5250 32d4 3350 d201 4b05 14e5 a794 2697 RP2.3P…K…&.
00000050: 8454 16a4 0225 a241 6240 510b 882c 9065 .T…%.Ab@Q…,.e
00000060: 64a0 0462 c542 5527 56e6 e427 a680 8c70 d…b.BU’V…’…p
00000070: 8d08 5030 3030 841a e396 9993 0a35 0364 …P000…5.d
00000080: 6456 6a72 095c a628 b73c b128 15c5 7633 dVjr…(.<.(…v3
00000090: 4357 a0b1 b500 504b 0304 0a00 0008 0800 CW…PK…
000000a0: 5206 2157 7bfa f664 c212 0000 923e 0000 R.!W{…d…>…
000000b0: 0700 0000 4558 5020 3030 31cd 5a09 7853 …EXP 001.Z.xS
000000c0: c5da 7e67 cec9 d234 ed24 dd59 6c4a a540 …~g…4.$.YlJ.@
000000d0: a140 d296 9d42 8b80 8002 6153 40d4 a241 .@…B…aS@…A
you see where it says manifest.json on the left? (ok it’s not formatted correctly cause the font is not monospace so you don’t see proper alignment)
that’s a good sign I’d say. EXP 001 is the name of the project.
IT SHOULD BE SIMPLE TO CODE!!! aahahahahahahhahahahaha
Edit: It’s actually a zip file, so we know that elektron rytm can zip and unzip files now 
Not sure what you’re asking me here, vendor provided toolchains can be rather specific about what they’re expecting.
Ah I’m not asking anything, I think it’s quite bad design… People on the forums complained about losing their code for some IDE bugs… I mean, I understand what kind of problem they wanted to solve with that… but honestly the solution for me is terrible…
1 Like
so unzipping a arprj you get two files, a manifest.json and a [project-name] file.
the manifest content is like this:
bloom$ cat manifest.json
{
“FormatVersion”: “1.0”,
“ProductType”: [
“8”,
“20”
],
“Payload”: “EXP 001”,
“FileType”: “Project”,
“FirmwareVersion”: “1.61E”
}
the EXP 001 looks like a binary file, I can see the string KIT 1 so I guess around there there is KIT information, I suppose it’s just a file with the parameters dumped one by one. defo possible to reverse engineer.
Midi is sent as 7 bits instead of 8. A semi standard method of packing is to transmit the low 7 bits of 7 messages and then all their MSBs as an 8th message. Another is to base64 the stream and just send it 7 bits at a time
1 Like
Yes but once you have a sysex and you know that the block is 128 bytes in total, the body of the 119 bytes can be fully made with 8 bit of information, isn’t it?
The 7 bit thing I think applies when you have to keep the first bit 0, so you can distinguish a control byte (is called like that?) from the info byte…
Edit: sorry they are called the status byte and the data byte
Edit2: On second thought that may apply always so you can catch up with the info even if you start listening in the middle?
No the first bit of every sysex byte is 0, and in most (possibly all) schemes the bits are rearranged so you can’t just strip out the first bit and jam them all together. If you look in the back of a sequential manual you’ll see an example
1 Like