Vibe Coding Log - Sharing Journey - Demo of Smaller Spinoff (Unique Time Based Synth - Grossbeat Like)

[Touch The Universe]

Ah, I see more replies. I'll dig into those next chance I get, don't want to seem I'm disregarding them. Just logging for now.

[Almondo]

I came across an example where Claude nailed an html to css port that GPT struggled with. Interestingly, it was the one who created the html. I usually don't notice differences.

It's javascript that's making the noises, not html. The thought of debugging a javascript synth...

[TechHaus]

Too late now but these vibe coding videos really should not have been on your professional sound packs channel.

Thanks for your concern, but why not, might I ask Do you think it might hurt sales

Because of the way the Youtube algorithm works. You just uploaded a bunch of long videos that are most likely uninteresting to your subscribers and viewer base, have extremely low watch times, and have very high abandonment rates, etc.

Why would they ever send you another viewer again?

This is how you tank a channel. Very hard to dig yourself out of it.

On the other hand, you could have debuted a new vibe coding plugins channel, and maybe found a relevant audience with the right framing of the videos.

And for the record, they do show me your new uploads because I watched a few, so that does contradict my point. But care should be put into how you position yourself on the second biggest search engine in the world.

You know who is good at prescribing internet marketing plans? LLM's! (internet marketers love to blog about their methods and LLM's goobled all of that crap up).

[Touch The Universe]

So just stumbling across weird behavior, all of a sudden GPT kind of just made a pass that reduce the size from like 800 KB of 650 so it randomly arbitrarily just deleted a fifth of the code, so for now on I'm just kind of having it specify the size length before and after that might be an easier way to keep track of these big Fumbles

[TechHaus]

You can just revert back to the last git commit. (Get why git is important now?) And you can start a new branch for a new feature and not even touch the man branch until you are ready to merge it.

[Touch The Universe]

After about four passes, it took me a while to figure out that something was wrong. That approach only works the way I want if I commit more frequently. Usually, I only commit after finishing a whole sequence of ideas I want to implement.Because of that, I need to start making more frequent commits. At that point, it almost feels like I should just save the updated file in a zip file and collect them. That is essentially a Git workflow anyway. However, the app itself lets you clearly highlight the differences between each build and add notes, which is incredibly helpful.

[Touch The Universe]

This is quite amazing app, stupid good. Will be first rerlease when its done.

Screenshot 2026-06-08 at 1.27.59 AM.jpg

The routing is quite powerful.

[Touch The Universe]

Screenshot 2026-06-08 at 4.04.13 AM.jpg

[Touch The Universe]

Sampler CPU has been solved. It has a more direct output path and not going through the entire voice loop. Turns out the voice loop audio path is the issue in this particular case, having more intentional, explicit path is of course highly important for cpu, and common sense.

[Touch The Universe]

In the phase of removing stuff/bloat and various gui/cpu auditing code to help narrow issues. I'm done adding FX, I'm happy where I'm at with ONE exception but that will likely be an update after release. I at some point will want to implement that FOCUS TIME FX curve editor, but I'll finalize that as it's own thing first, then add it in later. No more new synthesis types, that can be for later updates too. Minimize the final inclusions, and refine the gui is likely the phase I'll be jumping in, then probably will open up a beta.

[Touch The Universe]

Sampler CPU has been solved. It has a more direct output path and not going through the entire voice loop. Turns out the voice loop audio path is the issue in this particular case, having more intentional, explicit path is of course highly important for cpu, and common sense.

Spoke too soon.

It was fixed because it bypasses the entire voice loop - AGAIN. I keep falling for the same trip by GPT. I'm going for a different route, we worked some important things out, but it seems the sampler didn't have its own bus, so that's probably a good place to start.

Screenshot 2026-06-09 at 12.50.11 AM.png

[Touch The Universe]

# FirstSynth 527 Routing / CPU Architecture Notes

## Current observed problem

The sampler itself is cheap. Testing showed:

* Bare sampler reader: roughly 3–9% CPU
* Sampler fast dry: roughly 8–10% CPU
* Normal/full path sampler: can jump much higher

So raw sample playback is not the problem. The expensive part appears to be the surrounding routing/voice-shell/post-processing architecture.

## Current high-level routing model

The current processor is mostly one large `processBlock()` path.

Simplified:

```text
MIDI input
↓
Parameter cache / source-state checks
↓
Optional fast sampler reader
↓
Native per-sample voice shell
↓
Shared filter / tone / drive area
↓
FX / delay / reverb / VerbLab / FX2 / master
↓
Main output
```

The newer sampler fast path added a separate temporary bus:

```text
Sampler Fast Reader
↓
samplerFastBus L/R
↓
mixed back before filter / FX / master
```

But most other engines still appear to be connected through the main native shell and shared output buffer rather than through fully isolated buses.

## Important current buses / buffers

Known bus-like paths in the current code include:

```text
Main output buffer
- left/right audio buffer used by most processing

Sampler Fast Bus
- newer independent sampler fast path
- intended to avoid the heavy oscillator/native voice shell

Sampler Filter Bypass buffer
- used to keep sampler audio out of unified filter in some modes

Attack2 route buffer
- separate buffer for Attack2 routing

OSC Vital bypass buffer
- used when OSC Vital filter routing is off

1OSC Transplant scratch buffer
- donor bridge path before being mixed into main processing
```

So there are some side buffers, but not a clean universal source-bus architecture yet.

## Current likely issue

