Vibe Coding an Audio Plugin with Cursor vs Claude Code

Hinzugefügt: 2026-05-06

[00:00:00]In our last episode, we vibe coded an audio plugin and I built a planning tool to help structure things up front and the result was better. It wasn't perfect, but overall we had cleaner code and fewer surprises. Since then, people have been asking me if I've tried cursor because they've seen some better results. And the honest answer is no.

[00:00:19]I've been heads down with Claude code, so today we're going to give cursor a spin together for the first time and I'm going to share my observations. I imagine that this experience will be something like using a different DAW.

[00:00:30]Same core principles, but different workflows. So today we'll download cursor for the first time and try to find my way around, set it up with Claude so that we're comparing apples to apples with Claude code and try to build the same ping pong delay as the last tutorial. It'll be the same product requirement document and I'm curious to see if we get similar, better or vastly different results. Honestly, I have no idea where this is going to go. Some of you have told me that cursor is highly addictive and life-changing, while other people have said that it makes a complete mess and we're about to find out. Before we dive in, if we haven't met before, my name is Josh and I'm the director of the audio programmer. We'd love for you to join our community and learn together on Discord. You can find out more about this and more on our website theaudioprogrammer.com.

[00:01:15]If you find this video helpful, be sure to give it a like and subscribe. It's a great way of showing your support for what we're doing. And without further delay, let's dive in. So here we are on the homepage for cursor, cursor.com and here we can answer the question, well what is cursor? From what I understand, cursor is an AI-powered code editor that's built on top of VS code.

[00:01:35]So people have told me that if you've used VS code before, a lot of it should look familiar. Same sort of shortcuts, extensions and layout. The main difference here is that AI is baked into every part of this editor. So you have things like smart auto complete, a chat panel and an agent mode that can read your project, edit files and run commands. So conceptually, it sounds a little bit like Claude code and VS code having a baby. It's Claude code, but in a visual editor like VS code rather than in a terminal. So one thing that I'm seeing here that looks particularly interesting is that it looks like you can choose from different models such as Claude, GPT, Gemini and a few others. So when we set this up, I'm going to try this out with Claude. So it'll be something like driving using the same engine, but driving it inside a different car. So let's go ahead and download cursor. I'm going to try this hobby plan here that's for free and see how far we can get with that. So let's go ahead and download this.

[00:02:34]All right, let's open this up for the first time. Now we're going to sign up.

[00:02:38]All right, I'm all signed up and it looks like we have some options here where we can connect our Figma or our notion into this. I'm just going to skip this for now.

[00:02:47]And here we are. We're in cursor. Here we have some options that have popped up in the bottom left to import our settings and extensions, so we'll go ahead and import those.

[00:02:58]And we'll say import.

[00:03:02]And we also have an option here where we can use cursor commands from the command line. I'll go ahead and install that.

[00:03:09]Looks like I'll install using cursor.

[00:03:13]Let's do that.

[00:03:16]And okay.

[00:03:19]Putting in my password.

[00:03:24]And now we can launch cursor commands from the command line. All right, now I'll create a new project.

[00:03:33]Let's just put this on our desktop.

[00:03:37]Create here.

[00:03:39]So here we are. Uh this looks very similar to VS code and we're presented with this dialogue that's asking what we want to work on. Before we jump in, I want to make sure that we're working with the right model. So let's just jump up here to settings and then let's go down. Here we are in models.

[00:04:05]Very interestingly, it looks like you can run more than one model at a time.

[00:04:11]Um so I'm not sure how that works. Maybe that's something I can look at a little bit later, but I'm just going to switch [snorts] on um Sonnet for now since that's what we used for Claude code and let's just use that. So I did a little bit of digging into how the models work and model selection. So what you do is you can enable or disable your model selection here and then in the agent itself in the chat window, what you can do is if you're on a paid plan then you can switch between the models.

[00:04:49]This isn't available on a free plan that we're on now, but if I upgraded to pro, I'd be able to switch between the models here. If you keep it on auto, then cursor actually selects the model that it wants to use depending on what task that you you're asking it to do.

[00:05:09]Otherwise, you can actually um just select your model and there'll be a drop-down menu here. Just wanted to uh let you know that, so that's a little bit helpful for considering what model that you want to use.

[00:05:23]So we're going to start with this prompt. Let's build an audio plugin together using this PRD that I've attached. Please ask focused questions one at a time to ensure we get the best and most accurate outputs possible. So this is something that I love to do, especially when you're starting off on a project uh so that your LLM uh can uh ask questions just to make sure that it's getting the best idea of what you want to do. And just to go through the PRD again, here it is. So we're creating a ping pong delay plugin. So this is stereo ping pong delay effect and that we have the parameters here, delay time, feedback, mix and degradation, which is like a tape saturation type of effect.

