DEV Community: Gary Doman/TizWildin

Building a Local-First AI, Audio, and Simulation Ecosystem as a Solo Developer

Gary Doman/TizWildin — Fri, 15 May 2026 01:29:13 +0000

Building a Local-First AI, Audio, and Simulation Ecosystem as a Solo Developer

I’m Gary Doman / TizWildin, a solo developer and musician building a local-first open-source ecosystem across audio plugins, AI tooling, browser instruments, deterministic simulation, runtime dashboards, and experimental developer frameworks.

This post is the hub map for the projects I’m building.

The common thread is:

local-first
open-source foundation
receipt-backed systems
deterministic runtimes
audio + AI + simulation
tools that creators and developers can inspect

1. FreeEQ8 — free open-source JUCE EQ plugin

FreeEQ8 is a free open-source EQ plugin built with JUCE.

It is aimed at producers, engineers, and plugin developers who want a practical open EQ project to test, inspect, and improve.

Repo:

https://github.com/GareBear99/FreeEQ8

DEV.to post:

FreeEQ8: Looking for Testers for a Free Open-Source JUCE EQ Plugin

2. Instrudio — browser instrument ecosystem

Instrudio is a browser-based virtual instrument ecosystem.

The flagship instrument is Studio Violin, a physically modelled bowed-string instrument using Helmholtz motion synthesis, H2 correction, Stradivari-style body EQ, sympathetic resonance, MIDI control, and a single-source-of-truth JSON instrument runtime.

Repo:

https://github.com/GareBear99/Instrudio

3. ARC-Neuron LLMBuilder — local-first AI model lifecycle

ARC-Neuron LLMBuilder is a local-first AI model lifecycle framework.

It focuses on dataset-connected model growth, benchmark receipts, candidate/incumbent promotion, archive-ready lineage, and governed small-model improvement.

Repo:

https://github.com/GareBear99/arc-neuron-llmbuilder-v1.0.0

4. ARC-Core — authority, receipts, and event spine

ARC-Core is the authority/control-plane layer for the wider ARC ecosystem.

It is focused on receipts, event logging, replay/rollback, runtime state, governed actions, and evidence-backed system behavior.

Repo:

https://github.com/GareBear99/ARC-Core

5. ARC Language Module — governed multilingual backend

ARC Language Module is a governed multilingual backend.

It is not just a translator. It models language graph data, runtime routing, readiness, coverage reports, ingestion governance, FastAPI/CLI/SQLite surfaces, and evidence snapshots.

Repo:

https://github.com/GareBear99/arc-language-module

6. ARC-StreamMemory — AI-readable visual memory spine

ARC-StreamMemory turns visual sources into deterministic AI-readable memory modules.

It can work with video files, screenshots, screen recordings, robotics feeds, DAW/plugin sessions, game footage, and UI states.

The direction includes FFmpeg ingest, frame hashes, seeded source spines, AI digests, module attachments, ARC-style receipts, OmniBinary-style chunk maps, Arc-RAR-style bundle manifests, and local viewers.

Repo:

https://github.com/GareBear99/ARC-StreamMemory

7. Proto-Synth Grid Engine — math-first 2D world runtime

Proto-Synth Grid Engine is a deterministic, blueprint-driven, math-first simulation surface.

The idea is:

Geometry = storage
Movement = computation
Entities = executors

It uses deterministic 2D simulation projected into a visually 3D synth-grid interface.

Repo:

https://github.com/GareBear99/Proto-Synth_Grid_Engine

8. ARC Turbo OS — collapsing redundant computation

ARC Turbo OS is a seed-rooted deterministic runtime concept focused on canonical problem graphs, reusable subgraphs, branch-aware execution, ARC receipts, and end-state resolution.

The goal is not magic speed. The goal is to avoid recomputing work that has already been resolved safely.

Repo:

https://github.com/GareBear99/ARC-Turbo-OS

9. Seeded Universe Recreation Engine — deterministic universe timeline

Seeded Universe Recreation Engine is a deterministic seed-based universe simulator.

The project connects universe simulation, Synth Origin, Universe Bridge, ARC receipts, TT-101 doctrine, branch-comparable timelines, and seeded physics/life/civilisation experiments.

Repo:

https://github.com/GareBear99/Seeded-Universe-Recreation-Engine

10. Neo-VECTR Solar Sim NASA Standard

Neo-VECTR Solar Sim NASA Standard is the solar/planet simulation sibling direction.

It is part of the seeded simulation family, focused on solar-system simulation, planetary state, orbital structure, and NASA-style validation framing.

Repo:

https://github.com/GareBear99/Neo-VECTR_Solar_Sim_NASA_Standard

11. AI Desk Meter — local-first runtime dashboard toward MuseMeter

AI Desk Meter is an open-source local-first runtime dashboard.

It syncs with a JSON source of truth and is the open foundation leading toward MuseMeter, a future second-brain / Neural Synth / AI buddy product.

Repo:

https://github.com/GareBear99/ai-desk-meter

12. TT-101 Handbook — doctrine layer

TT-101 Handbook is the doctrine/canon layer for seeded universe handling, emergent life, communication ethics, intervention rules, and signal bridging.

Repo:

https://github.com/GareBear99/TT-101_Handbook

Why these projects connect

The ecosystem is built around a few shared principles:

Local-first where possible
Open-source foundation
Deterministic state
Receipts and audit trails
Source-of-truth files
Replayable memory
AI-readable modules
Lightweight runtimes
Creative tools for musicians and developers
Simulation systems that preserve lineage

The audio tools prove creative utility.

The AI tools build memory, language, evaluation, and runtime control.

The simulation tools test deterministic world/state ideas.

The dashboard tools make runtime state visible.

Together, they form one larger architecture.

Main GitHub

https://github.com/GareBear99

Feedback welcome

I’m looking for feedback from:

audio developers
AI developers
local-first software builders
simulation developers
game developers
Web Audio developers
Python developers
JavaScript developers
open-source maintainers
people interested in deterministic runtimes and creative tools

This is a solo-dev ecosystem, built in public, with the goal of making useful creative tools and long-term local-first AI infrastructure.

Seeded Universe Recreation Engine: Building a Deterministic Universe Timeline from One Seed

Gary Doman/TizWildin — Fri, 15 May 2026 01:00:51 +0000

Seeded Universe Recreation Engine: Building a Deterministic Universe Timeline from One Seed

I’m building Seeded Universe Recreation Engine, a deterministic seed-based universe simulation project.

The core idea is simple but ambitious:

one canonical seed
→ physics
→ stars
→ planets
→ atmospheres
→ oceans
→ geology
→ chemistry
→ life
→ civilisation
→ signal detection
→ ARC receipts
→ branch-comparable timelines

The project is designed around a doctrine where the universe is not manually forced into outcomes. The seed defines the canonical timeline, physics unfolds from that seed, and interventions must be receipted instead of silently rewriting causality.