The sampler was historically living inside, or too close to, the same native voice shell used by oscillators. That shell includes many things a simple sampler does not need:

```text
oscillator checks
voice envelopes
filter envelope
amp extras
mod envelope work
matrix accumulation
shared filter bridge
source routing branches
possibly hidden/retired source checks
```

Even if only the sampler is audible, the code may still be paying for parts of that architecture unless the fast sampler path bypasses it correctly.

## What “waking the native shell” means

It means entering the expensive per-sample / per-voice code path that was built for oscillator engines.

This should happen only when a real synth source is active, such as:

```text
OSC enabled and audible
OSC Vital enabled and audible
OSC Master enabled and audible
1OSC Transplant full host path active
Thorn / Modal / Poizone enabled and audible
Granular/wavetable source enabled and audible
```

It should not happen merely because those pages exist or have parameters.

## Effects: insert or send?

The current effects are mostly not formalized as a clean rack graph. They are mostly sequential processing blocks in the main post path.

A practical interpretation:

```text
Filter / tone / drive = insert-style processing
FX2 modules = mostly insert-style with wet/mix controls
Delay/reverb/VerbLab = time-based wet processing inside the post chain
Master limiter/clipper/output = final post processing
```

It would be clearer and safer if the project explicitly separated:

```text
Insert FX
Send FX
Master FX
```

## Better target architecture

A cleaner architecture would be:

```text
Sampler Engine
↓
Sampler Bus
↓
optional filter rack / FX sends

OSC / Vital / Thorn / Modal / Poizone / 1OSC
↓
Synth Bus
↓
optional filter rack / FX sends

Granular / Stretch / Drum Slice
↓
Texture Bus
↓
optional filter rack / FX sends

All source buses
↓
Shared Filter Rack / Harmonic Filter if selected
↓
FX2 Insert Rack
↓
Delay/Reverb/VerbLab Sends
↓
Master Output
```

This avoids making sampler playback enter the oscillator voice shell just to reach filters and effects.

## Specific improvement targets

1. Create explicit `SourceBus` structures:

* Sampler Bus
* Synth Bus
* Texture Bus
* Drum Slice Bus
* 1OSC Bus

2. Create an explicit `FilterRack` processor that can process any bus, instead of being tied to the oscillator voice shell.

3. Create an explicit `FxRack` / `SendFxRack` distinction:

* insert effects process inline
* send effects receive from buses and return wet tails

4. Replace broad “can sound” checks with precise active checks:

* enabled
* level above threshold
* has active voice or tail
* not merely “page exists”

5. Hide/disable retired pages should also remove them from CPU source-wake logic:

* OSC TEST
* OSC LAB
* OSC DSP
* Nebula/N page

6. Avoid per-block heap allocation for temporary buffers.
Preallocate reusable buffers as member variables.

7. Gate FX modules hard:

* if module off and mix zero, do not process
* formant should require explicit on
* Nebula/convolution/visuals should default off

## Likely next build direction

The next major pass should not copy the whole filter section. It should make routing explicit:

```text
Sampler Fast Bus
↓
shared filter rack if selected
↓
FX rack / sends
↓
master
```

The synth voice shell should run only when actual oscillator/synth sources are enabled and audible.


In plainer terms: I do not think copying the entire filter section into a new sampler-only duplicate is the best first move. That would work short-term, but it creates two filter systems to maintain.

The cleaner solution is to make the filter section a reusable rack processor that can accept audio from the sampler bus, synth bus, or combined bus. The sampler should have its own source bus, but it should still be able to feed the same good filters and effects.

The most suspicious specific thing in the current code is this kind of logic:

if any non-sampler source can sound,
run native shell

That is reasonable in concept, but dangerous if “can sound” means “this module exists / has params / page is available” rather than “this module is actually enabled, audible, and has voices or tail energy.” Hidden retired sources like OSC TEST / OSC LAB / OSC DSP should not be part of that wake decision anymore unless they are truly active.

Also, there are many temporary buffers created inside processBlock() as std::vector<float> per block. That is not ideal for real-time audio. Even if it is not the main issue, the cleaner architecture should preallocate reusable bus buffers as processor members.

What I would fix next

527-61 — Source Wake Audit / Bus Truth Pass

Before more sound features, I’d add or print a clear internal readout:

Sampler Fast Bus: on/off
Native Shell: on/off
Reason Native Shell Woke: OSC / Vital / Thorn / Modal / Granular / etc.
Filter Rack: on/off
Post FX: on/off
FX2 active modules: list/count

Then we can see exactly why the native shell wakes. That is better than guessing.

After that:

527-62 — Explicit Bus Routing
Make sampler bus and synth shell bus truly separate, then feed both into a shared filter/FX rack.

527-63 — Preallocate Buses / Remove Per-Block Vectors
Move temporary audio buffers out of processBlock() into reusable member buffers.

527-64 — Hide/remove CPU-test clutter
Only after stable.

[Touch The Universe]

The above too long didn't read version...

Based on the latest 527-60 source, this synth is not yet cleanly structured as “every page has its own isolated bus and then all buses sum at the end.” It is closer to a large, mostly monolithic processBlock() with a few newer side buses added during optimization.

So going to start here

[Touch The Universe]

Yes, adding its own outbus for the sampler preserves the cpu savings and I can still bring in other synths, this is good.

[Touch The Universe]

Hoping to get some help. What could be causing this weird release behavior? Sounds like gating? Then I switch to an osc that has its own ADSR and its the normal release behavior.