[00:06:14]We have a tempo sync system that will have a tempo sync toggle button, note division selector with these different options and a timing modifier that gives us dotted or triplet notes.

[00:06:31]And then here are some notes that we have on the behavior that we want.

[00:06:37]And then we have some other things that are out of scope.

[00:06:41]We're not going to worry about a preset system, side chain input or any of those things. So that's what I have dropped in here and let's see what it comes out with.

[00:06:51]>> [snorts] >> So it's read my PRD and it thinks that it's great and it's asking which framework we want to use for the plugin implementation, JUCE or iPlug 2. Very interesting that it's given me these two choices. Um kind of makes me feel like those are the only two choices. So out of curiosity, I want to ask, are there any other available frameworks? Just to see how it responds.

[00:07:15]Okay, so it's given us a few more options here to consider. We have the raw SDKs, of course. We have HISE, great for instruments, distro and DPF, which are open source plugin frameworks, traction engine, which is better for DAW-like projects and we have NIH plug for rust-based frameworks.

[00:07:37]And it's saying for our PRD that JUCE is still the most practical and documented path.

[00:07:45]And now it's asking if we want to prioritize teaching clarity or production robustness. Since we want to see the highest quality of code that it could come out with, let's go for production robustness.

[00:07:58]It's asking if we want to use CMake or the Projucer for this. We will use CMake. Wants to know if we want to create a new plugin project with a new folder or if we have an existing directory. So we'll create a project called time warp cursor with a folder with the same name.

[00:08:16]Okay, so it already started jumping in and coding things out. I didn't realize that it was just going to jump in like this. So what I've done is I actually stopped it for a second because I want to be able to supply it with my coding practices template that we created in our last video. So we have this claude.md file and this is where we outline what framework we want to use, which is JUCE, the C++ version we want to use, which is 17. I'm using CMake with CPM and some of the coding principles that I like to have like single responsibility, small functions and separating out the DSP and following um the JUCE coding style, things like that.

[00:08:59]So here's my prompt. Can you delete what you've created already and start again using the coding practices and guidelines that I've outlined in this file? Let's see how it handles this.

[00:09:08]Okay, says it's removed everything and now it wants to recreate the project with time warp cursor using CPM with CMake as the first step and I said, yes, please, let's go ahead.

[00:09:32]Okay, so we've arrived at this point and let's see what it's got. So it says that it's recreated the project from scratch using CMake with CPM with C++ 17, clean processor, editor split and so on.

[00:09:47]And now it's saying, do you want me to run the first full configure with elevated permissions so JUCE can be fetched {slash} cloned correctly, or continue implementing the DSP first and build after. Actually, I'm a bit confused what it's asking here. I don't know what it means because I just kind of expected it to build the plug-in and just show me what it had when it was finished.

[00:10:14]So, I'm very curious. I want to check out what it's done so far. So, let's go over here to the files. We'll go into the folder here. Let's look Let's first look at the C make list and see what we've got here.

[00:10:30]So, C make version is fine.

[00:10:36]We have the project.

[00:10:38]We have CPM that's being added. All looks good.

[00:10:43]And Okay, so Uh okay, this looks interesting. I'm not sure what it's done here.

[00:10:52]It looks like it's put everything twice.

[00:10:56]Um unless I'm misreading this. So, it's named the project again. So, project is up here and it's basically done everything again.

[00:11:09]And this time it looks like it's using fetch content rather than CPM.

[00:11:15]So, it's actually looks like it it actually looks like it's done everything twice.

[00:11:22]So, very confused what it's done here.

[00:11:23]It's basically done this wrong. Um not sure what's happening here. Um So, okay. So, how to answer this question? So, I don't want to call it out on its error just yet. What I'm going to do is I'm just going to say build a complete plug-in including the DSP, then compile and run in standalone mode, and let's see what it does here.

[00:11:51]All right, looks like it tried to run the time warp cursor in standalone mode and it crashed. So, I'm just going to okay out of this crash here.

[00:12:02]And I'm going to hit run again.

[00:12:05]Let's see what happens. Okay, looks like it's built successfully. This isn't inside a DAW, so I can't run audio through it to test it just yet, but let's see what it says here in cursor.

[00:12:16]Says that it implemented the complete plug-in and got it running in standalone.