What the project is

Seeded Universe Recreation Engine is a browser-based deterministic universe simulator with an optional Python/FastAPI ARC backend.

The current system combines three major pieces:

Universe Engine v16
Synth Origin / Proto-Synth Grid Engine
Universe Bridge v1
ARC-Core receipt and ledger backend

Together they create a split-screen master-control environment where the universe simulation and the synth/observer system can communicate without breaking causality.

Universe Engine v16

The Universe Engine is the deterministic simulation layer.

From one seed, the engine unfolds a traceable universe containing:

stars
planets
atmospheres
oceans
geology
chemistry
life checks
evolution paths
civilisations
signal signatures
intervention branches

The model includes physics concepts such as:

Stefan-Boltzmann temperature
Jeans escape atmospheres
water phase diagram checks
Kepler-style orbital structure
tidal locking
radioactive heating
supernova enrichment
Kardashev civilisation detection
64-bit genome encoding
autocatalytic first-replication events

The point is not to hand-place life or civilisation.

The point is to let a deterministic seed produce a traceable universe state.

Zoom stack

The universe view is organized into zoom levels:

L0 → Cosmos / full universe
L1 → Galaxy cluster
L2 → Stellar system
L3 → Planet surface
L4 → Region cross-section
L5 → Molecule field
L6 → Atom patch
L7 → Synth Center / universe origin eye

The zoom stack matters because the project is not only a visual demo. It is meant to show a universe that can be explored across scale.

From cosmos to atoms, the goal is a continuous seeded timeline.

Synth Origin

The Synth Origin layer comes from the Proto-Synth Grid Engine direction.

In this universe project, the synth sits at the center as the signal instrument.

It acts as:

master control eye
scanner surface
signal router
blueprint-driven execution shell
communication backbone
ARC-gated authority surface

In universe mode, the synth scanner can detect civilisation contacts from the universe state.

The synth’s signal network then becomes the communication backbone for universe events.

Universe Bridge v1

The Universe Bridge connects the universe simulation and the synth system without breaking causality.

The bridge flow is:

Universe state
→ bridge extraction
→ civilisation contacts
→ synth scanner feed
→ synth signal events
→ universe receipt

The bridge logs crossings and keeps the interaction traceable.

That means the synth can observe and signal without silently mutating the canonical universe.

ARC-Core backend

The optional ARC backend provides a receipt and ledger layer.

A typical local backend setup is:

pip install fastapi uvicorn pydantic
python launch.py

The backend direction includes:

universe record ledger
tamper-evident receipt chain
branch simulation
REST endpoint surface
intervention evidence
origin record tracking

The repo’s architecture frames ARC-Core as the system that records truth, receipts, and branch outcomes.

TT-101 Doctrine

The project follows six core TT-101 rules:

1. Seed canonical — the seed is never changed to force outcomes.
2. Causality absolute — no signal travels faster than c_sim.
3. Energy conserved — ΔE_total = 0 always.
4. Intelligence emergent — life cannot be hardcoded, only arise from physics.
5. Interventions receipted — every perturbation is logged in ARC.
6. Branch comparable — a modified universe never replaces the canonical timeline.

This doctrine is the most important part of the project.

It means the simulation is not just about visuals. It is about traceability, causality, receipts, and controlled branching.

Why branch comparison matters

In a normal simulation, changing a value can overwrite the timeline.

In Seeded Universe Recreation Engine, an intervention should create a comparable branch.

That means:

canonical universe remains intact
intervention creates branch
branch stores divergence
branch can be compared
receipts explain what changed

This makes the project more like a deterministic timeline laboratory than a simple sandbox.

Master Control

The top-level launcher is MasterControl.html.

It provides:

split view between universe and synth
universe-only mode
synth-only mode
synth-center jump
bridge test pulse
ARC console access
draggable split panels

The point of Master Control is to make the system observable from one surface.

File structure direction

The repo includes major pieces such as:

MasterControl.html
launch.py
universe_bridge.js
sure/universe_observer_v16_vision.html
synth/index.html
ARC_Console/

The architecture connects them like this:

MasterControl.html
├─ Universe Engine v16
├─ Universe Bridge
├─ Synth Origin
└─ ARC-Core

Why this matters

Seeded Universe Recreation Engine is exploring a larger question:

Can a deterministic seed-based world be made traceable from cosmic scale down to chemistry, life, intelligence, signal detection, and intervention receipts?

That makes the project useful as an experimental foundation for:

universe simulation
deterministic timelines
procedural world generation
AI observer systems
seeded replay
emergent-life modeling
branch-comparable experiments
local-first scientific visualization
ARC-style receipt ledgers
Synth/observer interfaces

Repo

https://github.com/GareBear99/Seeded-Universe-Recreation-Engine

What I’m looking for

I’m looking for feedback from:

simulation developers
procedural generation developers
game engine developers
physics/math people
AI researchers
local-first software builders
JavaScript developers
Python/FastAPI developers
worldbuilding/tooling developers
people interested in deterministic timelines

Useful feedback includes:

physics model suggestions
seed/replay architecture feedback
zoom-stack design ideas
branch comparison design feedback
ARC receipt format suggestions
Universe Bridge feedback
Synth Origin integration feedback
performance ideas
visual clarity improvements
docs/onboarding suggestions

Long-term direction

The long-term direction is a deterministic universe recreation engine where the whole world can be traced back to a canonical seed.

Not just procedural noise.

Not just a pretty universe view.

A seed-rooted, branch-comparable, receipt-backed simulation where physics, life, civilisation, observation, and intervention all remain traceable.

Related ARC / Synth Ecosystem Repos

Seeded Universe Recreation Engine is part of a larger local-first ARC/Synth research ecosystem.

Related projects:

ARC-Neuron LLMBuilder — local-first AI model lifecycle, benchmark receipts, candidate/incumbent promotion, and dataset-connected model growth.

https://github.com/GareBear99/arc-neuron-llmbuilder-v1.0.0
ARC-Core — authority, receipts, event ledger, replay/rollback, and governed runtime control plane for ARC-style systems.

https://github.com/GareBear99/ARC-Core
Proto-Synth Grid Engine — deterministic 2D simulation projected visually as 3D, blueprint geometry, Neural-Synth view, Voxel Directory, and programmable world/runtime surfaces.

https://github.com/GareBear99/Proto-Synth_Grid_Engine
Neo-VECTR Solar Sim NASA Standard — seeded solar-system simulation direction with NASA-style physics framing, orbital structure, planetary state, and simulation validation goals.

https://github.com/GareBear99/Neo-VECTR_Solar_Sim_NASA_Standard
TT-101 Handbook — doctrine layer for seeded universe handling, emergent life, communication ethics, signal bridging, and intervention rules.

https://github.com/GareBear99/TT-101_Handbook
ARC Language Module — governed multilingual backend for language graph, routing, readiness, coverage reports, and future AI communication layers.

