Vibe Coding Log - Sharing Journey - Git - Glitch/Time Warping FX - More MIT delays, A dozen types of Lush Supersaws

[Touch The Universe]

Your analysis is correct. And congrats, some people take years to reach that realization. Starting over is probably the right move now. The main issue is not the individual code quality anymore, but the lack of clear architecture and system boundaries. And that now comes back to bite you. At this point, a rewrite is likely cheaper than a refactor.

In game development there is a saying that your first ten games will be bad. Software development is not much different. You first need to learn the fundamentals properly. Vibecoding shortens the learning curve a lot, but it does not replace understanding architecture and system design. That’s why I usually recommend starting with the smallest possible projects and building up from there.

AI tends to generate locally working solutions, but audio software needs global coherence. If you do not explicitly enforce structure, you often end up with one giant implicitly coupled system. And AI usually will not warn you about that unless you already know enough to ask the right questions.

My advice would be: stop doing “passes” and “transplants”. Freeze the current project as reference only and treat it as the learning phase.

Then rebuild a minimal vertical slice with proper structure:
• oscillator
• envelope
• filter
• audio out

Define strict boundaries early:
• DSP separated from UI
• no hidden state
• explicit parameter routing
• realtime safe audio thread

In short: make sure the architecture fits from the beginning by building the smallest possible version first and polishing it properly. Once that foundation is solid, expand from there.

Trying to untangle a giant implicitly coupled synth after 80+ AI passes is usually harder than rebuilding it cleanly.

I definitely detect wisdom here but I still can't bring myself to do this iF i could cry I would, haha. So much work. I will keep trying a couple more days before I go that route, but I am glad I learned the importance of coherence via explicit rules and logic for the audio flow etc. I no longer want to transplant but adding that structure in the implicity so it becomes explicit, if that makes sense. It seems to be working yet I noticed no cpu savings (yet). Will see how this goes.

What do you think of the idea of removing, deleting 29 pages until only 1 page remains, the .cpp and .h goes from 1.7mb to like 50kb. Is this more managle to work with either root, transplant or imposing explicit paths? I'd also want to try this before I restart.

[Tiles]

Haha, that's development. Work never stops. And you usually count in manyears

I know too little about synthesizer architecture to be able to answer your question regarding root, transplant or explicit paths. But my belly tells me root. And modular approach.

Page 1 already looks troubled from what I can see. It is imho already built on wrong assumptions. And in my opinion, you don't really gain much from trying to salvage it. I would honestly start completely over, this time with the proper architecture and structure in mind.

My advice still stands though: do the smallest possible projects first, and actually finish them. That's where you really learn the basics. You want to use a reverb in your synthesizer? Then build it as a standalone first. You will run into trouble again once it comes to polishing. You will run into trouble with UI and UX design. You might realize halfway through that you missed an important architectural aspect and need to start over again. That's exactly why these things are best learned through very small projects first. In worst case you loose a few days instead of weeks and months.

I know it's hard, but it really is the best way to go. I've been there myself. I started with game development first, decades ago. The first game I ever tried to make was an RPG. For some completely unknown reason (sigh), I failed. My second game was something between Pong and Breakout, and from there I gradually expanded my skills.

I'm new to audio development myself, and I'm currently approaching it the same way. It has simply become part of my problem solving strategy over the years. I started with a small filter first, and quickly realized that I still need to gather a lot more knowledge before attempting a fully functional, full fledged synthesizer. That's why I followed your journey here with so much interest.

[Touch The Universe]

From the OSC Vital page, I was able to reduce the cpu from PER VOICE FILTER UNISION, which multiples voices x unison x filters from 100% cpu with 8 voice 8 unison lp12 filter to 50% cpu. This is a huge win! The refactoring insided the MASSIVE .cpp file is baring fruit, dramatic and I don't need to worry about reconnecting connections from a dozen filters and a dozen feedback modes (linked to filters) etc. This is promising. Will update a bit more, shortly, just wanted to share something promising. wahoo

However Im not noticing cpu savings anywhere else but this wild mode, though sounds lovely with filter spread on self resonance filters on pads or mono basses.

[BertKoor]

+1

And (learn to) use "The Git", with some form of continuous integration (automated builds, automated tests to stop regression)

[Touch The Universe]

Scored another win - CPU down from 60% to about 10% with similar sound. It was a big issue so I'm curious what caused it to be fixed so I want to preserve this answer. This applies to getting a full per voice unision filter spread.

I'll upload a video demonstrating the sound and the a/b here in a bit.



That is a huge win. What BE did was basically prove that the sound was not expensive by nature — the expensive part was the old architecture around the sound.

The original good-sounding path had two important tone behaviors:

First, it used legacy unison lane math. With 8 voices, the lanes were spread like this:

-3.5, -2.5, -1.5, -0.5, +0.5, +1.5, +2.5, +3.5

That matters because the filter spread effect was not just “left/right stereo.” It was using each unison lane as a different filter/pitch position. That creates the wide, animated, almost chorus-like filter movement you liked. Earlier cheap versions used a normalized spread like -1 to +1, which was much weaker and sounded flat.

Second, BE restored the legacy amp/filter order. The weak versions were more like:

oscillator → amp envelope → filter

But the better original behavior was closer to:

oscillator lane → per-unison filter → voice amp envelope

That means the filter gets to react to a full raw oscillator lane before the amp envelope turns it down. That preserves more resonance, motion, and filter-spread character. Filtering after the oscillator but before the amp gave back the “alive” tone.

