Vibe coding Daisy Seed

[xconverge]

I got most of it working, there's just too little CPU left after NAM, so doing IRs and a doing a screen is a little bit hard to do, thinking about doing a separate ESP32 module to handle inputs and leave the daisy handling the audio

For the IR, I got it to be VERY lightweight, and you can even reduce the number of taps if you wanted to.

Here is just my IR changeset https://github.com/bkshepherd/DaisySeedProjects/pull/96

I add 1ms of latency by buffering the samples (48 samples at 48khz is 1ms), but this lets me use CMSIS efficiently and loop unrolling (ARM_MATH_LOOPUNROLL) to have full length IRs with very little processing power.

If you lower the IR length to 512 (opposed to the 1024 I am using as "full length"), you will have something VERY lightweight that sounds very good still.

That same buffering of 48 samples also allows you to do some similar optimizations with the NAM processing. Furthermore, you could probably get away with adding another 1ms of latency or so to further reduce the processing and still be pretty hard to detect a change.

 

[balazs.bencs]

For the IR, I got it to be VERY lightweight, and you can even reduce the number of taps if you wanted to.

Here is just my IR changeset https://github.com/bkshepherd/DaisySeedProjects/pull/96

I add 1ms of latency by buffering the samples (48 samples at 48khz is 1ms), but this lets me use CMSIS efficiently and loop unrolling (ARM_MATH_LOOPUNROLL) to have full length IRs with very little processing power.

If you lower the IR length to 512 (opposed to the 1024 I am using as "full length"), you will have something VERY lightweight that sounds very good still.

That same buffering of 48 samples also allows you to do some similar optimizations with the NAM processing. Furthermore, you could probably get away with adding another 1ms of latency or so to further reduce the processing and still be pretty hard to detect a change.

I agree, I did the same exact thing! I'm progressing well.. Just so little time to do any of this with a 9 month old who does not sleep without body contact

 

[balazs.bencs]

I uploaded a simple example kicad project that I used to verify everything working. Nothing really complex, I copied the Terrarium project basically and added encoders, screen pins, etc.. Oh also it's SMD, I ordered them from JLCPCB - working absolutely fine.

Works with Bourns PEC-11R or ALPS EC11 encoders too (tested with both)

daisy-multifx-pedal/pcb at main · balazsbencs/daisy-multifx-pedal

This is a multi effects pedal project for the Daisy Seed containing a modulation, delay and reverb effect section. - balazsbencs/daisy-multifx-pedal

github.com

 

[David1972]

Let me start with saying that I know this following topic might be touching some nerves, but I feel the whole AI development thing is becoming more and more useful and that’s where my project started.

Lately I was thinking about getting a Daisy Seed and start messing with projects.
I am a 40yo backend developer from Hungary and we started using a lot of AI in development which I started to like it in the last 3-4 months, when I have complete freedom I am 3-4 times faster than normal - even with brutal code reviews. A lot of people say it is dangerous to trust it, but lately I feel that I want to hate it, but our code reviews have only minor things and I started using more and I am starting to see the value.

One day on my way home I thought that hey I should be able to generate plugdata projects with AI, it should be fun to try it out. I generated a bunch of crap that did not work and I did not like. It was a total failure.

Since I just had a baby, I have zero extra time to learn DSP even with the libdaisy library, but I thought that Claude Code might be good here even after the plugdata failure. I did not know if anything comes out will work, but I wanted to try at least so here we go..

I really like the Strymon pedals with multiple delay options and modulation (timeline and mobius) so I thought I will try to get some of the features of those on the Daisy.

I generated two projects with Claude to mimic these two pedals and I had a lot of success. I asked it to use encoders instead of regular pots, so the Terrarium project will not be able to run this project but my plan is to design a Terrarium inspired PCB design with encoders and display and have more capability.