https://github.com/GareBear99/arc-language-module
ARC-StreamMemory — local-first visual memory spine for AI-readable footage, screenshots, frame hashes, module attachments, and receipt-backed visual replay.

https://github.com/GareBear99/ARC-StreamMemory

Together, these repos form the larger architecture around deterministic simulation, local-first AI memory, governed receipts, language routing, visual replay, and Synth-style runtime interfaces.

ARC Turbo OS: Building a Seed-Rooted Runtime That Collapses Redundant Computation

Gary Doman/TizWildin — Fri, 15 May 2026 00:53:30 +0000

ARC Turbo OS: Building a Seed-Rooted Runtime That Collapses Redundant Computation

I’m building ARC Turbo OS, a deterministic execution runtime designed around one core idea:

Collapse computation. Reuse everything. Jump to the end when possible.

The project explores a runtime model where tasks are transformed into canonical problem graphs, resolved outputs are indexed, dependency subgraphs can be reused, and repeated workflows can jump directly to already-known end states.

This is not about claiming every task becomes magically faster.

It is about recognizing when work has already been done, when subgraphs already exist, when the final state is derivable, and when recomputation can be avoided.

The core idea

Traditional execution usually looks like this:

input → compute → output

ARC Turbo OS execution is designed to look more like this:

input → normalize → match → reuse → jump → output

If the system has already resolved the same normalized problem, it should not recompute the whole chain.

It should jump directly to the resolved output.

What ARC Turbo OS is

ARC Turbo OS is a seed-rooted, branch-aware deterministic runtime.

The system model is:

State(t) = F(root_seed, branch_id, event_spine)

Where:

root_seed defines the deterministic session origin
branch_id identifies the lineage path
event_spine is the append-only causal history

The design goal is to avoid hidden mutable state and make runtime state reconstructable from explicit inputs, branches, and events.

Architecture

The architecture is built around several layers.

1. Root Seed Layer

The root seed defines the deterministic origin of the session.

It gives the runtime a reproducible starting point so future state can be understood as a function of seed, branch, and event history.

2. Binary Event Spine

Every meaningful action becomes a structured event.

The event spine acts as an append-only causal log, allowing state reconstruction, replay, lineage inspection, and receipt generation.

3. Deterministic Runtime

The runtime avoids uncontrolled randomness.

All state transitions should be explicit, and external I/O should be wrapped as receipts so the system can distinguish deterministic internal state from externally observed effects.

4. ARC Receipt Layer

The receipt layer tracks:

causality
dependencies
trust levels
execution lineage
external observations
resolved output provenance

This is important because reuse only works safely when the system knows what was reused and why.

5. Implicit to Explicit Expansion

High-level user intent can be expanded into structured execution graphs.

For example:

"build project"
→ compile
→ link
→ package
→ validate
→ export

Once a workflow becomes an explicit graph, the runtime can identify which pieces are new and which pieces have already been resolved.

6. Turbo Resolver

The Turbo Resolver is the core engine.

It is responsible for:

canonical problem identification
output matching
subgraph reuse
execution collapse
end-state resolution

Canonical problem identity

The runtime depends on normalized task identity.

problem_id = hash(normalized_task)

Equivalent tasks should map into the same solution space.

That lets the runtime ask:

Have I already solved this?
Have I solved part of this?
Is the output still valid?
Can I reuse a subgraph?
Can I jump to the end?

Resolved output index

The resolved output index stores completed results:

resolvedOutputs[problem_id] = output

A simplified resolver looks like this:

function resolveTask(task) {
  const id = hash(normalize(task));

  if (resolvedOutputs.has(id)) {
    return resolvedOutputs.get(id); // jump to end
  }

  const graph = expand(task);

  for (const node of graph) {
    if (!resolvedOutputs.has(hash(node))) {
      execute(node);
    }
  }

  const result = finalize(task);
  resolvedOutputs.set(id, result);

  return result;
}

The idea is simple: if an output or dependency is already known, do not recompute it.

Where this helps

ARC Turbo OS is strongest in structured, repeatable workflows.

Examples include:

build systems
packaging pipelines
deterministic AI workflows
simulation reruns
branch comparisons
session restoration
structured content generation
repo maintenance tasks
repeated validation pipelines

These are cases where the same or similar work often appears again and again.

Performance model

The performance benefit depends on how much work is reusable.

A rough model:

new task             → baseline speed
partial reuse        → faster
structured workflow  → much faster
fully resolved state → instant jump

The repo frames this as a system where performance improves as reusable outputs accumulate.

The important part is that the speedup comes from avoiding redundant work, not from violating the cost of genuinely new computation.

What it does not accelerate

ARC Turbo OS does not accelerate everything.

It does not eliminate the cost of:

irreducible new computation
unpredictable external systems
non-deterministic processes
novel problem spaces with no prior lineage
unsafe reuse where dependencies have changed

This matters because the runtime has to be honest.

The system should only jump when the end state is already computed, safely derivable, or verified as reusable.

Branch-aware execution

Branch awareness lets tasks fork from any point while preserving lineage.

That makes it possible to explore alternate outcomes without destroying history.

A branch-aware runtime can support:

alternate build paths
candidate outputs
rollback
replay
comparison
promotion
experiment tracking
deterministic restoration

This fits the broader ARC-style architecture direction: receipts, lineage, replay, promotion, and reproducible state.

End-state resolution

The defining feature is end-state resolution:

If an output is already derivable, the system jumps directly to it.

Example:

first run:
build plugin
→ compile
→ link
→ package
→ export

second run:
build plugin
→ matched
→ jump to final artifact

In a mature system, the runtime should identify exactly which stages changed and which outputs remain valid.

Why this matters

Modern systems recompute too much.

A lot of development workflows repeat the same work:

rebuilding unchanged dependencies
regenerating unchanged assets
rerunning identical validation
reprocessing already-known source states
recreating artifacts that could have been resolved from lineage

ARC Turbo OS explores a runtime model where the system remembers solved work, verifies dependency identity, and collapses repeated computation into reuse.

Current roadmap

The repo roadmap is staged around:

v0.1

task normalization
output cache
basic graph expansion
manual execution

v0.2

ARC receipt system
branch tracking
reusable subgraphs

v0.3

implicit command expansion
turbo resolver

v1.0

full runtime shell
session rail
deterministic workspace

Repo

https://github.com/GareBear99/ARC-Turbo-OS

What I’m looking for

I’m looking for feedback from:

systems developers
build tool developers
DevOps engineers
AI workflow developers
deterministic runtime builders
cache/incremental build people
graph execution researchers
local-first software builders
open-source maintainers

Useful feedback includes:

task normalization ideas
graph expansion design feedback
cache invalidation concerns
receipt format suggestions
branch lineage ideas
deterministic runtime risks
reuse safety rules
build-system comparisons
roadmap suggestions