The CPU problem was that the original route got that sound by calling the whole old renderOsc() / voice-loop machinery. That path carried a lot of extra baggage: modulation routing, scaffold frames, source buses, post-routing logic, coefficient checks, envelope bridges, route meters, hidden compatibility layers, and probably a bunch of objects being updated even when they were not musically needed.

BE kept the good math and signal order, but avoided waking the full old voice loop. So the new route is more like:

MIDI → lightweight OSC1 source → legacy-style lane spread math → real main filter coefficients → per-lane filter state → post-filter amp → output

That is why the CPU dropped to around 10% while the tone stayed close enough. We stopped paying for the whole old architecture and kept only the parts that mattered for the sound.

The discovery, in plain terms:

The filter spread sound was not the CPU monster. The old voice-loop/render route was the CPU monster.

And the “magic” was mostly:

legacy lane spread + per-unison filter state + filter-before-amp order.

That gives us the roadmap now: make the BE Lite LegacyMath path the real OSC1 path, then carefully add back features one at a time only if they are worth their CPU cost.

[Tiles]

I almost hesitate to say it, but you are still trying to patch up a sinking ship with duct tape. Well, yeah this research is still useful. But that won't save the ship

[Touch The Universe]

I almost hesitate to say it, but you are still trying to patch up a sinking ship with duct tape. Well, yeah this research is still useful. But that won't save the ship

Eh, we'll see

I'm quite happy to take the win this round, but I realize I have a long way to go. I haven't even addressed the bus insert and send lanes yet. The reverb also tanks the synth. One problem at a time and will keep up the hope

I've addressed 2 pages out of 30 so far, so regardless, at this rate it'll take awhile to make the synth cpu efficient, but adding structure inside this monstrosity has proven more affective, than starting from a blank canvas. All the ai agents first recommended the from blank canvas method and transplanting but that was a nightmare. I would prefer to make one from scratch than that way. This particulary issue however HAD NOTHING at all to do with the structure and explicity of the audio paths voices and lanes, so it's interesting how the biggest issues aren't necessarily the foundational ones, but specialized ones based on quirky tastes. I ABSOLUTELY INSIST on per voice filter unison so i can have that lovely sound.

I'm happy over all, with direct explicte lanes, it will become more effiicent with layers are stacked and send buses and inserts are activating with lots of modulations. That seems to be a fair bet, but to what degree I'll find out. Yet before, I couldn't even play 2 voice chords on some areas, but these are being addressed and i can hopefully get into more deep sound design here soon.

[Touch The Universe]

+1

And (learn to) use "The Git", with some form of continuous integration (automated builds, automated tests to stop regression)

Sounds like good practice. Making a note of that here.

Modern Software Development PracticesThe Git: "Git" is a software tool for tracking changes in code. It allows multiple programmers to work on the same project without overwriting each other's work.Continuous Integration (CI): CI is a practice where developers frequently merge their code changes into a central repository.Automated Builds: Every time code is updated, a server automatically compiles the software to ensure it builds without errors.Automated Tests: Computer programs automatically run tests on the new code to check for bugs.Stop Regression: Regression means new code accidentally breaking features that used to work. Automated tests stop this by catching errors early.Why Teams Use This SetupPrevents Bugs: Catching errors early stops broken software from reaching users.Saves Time: Automation replaces manual testing and manual building.Improves Collaboration: Teams can code simultaneously with fewer conflicts.To help clarify, are you learning programming for the first time, or are you setting up a CI/CD pipeline for a specific project?

[BertKoor]

Q: are you learning programming for the first time, or are you setting up a CI/CD pipeline for a specific project?
A: both

[Touch The Universe]

Q: are you learning programming for the first time, or are you setting up a CI/CD pipeline for a specific project?
A: both

I am currently using both Claude and ChatGPT for my development work. However, because I frequently hit the usage limits on Claude, I end up juggling between the two AI agents. My goal is to find a way for Claude to automatically update based on the changes ChatGPT just made, without me having to manually merge the two codebases.Right now, I am just completely overwriting the files and keeping backups. This is inefficient because Claude’s 4-hour lockout period means that by the time I can send it my updated .cpp source code files, I have already done significantly more work inside ChatGPT. At that point, the versions conflict and it makes no sense. I need a way for them to seamlessly update each other or sync the changes, but I have no idea how to implement that yet. I am just keeping track of this idea for now.

[BertKoor]

git is an industry standard. All tools should be able to work with it. Delaying using it is plain stupid. It solves exactly the problems you just outlined.

I learned it all by myself over a decade ago from here: https://git-scm.com/learn -> https://git-scm.com/book/en/v2
When I finished reading chapter 3 and doing some experiments, I prepared a course which would take a few hours and taught it to 60 coworkers (old-fashioned COBOL programmers)

The main commands are very simple, especially if you're using an IDE:

Code: Select all

git pull
[change some code]
git add *
git commit -m "this is what I did"
git push

Now you know git as well

[TechHaus]

Learning git doesn't mean copy pasting the definition. It means learning and adopting branching strategies.

What llm's are really good at is giving you an outline for a learning path for something you want to study.

Btw git would be like day 1 hour 1 of a coding bootcamp.

[whyterabbyt]

FWIW, If there are any larger (ie non text) assets as part of the project (from images for the UI to samples and large wavetables) you may want to add GitLFS (https://git-lfs.com/) to your git install.

[Tiles]

Don't scare our poor Touch The Universe with things that he might never need ^^

It is currently his private project, so not even on Github from what i can say. And then Git alone is just fine. I don't see big problems as long as you don't change these large assets daily. You can also simply exclude such large assets with git ignore, and don't track these large assets at all. The important part is the code.

[Urs]

So much work.

(sorry, that one was too hard to resist)