It all started few days ago when i noticed ArtCraft visual creation suite. I tried it, and was pleasantly surprised with its first steps (being it is obviously vibe-coded). New versions pilled up quickly, and with every new version, bugs & annoyances were shrinking. I’m not sure what i actually think of it all(morally), but it’s there and it is what it is…
Today i went to visit linuxdaw.org after a few months and i was stunned by the sheer amount of new plugins available.
First of all - how to know which ones are vibe-coded and which are not?
Then, does anyone here use vibe-coded plugins and how do they behave in Ardour?
Are there any good and functional ones?
Are they resource heavy&safe? The last thing i need are resource heavy plugins that are also AI agents backdoors (and is that even a thing/real world issue?) ) .
Right now i trust and belive only in ancient known ones (airwindows, dragonfly, surge, gx etc), but i wonder is there a point in checking these new ones out?
A related question about resource usage and safety (both audio data safety, and personal information theft safety) of new plugins is what source code data were the LLMs trained on? There are many notorious instances of plugins making…I think the most polite description would be “sub-optimal choices” in design and implementation. I don’t think we really need a flood of plugins created with an LLM trained on CALF plugins (which is probably not far fetched, considering how widely distributed they were, and how easily available the source code).
It’s not just plugins being created in the spirit of “vibe-coding” - entire DAW programs are emerging that are built this way. I’m referring not only to “SoundCraft” (from the ArtCraft suite) - a Pro Tools clone - but also, for instance, to “FaderFrame,” which is, frankly speaking, amazing. It is a native Wayland application that supports X11 plugins, including their graphical interfaces… Even Fender Studio Pro can’t do that. I never imagined that “vibe-coding” would make it possible to create things like this.
Most of the AI generated DAWs are likely only possible because the models have been trained on open source projects which actual developers with real knowledge spent years of their time creating from scratch.
We are currently in the early (stage 1 more likely stage 2) of the AI enshitification cycle, and when we reach stage 3 and the true cost of these AI tools used to create (and required to maintain) these projects have to be paid for, without billionaire subsidies, we might see less of them. Unfortunately by then those who know how to do this stuff properly will likely have been disincentivized and that knowledge will be extinct. Welcome to the future.
Its kind of ironic and oddly amusing to see these vibe-coded renditions of commercial apps being created to liberate them (and their users) from the “tyranny” of a commercial business model, when in fact the only reason they are possible is because the tools used to create them are at a different point in the cycle. Once the inevitable enshitifactory business pressures kick in, it’ll become apparent that all they’ve really done is replaced one tyranny with another.
That’s aside from any (inadvertent) AI laundering of proprietary code, intentionally or otherwise, and / or AI washing of licenses, proper attribution etc. And without considering the ethical, environmental and socioeconomic costs associated with (generative) AI.
Somehow i find it very hard to appreciate anything vibe-coded. I guess i wouldn’t mind it in cases where the programmer understands what he “coded” and uses ai basically because he’s to lazy to type it, check the syntax etc, but he’s perfectly capable to correct and change anything by hand. But, as i understand the current situation, those cases are very very rare.
So, in cases of plugins, you should optimize because of latency or stability issues - you can’t. Your users are telling you about the issues they noticed - you can’t react with your magic patch made of pure experience . Your plugin behaves erratically at certain times - you can’t tell what the hell is wrong with it… That shiny new plugin might seem to be a super-cool looking vibey thing, but at the end of the day, i find it hard to appreciate.
AI or not doesn’t change the quality or performance of code. I think if one relies entirely on AI without understanding what’s going on that inevitably leads to issues. There’s no real way to tell other than to use something and see if it works well, AI or not.
Well i guess there’s an obvious upside for real programmers here vs ai slopers… Successful vibe-coding in c++, from what i can gather, isn’t really an easy thing to do, and i guess there’s a good reason c++ is still the most used language for audio related stuff - like optimizing for speed and memory allocation?
That’s one of the main reasons why i’m asking are these plugins any good&stable …I mean, vibe-coded plugins that should handle realtime audio?..Aren’t they inherently more likely to introduce more latency?
Ouch…that felt like a small punch below the belt. Suddenly i feel old (and i never did in this brave new world, whatever it threw at me) . AI music&art ain’t fun, and it is everywhere. AI coding is no fun, and i was hoping to begin to code again which i didn’t do since childhood. I even messed around in VSCodium and bought a real, physical item book on c++ - which, by the way, clearly wasn’t for me, cause it it was all about advanced structural concepts. Hell, i even tried to comprehend & use NeoVim for an entire day .
If you want to code, then code - AI isn’t stopping you from doing that. To me its no fun using AI to code - I’ve always wanted to understand how things work at a deep level, and I learned to code (for some definition of learned…) because I enjoyed the intellectual challenge and generally the pursuit of knowledge. Using AI to write code, especially without relevant experience to guide it is literally like just asking someone else to do it - you can enjoy the result, but you’re now in a management role - that never (and doesn’t) appeal to me.
From what I’ve seen of vibe-coded DAWs (and to some extent plugins) is that they provide a (too easy) way for a user to scratch a particular itch - a lot of it is “All the DAWs I’ve tried didn’t suit my workflow, so I made my own” - and one has to wonder why a DAW created by someone who perhaps didn’t understand the normal workflow well enough, would think that their workflow is going to revolutionize the process for everyone else. Learn the process first (its served talented audio engineers for a long time) before going full Dunning-Kruger with an AI
The quality of AI coded plug-ins is variable - if you want to do what I do (without AI) and build software inspired by actual hardware, a schematic and an AI doesn’t cut it - you need the actual hardware and / or a deep understanding of it - all of which costs. You need to appreciate the effect individual component specifications and tolerances have, even if you build a circuit model from a schematic it won’t necessarily be right if an individual component model is off (the 1176 is a good example - a lot of its character depends on specifics of individual JFET devices, that are obsolete, and or have aged, you won’t get that from a generic free component model)
There’s no real reason why an AI coded plug-in should be more or less latent than any other or more or less optimized than any other - stability maybe - I’ve seen several where the UI just doesn’t work properly (I guess that’s harder to automate tests for). Its also hard to automate tests for how plug-ins (mis)behave in specific host applications, and historically that has been where most of the ‘gotchas’ are (on both sides).
Security - usual caveats apply - for example free (Windows) binaries may not be code-signed, (because aside from ideological objections, that costs money and normally requires documentation and creation of a company / legal entity), so that removes a level of provenance. I’ve also seen AI generated binaries for platforms a developer admits they don’t test on - meaning the user might literally be the first person to run their code. I wouldn’t want that to be me.
I’ve always wondered how programmers translate the function of a capacitor into “code.” There are various types of analog capacitors—parallel-plate, film (wound), and electrolytic, for instance. The different insulating materials must surely affect the voltage flow, which in turn influences the sound. How is this modeled when recreating analog sound-shaping equipment in the digital domain? Are there any resources available that explain this in a way that’s accessible to a complete beginner? Apologies if this goes beyond the scope of the discussion—I hope it’s not entirely inappropriate to ask this here.
I don’t mind using some AI to generate code, but you have to understand what it does, IMO. I have seen a few times how some people use AI to build HTML/CSS/PHP/whatever, and they hit a wall when customers want changes. AI is used even in operating system programming, but I suspect those will outlive any vibe-coder plugin in the long term.
After two decades, I’m playing with C++ again, or maybe I should say C++23, which, in my limited experience, isn’t quite the same language as C++17, not to mention older versions.
To me, C++23 is now more or less the language I want C++ to be, and I’m trying to learn it. But when I experiment with AI and try to leave old-school stuff like std::cout behind, AI doesn’t help much. In my, again, limited experience, it’s not good enough to see modern C++23/26 as anything beyond, let’s say, C++13, which makes code messy and, to me, slightly confusing, and I have to modernize it manually.
So what happens with these plugins? Are they guaranteed to work, or to exist as expected, in the future? AI is still getting better and better and easier (?), so I guess that it does not matter. But I probably won’t use plugins I know are vibe-coded. I have so many great plugins, both open source and proprietary, made by people and organizations I trust, so if I use a plugin I know is vibe-coded, it should be something very special.
C++ STL is huge by itself. To say you really “know” C++ is unimaginable to me. I guess the best attempt in learning it would be to get a glimpse of it’s logic, how it’s generally structured and it’s syntax by following simple examples, and then dig in using existing examples in fields you’re interested in and informed about. To learn it by learning all of it’s functions sounds insane to me. On top of that, i find C++'s syntax incredibly hard for noobs with all the necessary punctuation etc (luckily, there are IDEs)…
On the other hand, saying it is interesting is an understatement.
When I first started “coding” - on 8 bit machines about 40 years ago, I used to write code in assembler language. In some cases, when there were only a few KB to play with, the binary was the source code, the idea of an IDE was absurd That was probably the last time I could say I knew everything about a language.
I’ve been coding in C / C++ for longer than I care to remember but my particular ‘dialect’ probably leans a little more toward C than modern C++ . I have what I consider a comprehensive knowledge, enough to express complex concepts, but I’ve only scratched the surface.
FWIW I find Rust difficult. I don’t mean I find it difficult to understand, I mean I find coding in it difficult. So you can imagine that AI coded Rust is my own personal vision of hell…
I’m completely ignorant of how the Ardour team does it, but the theory and technique is taught in an undergraduate electrical engineering curriculum. Once one understands the continuous-time concepts behind Fourier transform theory, it can be extended to the sampled-time domain and the so-called “z-transform”. Once this is established, modeling any linear component or network for purposes of simulating its behavior in a computer program becomes straightforward.
In my case the heavy use of the Matlab program from Mathworks was crucial to really understanding how this all works.
Component level circuit modelling is a complex topic to say the least - the massively oversimplified version is that non-ideal component behaviours can mostly be modelled as a combination of ideal components. Ceramic capacitors might have non-linearities for example, or an inductive element in the case of a wound construction. Determining how much that matters in a plug-in where there is almost always a tradeoff between I hesitate to say - unnecessary - accuracy vs performance is part of the art.
.