I tried to follow the path of @mike a few years ago, but things are in a slightly different place and I had slightly different symptoms, so starting a new thread.
I am trying to upload the current tip of 0.24 tagged branch (d9deea5f99fe011263573b7510db6f01e4589df0) and having issues. I can open the file ytx-main-controller/ytx-main-controller.ino in the arduino IDE, select KilomuxV2-main as my board and export the sketch. It creates a file ytx-main-controller.ino.app.bin.
This file itself can’t be uploaded by the YTX Firmware Manager, but I can go to advanced options and make a composite firmware, first creating a file ytx-v2-firmware-v0-25.bin (just picked a name that seemed reasonable), then selecting the above .app.bin file, then selecting binaries/prev/ytx-v2-firmware-0-22-aux.bin. It forms the firmware, sends something to the controller, but then the controller is just dead, neither responding to or receiving midi. (Luckily I can fix it by uploading the correct firmware binaries/ytx-main-controller-v0_24.bin).
What am I doing wrong here? I assume I’m constructing the composite firmware wrong?
Love the energy and time you’re putting into this
I’d think it’d be really cool if you get to tweak the code and find how to make faster updates.
You can download the split firmware uploader which was the old tool we used and let’s you upload directly the file you get after compiling the project.
You’ll see separate buttons for the MAIN and AUX microcontrollers.
The new firmware manager is intended for users who just want to update their firmware.
It seems though that you managed to build the firmware file correctly using the firmware manager, but surely you’ll prefer less steps while developing so the split uploader will serve you well.
Why it doesn’t boot after loading the firmware could be for many reasons.
Did you make any changes?
Try the split uploader and let me know if something new comes up
Thanks for the response. Is there a mac version of the split uploader? If not, how precisely can i use the advanced builder in the one available for mac.
I made no changes, first trying to get it to build/run. Im clearly doing something wrong, i can try again from scratch. It doesnt even show the rainbow pattern on boot, and the LED in the corner was a different color than normal.
Is the aux firmware supposed to stop at 22? I dont see a 23 or 24 version.
Got the firmware on the box. What I had to do was… ask cursor to write me a script to split an already combined .bin file into a main.bin and aux.bin, then combine the aux.bin that came out with the app.bin i compiled with the arduino ide. So the problem was likely that I was using the wrong aux.bin file. Great. I now have a path forward.
I have successfully added two new SYSEX commands: set LED color by RGB and dump all analog state. Feeling empowered, will work on the harder stuff tomorrow.
Yeah I got it working stably, i can flash the lights at audio rate and the encoders are fine! I also had to compile the aux firmware, so i had cursor make me a makefile and… it worked somehow.
the solution: send all messages in a burst at once and wait for the acks in parallel. no more serial I/O waits. Did the trick.
But the actual code: written 100% by the machine. I don’t generally “vibescode” but… it worked. I’ll upload to github tomorrow and you can decide if you like it.
My controller works great, but I don’t have enough context to understand if the code is “correct”, much less “stylistically correct”. Theres still a circular buffer overrun hiding somewhere, but now the updates are fast enough that I can’t hit it with my actual instrument.
This is the first time I’ve actually “vibescoded” something in the sense of not really understanding what the code is doing, but I feel like I understood the architecture of the controller and the change and why the fix worked. I’m honestly a little… like “what just happened?”
I think for me I can optimize it further with a “flush” sysex that skips the 5ms wait after the host knows its done sending, but it runs stable without that.
That’s the whole spirit for this project to have an open source code, if something is not perfect to your liking you can make it work as you want.
Regarding the fix, or the modification you made to make it work, it’s understandable that it’d make the whole thing smoother and even make the encoders work better, since it’s not blocking the whole controller while it’s sending the burst.
The drawback is that if there should by any communication errors, the checksum would discard a pixel and there wouldn’t be any retries, so the information would be lost.
At some point we introduced a per-frame ACK and retry logic to prevent this, thinking that the speed was “good enough”.
I’d love to see a video of the working controller now!
Ok I fixed the checksums and uploaded a patch to my github. Works great now: heres what it looks like:
Not pictured: I can really quickly (but with a button combo so not while holding my phone) assign and re-assign my analogs to various combinations of knobs (octatrack inspired of course). Thats why its called WRLD.BLDR. I do a lot of improvising and jamming with friends, so I kind of pick the interesting knobs at jam-time and assign them over the course of the jam, so I end up with a different custom physical instrument every time. The joysticks are are just… chef’s kiss. Dream instrument.
