Vibe Coding Log - Sharing Journey - Git - Glitch/Time Warping FX - More MIT delays, A dozen types of Lush Supersaws
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615 - KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
Also wanted to chime in, I built a windows version in visual studio and that went off relatively well, building wise, yet it has a lot more crashing, at some point I might want to switch over to windows to finish the build. Hopefully it's not all that bad, getting them up to speed stabillity wise.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
UPDATE on the CPU issue. It isn't simply poor audio path routing as far as I can tell. Sharing what I'm learning. Going back to OSC 1 which had 70% cpu then down to 10% by bypassing the ENTIRE voice loop, which essentially unlinked it from everything - NOT good.
THIS IS THE THING THAT HELPED CPU, NOT THE FULL VOICE LOOP
In the previous bad version, the CPU cost was not mainly from the actual filter coefficient mode. It was from common overhead that every mode was still doing before it ever reached the mode-specific branch.
So when Patch 7 cleaned up things like:
per-sample parameter reads
string/APVTS lookups inside renderOsc()
cutoff/filter-spread math still running even when bypassed
unused route/harmonic clutter
per-lane calculations that did not need to happen in every CPU mode
It tells us the real CPU win was probably not just coefficient caching. It was more broadly:
block-level parameter caching
hot-loop cleanup
removing unnecessary per-sample work
not running filter/cutoff/math clutter when not needed
That is probably exactly the kind of optimization rule we need for the full synth.
What I think we learned
The big lesson is:
The hidden CPU monster was likely not the waveform, not the sends, not the matrix, and not just the filter itself. It was the render path doing too much “administrative work” at audio rate.
That means for the real synth, the rule should be:
Cache all parameter values once per block.
Do not use APVTS/string lookups in the sample/voice/unison loop.
Do not calculate unused modulation/filter paths.
Do not run math for disabled routes.
Only update filter coefficients when needed.
That is the exact principle we should apply to Vital, modal, sampler, delays, and anything else going forward.
WHICH HONESTLY SOUNDS PRETTY BASIC - Don't do audio rate stuff
The encouraging thing is that this OSC1 breakthrough gives us an actual rule to reuse:
Don’t rebuild expensive DSP state at audio rate unless the sound truly requires it. Cache the values, detect changes, update at control rate, and keep the audio loop clean.
**EDIT*** THE TRAIL CONTINUES
Thought for a couple of seconds
That is actually a very clean diagnostic result. For the small OSC1-only synth, your numbers say:
Legacy Full: 58%
Coeff Cache: 58%
Block 32: 50%
Source Only: 32%
Source 1 Lane: 24%
No Wave Math: 29%
Muted CPU: ~0%
So now we can separate the costs pretty clearly.
What this means
The biggest confirmed cost is the filter path.
Going from:
Block 32 = 50%
Source Only = 32%
means the filter system costs about:
18 percentage points
That is significant.
Then going from:
Source Only = 32%
Source 1 Lane = 24%
means the unison lane loop costs about:
8 percentage points
That also makes sense, because Source 1 Lane removes detune/unison spread and only processes one lane.
Then:
No Wave Math = 29%
Muted CPU = ~0%
means there is still a lot of non-wave oscillator machinery running even when audible waveform generation is removed. That is probably voice/sample/unison bookkeeping, parameter/cached value use, envelope stepping, lane math, pan/detune setup, and whatever else is still inside the render loop.
The surprising part
Legacy Full = 58%
Coeff Cache = 58%
That means the coefficient cache is probably not actually reducing work in that specific small synth mode, or the cache is being invalidated constantly.
Possible causes:
cutoff is changing every sample from filter envelope
cache threshold is too sensitive
cache hold counter is not being honored
the code still rebuilds coefficients before/after the cache
Legacy and Coeff Cache are accidentally routed to the same behavior
The fact that Block 32 drops to 50% proves that reducing coefficient-update frequency does help somewhat. So the coefficient system matters, but the “Coeff Cache” mode itself may not be doing enough yet.
The current cost map
Roughly:
Base engine / voice machinery: ~24–29%
Unison lanes beyond lane 1: +8%
Filter path with Block 32: +18%
Full/Coeff filter behavior: +26%
So the small synth is not just expensive because of one thing. It is layered:
voice/render machinery
+ unison
+ filter spread/filter stages
+ coefficient update behavior
What I would do next
The next diagnostic should split the filter path into smaller pieces:
Source Only
Filter Audio Only, no coeff updates
Coeff Update Only, no filter audio
Full Filter
Because right now “filter cost” combines two things:
1. processing audio through filters
2. rebuilding/updating filter coefficients
We need to know which one is bigger.
Also, I would add one more mode:
Source All Lanes No Pan/Detune Math
because Source 1 Lane saves CPU but destroys the sound by removing detune. A better optimization would keep all lanes but reduce unnecessary per-lane math.
Practical conclusion
For the small synth:
Block 32 is currently the best useful CPU mode among the filter modes.
Source Only proves the filter path is expensive.
Source 1 Lane proves unison lanes are also expensive, but removing them changes the sound too much.
Coeff Cache is not yet behaving as the expected CPU saver.
So the next useful patch would be a Filter Cost Split patch, not more broad guessing. It should tell us whether to optimize coefficient updates, filter processing itself, or unison-lane overhead next.
THIS IS THE THING THAT HELPED CPU, NOT THE FULL VOICE LOOP
In the previous bad version, the CPU cost was not mainly from the actual filter coefficient mode. It was from common overhead that every mode was still doing before it ever reached the mode-specific branch.
So when Patch 7 cleaned up things like:
per-sample parameter reads
string/APVTS lookups inside renderOsc()
cutoff/filter-spread math still running even when bypassed
unused route/harmonic clutter
per-lane calculations that did not need to happen in every CPU mode
It tells us the real CPU win was probably not just coefficient caching. It was more broadly:
block-level parameter caching
hot-loop cleanup
removing unnecessary per-sample work
not running filter/cutoff/math clutter when not needed
That is probably exactly the kind of optimization rule we need for the full synth.
What I think we learned
The big lesson is:
The hidden CPU monster was likely not the waveform, not the sends, not the matrix, and not just the filter itself. It was the render path doing too much “administrative work” at audio rate.
That means for the real synth, the rule should be:
Cache all parameter values once per block.
Do not use APVTS/string lookups in the sample/voice/unison loop.
Do not calculate unused modulation/filter paths.
Do not run math for disabled routes.
Only update filter coefficients when needed.
That is the exact principle we should apply to Vital, modal, sampler, delays, and anything else going forward.
WHICH HONESTLY SOUNDS PRETTY BASIC - Don't do audio rate stuff
The encouraging thing is that this OSC1 breakthrough gives us an actual rule to reuse:
Don’t rebuild expensive DSP state at audio rate unless the sound truly requires it. Cache the values, detect changes, update at control rate, and keep the audio loop clean.
**EDIT*** THE TRAIL CONTINUES
Thought for a couple of seconds
That is actually a very clean diagnostic result. For the small OSC1-only synth, your numbers say:
Legacy Full: 58%
Coeff Cache: 58%
Block 32: 50%
Source Only: 32%
Source 1 Lane: 24%
No Wave Math: 29%
Muted CPU: ~0%
So now we can separate the costs pretty clearly.
What this means
The biggest confirmed cost is the filter path.
Going from:
Block 32 = 50%
Source Only = 32%
means the filter system costs about:
18 percentage points
That is significant.
Then going from:
Source Only = 32%
Source 1 Lane = 24%
means the unison lane loop costs about:
8 percentage points
That also makes sense, because Source 1 Lane removes detune/unison spread and only processes one lane.
Then:
No Wave Math = 29%
Muted CPU = ~0%
means there is still a lot of non-wave oscillator machinery running even when audible waveform generation is removed. That is probably voice/sample/unison bookkeeping, parameter/cached value use, envelope stepping, lane math, pan/detune setup, and whatever else is still inside the render loop.
The surprising part
Legacy Full = 58%
Coeff Cache = 58%
That means the coefficient cache is probably not actually reducing work in that specific small synth mode, or the cache is being invalidated constantly.
Possible causes:
cutoff is changing every sample from filter envelope
cache threshold is too sensitive
cache hold counter is not being honored
the code still rebuilds coefficients before/after the cache
Legacy and Coeff Cache are accidentally routed to the same behavior
The fact that Block 32 drops to 50% proves that reducing coefficient-update frequency does help somewhat. So the coefficient system matters, but the “Coeff Cache” mode itself may not be doing enough yet.
The current cost map
Roughly:
Base engine / voice machinery: ~24–29%
Unison lanes beyond lane 1: +8%
Filter path with Block 32: +18%
Full/Coeff filter behavior: +26%
So the small synth is not just expensive because of one thing. It is layered:
voice/render machinery
+ unison
+ filter spread/filter stages
+ coefficient update behavior
What I would do next
The next diagnostic should split the filter path into smaller pieces:
Source Only
Filter Audio Only, no coeff updates
Coeff Update Only, no filter audio
Full Filter
Because right now “filter cost” combines two things:
1. processing audio through filters
2. rebuilding/updating filter coefficients
We need to know which one is bigger.
Also, I would add one more mode:
Source All Lanes No Pan/Detune Math
because Source 1 Lane saves CPU but destroys the sound by removing detune. A better optimization would keep all lanes but reduce unnecessary per-lane math.
Practical conclusion
For the small synth:
Block 32 is currently the best useful CPU mode among the filter modes.
Source Only proves the filter path is expensive.
Source 1 Lane proves unison lanes are also expensive, but removing them changes the sound too much.
Coeff Cache is not yet behaving as the expected CPU saver.
So the next useful patch would be a Filter Cost Split patch, not more broad guessing. It should tell us whether to optimize coefficient updates, filter processing itself, or unison-lane overhead next.
Last edited by Touch The Universe on Sun May 31, 2026 10:01 pm, edited 1 time in total.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
- KVRer
- 23 posts since 20 Mar, 2026
I was referring to the codebase. It has no idea what it's doing, it's just regurgitating what is already publicly available. As an example, CPU performance - there will be unique coding techniques known to the developer of a synth that are not publicly available, which means AI can't apply those techniques. Anyway, when are you going to unleash this so we can test it?Touch The Universe wrote: Sun May 31, 2026 8:18 pmlike new physics?Almondo wrote: Sat May 30, 2026 8:18 pm It's hard to imagine AI ever really competing in this area. I said it earlier in this thread, humans are forward thinking whereas AI is literally stuck in the past and always will be. You can throw all the ideas you like at it but it simply doesn't have the ability or data to create something unique. And the chances of Urs giving up his codebase for model training is about 0%.
Having said that, and as a software developer of 30 years, it's an interesting experiment.
Try giving it crazy ideas like make a knob with unique Feedback implementation that has resonance peaks part of the knob path, like first 40% then have fm from 50-70% that affects multiple parameters at once to sound good and work with feedback, have distortion in the, and link it to speak with a ZDF filter so there is cross communication. I've never heard this in any synth. Is this not unique? It can piece together and do anything IN MATH. Those combinations can be unique. See for yourself. Just say build this so i can test in html, no need to build and compile.
Not having a go at you by the way, I'm just not convinced AI can be used to create a professional synth.
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
Updated diagnosis
The CPU cost breakdown looks roughly like this: FOR 8 UNISON 5 NOTE POLY WITH PER VOICE FILTER
Voice/envelope system: ~2%
RenderOsc source/unison machinery: ~21–31%
Pan/detune/spread math: ~6%
Filter audio processing: ~16%
Coefficient update path: ~21%
The worst offenders are:
1. Coefficient update path
2. Unison/renderOsc machinery
3. Filter audio processing
4. Pan/detune math
Best next optimization target
The next patch should focus on per-lane caching, not just coefficient caching.
We need to cache:
per-lane detune multiplier
per-lane pan gains
per-lane filter spread multiplier
per-lane cutoff offset
per-lane coefficient state
Those should only update when these change:
voices count
detune knob
stereo knob
pan knob
filter spread knob
filter type
filter slope
sample rate
base pitch / note if needed
Right now, it sounds like too much of that is being calculated in the hot loop.
The CPU cost breakdown looks roughly like this: FOR 8 UNISON 5 NOTE POLY WITH PER VOICE FILTER
Voice/envelope system: ~2%
RenderOsc source/unison machinery: ~21–31%
Pan/detune/spread math: ~6%
Filter audio processing: ~16%
Coefficient update path: ~21%
The worst offenders are:
1. Coefficient update path
2. Unison/renderOsc machinery
3. Filter audio processing
4. Pan/detune math
Best next optimization target
The next patch should focus on per-lane caching, not just coefficient caching.
We need to cache:
per-lane detune multiplier
per-lane pan gains
per-lane filter spread multiplier
per-lane cutoff offset
per-lane coefficient state
Those should only update when these change:
voices count
detune knob
stereo knob
pan knob
filter spread knob
filter type
filter slope
sample rate
base pitch / note if needed
Right now, it sounds like too much of that is being calculated in the hot loop.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
Going deep in the weeds testing every single parameter. I'm thinking multithreading is the way to go for this.
Okay, so testing the Monosc one. So going at Legacy Fool is at 58% per voice, filter root. Relax Cosh is at 56%, I'm sorry, 57%. Half filters is at 55% and I'm noticing a different sound quality. It sounds different at least. So half filters goes to 55% and the sound quality is improved, just went down. Quarter filters goes to 55%, block 128 goes to 53%, lane plus block goes to 50%, lane half filter goes to 52%. So now testing the 16 voice, maybe 16 unison, maybe that gives us more information.So, 16 voices, 5 poly gets 84% legacy full. Coefficient cock, 83%. Block 16, 83%. Block 32, 81%. Source only, 47%. Source one lane, 23%. Muted CPUs, 4%. Filtered audio only, 77%. Coefficient update only, 80%. Source no pan, 37%. Voice envelope only, 4%. Lane kosh, 76%. Coefficient frozen, 77%. Lane plus frozen, 67%. Block 64, 80%. Relax kosh, 84%. Half filters, 84%. Quarter filters, 81%. But that increases when I increase the filter spread to, it goes to 85%. Block 128, 80%. Lane block, 64%, 70%. Lane half filter, 76%.
Okay, so testing the Monosc one. So going at Legacy Fool is at 58% per voice, filter root. Relax Cosh is at 56%, I'm sorry, 57%. Half filters is at 55% and I'm noticing a different sound quality. It sounds different at least. So half filters goes to 55% and the sound quality is improved, just went down. Quarter filters goes to 55%, block 128 goes to 53%, lane plus block goes to 50%, lane half filter goes to 52%. So now testing the 16 voice, maybe 16 unison, maybe that gives us more information.So, 16 voices, 5 poly gets 84% legacy full. Coefficient cock, 83%. Block 16, 83%. Block 32, 81%. Source only, 47%. Source one lane, 23%. Muted CPUs, 4%. Filtered audio only, 77%. Coefficient update only, 80%. Source no pan, 37%. Voice envelope only, 4%. Lane kosh, 76%. Coefficient frozen, 77%. Lane plus frozen, 67%. Block 64, 80%. Relax kosh, 84%. Half filters, 84%. Quarter filters, 81%. But that increases when I increase the filter spread to, it goes to 85%. Block 128, 80%. Lane block, 64%, 70%. Lane half filter, 76%.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
I will look into creating like a demo beta thing or whatever if anybody wants to test this an experiment with it I just need to look into seeing how I do that, if there's interest in thisAlmondo wrote: Sun May 31, 2026 9:33 pmI was referring to the codebase. It has no idea what it's doing, it's just regurgitating what is already publicly available. As an example, CPU performance - there will be unique coding techniques known to the developer of a synth that are not publicly available, which means AI can't apply those techniques. Anyway, when are you going to unleash this so we can test it?Touch The Universe wrote: Sun May 31, 2026 8:18 pmlike new physics?Almondo wrote: Sat May 30, 2026 8:18 pm It's hard to imagine AI ever really competing in this area. I said it earlier in this thread, humans are forward thinking whereas AI is literally stuck in the past and always will be. You can throw all the ideas you like at it but it simply doesn't have the ability or data to create something unique. And the chances of Urs giving up his codebase for model training is about 0%.
Having said that, and as a software developer of 30 years, it's an interesting experiment.
Try giving it crazy ideas like make a knob with unique Feedback implementation that has resonance peaks part of the knob path, like first 40% then have fm from 50-70% that affects multiple parameters at once to sound good and work with feedback, have distortion in the, and link it to speak with a ZDF filter so there is cross communication. I've never heard this in any synth. Is this not unique? It can piece together and do anything IN MATH. Those combinations can be unique. See for yourself. Just say build this so i can test in html, no need to build and compile.
Not having a go at you by the way, I'm just not convinced AI can be used to create a professional synth.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
SIMD implementation seems to be the most promising, for unison voices alone, not yet filters per voice, I'm seeing 16 unison 5 voice chord go from 90% to 24%. FED GPT this....https://github.com/madrona-labs/madronalib... Testing now the results for per voice filter
2. CPU probe methods we tried
We created a lot of probe modes. The main categories are:
Basic reference modes
Legacy Full
Coeff Cache
Block 16
Block 32
Block 64
Block 128
Source Only
Source 1 Lane
No Wave Math
Muted CPU
Filter split diagnostic modes
Filter Audio Only
Coeff Update Only
Source No Pan
Voice Env Only
Lane/cache modes
Lane Cache
Coeff Frozen
Lane + Frozen
Relaxed Cache
Lane Table
Table + Frozen
Dynamic unison cap modes
Dyn Uni Cap
Table + DynCap
Table + Dyn + Frozen
DynCap 4
TableDyn4 Live
DynCap Custom
TableDyn Custom Live
Forced lane count modes
Force 2L Full
Force 4L Full
Force 8L Full
Force 16L Full
Source 2L
Source 4L
Source 8L
Source 16L
SIMD source modes
SIMD Source 4L
SIMD Source 8L
SIMD Source 16L
Scalar 16Phase Source
Madrona Source 4L
Madrona Source 8L
Madrona Source 16L
Threading modes
Thread Mode Off
Persistent 2T
Persistent 4T
Auto
2. CPU probe methods we tried
We created a lot of probe modes. The main categories are:
Basic reference modes
Legacy Full
Coeff Cache
Block 16
Block 32
Block 64
Block 128
Source Only
Source 1 Lane
No Wave Math
Muted CPU
Filter split diagnostic modes
Filter Audio Only
Coeff Update Only
Source No Pan
Voice Env Only
Lane/cache modes
Lane Cache
Coeff Frozen
Lane + Frozen
Relaxed Cache
Lane Table
Table + Frozen
Dynamic unison cap modes
Dyn Uni Cap
Table + DynCap
Table + Dyn + Frozen
DynCap 4
TableDyn4 Live
DynCap Custom
TableDyn Custom Live
Forced lane count modes
Force 2L Full
Force 4L Full
Force 8L Full
Force 16L Full
Source 2L
Source 4L
Source 8L
Source 16L
SIMD source modes
SIMD Source 4L
SIMD Source 8L
SIMD Source 16L
Scalar 16Phase Source
Madrona Source 4L
Madrona Source 8L
Madrona Source 16L
Threading modes
Thread Mode Off
Persistent 2T
Persistent 4T
Auto
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
Tested Detuning Laws, coming up with awesome saws cpu probing to see what might save cpu.
I was also finally able to isolated ENTIRELY a page from the monstrosity so it's 30kb from 1.7mb sourcecode file. this is NOT easy to get GPT to play ball on this. It's a thousand times easier to add code than remove it.
I isolated the problem page and begain throwing all I could at this thing. I stumbled on some nice things in the process. At times I thought I stumbled upon the secret with drastic cpu savings, only to later discover the cons. Need to experiment more. All the while Surge is getting 16 voice 5 poly chord at 15% and I'm at nearly 30% though at times I was around 22% though I think voices were dropped to get there.
As usual, I've requested 4-5 times to implement surge and the ACTUAL madrona libs SIMD code and it's NOT, just facimile. I want to try the actualy code and see if that makes a difference, and i suspect it will.
I was also finally able to isolated ENTIRELY a page from the monstrosity so it's 30kb from 1.7mb sourcecode file. this is NOT easy to get GPT to play ball on this. It's a thousand times easier to add code than remove it.
I isolated the problem page and begain throwing all I could at this thing. I stumbled on some nice things in the process. At times I thought I stumbled upon the secret with drastic cpu savings, only to later discover the cons. Need to experiment more. All the while Surge is getting 16 voice 5 poly chord at 15% and I'm at nearly 30% though at times I was around 22% though I think voices were dropped to get there.
As usual, I've requested 4-5 times to implement surge and the ACTUAL madrona libs SIMD code and it's NOT, just facimile. I want to try the actualy code and see if that makes a difference, and i suspect it will.
You do not have the required permissions to view the files attached to this post.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
- KVRist
- 189 posts since 31 Oct, 2017
It can certainly be leveraged professionally, but IMHO not yet at a full vibe-coded hackathon like this is. POV: I'm a professional audio plugin and hardware/soft synth developer.Almondo wrote: Sun May 31, 2026 9:33 pm Not having a go at you by the way, I'm just not convinced AI can be used to create a professional synth.
To produce anything professional grade you seriously need to know what you're doing. Both in terms of the field/domain and the correct and most productive ways of leveraging frontier coding model AIs.
No disrespect to 'Touch The Universe', they're clearly having a ball doing something that would very likely be completely out of their reach without AI. There's something cavalier and spirited about that.
But each time I look at this thread now I'm borderline getting anxiety attacks thinking about how the codebase must look at this point and the horror show mountain of technical debt that's almost certainly building up.
-
- KVRer
- 23 posts since 20 Mar, 2026
Agree 100%, as a developer myself (enterprise systems, not audio) I could incorporate AI tools but I'd still be doing the vast majority of the work.JustinJ wrote: Mon Jun 01, 2026 2:35 pmIt can certainly be leveraged professionally, but IMHO not yet at a full vibe-coded hackathon like this is. POV: I'm a professional audio plugin and hardware/soft synth developer.Almondo wrote: Sun May 31, 2026 9:33 pm Not having a go at you by the way, I'm just not convinced AI can be used to create a professional synth.
To produce anything professional grade you seriously need to know what you're doing. Both in terms of the field/domain and the correct and most productive ways of leveraging frontier coding model AIs.
No disrespect to 'Touch The Universe', they're clearly having a ball doing something that would very likely be completely out of their reach without AI. There's something cavalier and spirited about that.
But each time I look at this thread now I'm borderline getting anxiety attacks thinking about how the codebase must look at this point and the horror show mountain of technical debt that's almost certainly building up.
Also for the tech debt, I was thinking the same. TTU is approaching the same scenario as having a bunch of developers all throwing software at a codebase over a few years without any real coding standards or testing procedures to guard against the inevitable mess.
AI as a tool? Sure why not. Replace devs? Nah.
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
I found this reply helpful. Adding notes here because I had to look things up. Anything besides these or othe comments, appreciated.JustinJ wrote: Mon Jun 01, 2026 2:35 pmIt can certainly be leveraged professionally, but IMHO not yet at a full vibe-coded hackathon like this is. POV: I'm a professional audio plugin and hardware/soft synth developer.Almondo wrote: Sun May 31, 2026 9:33 pm Not having a go at you by the way, I'm just not convinced AI can be used to create a professional synth.
To produce anything professional grade you seriously need to know what you're doing. Both in terms of the field/domain and the correct and most productive ways of leveraging frontier coding model AIs.
No disrespect to 'Touch The Universe', they're clearly having a ball doing something that would very likely be completely out of their reach without AI. There's something cavalier and spirited about that.
But each time I look at this thread now I'm borderline getting anxiety attacks thinking about how the codebase must look at this point and the horror show mountain of technical debt that's almost certainly building up.
Why Domain Knowledge Still Wins
Architectural Design: AI excels at writing localized code blocks but struggles to design scalable, low-latency software architectures independently.
Debugging Complex Systems: When an AI-generated script fails or introduces a subtle bug, only a skilled developer can trace the root cause through the system.
Audio Specifics: Professional audio requires deep math knowledge, including Digital Signal Processing (DSP), fast Fourier transforms (FFT), and buffer management.
Constraint Management: Audio software must run in real-time with zero latency; AI often writes code that is functionally correct but too slow for production.
Leveraging Frontier Coding Models Productively
Context Inflation: Provide the AI with your exact framework constraints, API documentation, and performance requirements before asking for code.
Iterative Prompting: Break down large features into tiny, testable components rather than asking the AI to build a whole plugin at once.
Code Reviewer AI: Use the AI to review your human-written code specifically for edge cases, memory leaks, or optimization opportunities.
Test Generation: Ask the AI to write unit tests for your functions to catch edge cases you might have overlooked.
If you are currently working on a development project, I can help you optimize your workflow. Would you like to explore how to structure prompts for DSP/audio code, or should we look at strategies for debugging AI-generated code? (IM FOLLOWING THIS THREAD HERE TOO)
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
Still working on CPU optimization.
Just want to reiterate, the signal routing might be okay (not an utter disaster), perhpas I mistakingly arrived at a false conclusion on it while troubleshooting cpu.
Two people asked if the cpu goes down when closing the, before it wasnt, now it seems to be the case.
Important known results:
Closing plugin GUI drops CPU significantly.
Playing notes can reach ~80%.
GUI open + DAW stopped/no MIDI still stays ~40%.
In Build172R, clicking MAIN TMR drops idle CPU from ~40% to ~25–28%.
Having two agents work on it, as it's been 4-5 passes so far on this, but switching to pro monde on GTP and have claude on it. Want to take a break in troublehooting, optimizing and want to incorporate the rest of the delays I narrowed to transition into something "enjoyable".
I was able to extract a page form the monster, modify, and reimplement it back in the synth to great success, though I had to get explicit in the prompting otherwise it will try to either, recreate the old code into it pass by pass, or add facsimiles, either though I request just copy and paste the code..
This is the prompt i asked it to create for it's future self, after finally saying the "magic" words to get it to work.
STRICT TRANSPLANT MODE.
Do not recreate, approximate, simplify, rewrite, reinterpret, optimize, or make a facsimile of the source code.
I want a direct code transplant from the donor project into the target project.
Rules:
Copy the donor implementation exactly wherever possible.
Preserve the original equations, constants, scaling, curves, detune laws, phase behavior, filter behavior, smoothing, defaults, and control mappings.
Do not change any math unless the build cannot compile without a minimal adapter.
Do not “improve” the code.
Do not replace the donor behavior with a simpler version.
Do not create a new implementation that merely sounds similar.
Do not rename behavior or re-map controls unless required by the target project’s parameter system.
If the donor code depends on missing systems, create the thinnest possible adapter/shim around the original donor code rather than rewriting the donor code.
If a direct transplant is not possible, stop and explain exactly why before making any substitute.
Any substitute, shim, stub, wrapper, or adapter must be clearly labeled in the response.
Implementation priority:
Preserve donor sound and behavior first.
Compile second.
UI integration third.
CPU optimization last.
Required response format after the build:
“Copied exactly:” list the donor functions/classes copied without behavior changes.
“Adapters/shims added:” list any wrapper code added around the donor code.
“Changed from donor:” list every behavior/math/control change, even small ones.
“Not implemented:” list any missing donor behavior.
“Test this:” give the exact controls to A/B against the donor project.
If you find yourself wanting to say “I implemented a similar version,” stop. That is not allowed. I want the donor implementation, not a facsimile.
Just want to reiterate, the signal routing might be okay (not an utter disaster), perhpas I mistakingly arrived at a false conclusion on it while troubleshooting cpu.
Two people asked if the cpu goes down when closing the, before it wasnt, now it seems to be the case.
Important known results:
Closing plugin GUI drops CPU significantly.
Playing notes can reach ~80%.
GUI open + DAW stopped/no MIDI still stays ~40%.
In Build172R, clicking MAIN TMR drops idle CPU from ~40% to ~25–28%.
Having two agents work on it, as it's been 4-5 passes so far on this, but switching to pro monde on GTP and have claude on it. Want to take a break in troublehooting, optimizing and want to incorporate the rest of the delays I narrowed to transition into something "enjoyable".
I was able to extract a page form the monster, modify, and reimplement it back in the synth to great success, though I had to get explicit in the prompting otherwise it will try to either, recreate the old code into it pass by pass, or add facsimiles, either though I request just copy and paste the code..
This is the prompt i asked it to create for it's future self, after finally saying the "magic" words to get it to work.
STRICT TRANSPLANT MODE.
Do not recreate, approximate, simplify, rewrite, reinterpret, optimize, or make a facsimile of the source code.
I want a direct code transplant from the donor project into the target project.
Rules:
Copy the donor implementation exactly wherever possible.
Preserve the original equations, constants, scaling, curves, detune laws, phase behavior, filter behavior, smoothing, defaults, and control mappings.
Do not change any math unless the build cannot compile without a minimal adapter.
Do not “improve” the code.
Do not replace the donor behavior with a simpler version.
Do not create a new implementation that merely sounds similar.
Do not rename behavior or re-map controls unless required by the target project’s parameter system.
If the donor code depends on missing systems, create the thinnest possible adapter/shim around the original donor code rather than rewriting the donor code.
If a direct transplant is not possible, stop and explain exactly why before making any substitute.
Any substitute, shim, stub, wrapper, or adapter must be clearly labeled in the response.
Implementation priority:
Preserve donor sound and behavior first.
Compile second.
UI integration third.
CPU optimization last.
Required response format after the build:
“Copied exactly:” list the donor functions/classes copied without behavior changes.
“Adapters/shims added:” list any wrapper code added around the donor code.
“Changed from donor:” list every behavior/math/control change, even small ones.
“Not implemented:” list any missing donor behavior.
“Test this:” give the exact controls to A/B against the donor project.
If you find yourself wanting to say “I implemented a similar version,” stop. That is not allowed. I want the donor implementation, not a facsimile.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube
-
Touch The Universe Touch The Universe https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=190615
- KVRAF
- Topic Starter
- 5772 posts since 2 Oct, 2008
CPU never goes above 40% in the same scenario - success.
Build172T / 172U mostly address the new transplant-era architecture, especially:
1OSC latch keeping the whole FirstSynth process path awake.
FX tail latch staying alive too long because a source was merely enabled.
child GUI timers that kept repainting while hidden.
1OSC worker-thread busy-spin risk in 172U.
But if an older pre-transplant build already had the same GUI-open CPU behavior, then those fixes do not fully address the deeper older architecture.
Pressing stop in the DAW and clicking a kill gui switch goes to zero but has a 30 second delay. addressing this next, though I'd consider the biggest hurdle passed.
Build172T / 172U mostly address the new transplant-era architecture, especially:
1OSC latch keeping the whole FirstSynth process path awake.
FX tail latch staying alive too long because a source was merely enabled.
child GUI timers that kept repainting while hidden.
1OSC worker-thread busy-spin risk in 172U.
But if an older pre-transplant build already had the same GUI-open CPU behavior, then those fixes do not fully address the deeper older architecture.
Pressing stop in the DAW and clicking a kill gui switch goes to zero but has a 30 second delay. addressing this next, though I'd consider the biggest hurdle passed.
100 High Quality Soundsets: Omnisphere 2, Dune 3, Tone 2 Synths, Pigments, Uhe Synths, Halion, Spire, and others.
TTU Youtube
TTU Youtube