# Product vision

> Tune.Toys lets developers, musicians, curious users and agents create and distribute playable software. It begins with audio instruments and effects and keeps a foundation for logi

Source: https://docs.tune.toys/contributors/vision/

Tune.Toys lets developers, musicians, curious users and agents create and distribute playable software. It begins with audio instruments and effects and keeps a foundation for logic applications, sensing, education, creative tools and connected systems as their runtimes are qualified.

## The creative loop

```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#FAFAF7', 'primaryTextColor': '#1C1C1B', 'primaryBorderColor': '#1C1C1B', 'lineColor': '#64645F', 'fontFamily': 'DM Sans, Inter, system-ui, sans-serif'}}}%%
flowchart LR
  START([Start from a Toy]) --> INSPECT[Inspect or prompt] --> EDIT[Edit graph and Frame] --> PLAY[Play] --> SAVE[Save] --> PUBLISH[Publish] --> SHARE[Share]
  SHARE --> FORK[Fork] -.-> START
  SHARE --> INSTALL[Install in a DAW]

  classDef make fill:#DCEBDD,stroke:#1C1C1B,color:#1C1C1B
  classDef play fill:#F0442E,stroke:#1C1C1B,color:#FAFAF7
  classDef share fill:#DED8F0,stroke:#1C1C1B,color:#1C1C1B
  class START,INSPECT,EDIT make
  class PLAY play
  class SAVE,PUBLISH,SHARE,FORK,INSTALL share
```

A recipient reaches a playable web experience from a link. A musician bookmarks it and finds it in TuneToys Player inside a DAW. A developer ships a separate plugin with its own identity and branding. A plugin company could eventually run its catalog, licensing, updates and distribution on the platform.

## Vocabulary

| Term               | Meaning                                                                            |
| ------------------ | ---------------------------------------------------------------------------------- |
| Toy                | The portable authored creation; can be a component or complete application         |
| Patch              | Familiar editor/community term for a Toy graph, not a separate file model          |
| Definition / group | Reusable implementation with typed ports and public parameters                     |
| Instance           | One use of a definition with independent values, DSP state, and observations       |
| Frame              | Explicit playable UI bound to one definition in an instance context                |
| Project            | Editable Toy source and working assets/history                                     |
| Release            | Immutable resolved content plus evidence and distribution terms                    |
| Catalog entry      | Mutable title/discovery/visibility metadata pointing to releases                   |
| Library            | A user's bookmarks, tags, ratings, acquisitions, and installed/cached releases     |
| Player             | TuneToys plugin/application that loads Toys; not a general third-party plugin host |
| Independent plugin | A compiled Toy exported under its own persistent plugin identity                   |

A Toy inside a Toy uses the same composition system as an ordinary reusable group. Reusing a definition shares immutable code and assets; each instance keeps its own runtime state. Forking creates a new project identity and preserves provenance. Remodeling an interface never silently changes the processing graph. The contracts behind these terms are the [Toy source format](https://docs.tune.toys/contributors/toy-format/) and [releases](https://github.com/joshstovall/TuneToys/blob/main/docs/specs/releases.md).

## Example journeys

A maker builds a stereo effect, asks an agent to expose a useful macro and create a three-knob Frame, auditions the proposal and shares a link. A recipient plays it, bookmarks it and opens the same release in the Player. Reopening the DAW project without internet restores the same sound.

Later, a developer creates a face-controlled synth. Camera inference produces bounded control data outside the audio callback. The web export requests camera access; a native plugin declares whether camera control is available and provides a fallback. A Frame can instead control a separately running host through an authenticated session. Local execution and remote control are explicit modes.

## Durable principles

- One authored model connects behavior, public controls, Frames, assets, presets and provenance.
- Humans and agents use the same authoring API.
- The audio engine runs without an open editor, an active account connection or a live model.
- Published source and remix access follow declared terms; private work stays private across dependencies, previews and builds.

The long-term target set is web hosting and self-hosted static sites, Player, independent VST3/AU plugins, Electron desktop apps, browser extensions, mobile apps and eventually firmware. **Each target earns support through implementation and tests.** Being expressible as JSON does not make a Toy portable to every host.

## Related

- [MVP scope](https://docs.tune.toys/contributors/mvp/) turns this into acceptance criteria; the [roadmap](https://github.com/joshstovall/TuneToys/blob/main/docs/delivery/roadmap.md) orders the gates.
- [System architecture](https://docs.tune.toys/contributors/architecture-overview/) and [decision 0001](https://github.com/joshstovall/TuneToys/blob/main/docs/decisions/0001-portable-model.md) implement the one-model principle.