[00:12:20]Uh removed duplicate merge code that had been accidentally appended in these files. So, we saw that a little bit earlier.

[00:12:29]Implemented the DSP.

[00:12:33]Did the tempo sync UI behavior in the plug-in editor.

[00:12:39]And then it's configured and built successfully.

[00:12:44]And then it's saying if I want I could do a type validation pass against the PRD audible behavior checks and edge cases like sync toggling.

[00:12:55]Okay, I think that this is a good idea.

[00:12:58]Uh so, let's say yes, please run the validation.

[00:13:05]Curious to see what it's going to do here.

[00:13:08]All right, this is what it says that the validation passed, that it's built all of the formats successfully.

[00:13:15]It's checked all of the code and that all of these supposedly pass.

[00:13:22]And it says that one caveat is that it can't hear the output in the environment. So, we're going to have to actually check this out ourselves and see if it sounds right. So, let's go ahead and load this up in a DAW and see how it sounds. Okay, here we are in Ableton and I have a vocal sample loaded up along with the plug-in. Let's just listen to the vocal sample. Hey, yo.

[00:13:47]And let's go ahead and activate the plug-in again.

[00:13:51]And the first thing that I notice is that there are no parameter names next to these uh different parameters, which is kind of inconvenient. But, um I'm sure that we can figure it out. So, this first one here, I think is delay time.

[00:14:05]Hey, hey, yo.

[00:14:10]It's pretty good. Uh I don't know if you're getting that through the speakers or not through YouTube, but that is a stereo delay. So, that is ping-ponging left and right.

[00:14:19]This second one, I believe is feedback amount.

[00:14:24]>> Hey, hey, yo.

[00:14:25]>> [cheering] >> Yeah, so that's feedback amount. Hey, hey, yo.

[00:14:31]Pretty good. Then we have wet dry. So, THIS IS DRY. HEY, YO.

[00:14:35]WET. HEY, YO.

[00:14:40]SO, this is nice because we can see that it's actually doing what it's supposed to be doing. And then this is supposed to be some type of degrade effect. Hey, yo.

[00:14:49]Yeah, so that's that's same sort of thing that we got from Claude code, which was like a low pass filterish type of effect. Let's see if the tempo sync works.

[00:15:01]So, turn on our metronome.

[00:15:03]Hey, yo. Hey, yo. Hey, yo.

[00:15:07]Yep.

[00:15:09]Let's try eighth. Hey, yo.

[00:15:11]>> [cheering] >> Yep.

[00:15:16]And then 16th. Hey, yo.

[00:15:19]Oh, let's give it a little bit more feedback. Hey, yo.

[00:15:24]Nice. Let's see if the dotted and triplet works. Hey, yo.

[00:15:31]Yeah, nice.

[00:15:33]That triplet.

[00:15:35]Turn off the degrade. Hey, yo.

[00:15:42]Cool. So, a couple things to say about the plug-in itself. I mean, doesn't have the parameter names, but I didn't ask it to name those. I guess if I didn't ask for it, then it's up to the LLM whether it does it or not. But, from what I can see here, it pretty much does what it says on the tin. Now, let's go ahead back to the code and take a look at the code itself.

[00:16:06]All right, here we are back in cursor.

[00:16:08]And first thing is that when I opened cursor, I saw a dialogue that updated.

[00:16:13]So, I hit update expecting it to hold all of the context in the previous chat, and it actually erased it. And there's no way for me to get it back. So, that is a little bit inconvenient. I would have expected it to be something like GPT or Claude where it would have held the context for the chat, but it's all gone. Um but that's okay, just a small thing uh that's not a big deal at this stage. Um but maybe something to consider before you update. Uh make sure you save your project.

[00:16:43]Okay, let's go ahead and just take a really quick look at the code quality here.

[00:16:50]Do a little code review.

[00:16:52]First thing is the C make list and taking a look at this, it all looks pretty standard.

[00:16:59]Uh all looks much cleaner now. We don't have any confusion. It's using CPM like I asked it to.

[00:17:07]All of this looks clean. Um I mean, there's not much to mess up here.

[00:17:14]But, just taking a look, it all looks pretty tidy to me.

[00:17:18]Now, let's go ahead and take a look at the source file. Uh we'll go to pluginprocessor.h first.

[00:17:24]Okay. First thing that I notice is that it's got some erroneous um error marks here saying that it's not found. This is actually a problem that I've been having in CLion as well recently where I'm seeing these errors besides beside the JUCE namespace.

