Battery 3 from Native Instruments is a drum sampler from around 2013. This is in the manual:
Remember, machines don’t kill music, people do—and quantization is one of the main weapons.
...
Quantizing everything is the quickest way to suck the life out of a piece of music.
I've been trialing this for the last few hours. It was quite slow at first, but now I'm getting around 300-400tps. Still nowhere near 1000tps, but it's still incredibly fast compared to what I'm used to with other models. It's quite capable as well. I asked it to present strategies for training an AI to play fighting games and it gave quite well-reasoned output. It searched the existing my existing knowledge base for details about the game's internals, including record/playback, and it's own general knowledge about the game is played. It wasn't sycophantic about my opinions either - it challenged me appropriately.
I think they might have a really decent model if they can deliver their advertised speeds at scale at reasonable prices. A tiered approach could work well.
I suspect that we may soon be seeing a modern version of VHS vs Betamax. Betamax was better quality, but VHS beat it in virtually every other metric that mattered to most consumers.
(yes, I'm aware the analogy isn't perfect for many reasons)
I've all but given up on these types of approaches. Models will often just ignore your process instructions at the most inopportune moments. For work, I've resorted to mostly just using single agents for smallish pieces of work that I orchestrate myself. I treat it as a tool, with me being the craftsman.
Everyone is pushing Agent Fleets and Swarms, and I'm sure that there are many success stories, but from our internal experiments many devs don't see any speed advantage for complex work. Here's what one of them told us recently: "The speed advantage is offset by the manual refactoring work. The code is 'correct', but it's just not what any of us would have written".
Now one could argue that you could just ignore the code if it's working (that is in fact what Ex Co instructed us to do) and just keep running these fleets if the end result "works", but I'm not fully convinced this will end well in the long term.
Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...
First I wasn't sure if technical debt still matters but I think it absolutely does. As long as I'm involved in the planning phase at all, the complexity of the code base still bubbles up to me. Claude will say: ok we can build that but how should we handle legacy code paths A,B,C,D that no one needs and I wasn't even aware existed.
I think the current LLMs benefit from the modular design, but also from things humans would hate: arbitrary uniqueness. If you have three services, your main() function better just be a single call to a unique function else they're going to slowly lose track of which one you're talking about.
I broke apart a 1k length script into functional components because the local AI just couldn't figure out where edits landed. But once that was complete, it had no problem tweaking features in those scopes.
I think the real TAM is local coding models starting around 32GB sometime in 2027. Obviously, Capitalism gets to decide what we're blessed with but knowing that you can get Qwen3.8-Flash-Next running at around 40GB VRAM with SSD offloading means data centers are either going to become way more efficient, or they're going to die on the vine.
> Then again, I'm stuck with decades of legacy code and systems that noone understands that were introduced by humans...
But that's despite many efforts made to keep that code understandable, maybe even documented. If now that's not even tried the results will be a thousand times worse - and the dependency on the LLM absolute.
The only time I ever few like I need agent swarms is when I am doing mechanical whole-codebase migrations/verification.
The LLMs are so much faster than I can check the output anyway. If I have a long-running task I just work on another one in parallel while I wait on the first one.
The advantage is not so with speed, but with autonomity and doing MORE work. The benefits are clear when you stop micromanage your agents and start scaling their work
It's also a way to make the system more reliable in terms of doing the work!
But I think many people are still missing the point about how AI systems should learn. Arguably, with people we tend to hire and "grow" in-house experts as opposed to outsourcing everything, so why shouldn't we build a system that learns from experience, from its failures?
At first I thought the key was in skills, but skills are static, while you need a continuously learning system
Agreed on all counts. Once you set up an alignment and verification system, you really see how many gaps are present in initial code generation, regardless of what might have been specified.
Even if you have a basic skill-based workflow, a rudimentary retrospective > process improvements artifact that can be ingested on the next run can have a positive impact.
> The code is 'correct', but it's just not what any of us would have written".
I'd fine with not what we'd have written ... if it worked.
Trying ChatGPT for a simple one page of HTML JS having draggables, I said clamp touch point to visible viewpoint. Fine. Then I said add 3x drag gain. It put that after the clamp, whereas anyone/thing having an ounce of intelligence would have urecognised the only possible purpose of the clamp and so put the gain before.
This is fundamentally why we cannot trust stochastic parrots to code. They lack the human's understanding of purpose which cannot be abstracted from the code yet is essential for success.
Brother what “report” are you talking about? Do you mean your comment? The one with your story that ended before the resolution of your problem was reached?
I've been using DS v4.1 Flash daily for nearly a month now on Agent Swarm experiments. I've tested it against GLM-5.3-flash and Opus 5.5. DS 4.1 comes out tops for me. Opus 5.5 is still the smartest, but DS 4.1's speed and price more than make up for the "intelligence" gap. I've ran Chief/Builder/Reviewer swarms autonomously for multiple days. I think my new workflow is going to have DS 4.1 Flash do all the engineering and just have Opus review its work. 4.1 Flash really is a very impressive model. Kudos to the Deepseek team.
My current experiment is running a Chief of Staff pattern within herdr, nothing too fancy. You should be able to find quite a few resources on the net.
Huh? This is a new checkpoint. It has identical architecture, only different weights, and most likely just more post-training.
Much like Qwen 3.8 Next; which is qwen4-exp in a lot of the code/patches, there's usually a tick-tock cycle with LLMs. That said, it's hard to know for closed frontier models.
Probably not universally true, but good writing is a skill regardless.
And maybe they are "too long" in the same way that Lean proofs are "too long"? I have no idea - I don't read either very often.
However, often I don't care how verbose a piece is if it can hold my interest. For example, the late Umberto Eco wrote some of my favourite pieces. He was a philosopher (among other things), and many of them - notably of the "post-modern" - are known to be particularly verbose.
I use it at work. On Windows it also launches a new console window every it executes (?) a command. You should definitely disabled this using --no-daemon.
I don't know how and why they ruined this CLI with needless "features". It was perfectly usable two weeks ago.
A bit off-topic, but on the rare occasions I help some acquaintance with Windows I always feel a bit upset that random split second console windows still pop up when installing everyday software, even that from Microsoft.
I remember them from way back on Windows 98 and no one seems to care to hide them (?).
I tried really hard to get senior management to understand this where I work. Yes, AI is an accelerator, but that doesn't necessarily mean it's going to accelerate you in the "right" direction.
I wrote about this recently on one of our company's IT channels. I called it "slop-fatigue". I - and others - have started to get noticeably dismissive of content that appears to be written by an LLM. The whole thing was a piece about the ironies of software development in the world of LLMs. This part spoke about how easy it is to generate docs now, but it's also even easier to dismiss it. This contributed to cognitive-debt, because humans didn't write the docs, and other humans tend to dismiss the content. I saw a recent reaction to this on HN as `ai;dr`. That's almost exactly how I feel about it.
Remember, machines don’t kill music, people do—and quantization is one of the main weapons. ... Quantizing everything is the quickest way to suck the life out of a piece of music.
https://docs.native-instruments.com/pdf-guides/Battery_3_Man...
reply