Long-term direction

The long-term goal is to make ARC Turbo OS a deterministic runtime shell that reduces redundant work through canonical identity, reusable outputs, event-spine lineage, and safe end-state resolution.

Not magic speed.

Not speculative future computation.

A runtime that knows when the work is already done.

Proto-Synth Grid Engine: Building a Math-First 2D World Runtime That Feels 3D

Gary Doman/TizWildin — Fri, 15 May 2026 00:50:08 +0000

Proto-Synth Grid Engine: Building a Math-First 2D World Runtime That Feels 3D

I’m building Proto-Synth Grid Engine, also described in the repo as I/O Synth Grid Engine.

The project is an experimental, deterministic, low-weight world runtime where geometry is not just decoration. Geometry becomes structure, storage, routing, and execution space.

The core idea is:

Geometry = storage
Movement = computation
Entities = executors

Instead of building a heavy 3D stack first, the engine starts with deterministic 2D simulation logic and projects it into a visually 3D synth-grid interface.

What this is

Proto-Synth Grid Engine is a math-first simulation surface.

It treats the world like a programmable environment:

shell geometry defines the world
module blueprints attach systems into that shell
entities move through the grid as executors
grid mutations become event-shaped state changes
deterministic replay becomes possible through event logs and receipts
the render layer projects the 2D core into a 3D-feeling visual surface

The result is not just a game prototype or visual toy. It is an engine surface for future local-first systems, AI runtimes, neural interfaces, spatial dashboards, and programmable world simulations.

Why 2D first

The engine is built around a deterministic 2D vector-space core.

That matters because 2D simulation is:

easier to replay
easier to audit
easier to seed
easier to run on older hardware
easier to reason about
lighter than full 3D
still capable of looking spatial through projection

The visual layer can then use:

perspective scaling
cube-grid projection
layered sprite depth
shell overlays
depth shading
reticle and HUD surfaces
synthwave geometry

That creates a 3D-feeling interface without making the core simulation dependent on a heavyweight 3D engine.

Blueprint-driven worlds

The engine loads blueprints that define the structure and behavior of the world.

The main blueprint layers are:

Shell Blueprint — defines the geometry of the world.
Module Blueprints — attach systems into the shell.
Execution Layer — runs the deterministic simulation loop.

Example runtime concepts include:

shell blueprints
ship modules
scanner modules
HUD modules
cube-grid projection mapping
deterministic seeded worlds
modular system attachment
spatial execution visualization

This lets the world become a programmable surface instead of a fixed scene.

ARC-Core-shaped event discipline

Proto-Synth Grid Engine is designed around the same doctrine as the ARC ecosystem: authority, events, receipts, deterministic replay, and audit trails.

The repo describes the engine as built on an ARC-Core pattern where grid mutations, module attachment, blueprint loads, and execution steps are modeled as receipt-shaped events.

That means core actions can be thought of as:

blueprint load → signed receipt
grid mutation → append-only event
module attach → authority-gated event
simulation loop → deterministic replay
save/load → event log + snapshot

This direction is important because it gives the engine a path toward:

reproducible worlds
receipt-verified loads
replayable simulations
audit trails
source-of-truth state
module synchronization

Iteration path

The repo has evolved through multiple iterations:

Iteration 8 — Blueprint Shell Prototyping

Early shell generation and blueprint structure.

Example direction:

blueprint_octagon.json
→ octagon shell
→ module attachment surface

Iteration 9 — Game Engine Prototype

Prototype world runtime demonstrating:

blueprint shell generation
cube-grid projection mapping
deterministic seed worlds
modular system attachment
spatial execution visualization

Iteration 10 — Synth Grid Engine

A stronger blueprint-driven simulation shell where geometry becomes computation.

This iteration frames the runtime as a serious modular world engine direction, not just a one-off demo.

Iteration 11 — Neural-Synth / Wetware Core

The engine expands into a neural-style interface direction with:

Neural-Synth view
Voxel Directory view
synchronized visual structures
RGB/seed reproducibility
wetware-style runtime presentation
spatial interface concepts for future AI systems

Neural-Synth and Voxel Directory

One of the most interesting pieces is the relationship between the Neural-Synth view and the Voxel Directory view.

Both are intended to represent the same underlying source information through different visual surfaces:

Neural-Synth: node/web/thinking surface
Voxel Directory: icon/grid/filesystem-style surface

The important idea is synchronization.

A change in one representation should correspond to the same source structure in the other representation.

That creates a future path where an AI or user can inspect the same runtime through multiple visual modes without losing the underlying source-of-truth relationship.

Why this matters

A lot of engines treat visuals, state, and logic as separate concerns.

Proto-Synth Grid Engine explores a different idea:

space itself can act like a filesystem
geometry can be executable structure
visual layout can reflect runtime state
entities can act as autonomous executors
blueprints can define both shape and behavior

This makes the project relevant beyond normal game development.

Possible use cases include:

deterministic game/sim prototypes
AI runtime visualizers
spatial dashboards
local-first programmable environments
neural interface experiments
visual source-of-truth editors
low-weight world simulations
seeded universe or grid simulations
blueprint-based runtime shells

Controls

The engine includes simple interaction controls such as:

W A S D → move master control
Mouse   → aim vector
C       → toggle reticle
R       → reset

The goal is direct interaction with the simulated surface while still keeping the core lightweight.

Repo

https://github.com/GareBear99/Proto-Synth_Grid_Engine

What I’m looking for

I’m looking for feedback from:

game developers
simulation developers
JavaScript developers
AI interface builders
low-level engine designers
UI/UX experimenters
local-first software builders
people interested in deterministic systems
people interested in visual AI runtimes

Useful feedback includes:

simulation architecture feedback
blueprint format ideas
deterministic replay suggestions
low-weight rendering ideas
Neural-Synth interface feedback
Voxel Directory interaction ideas
event/receipt architecture feedback
performance suggestions
docs and onboarding improvements

Long-term direction

The long-term goal is to make Proto-Synth Grid Engine a lightweight programmable world surface.

Not just a visual demo.

Not just a grid.

A deterministic simulation layer where geometry, execution, memory, and interface all live in the same blueprint-driven environment.

ARC Language Module: Building a Governed Multilingual Backend for Future AI Systems

Gary Doman/TizWildin — Fri, 15 May 2026 00:45:38 +0000

ARC Language Module: Building a Governed Multilingual Backend for Future AI Systems

I’m building ARC Language Module, a governed multilingual backend foundation for future AI systems.

The project is not meant to be “just another translator.” It is a language knowledge engine and multilingual control layer that helps an AI system understand:

what languages it has data for
what scripts, variants, pronunciation hints, and lineage relationships exist
what it can actually translate or route today
what still depends on external providers or future corpora
what was seeded, imported, changed, reviewed, or left unresolved