[00:17:44]Not sure what's happening there, but that those aren't errors. Um Another thing that I see here is that it's used JUCE header. Uh once it once again, this is the thing that you know, isn't necessarily uh um an error or a bad thing. Uh I prefer to use the specific headers for the objects that that were and classes that were using within that file rather than using the entire JUCE header for every file.

[00:18:15]I didn't specify this, so I I guess I couldn't really expect it to to to know that and to do that. But, when I did use Claude code, it did actually use the specific headers rather than using the entire JUCE header.h.

[00:18:32]>> [snorts] >> All right, so I wasn't satisfied with letting those red squiggles hang around and went for a fix here. And the first thing that I did was I installed the clangd extension from VS Code. So, that is how the code is read and the errors are determined. Uh and that I installed that, that still didn't fix it. But then, uh what we did was we replaced the generic JUCE header, which once again loads the entire JUCE library as a as a header file, and replaced those with the actual module names, the module headers of the specific objects and classes that we needed. And that actually fixed our um our erroneous errors that were that were appearing. So, now we should have a clean slate here and we can go and we can actually look at the code here. So, I'm just going to close this out for a bit.

[00:19:32]So, as I was saying, um look going back to pluginprocessor, now we've replaced JUCE header with the specific header for the audio processor or whatever objects we're using within here.

[00:19:47]And that's cleaned that up nicely. Um just taking a look through this file, everything looks quite standard. Uh Uh, there there there really no surprises here. We have our DSP that's coming into our audio processor via delay engine. We have these two functions, calculate effective delay time in milliseconds, uh, which is taking the millisecond timing and uh, and if we're using the tempo sync, then it's actually calculating in the correct tempo sync. And then we have another function for updating DSP parameters, which is your update function that's going to update when your parameters change from the plugin. Let's go ahead over to the CPP file.

[00:20:35]Once again, >> [clears throat] >> all of this is looking pretty good, pretty standard.

[00:20:42]So, we have this function here, update DSP parameters.

[00:20:48]Um, we have the delay engine, which is our DSP processing that is uh, that's calling prepare. We'll take a look at that in just a few minutes. So, let's take a look at update DSP parameters. And we'll go down to this function here.

[00:21:06]And all of this looks quite standard.

[00:21:09]So, we have a couple consts that are getting the delay time in milliseconds, it's getting the it's getting the value.

[00:21:17]These functions are getting the value of the parameters from our audio processor value tree state. And if you don't know, um, this these terms that I'm talking about, I actually have many tutorials on the channel that are talking about all these things, setting up an audio processor value tree state and your parameters and how to get those values. So, that's what all of these are referring to. And I can put some links to those in the video description below.

[00:21:46]So, from there it's taking and it's setting all of the values, uh, as uh, and and um, and just updating the values here in the delay engine.

[00:22:00]>> [cough and clears throat] >> Let's go up to our audio callback.

[00:22:06]Uh, so, this should be if I just maybe search for buffer, maybe.

[00:22:13]There we go.

[00:22:14]So, we have our process block.

[00:22:17]And process block, I love that it's looking minimal like this, so no spaghetti code, uh, nice nice and clean.

[00:22:26]So, I can see that, uh, it's kept our node to normals, uh, then it's doing the update DSP parameters here again.

[00:22:36]So, going back here to that function, one thing that I can see that is probably not problematic for this type of plugin, but would be problematic for a larger plugin, is that all of the values are being updated every single audio callback. So, every time that you're calling this, it's getting um, it's getting the value that's coming from uh, our parameter tree and it's using that to update our delay engine.

[00:23:12]Uh, a better way or a more optimal way of doing this would be to have it set either to a listener that's listening for changes when the user is making a change in the dial and to only do the update if they sense if if it um, triggers a change from the user. Uh, so, but but this is updating every time. So, I'm probably not a problem when you have four parameters, but if you had maybe a hundred parameters, if you were doing a very large plugin, that would be uh, more problematic. So, what you want to do here is either have uh, a value tree listener, which you could inherit from here in the audio processor, or you could um, compare the two values between the whatever the delay or whatever the feedback percentage was from the current callback, set that into a member variable, and then when it does the next callback, see if those see if the value has changed and if the value has changed, then do an update, otherwise just leave it alone, so it doesn't unnecessarily have to do updates.

[00:24:28]Then we have this uh, calculate effective delay time in milliseconds.

[00:24:32]So, it's um, what it's doing is it's looking to see um, if we're we're doing tempo sync and doing the calculation here.

[00:24:45]I have to be picky, I would say that maybe this would be a free function, so something that's not specific to audio processor, but something that's a little bit more generic.

