Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Comments
AI is definitely advancing. But I've seen lots of these kinds of essays over the last couple years. They have a few things in common.
Who is the author of the article? Why, just a guy who runs an AI subscription service that generates writing
. It's quite telling that he insists "you gotta pay for the premium" in order to really understand what AI can do. Here's a critical response to the article by a professor of neural science (who also has an AI company, natch).
The actual nature of LLMs is that they have significant architectural flaws that are not overcome by simply creating better models and adding compute. And there is no evidence to suggest that it is possible to overcome those flaws at all. Simply pointing out that AI has improved a lot recently is not proof that its problems will be magically resolved over time.
From the (AI) horses mouth:
“ Yes, AI is already transitioning from using human languages to designing new, "AI-native" ones.
AI-Native Languages: New languages like Dana and Pel are built specifically for AI agents to communicate and execute intent without human-readable boilerplate.
Performance Optimization: AI is driving the creation of languages like Mojo, which combine the simplicity of Python with the raw speed of C++ to better handle modern AI hardware.
"Alien" Logic: Using genetic programming, AI can evolve code that is functionally perfect but follows patterns incomprehensible to humans, potentially leading to machine-to-machine languages that bypass human abstractions entirely.
Invisible Infrastructure: In the future, coding languages may become "invisible infrastructure". You will describe your goal in plain English, and the AI will generate and run a custom, highly-optimized language in the background to complete the task.”
Ultimately it's their app and they can charge whatever they want. I liked it so I will buy it. But what I said in my original post is what happened. In his manual, he states that it was vibe coded and he decided to release it because it just happened to "work".
Not to belabor the point, but you said "I do have a problem with charging $10 for an app that you admit was vibe coded ... " etc.
I was only addressing that part of the comment. It wasn't like they just wrote a prompt and charged $10 for what came out. They worked part-time for six months on it. They also pay the $99 per year to make it available in the App Store.
No big deal. I'm not here to start an argument.
Anthropic (creator of Claude and Claude Code) is quite open about how much of its code is AI generated. For example, Claude Code itself was created by a small team (four or five) in the space of two weeks and apparently has around 90% of its own code generated by Claude:
https://fortune.com/2026/01/29/100-percent-of-code-at-anthropic-and-openai-is-now-ai-written-boris-cherny-roon/
Yes, I don't know exactly what vibe coding is. But I do know that Boris Cherny of Anthropic said this back in January:
Not sure I get it. If you port faulty logic from one language to another it will remain just as faulty. I'm also not sure that "perfectly optimized code that doesn't work" is a concept that even makes sense. That is, if someone gave me some code and maintained that it was "perfectly optimized" despite it "not working", I'd be left scratching my head about what they were thinking
It was reading that post that prompted me to start this discussion here:
https://forum.loopypro.com/discussion/67585/anyone-coded-a-music-or-other-type-of-app-entirely-using-ai#latest
The suggestion that you could just tell AI what you wanted an app to do, and it’d go off and code, test and even make suggestions for improvements, seemed a bit far-fetched to me, so I was interested to see what coders on here thought about it.
So yeah, I agree, a lot of pro-AI PR going on there, but also some points worthy of further consideration.
Well put. those were my doubts too. That linked article reports prior accusations by some AI researchers that his earlier model’s capabilities were exaggerated:
https://oodaloop.com/briefs/news-briefs/reflection-70b-model-maker-breaks-silence-amid-fraud-accusations/
https://venturebeat.com/ai/reflection-70b-model-maker-breaks-silence-amid-fraud-accusations
Given that history, readers should demand proof before accepting his anecdotal claims. As written, the piece reads promotional and relies on fear-based rhetoric rather than verifiable evidence.
xcancel for people who don't want to give clicks to x, btw.
https://xcancel.com/mattshumer_/status/2021256989876109403
I said "perfectly optimized code", not "faulty logic". If it's perfectly optimized that means it's perfectly efficient. If the underlying language and compiler doesn't like that code, it won't run, there are two options: Change the code to be less optimal but work with a language and complier that can't run it, or modify the language so that it can accommodate this brilliant code.
We write code to fit the constraints of available language and compilers. If the language and compiler aren't themselves perfectly optimized then we currently have to modify our code to fit their constraints. If the code is logical and optimized and the language itself can be optimized to accommodate it, that can in some cases be the better answer.
Until now humans design programming languages. They do so with a set of assumptions that don't work for all cases. Because they're hard to change, we change our code to fit their constraints. It no longer has to be that way.
One aspect of the power of AI is it doesn't have to know how to do something. It can iterate through millions or billions of permutatoins until it finds the most efficient way to do something. Humans don't have the luxury to spend that kind of time in problem solving.
You said "perfectly optimized" and "doesn't work". That's the combination I find odd. If it doesn't work, it seems it must be because of faulty logic. Or, if you maintain it's nevertheless "perfect" and a competent compiler rejects it, I'd say that unless you can show me a bug in the compiler, it's not "perfectly optimized" code. Otherwise, I'm not sure how code can be perfectly optimized if it won't even compile and run. If "the underlying language" doesn't like that code, again, I struggle to understand what "perfectly optimized" might even mean. (And how a language itself could be "perfectly optimized" at all is I think, slightly different, but again an incoherent concept. Maybe my brain is just too small. Or I'm misunderstanding something.)
OK,I've explained it as well as I'm able. You are assuming a zero sum game where the language and compiler rule. I'm saying it's not a zero sum game. The language and compiler might be bug free but not designed as well as they can be. We currently change our programming because it's "cheaper" to do so than to improve a programming language. It no longer has to be that way if re-designing one is as easy as re-designing the other.
Haha. You are too polite. i thought you might just respond, "Yes, your brain is too small."
On that subject, programming languages themselves can also be thought of as unnecessary layers. We use programming languages (and operating systems themselves!) as constructs to make producing code that directs chips to do things feasible time-wise.
Now I'm wondering if we really need these languages at all. If a machine can code at the CPU level directly, why bother with the overhead? "Make my computer calculate the square root of 25301" really doesn't need to be produced in python, C++ or any other language in order to be interpreted into machine level code.
That's kind of scary too though since operating systems and languages also supply the guard rails that keep bad shit from happening.
Never. If I can't communicate what's in my head, it's either wrong, ridiculous, or my brain is too small. 😉
I just give up pretty easily when I can't get over that hurdle.
I can't find it now, but I recently read someone's blog post where they suggested that, if we're using AI to write the code anyway, we might as well have it program in C, because C compilers tend to produce the most efficient machine code. C is of course difficult for humans to read, but that matters less and less if we get to the level of AI being more trustworthy than humans at coding. The logical extension of that would be using AI to write in assembler or machine code directly.
[Though I would maintain that the machine code of a chip is itself a language (it's literally called "machine language"), and at that level the absurdity of saying "this (machine language) code is perfectly optimized but it won't run or doesn't work on the chip" is clearly exposed.]
Interesting conversation here…
As far as languages go, C is most definitely not difficult to read or write in. It is possible to write difficult to understand code in C, but that’s true of most programming languages.
If a human isn’t going to look at the code being generated, I can’t think of a reason for AI not to skip the intermediary compiled or interpreted language and write directly to the hardware.
As a programmer for nigh on 3 decades, and a CTO in my day job, I have thoughts. I use Claude Code quite extensively, but in a very structured way that involves getting it to write out its plans, interrogating them with it, rewriting and eventually letting it write some of the code. Last weekend I tried to get it to write me an admittedly fairly complex delay plugin, without me writing any of the code. There were things it did a great job of, and things it did a terrible job of, but the end result was absolute garbage. It had a nice interface, but god only knows what the hell it was doing with the audio routing behind the scenes. My takeaway from the session was that an audio plugin might just be one of the hardest things you can try to get AI to do if you don't at least have some understanding of low latency audio programming. Partly because it's actually incredibly difficult to describe in words how you want the audio to flow through the system, and partly because it can't try running the plugin and listening to the results. The sort of things I use Claude Code for are time saving tools for personal / work use that have deterministic behaviour and can be described in full in a test suite. I suspect though that someone with at least a little bit of knowledge of low latency audio programming will be able to get something considerably better than I managed because they'll be able to see the mistakes it makes and have the language to explain to it what it's done wrong.
I do have an idea for a midi AU to try next, and I suspect it will do a far better job there because I can accurately describe the system it needs to create, and that system can be expressed in tests.
Well, I gotta say, while I'll almost certainly never vibe code myself (for my own personal reasons)...
If this app is an example of what vibe coding can enable for someone with good ideas that wouldn't otherwise have turned them into an app, I'm all for it. This is a great app.
One can also argue that it may have come out much less good, if at all, if the design and development process was constrained by programming ability.
I wouldn’t dare charge for it if it didn’t genuinely offer musical value.
What a fascinating thread! I hope to find time on the weekend respond and comment. A few points for starters:
AI won't replace genuine ideas and creativity. If your prompt is "create a reverb", you'll get "a reverb", like stock reverbs you already own and don't use. Thrash in, thrash out. Yes, something basic can be done easily, so for sure we will see thousands of lo-fi tape effects and delay plugins that sound exactly the same. If we think AI is spitting out something creative, it's only because we are ignorant and we just don't see from whom AI stole it.
AI won't build anyting more advanced if you don't understand basics about real time audio processing. I didn't write a single line of C++ code (I'm serious), so, coding per se is not a must, but if I wouldn't know what PPQN is and how to create swing by changing PPQN timing, I wouldn't build the plugin. Without earlier Reaktor/Max experience, the best I could do is probably a AUv3 wrapper for Grids as exists in Eurorack. I hope all users of Augmatic GRE can see that the plugin is much more than that. I'm not diminishing amazing work by Émilie Gillet, but I hope I contributed something to it.
AI will never say "I don't know", so when something doesn't work as you expect, AI will try to "fix it" effectively creating problems and breaking things that used to work. I didn't learn C++, but I had to learn Git ;-)
I will make the code available probably by the end of March, for professional JUCE developers to see if AI did a good job.
You did great. Separate engines for each hit, blending between grids and euclidean per hit, the linear priority thingy. That's all very respectful of the original, while extending the functionality in really useful ways. I assume that this all came out of what you did over time with miRack ... and I'm glad I don't need to face a patch like that.
If there was one single thing that I think would improve AI in general - that is it.
... hopefully while there are still any skilled coders left. 😉
..
Thank you so much!
I think that my project shows how positive vibe-coding can be. I built prototypes of Augmatic GRE in VCV and miRack, also in Max, but it wasn't as handy as a self-contained plugin. I can't afford to hire a JUCE developer (although a very skilled one lives in my city), so I tried to build it on my own.
I’m not worried about AI replacing skilled developers. The hype is already cooling off. Yes, we’ve seen big leaps between GPT versions, but training the next model in monster-datacenters that use 10% of U.S. electricity isn’t going to magically produce AGI. That was Sam Altman’s sales pitch, but the industry starts to realize, that it's not reality. AI is leveling off: it’s an incredibly useful tool for people, but nowhere near to be an autonomous replacement. I recommend recent Cold Fusion's videos about this topic.
I haven’t read much about vibe coding but it does seem like it could potentially be great for community led projects as it matures. On the loopy pro slack for instance, there’s really great group discussions about new features and how they should work. I can imagine AI being part of discussions like this in the future and producing the code once the idea is ready, or even coding multiple ideas so everyone can try them out and vote for them.
On the flip side of this, I’ve tried using ChatGPT for some basic css coding and it’s been an awful experience.
Same case for me. I actually used a stronger model via a browser first, to do research, write specs, which I would review and then feed to Claude Code as a 10-pages long prompt. I wasn't checking C++ snippets, that were included in the specs, but overal signal flow, application logic, if you will
Same again. One thing that Claude surprised me was the foundation of LINEAR DRUMMING which is detection of events occuring "at the same time". I know quite well what it takes in Max to detect that events occur at the same time, but Claude got it right at the first shot, with quite simple prompt.
I agree, but I think the reason why it's difficult is different: there is not as much DSP C++ code available for AI to learn from, as for reguar, non-real time desktop apps.
When Claude couldn't do something, I was trying to find open source VCV module that was doing something and telling Claude to learn how something works. Not to steal the code, but to "teach" Claude some concepts, like how transport/PPQN is altered to create swing. It was kinda funny, Claude made 6 iterations of SWING feature which failed misarably - it tried to delay or accelerate notes AFTER Grids, and it's impossible to know ahead of time what Grids will send out. I was trying to explain how it works in Max (Philip Meyer did a great job in "Swing Rhythms in Max" video), but Claude wouldn't get it until I pointed it to a VCV module that has build-in swing and Claude quickly responded almost literally "aha, you were right all the time, now I get it".
In a sense, it felt like a conversation with a very good C++ developer who can build RDBMS kernel, but has no idea how real time audio works ;-)
Hey @Augmatic, thank you very much for joining in the discussion here - obviously you’re the perfect person to comment on the experience of vibe coding an app to fruition.
I just wanted to restate, as the the person who started the thread, that it was reading on your website about how Augmatic GRE was coded - and my admiration for your honesty in being open about it - which prompted me to ask people’s opinion on vibe coding and what it could mean as the experience of doing so gets easier and the results more reliable. I absolutely didn’t create the thread meaning it to imply any sort of judgement on Augmatic GRE as a finished product - by all accounts here it seems to be very impressive. If, though, you would prefer me to take ‘Augmatic GRE’ off the thread title, please do say. Cheers.
They are going in that direction with their next models, according to OpenAI. The training of next token prediction in current models has given too much incentive to make a guess when being uncertain.
Here is a writeup from September: https://openai.com/index/why-language-models-hallucinate/
LLM hallucination and confident guessing are not inherent byproducts of LLMs that always have to be there, it is just a side effect of the current training objectives and evaluations.
No worries at all - I never took anything negatively. On the contrary, I’m genuinely and very positively surprised by how constructive the community is here.
I also wanted to be open about the whole vibe‑coding aspect from the very beginning. I’m using the original Mutable Instruments Grids code, which is licensed under GPL‑3.0, so I knew from the start that my own code would need to be open as well. For me, that’s actually added value. I really hope some developers will dig into the code, and that this will give all of us a much clearer picture of how good AI really is for plugin development.
Question: is Augmatic GRE the first 100% vibe-coded plugin?
Interesting insight. Context: I'm a JUCE / C++ dev and don't use AI tools at all.
I think it might be hard to evaluate clearly on a relatively complex project like yours. Not to say it doesn't have value of course.
I think it would be interesting to let AI loose on a much simpler project, at least in scope, but with some known typical pitfalls / gotchas. This would be very much like the coding test you'd get when going for a developer role. That would be how I'd evaluate how good AI is for plugin development, much in the way I'd evaluate a real person if I was going to hire them.
My €0.02.
PS. I might take a look at the code when it's available if I have the bandwidth. Also, might be worth consisdering posting on the JUCE forum if you haven't already.