The goal is to make multilingual capability visible, inspectable, and honest.

Why this exists

Most language tools specialize in one narrow layer:

translation endpoint
offline machine translation
browser translation
locale/reference data
script or formatting data

Those are useful, but future AI systems need something broader.

They need to know:

what language knowledge they own
what runtime tools are available
what support is partial or missing
which routes are trustworthy
which data came from which source
what changed between releases
what needs to be acquired, reviewed, or expanded

That is the lane ARC Language Module is built for:

not best translator in the world
but a governed language substrate for multilingual AI memory, routing, readiness, and auditability

What ARC Language Module is

Think of it as the brain, filing system, and traffic controller behind a multilingual AI stack.

It provides:

a structured language graph
SQLite-backed storage
CLI operator tooling
FastAPI API surface
seeded language records
scripts and variants
pronunciation and phonology profiles
transliteration profiles
phrase translation seed data
capability/readiness records
coverage reports
policy snapshots
release evidence snapshots

The important distinction is that the system separates language knowledge from runtime capability.

Knowing a language exists is not the same as being able to translate it, speak it, transliterate it, or route it through a provider.

ARC Language Module models that distinction directly.

What it can do today

The current production-track foundation can store and report structured language knowledge such as:

language records
aliases and alternate names
scripts
language lineage / family relationships
variants, dialects, registers, orthographies, and historical stages
pronunciation profiles
phonology hints
transliteration profiles
seeded phrase translations
runtime capability and readiness records

It can answer practical operator questions like:

Which languages are loaded?
Which scripts are attached to each language?
Which languages have pronunciation or phonology profiles?
Which languages have transliteration coverage?
Which capabilities are production, reviewed, experimental, or absent?
Which runtime routes are available?
What changed between releases?

Honest routing

A key idea in ARC Language Module is honest routing.

Instead of pretending every language path is fully supported, the system can route requests through explicit states such as:

seeded local phrase support
optional local/runtime providers
external provider bridges
not-ready states
gap states
missing corpus states

That makes it a language operations layer, not just a translation wrapper.

For AI systems, that matters because false confidence is dangerous. A multilingual backend should be able to say:

I know this language exists.
I have partial metadata.
I have script information.
I do not have enough translation data yet.
This route requires an external provider.
This path is experimental.
This path is production-ready.

That kind of capability boundary is the difference between a toy translation endpoint and a governed AI language substrate.

Architecture

The repo is split into clear layers:

core/      → config, database, models
services/  → language logic, ingestion, routing, policy, evidence, coverage
api/       → FastAPI surface grouped by concern
cli/       → operator entrypoints and handlers
config/    → seed manifests and curated inputs
sql/       → schema and indexes
docs/      → architecture, runtime, policy, onboarding, and comparison docs

This gives the system both application-facing and operator-facing surfaces.

Current release snapshot

The current package snapshot reports:

Version: 0.27.0
Languages: 35
Phrase translations: 385
Language variants: 104
Language capabilities: 245
Pronunciation profiles: 35
Phonology profiles: 35
Transliteration profiles: 21
Semantic concepts: 30
Concept links: 46

Provider support is intentionally modeled separately from core graph truth. Runtime provider availability depends on what is installed, registered, and enabled in the target environment.

Quick start

A typical local setup looks like:

pip install -e .

PYTHONPATH=src python -m arc_lang.cli.main init-db
PYTHONPATH=src python -m arc_lang.cli.main seed-common-languages
PYTHONPATH=src python -m arc_lang.cli.main stats
PYTHONPATH=src python -m arc_lang.cli.main coverage-report
PYTHONPATH=src python -m arc_lang.cli.main system-status
PYTHONPATH=src python -m arc_lang.cli.main build-implementation-matrix
PYTHONPATH=src python -m arc_lang.cli.main release-snapshot

The point is not just to run a server. The point is to inspect what the language backend actually contains and what it can honestly support.

Evidence and release snapshots

ARC Language Module includes release/evidence snapshot concepts so the package can explain what it contains.

A release snapshot can include:

package version
version consistency checks
API health/version integrity checks
live graph counts
coverage state
readiness state
evidence outputs

That helps turn language infrastructure into something auditable instead of a hidden pile of tables and assumptions.

Where it fits compared to other tools

Different projects solve different problems well.

Argos Translate is useful for offline open-source translation packages.
LibreTranslate is useful as a self-hosted translation API.
Firefox Translations / Bergamot is useful for local browser translation.
Unicode CLDR is useful for locale/reference data and internationalization.
ARC Language Module is aimed at the governed orchestration layer: language knowledge, routing, readiness, provenance, and auditability.

The project can sit above or beside translation providers instead of replacing every provider.

What it is not

To keep the claims honest, ARC Language Module is not:

a universal best-in-class machine translation model
a finished speech/TTS stack
a complete transliteration engine for every script pair
a giant cloud service by itself

It is strongest as a multilingual control layer inside a larger AI product, local-first stack, research runtime, or language-aware system.

Repo

https://github.com/GareBear99/arc-language-module

What I’m looking for

I’m looking for feedback from:

AI developers
NLP developers
localization engineers
language technology researchers
multilingual app builders
Python developers
FastAPI developers
SQLite/data-modeling people
corpus/data curators
open-source maintainers

Useful feedback includes:

language graph design feedback
provider routing ideas
corpus ingestion ideas
coverage/reporting improvements
pronunciation/phonology expansion ideas
transliteration profile suggestions
API/CLI design feedback
release snapshot and evidence improvements
docs and onboarding issues

Long-term direction

The long-term goal is to make ARC Language Module a governed multilingual substrate for future AI systems.

Not just translation.

Not just locale data.

A language operations layer that can tell an AI system what it knows, what it can route, what it can prove, and what still needs to be acquired or reviewed.

ARC-StreamMemory: Building a Local-First Visual Second Brain for AI-Readable Video Memory

Gary Doman/TizWildin — Fri, 15 May 2026 00:39:22 +0000

ARC-StreamMemory: Building a Local-First Visual Second Brain for AI-Readable Video Memory

I’m building ARC-StreamMemory, a local-first visual memory system for AI-readable video, screen, snapshot, robotics, DAW/plugin, game, and app UI sessions.

The goal is to turn visual activity into something an AI can inspect, replay, cite, verify, and attach to a module.

Instead of treating video as a flat recording, ARC-StreamMemory turns it into a structured memory object:

visual source
→ FFmpeg video/snapshot ingest
→ AI frame-speed schedule
→ frame hashes
→ seeded source spine
→ OCR-ready/event-ready timeline
→ AI digest
→ ARC-style receipts
→ OmniBinary-style chunk map
→ Arc-RAR-style bundle manifest
→ local source-spine viewer
→ AI module attachment JSON

What ARC-StreamMemory does

ARC-StreamMemory can ingest visual sources such as:

