Very cool! I posted my own experiments in this area a few months back, which were an iteration on an existing Ableton MCP. It’s great to see more people experimenting in the spaces of interfacing with complex applications and music production.
One thing I don’t cover in the blog post is ensuring your MCP tool calls are well documented. (If it’s an existing MCP you can do this with a README or instructions file.) I saw a jump in efficiency when I manually edited the docstrings with examples of when each tool would be used, how to call it, and better argument descriptions.
Author here, I think you’re spot on. If I set out specifically to make a mashup and spent the same number of hours working toward that goal I think I could have gotten to the same place. This was a journey that started with wrapping my head around MCP and LLM local software interoperability, and my Ableton knowledge leveled up a lot along the way.
I think this tooling could be useful in the hands of more capable musicians / audio engineers / etc. as there are often repetitive tasks in DAWs and it could potentially unlock new workflows that would have been too tedious without knowing how to program.
I think it just got folded under the umbrella concept of model alignment. And it moved from theoretical discussions to practical daily struggles with LLMs deleting failing unit tests
That’s exactly what I have. The C++ codebases I work on build against a specific pinned version of LLVM with many warnings (as errors) enabled, and building with a different version entails a nonzero amount of effort. Ubuntu will happily install several versions of LLVM side by side or compilation can be done in a Docker container with the correct compiler. Similarly, the TypeScript codebases I work with test against specific versions of node.js in CI and the engine field in package.json is specified. The different versions are managed via nvm. Python is the same via uv and pyproject.yaml.
three.js might not be the right fit for computational rendering/raytracing, optimization techniques like frustum culling are more or less baked into the engine.
vscode remote containers are still the standard, but I find them very usable nowadays. My setup is a MBP M2 that I use to remote into a Windows WSL setup at home, a Linux desktop at work, and various servers. Nesting remote SSH + remote Docker works seamlessly, that was previously a major headache.
Take a look at the MCAP file format (https://mcap.dev), we invented it for the robotics industry but it’s a generic write-optimized container format for time series data. Since it’s a container format, you need to choose a serialization format as well such as flatbuffers or protobufs.
It’s not just you, this is a fundamental challenge in programming. I think this paper by Peter Naur lays out the reason why it’s difficult, because software is a lossy representation of a theory held in one or more individuals heads. The original author had a model for how a problem could be solved by written code, and how that code might be extended or refactored in the future to solve related problems. No amount of API design or naming conventions or documentation can perfectly capture those ideas.
Verdant Robotics (https://www.verdantrobotics.com/) does targeted herbicide applications using weed detection and a two-axis turret, with a laser-based variant in the works.
My company is remote only and the money saved on office space has been reallocated to additional team outings and a longer runway. Constant outings sounds a bit overwhelming, personally.
Even for our company, we would fork over the $600 but it looks like all of the EV cert options require a hardware signing key. Putting a human in the loop for our otherwise fully automated release process is a non-starter.
I had the opportunity to go down to JPL and speak with team members about this design decision. The space hardened processors are not fast enough to do real time sensor fusion and flight control, so they were forced to move to the faster snapdragon. This processor will have not flips on Mars, possibly up to every few minutes. Their solution is to hold two copies of memory and double check operations as much as possible, and if any difference is detected they simply reboot. Ingenuity will start to fall out of the sky, but it can go through a full reboot and come back online in a few hundred milliseconds to continue flying.
In the far future where robots are exploring distant planets, our best tech troubleshooting tool is to turn it off and turn it on again.
https://news.ycombinator.com/item?id=46428922