[00:24:56]But I mean, I'm being >> [clears throat] >> picky there for a plugin this small, I think that it's fine.

[00:25:02]Uh, yeah, I would say that all of this looks pretty clean and tidy to me. Taking a look at the parameters here.

[00:25:12]Uh, let me just close this here for a second.

[00:25:15]And I'm um, yeah, everything looks everything looks pretty standard. I mean, when you're when you're doing a smaller plugin like this, I would say that there's there's not much to mess up really, not as much to mess up, but I would say that uh, that that we're looking pretty good here. Not seeing anything that's that's problematic.

[00:25:42]Not sure what this what the problem is here.

[00:25:45]Okay, so so we have a little a warning here.

[00:25:49]Um, that you know, one warning. So, that's another thing that I notice here is that not seeing a whole lot of warnings um, at all, which is which is nice.

[00:25:59]Okay, let's take a look at uh, I don't know if there's really going to be much to see here in the plugin editor. So, we have the slider attachments, um, you know, one of the things here is that these are unique pointers. This is something that I used to do um, back when I was giving the first JUCE tutorials and yeah, these are not these are unnecessary. These could just be slider attachments rather than unique pointers.

[00:26:26]There's no reason for them to be unique pointers, but hey, now it's in the um, >> [clears throat] >> it's in the memory forever of JUCE code and um, yeah, so I can blame myself for that.

[00:26:39]So, nothing really to see here in the in the uh, in the editor here, all of this looks pretty standard, the way that it's laid out and everything.

[00:26:52]Going over to the delay engine. So, I'm not much of a DSP expert, so I'm not going to be able to really look at the algorithm unless I really like step back and took some time to take a look at it.

[00:27:06]But one thing that I really like that it's done here is that it's used the JUCE smooth values. So, you want to use smooth values whenever you're doing uh, very quick parameter changes over time, otherwise you get this kind of zipper effect that happens, uh, and so, it's good to see that they've used that.

[00:27:27]Taking a look at the prepare function, it's uh, it's all looking pretty good here.

[00:27:33]Uh, it's resetting all of the smooth values, updating the coefficients.

[00:27:40]All standard stuff that I would expect to see.

[00:27:44]Um, the engine is when you're resetting it, it's uh, it's taking it back to its default state.

[00:27:53]All looks pretty good.

[00:27:57]And taking a look at the process function, uh, can't really see anything here that looks out of order. All of it looks fine to me. I um, and and you know, just as importantly, listening to the plugin itself, it all sounded like it functioned correctly. So, if you're looking to write a very quick generic delay plugin for one reason or another, there you go. It's it's, you know, it's it's as easy as just popping it in, making sure that you have a really tight specification and, you know, letting Cursor do its thing. So, how do I feel about Cursor? Well, at first it worried me a little bit. In the middle of creating the plugin, it asked me a weird question that I didn't quite understand and the C make at that point was all jacked up. I told it to finish the plugin and it more or less did exactly what I asked. There were some things that could have complained about, for example, not having labels for the parameters and using the entire JUCE header rather than specific module headers, but those could have been nailed down with a few more specifications up front from my side. I didn't ask and it didn't do it, so I can't complain about that. One thing that I will say is that it asked me if I wanted to build for testing and robustness. I said yes, but I didn't see any testing frameworks in there or particular optimizations that were any different from what we got with Clog code. In fact, if we were strictly evaluating performance, Clog code would have come out with the win here for using a parameter listener to update the parameters rather than just updating every single audio callback. One thing I do enjoy about Cursor over Clog code is the ability to cleanly see and edit files within the same window. That is very, very convenient. In Clog Code, I was giving commands via the terminal, then fumbling around in another IDE to view the files separately. That being said, all of this is convenience and could be easily remedied in a number of ways. For example, I could have just used the native terminal in C line and interface with Clog Code via the terminal. Very simple fix. So, my conclusion is that so far, these tools feel more or less interchangeable. But with that being said, I've been asking it to do some relatively easy stuff, focusing more on how well it reads and carries out my requirements and guidelines. My prediction is that this may change as we get towards more complex workflows. For example, building complex user interfaces or using multiple agents to carry out work. I can see some very interesting potential, such as using multiple agents building versions of similar plugins using different models, then communicating with one another to determine the best practices and having them win out. I'm also interested in seeing how these models perform and break when giving it more complex specifications that don't fit neatly into a box. With that, it's time for us to wrap up. Let us know what you think in the comments. Are there vital areas that I missed or workflows that are working for you? I'd love to hear them. In the meantime, happy coding and I'll see you next time.