video files
screen recordings
screenshots
DAW/plugin sessions
game footage
browser workflows
robotics camera feeds
app UI states

The output is not just a folder of screenshots.

The output is a deterministic visual memory bundle with:

frame indexes
frame hashes
event timelines
AI digest files
module attachment JSON
seeded memory spine
validation reports
bundle manifests
a local HTML viewer

Why this matters

A normal screen recording answers:

What happened?
Maybe watch the whole video again.

ARC-StreamMemory is designed to answer:

What happened?
→ Read the AI digest.
→ Jump to the relevant event.
→ Open the frame.
→ Verify the frame hash.
→ Follow the receipt.
→ Follow the chunk pointer.
→ Restore or export the bundle.

That makes visual memory easier for an AI or developer to inspect and verify.

Current capabilities

The current release foundation supports:

demo visual-memory session generation
snapshot folder ingest
regular FFmpeg video ingest
AI frame-speed policies
per-frame SHA-256 hashing
deterministic memory spine hashing
seeded source-spine lineage
Markdown and JSON AI digests
AI module attachment output
ARC-style receipt export
OmniBinary-style chunk map export
Arc-RAR-style bundle manifest export
local HTML viewer
validation reports
ZIP bundle export
ARC-FusionCapture adapter/spec layer

The repo intentionally avoids overclaiming unfinished integrations.

The current public foundation is complete for deterministic visual memory ingest, indexing, hashing, digesting, viewing, validating, and bundle export. Future gates include native live screen capture, full OCR engine hookup, native OmniBinary persistence, native Arc-RAR packaging, live ARC-Core sync, and production robotics sensor bus integration.

AI frame-speed policy

ARC-StreamMemory supports different frame sampling speeds depending on what the AI needs to remember.

Recommended frame rates include:

0.2 FPS → long passive session memory
0.5 FPS → lightweight visual diary
1 FPS   → general AI inspection default
2 FPS   → UI debugging / GitHub / DAW workflows
5 FPS   → detailed interaction review
10 FPS  → motion-sensitive review

This matters because not every AI memory task needs full video.

A long passive session may only need sparse visual anchors, while a DAW/plugin bug or UI regression may need denser frame sampling.

Deterministic source-spine model

The memory spine is built around a deterministic seed chain:

capture_policy_hash
+ source_fingerprint
+ frame_schedule_hash
+ ordered_frame_hashes
+ chunk_hash
= session_root_seed

That creates a reproducible source spine:

root_seed
→ chunk
→ frame
→ frame_hash
→ event_receipt
→ module_attachment_pointer

The goal is to make visual memory verifiable and replayable instead of vague.

Example workflows

A standard FFmpeg workflow looks like this:

python scripts/ffmpeg_probe.py
python scripts/ingest_video.py input.mp4 --fps 1 --out sessions/video_memory
python scripts/build_stream_memory.py sessions/video_memory --title "Video memory"
python scripts/hash_memory_spine.py sessions/video_memory
python scripts/build_seed_spine.py sessions/video_memory
python scripts/build_ai_digest.py sessions/video_memory
python scripts/validate_memory_bundle.py sessions/video_memory

A demo session workflow looks like this:

python scripts/create_demo_session.py
python scripts/build_stream_memory.py examples/demo_session --title "ARC demo visual memory"
python scripts/hash_memory_spine.py examples/demo_session
python scripts/build_seed_spine.py examples/demo_session
python scripts/build_ai_digest.py examples/demo_session
python scripts/validate_memory_bundle.py examples/demo_session
python scripts/make_bundle.py examples/demo_session --out release_evidence/demo_streammemory_bundle.zip

Output structure

A memory session can include:

session/
├─ frames/
├─ memory/
│  ├─ capture_policy.json
│  ├─ frame_index.json
│  ├─ event_timeline.jsonl
│  ├─ ocr_index.jsonl
│  ├─ ai_digest.md
│  ├─ ai_digest.json
│  ├─ module_attachment.json
│  ├─ memory_spine.json
│  ├─ seed_spine.json
│  └─ session_summary.md
├─ receipts/arc_receipts.jsonl
├─ omnibinary/chunk_map.json
├─ arcrar/bundle_manifest.json
├─ reports/validation_report.json
└─ reports/bundle_export_report.json

This gives each visual memory session a structure an AI system can navigate.

ARC-FusionCapture direction

ARC-StreamMemory also includes a compatibility layer for the planned ARC-FusionCapture runtime.

The future capture layer is meant to wrap regular FFmpeg with:

camera/feed profiles
robotics capture modes
hardware acceleration selection
sensor timestamp sync
rolling buffer policy
event-triggered clips
AI-friendly frame-speed output
ARC receipts
OmniBinary pointers
Arc-RAR bundle manifests

This creates a path from simple video ingest today toward robotics/media capture workflows later.

Public use cases

ARC-StreamMemory can be useful for:

AI developers

Turn debugging videos, browser workflows, and UI sessions into reproducible visual memory modules.

Audio/plugin developers

Archive DAW/plugin tests, plugin validation sessions, FreeEQ8 or FreeVox8 regressions, and visual evidence from test runs.

Robotics developers

Use FFmpeg now, then connect ARC-FusionCapture later for sensor-synced camera memory and robot black-box replay.

Research and reproducibility

Use seeded spines, hashes, citations, validation reports, and module attachments to make visual sessions inspectable and reproducible.

Game and app developers

Capture game states, UI flows, visual bugs, and build history as replayable evidence bundles.

Repo

https://github.com/GareBear99/ARC-StreamMemory

What I’m looking for

I’m looking for feedback from:

AI developers
computer vision developers
robotics developers
Python developers
FFmpeg users
local-first builders
reproducibility researchers
audio/plugin developers
game developers
people interested in AI visual memory

Useful feedback includes:

frame sampling policy ideas
OCR integration suggestions
robotics capture suggestions
viewer/UI feedback
validation/reporting improvements
bundle format feedback
source-spine design feedback
module attachment use cases
local-first architecture feedback

Long-term direction

The long-term goal is to make ARC-StreamMemory a local-first visual second brain for AI systems.

Not just video storage.

Not just screenshots.

A deterministic, replayable, source-verifiable memory spine that can turn visual sessions into AI-readable evidence.

AI Desk Meter: Building a Local-First Runtime Dashboard Toward MuseMeter

Gary Doman/TizWildin — Fri, 15 May 2026 00:36:36 +0000

AI Desk Meter: Building a Local-First Runtime Dashboard Toward MuseMeter

I’m building AI Desk Meter, an open-source local-first runtime dashboard for AI status, runtime state, and companion-style desktop visibility.

The project is also the open-source foundation leading toward MuseMeter, a future second-brain / Neural Synth / AI buddy product.

The core idea is simple:

local runtime state → JSON source of truth → dashboard sync → native/app/hardware display

AI Desk Meter is meant to stay lightweight, inspectable, and useful without requiring a server.