I am still waiting for my Daisy Seed to arrive so I had no option to try the code on actual hardware, so I asked Claude to generate a VST plugin with Juce so that I can test the code and set parameters and make changes if needed. The plan worked, the VST plugin works and is using the same code that will run on the Daisy.
Most of the delays are actually good sounding so I have high hopes.

After this delay code worked fine, I copied the project and gave claude the strymon mobius manual in html format and told him to delete all delays and make effects the same way what is described in the manual. I created a big plan with Opus and Sonnet coded the whole thing. That plugin works too, I will post it soon after some code review.

Git: https://github.com/balazsbencs/daisy-delay-pedal

I have CI build set up, so you can download the Daisy firmware file as well as the macos compatible VST3 file.

Since I am so new to this, I thought I’ll post it here and encourage people to contribute, I feel this might be a cool project, even if it is fully vibe coded.

I am planning to breadboard the shit out of it when my Daisy arrives, and perfect things to make it actually usable

Honestly, this is one of the more interesting uses of AI-assisted coding I've seen for embedded audio. The important part isn't that Claude generated the code, but that you already have a VST3 target where you can exercise the same DSP logic before the Daisy hardware arrives. That gives you a much faster feedback loop than blindly flashing firmware and debugging everything on the pedal.

I'd still be a little careful about treating the generated DSP as finished just because it sounds good in the plugin. CPU usage, memory, latency, parameter smoothing, encoder handling and real-time safety can behave differently on the Seed. I'd especially watch for anything that allocates memory or does unexpected work in the audio callback.

The Mobius-style approach sounds like a fun next step, though. Having the effect algorithms, UI parameters and hardware abstraction separated should make it much easier to swap the encoders/display in later without rewriting the DSP. Once the Seed arrives, I'd definitely profile each effect individually before combining everything.

And for a project that started as an experiment, having CI produce both firmware and VST3 builds is already a pretty solid foundation. I'm curious to see how close the hardware version ends up feeling to the plugin once you've actually breadboarded it.

 

[balazs.bencs]

Honestly, this is one of the more interesting uses of AI-assisted coding I've seen for embedded audio. The important part isn't that Claude generated the code, but that you already have a VST3 target where you can exercise the same DSP logic before the Daisy hardware arrives. That gives you a much faster feedback loop than blindly flashing firmware and debugging everything on the pedal.

I'd still be a little careful about treating the generated DSP as finished just because it sounds good in the plugin. CPU usage, memory, latency, parameter smoothing, encoder handling and real-time safety can behave differently on the Seed. I'd especially watch for anything that allocates memory or does unexpected work in the audio callback.

The Mobius-style approach sounds like a fun next step, though. Having the effect algorithms, UI parameters and hardware abstraction separated should make it much easier to swap the encoders/display in later without rewriting the DSP. Once the Seed arrives, I'd definitely profile each effect individually before combining everything.

And for a project that started as an experiment, having CI produce both firmware and VST3 builds is already a pretty solid foundation. I'm curious to see how close the hardware version ends up feeling to the plugin once you've actually breadboarded it.

Yeah, well most of the development was done with me flashing every step onto the hardware, trying it out, testing.. The VST plugin was needed only for a brief period where I was waiting for the shipment to arrive Since the hardware arrived, I haven't touched the VST plugin really, because flashing is so much faster.
I can confidently say: the plugin sounded identical to the hardware. There was no difference (the C code was the same, so in theory cannot be different sounding). And I was not just messing around in my office, I did a couple of gigs with the prototype and it sounded very good, I could easily get by in multiple bands with this pedal and a couple of overdrives..

Since then I kind of moved away a bit from the Daisy Seed, because I felt like there is so much more CPU power in a Raspberry Pi for around the same price, so feel free to check out the process here: https://forum.pedalpcb.com/threads/nam-a2-raspberry-project.29837/
The reason for that was, that I tried to do a NAM A2 based Daisy Seed modeling pedal and I managed to do it with the same hardware, same screen, etc.. But it was very on the edge in terms of CPU performance, I needed something beefier - but the prototype worked fine, that code is also open on my github profile.