What AI Desk Meter is

AI Desk Meter is a local-first dashboard project that displays runtime state from a JSON-backed source of truth.

It is designed as a visible companion surface for an AI/runtime system, showing state in a way that can eventually connect to:

local AI agents
runtime monitors
desktop companion apps
small hardware displays
Raspberry Pi / ESP32 style companion builds
native app shells
future MuseMeter hardware/software releases

The current project is focused on making the foundation clean, open, and usable.

Why I’m building it

Most AI interfaces are either chat boxes, dashboards, or cloud services.

AI Desk Meter is aimed at a different interaction pattern: a small visible runtime companion that can sit on your desktop, show what the system is doing, and eventually become a bridge between AI status, local memory, agent state, and companion hardware.

The long-term direction is MuseMeter:

second-brain style companion
local-first AI buddy
Neural Synth-inspired visual interface
desktop/runtime visibility
optional companion hardware
open-source foundation before the commercial 3.0 product line

Local-first design

The project is intentionally built around a no-server default.

That means:

no required cloud backend
dashboard state comes from local files/runtime output
JSON can act as the source of truth
the system can be inspected directly
future native/hardware layers can read the same state model

This keeps the project simple, portable, and easier to reason about.

Current release direction

The current AI Desk Meter direction includes:

runtime dashboard sync
JSON-backed state updates
local-first/no-server architecture
support/funding links
open-source project foundation
future native app holster direction
future companion hardware direction
roadmap toward MuseMeter 3.0

The small pixel companion character and “Musing...” state are intentional.

Right now, Musing... represents an active response/action/loading state. Later versions may split this into more specific runtime states such as:

responding
loading
thinking
idle
action running
waiting for input
agent task active

Why JSON as source of truth

The dashboard is built around a JSON state model because it gives the project a clean bridge between layers.

A JSON runtime state can be read by:

the web dashboard
a native app wrapper
Python CLI tools
hardware companion displays
future agent runtimes
test scripts
docs and demos

This makes the dashboard more than a static UI. It becomes a visible surface for a local runtime.

Where MuseMeter fits

AI Desk Meter is the open-source foundation.

MuseMeter is the larger product direction.

The plan is:

AI Desk Meter open-source foundation
→ runtime dashboard stability
→ native app shell / holster
→ real Muse/agent connection
→ companion hardware support
→ MuseMeter 3.0 commercial package

Everything leading up to the commercial 3.0 direction is meant to preserve the open-source foundation while proving the runtime/dashboard concept in public.

Repo

https://github.com/GareBear99/ai-desk-meter

What I’m looking for

I’m looking for feedback from:

AI developers
local-first app builders
Python developers
web dashboard developers
hardware/display builders
Raspberry Pi users
ESP32/Arduino experimenters
people interested in AI companion interfaces
open-source maintainers

Useful feedback includes:

dashboard layout issues
JSON runtime state suggestions
native app packaging ideas
hardware display ideas
local-first architecture feedback
UI/UX suggestions
install/run issues
roadmap feedback

Long-term vision

The long-term goal is a small, useful, local-first AI companion surface that can grow from a web dashboard into a native app and eventually into hardware.

AI Desk Meter is the foundation.

MuseMeter is the product horizon.

I’m building it in public so the runtime, dashboard, and companion architecture can be tested, improved, and documented as it grows.

ARC-Neuron LLMBuilder: Building a Local-First AI Model Growth and Evaluation Runtime

Gary Doman/TizWildin — Fri, 15 May 2026 00:31:49 +0000

ARC-Neuron LLMBuilder: Building a Local-First AI Model Growth and Evaluation Runtime

I’m building ARC-Neuron LLMBuilder, a local-first AI model lifecycle framework focused on small-model improvement, benchmark receipts, dataset-connected training paths, and governed candidate promotion.

The goal is not just to wrap an existing model. The goal is to build a repeatable system where model candidates, datasets, evaluations, receipts, promotion decisions, and archive lineage can all be tracked in a way that is inspectable and reproducible.

What ARC-Neuron LLMBuilder is

ARC-Neuron LLMBuilder is designed as a local-first framework for building and improving AI models through a governed lifecycle.

The core idea is:

datasets → candidates → evaluations → receipts → promotion gates → archived lineage → next candidate

Instead of treating model building as a black box, the project focuses on making each step visible:

what data was used
what candidate was produced
how it was evaluated
what metrics were captured
why a candidate passed or failed
which model became the incumbent
what lineage led to that decision

Why I’m building it

A lot of AI tooling is cloud-first, API-first, or hidden behind remote systems.

ARC-Neuron LLMBuilder is aimed at a different lane:

local-first AI experimentation
open model lifecycle tooling
reproducible evaluation receipts
dataset-connected improvement
small-model growth paths
archive-ready promotion history
lower dependency on remote services

The long-term goal is to support a practical local AI builder workflow where progress can be measured, replayed, compared, and preserved.

Current focus

The current public release focuses on the foundation:

candidate model tracking
benchmark/evaluation structure
receipt generation
promotion-oriented workflow
dataset integration direction
archive-ready lineage
local-first project structure
public documentation and reproducibility

The next major direction is connecting stronger datasets and pushing toward a more complete base-model workflow while keeping the evaluation path clean.

Candidate and incumbent model flow

The project is built around the idea that model improvement should be judged through a controlled candidate/incumbent process.

A candidate should not automatically replace the current model just because it exists.

Instead, it should pass through:

dataset selection
training or fine-tuning run
evaluation
benchmark receipt creation
comparison against the incumbent
promotion or rejection
archived lineage record

That makes improvement measurable instead of vibe-based.

Benchmark receipts

Benchmark receipts are a core part of the system.

A receipt records the evidence behind a model run or evaluation decision. The goal is to preserve:

model identity
dataset/source information
scoring output
timestamped evaluation data
comparison metadata
promotion status
failure notes when relevant

This gives the project a paper trail for improvement.

Why local-first matters

Local-first does not mean refusing all external resources.

It means the core development loop should not depend on a permanent remote service to function.

That matters because:

runs should be reproducible
project state should be inspectable
model lineage should be preserved locally
experiments should not disappear behind a cloud dashboard
users should be able to understand what changed and why

Where this fits

ARC-Neuron LLMBuilder is part of a larger local-first AI architecture direction around governed runtimes, archive-backed memory, reproducible evaluation, and offline-capable model workflows.

The repo is currently focused on the LLMBuilder layer: model lifecycle, datasets, evaluations, receipts, and promotion logic.

Repo

https://github.com/GareBear99/arc-neuron-llmbuilder-v1.0.0

What I’m looking for

I’m looking for feedback from:

AI developers
Python developers
local-first AI builders
machine learning engineers
dataset curators
benchmark/eval people
open-source maintainers
people interested in small-model improvement

Useful feedback includes:

repo structure issues
dataset integration ideas
benchmark suggestions
evaluation design feedback
reproducibility concerns
docs improvements
local runtime issues
model promotion workflow ideas

Current direction

The project is moving toward a stronger full pipeline:

dataset ingestion
→ training/fine-tuning candidates
→ evaluation receipts
→ candidate vs incumbent comparison
→ promotion gates
→ archive lineage
→ repeatable model growth

I’m building ARC-Neuron LLMBuilder in public as a local-first AI model growth framework.

Studio Violin: Building a Physically Modelled Bowed-String Instrument in Instrudio

Gary Doman/TizWildin — Fri, 15 May 2026 00:25:14 +0000

Studio Violin: Building a Physically Modelled Bowed-String Instrument in Instrudio

I’m building Instrudio, a browser-based virtual instrument ecosystem, and the flagship instrument right now is Studio Violin.

Studio Violin is a physically modelled bowed-string instrument built around Helmholtz motion synthesis, H2 harmonic correction, inharmonicity modelling, Stradivari-style body resonances, sympathetic open-string resonance, and live MIDI control.

The goal is not just to make a violin-like web instrument. The goal is to prove that a single version-controlled instrument definition can drive synthesis, UI, MIDI routing, plugin bridge behavior, presets, and live update propagation from one source of truth.

What Studio Violin does

Studio Violin models the behavior of a bowed violin string using a synthesis chain designed around acoustic measurements and practical browser audio constraints.

The instrument includes:

Helmholtz bowed-string waveform synthesis
H2 correction oscillator
Inharmonicity chorus per string
8-band Stradivari-style body EQ
Per-string tonal offsets
Sympathetic open-string resonance
Nonlinear bow coupling
Pressure-coupled vibrato
Interval-scaled portamento
Bow-pressure, bow-speed, bow-point, character, brightness, attack, and vibrato controls
External MIDI routing through the Instrudio app

Synthesis model

The Helmholtz waveform uses a Fourier-style bowed-string model:

bₙ = −(2 / (n²π²D(1−D))) · sin(nπD)
D = 0.5 + bowPressure × 0.30

The H2 correction oscillator is used to bring the second harmonic closer to the target H2/H1 balance measured in bowed-string acoustic research.

Studio Violin also includes per-string inharmonicity spread:

G = 0.00035
D = 0.00028
A = 0.00022
E = 0.00018

The result is a sound engine that behaves less like a static sample trigger and more like a continuously controlled bowed instrument.

Stradivari-style body resonances

The body EQ model uses eight resonance bands:

A0: 275 Hz
A1: 475 Hz
B1−: 530 Hz
B1+: 580 Hz
Bridge hill: 2800 Hz, Q = 6.5
Upper resonance: 4500 Hz
Notch: 1100 Hz
Warmth: 180 Hz

There are also per-string offsets:

G string: warmer, reduced bridge hill
E string: brighter, boosted bridge hill

This lets the instrument react differently across the G, D, A, and E strings instead of applying one flat tone curve to the whole range.

Sympathetic resonance

Studio Violin includes sympathetic resonance using four triangle oscillators tuned to the open strings.

Amplitude = (1 − cents / 20) × 0.038

The closer the played note is to an open-string relationship, the stronger the sympathetic contribution becomes.

Expressive controls

The instrument exposes controls for:

Bow pressure
Bow speed
Bow point
Vibrato rate
Vibrato depth
Attack
Brightness
Reverb
Volume
Playing character

Character modes include:

Solo
Bowed
Pizzicato
Col Legno
Tremolo
Spiccato

It also includes scale helpers such as G Major, D Major, A Minor, and Chromatic.

Signal chain

The current signal chain is:

PeriodicWave oscillator
→ H2 oscillator
→ chorus oscillators
→ WaveShaper
→ injection gain
→ warm shelf
→ 8 peaking body EQ bands
→ master output

Single-source-of-truth instrument architecture

The bigger architecture behind Instrudio is the part I’m most excited about.

Studio Violin is driven by a single JSON definition file. That one definition can drive:

The web audio synthesis engine
The instrument UI
External MIDI CC routing
Note mapping
Plugin bridge event protocol
Preset management
Live auto-update propagation across connected outlets

The runtime uses a remote-first fetch strategy, so definition changes pushed to GitHub can propagate to connected running instances within the cache TTL window.

The default TTL is currently 5 minutes.

Runtime metrics

Instrudio also includes live evaluation metrics for the single-source-of-truth runtime.

The metrics panel can display:

SSOT fetch latency
Definition apply time
Remote source availability
MIDI pipeline latency

These are captured with high-resolution timing through performance.now().

Metrics are also available programmatically through:

InstrudioSSOTRuntime.getMetrics()
InstrudioMIDI.getLatencyMetrics()

Why this matters

A lot of virtual instruments are either sample libraries, closed plugin binaries, or isolated web toys.

Instrudio is aiming for something different:

web-first instruments
version-controlled definitions
measurable runtime behavior
MIDI-aware performance
bridgeable plugin architecture
open development
fast iteration without redeploying every outlet manually

Studio Violin is the flagship proof-of-concept for that architecture.

Repo

https://github.com/GareBear99/Instrudio

Feedback wanted

I’m looking for feedback from:

audio developers
Web Audio developers
musicians
violinists
producers
plugin developers
MIDI users
people interested in physical modelling

Useful feedback includes:

browser and OS
MIDI device behavior
latency
tone realism
UI feel
control response
broken notes or stuck notes
console errors
ideas for the next instrument model

Studio Violin is the flagship instrument in Instrudio, and I’m building it in public.

FreeEQ8: Looking for Testers for a Free Open-Source JUCE EQ Plugin

Gary Doman/TizWildin — Thu, 14 May 2026 23:59:38 +0000

FreeEQ8: Looking for Testers for a Free Open-Source JUCE EQ Plugin

I’m building FreeEQ8, a free open-source EQ plugin made with JUCE.

The next goal is broad DAW compatibility testing. I’m looking for producers, engineers, and plugin developers who can test the plugin in real sessions and report what works or breaks.

What needs testing

VST3 loading
AU loading on macOS
DAW scanning
UI scaling
Preset and session recall
CPU behavior
Basic EQ workflow
Crashes or freezes

DAWs I’m especially interested in

REAPER
Ableton Live
Logic Pro
FL Studio
Studio One
Cubase
Bitwig

Links

GitHub repo:

https://github.com/GareBear99/FreeEQ8

Latest release:

https://github.com/GareBear99/FreeEQ8/releases

Tester feedback form:

https://github.com/GareBear99/FreeEQ8/issues/new?template=tester-feedback.yml

What helps most

Please include:

Operating system
DAW and version
Plugin format
FreeEQ8 version
What worked
What broke
Steps to reproduce
Screenshot or log if available

Thanks to anyone willing to help test a free open-source audio plugin.