# Overview Patcher is the digital twin workspace for Eurorack musicians. Use it to browse modules, build a collection, plan racks, capture patches, keep notes close, and share work on your terms. ![Patcher home page showing the module browser, saved racks, and public profile surfaces](/files/vIfzwZoWFUco7SyfyvYy) *The Patcher home page — public browsing on one side, signed-in workspace on the other.* ## Start here Patcher rewards a simple ladder: 1. Browse the public [Modules](/core-workflows/modules) database. 2. Add the modules you own to your [Collection](/core-workflows/collection). 3. Build [Racks](/core-workflows/racks) from that collection. 4. Capture [Patches](/core-workflows/patches) so routing, notes, and recall live together. 5. Share selected work — or keep it private — through [Public Profiles](/core-workflows/public-profiles) and per-item toggles. For a walk-through of a first useful session, see [Quick start](/getting-started/quick-start). ## What Patcher is good at * **Building a module library** that stays useful once planning starts. * **Turning your collection into working racks** before you move hardware around. * **Capturing patches while they are still fresh**, with modules, routing, and notes in one place. * **Keeping public browsing open** so modules, racks, and patches stay easy to explore. * **Letting you share selectively** through public racks, public patches, and public profiles. ## Public Open API Patcher also ships a key-required Public Open API, live at `api.patcher.xyz`, for reading catalogue data — modules, manufacturers, standards, and tags. There is no anonymous access, and it does not yet cover public patches, public racks, panel images, or pricing. See [Public Open API](/reference/public-open-api) for endpoints and examples. ## Guided reading * [What is Patcher?](/getting-started/what-is-this) * [Quick start](/getting-started/quick-start) * [Core Workflows](/core-workflows/learn-patcher.xyz) * [User Area](/core-workflows/user-area) * [Public Profiles](/core-workflows/public-profiles) * [Account and Privacy](/core-workflows/account-and-privacy) * [Modular Glossary](/reference/modular-glossary) ## Project and support * [Project Overview](/project/overview) * [FAQ](/project/the-project) * [Contact / Help / Community](/project/contact-us-help-community) * [Support and Status](/project/support-and-status) ## Useful links * [Open Patcher](https://patcher.xyz/) * [Discord community](https://discord.gg/JNy2HTb5ru) * [GitHub project](https://github.com/Polyterative/Patcher) * [Status page](https://patcher.statuspage.io/) * [Public Open API](/reference/public-open-api) *** *Patcher v6.5.2 — for what is shipping and what is next, see* [*Development status*](/project/development-status)*.* # What is Patcher Patcher is a digital twin workspace for Eurorack musicians. The public side is a browseable catalogue of modules with the racks and patches other people have built around them. The signed-in side is your own workspace — the modules you actually own, the racks you are planning, the patches you are capturing, and the manuals gathered around them. You can move between the two freely: browse publicly, sign in when you want to save your own work, and share back only what you choose to make public. ## First steps If you came here from the app and want the fastest onboarding path: * [Quick start](/getting-started/quick-start) — a step-by-step walk-through of a first useful session. ## The broader tour * [Docs home](/) — the top-level ladder from browsing to sharing. * [Core Workflows](/core-workflows/learn-patcher.xyz) — the workflow pages you will use regularly. * [Modules](/core-workflows/modules) * [Collection](/core-workflows/collection) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [User Area](/core-workflows/user-area) * [Public Profiles](/core-workflows/public-profiles) * [Account and Privacy](/core-workflows/account-and-privacy) ## Project background * [Project Overview](/project/overview) * [FAQ](/project/the-project) * [Modular Glossary](/reference/modular-glossary) # Quick start This is the fastest way to get practical value out of Patcher. For the shortest overview of the whole ladder — browse, collect, plan, capture, share — see the [Docs home](/). ## First useful session ### 1. Browse the module database Go to **Modules** and search for the hardware you already own, want to buy, or want to compare. Open module detail pages to check: * size and format * power information * panel images and panel variants * related public racks and public patches * manual links when they are available Read more: [Modules](/core-workflows/modules) ### 2. Create an account You can explore public data without an account, but you need one to build your own workspace. See [Account and Privacy](/core-workflows/account-and-privacy) for sign-in options. After signing up, your workspace becomes available through **User Area**. ### 3. Add your real modules to your collection Your collection is the source list for the rest of the app. Once modules are in your collection, they become available for: * planning racks * building patches * gathering manuals in one place under [User Area](/core-workflows/user-area) Read more: [Collection](/core-workflows/collection) ### 4. Build your first rack Create a rack when you want to test fit, compare layouts, or document an existing case. You can: * add modules from your collection * move modules visually * duplicate modules * replace modules with blank panels for spacing * undo an edit that did not land well * run rack analysis — power, function, layout, and signal — before committing to a layout Read more: [Racks](/core-workflows/racks) ### 5. Capture your first patch Create a patch when you want a reusable memory of a session, not just a temporary note. Use patches to save: * the modules involved * cable routing * names and descriptions * notes worth revisiting later Repeated copies of the same module stay distinct as numbered instances, which matters when a patch uses more than one copy of the same hardware. Patches also expose a graph view, a fullscreen mode, and a PNG export when you want to share the layout as an image. Read more: [Patches](/core-workflows/patches) ### 6. Review sharing before you share links Patcher supports both private workspace use and public sharing. New racks and patches start Public. You can switch them to **Private** before creation or at any time later. See [Racks](/core-workflows/racks) and [Patches](/core-workflows/patches) for the Private toggle in detail, and [Account and Privacy](/core-workflows/account-and-privacy) for the full model. For public discovery, both the item and the profile need to be public. See [Public Profiles](/core-workflows/public-profiles). ## Where to go next * [User Area](/core-workflows/user-area) * [Manuals](/core-workflows/manuals) * [Contributing module data](/core-workflows/contributing-module-data) * [FAQ](/project/the-project) * [Contact / Community](/project/contact-us-help-community) # Overview This section covers the parts of Patcher you will actually use regularly. If the docs homepage explains what Patcher is, these pages show how it works in practice. ## The shortest version Patcher works best when you move through it in this order: 1. browse modules 2. build your collection 3. plan racks 4. capture patches 5. share selected work when it is ready That is the simplest way to build a workspace worth returning to. ## The main pages * [Modules](/core-workflows/modules) * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) * [Search and Discovery](/core-workflows/search-and-discovery) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [Manuals](/core-workflows/manuals) * [Public Profiles](/core-workflows/public-profiles) * [Account and Privacy](/core-workflows/account-and-privacy) * [Contributing module data](/core-workflows/contributing-module-data) ## Where to start * If you are new, begin with [Quick start](/getting-started/quick-start). * If you already know the product, jump straight to [User Area](/core-workflows/user-area) or [Modules](/core-workflows/modules). ## Reference If you hit a term you do not recognize, the [Modular Glossary](/reference/modular-glossary) explains the words used across these pages — collection, module, panel variant, patch, public profile, rack, recall, and user area — in one page. # Modules The module browser is where most people start. It is both the public catalogue and the front door to your own workspace. Browsing is public. Adding modules to your collection or using collection-driven actions requires a signed-in account. ![Public module browser showing tag filters, manufacturer filters, and module tiles](/files/0Bm6ZsMhftcQEQ0HVWo0) *The Modules page — public, searchable, and the entry point into every module detail page.* ## Browse and filter The module list combines free-text search with structured filters: * **Tag filters** are grouped and support **Any / All** semantics. **Any** returns modules that match at least one selected tag; **All** returns only modules that match every selected tag. * **Manufacturer filters** narrow the list to a specific maker or a set of makers. * Free-text search matches module name, manufacturer, description, and tags at once. * Results grow with **load-more** as you keep scrolling — there is no infinite scroll. Filters compose, so combining tags, a manufacturer, and a search term gives you a shortlist rather than a full catalogue dump. ## What module detail pages include Detail pages are organized into a few consistent sections. Coverage varies by module, so a page only shows what has real data behind it. ### Discovery The **discovery** area lists public racks and public patches that use the module. Use it to see how other people are actually deploying the module before you commit to it. ### Analysis The **analysis** area surfaces module-level analytical fields — size, format, power information, category or function tags, I/O counts, and similar structured metadata. This is the "what does this module actually offer" answer. ### Panel The **panel** area shows the module's panel images. When a module has more than one panel image or variant, you can switch between them so the visual matches the hardware in front of you. ### Community stats The **community stats** area shows module-level numbers coming from public usage — how many public racks include the module, how many public patches include it, and similar aggregate signals. ### Submit-similar The **submit-similar** action lives on the detail page itself. Use it when a nearly identical module — usually a revision or a panel variant — is not yet in the catalogue and you want to add it while keeping the existing module as context. See [Contributing module data](/core-workflows/contributing-module-data). Manual links appear when a module has enough data and a manual URL has actually been added. ## Add a module to your collection 1. Create an account or log in. 2. Open **Modules**. 3. Find a module you own. 4. Open the detail page. 5. Use the add action to save it to your [Collection](/core-workflows/collection). Once a module is in your collection, it becomes available across the rest of the app. ## Why the collection matters Your collection is not a wishlist. It powers: * rack planning — see [Racks](/core-workflows/racks) * patch capture — see [Patches](/core-workflows/patches) * manual shortcuts inside your [User Area](/core-workflows/user-area) — see [Manuals](/core-workflows/manuals) * a more realistic picture of your real system If you skip this step, your racks and patches will feel more like disconnected drafts than reflections of your real setup. ## Missing module or missing data? If a module is not in the catalogue at all, use **Submit New Module**. If a module is in the catalogue but panels, manuals, or metadata are incomplete, improving the record is often the more useful contribution. Module data coverage is still improving; treat missing data as a reason to help, not as proof the feature is unavailable. See [Contributing module data](/core-workflows/contributing-module-data) for the full submit and improve flows. ## Panel images and manuals Some modules include multiple panel images or variants. That matters when the physical look of the module affects your planning or rack screenshots. Manual links become more useful as your collection grows, because Patcher also surfaces those manuals in [User Area](/core-workflows/user-area) under **Manuals**. ## Best way to use Modules 1. Search for hardware you already own. 2. Add that hardware to your collection. 3. Check panels, manuals, and metadata while you are there. 4. Use the collection as the source for racks and patches. ## Related pages * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [Manuals](/core-workflows/manuals) * [Contributing module data](/core-workflows/contributing-module-data) * [Modular glossary](/reference/modular-glossary) * [Public Open API](/reference/public-open-api) # Collection Your collection is the foundation of the whole workspace. If Modules is the catalogue, Collection is the working inventory behind everything else. Collection management requires a signed-in account. Public visitors can browse modules without logging in, but they cannot save modules into a personal collection. ## What the collection does The collection tracks the modules you want available in your workspace. That matters because Patcher uses the collection as the source for: * rack planning * patch creation * manual shortcuts in your user area * a more accurate picture of your real system ## Build your collection 1. Sign in. 2. Open **Modules**. 3. Find a module you own. 4. Add it to your collection. 5. Repeat until your core system is represented. You do not need to add everything in one sitting. Start with the hardware you reach for most often. ## Why this step is worth doing well A strong collection makes everything downstream faster and more believable: * racks become realistic * patches are easier to assemble * public sharing reflects your actual setup * manuals gather in one place as your library grows If your collection is incomplete, the rest of the workspace becomes harder to trust. ## Collection is not just storage Think of it as working data, not passive storage. A good collection helps you answer questions like: * what do I actually own? * what rack variants can I build from it? * what modules keep appearing in my patches? * what manuals do I need access to regularly? ## Good habits * add modules as they arrive * remove or adjust entries when your system changes * use the collection before making a new rack or patch * submit missing modules instead of working around gaps forever If you see disabled collection actions while browsing publicly, that is expected. Those actions become available after you sign in. ## Where it leads next Once the collection feels accurate, move on to: * [User Area](/core-workflows/user-area) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [Manuals](/core-workflows/manuals) * [Public Profiles](/core-workflows/public-profiles) If a module you own is not yet in the catalogue, or its record is thin, see [Contributing module data](/core-workflows/contributing-module-data). For terms used on this page, see the [Modular Glossary](/reference/modular-glossary). # User Area User Area is your personal workspace inside Patcher. It brings your saved modules, racks, patches, manuals, comments, stats, and profile controls together on one signed-in surface. User Area is only available to signed-in users. ![User Area dashboard showing modules, racks, patches, manuals, stats, and workspace search](/files/wwsfuHGVJzewGl8tdU9d) *User Area — your signed-in workspace, with search that spans every section at once.* ## What is in User Area The layout is built around a few practical sections: * **Modules** you have added to your collection * **Racks** you are planning or maintaining * **Patches** you are documenting * **Manuals** gathered from your saved modules * **Comments** you have left around the platform * **Stats** — profile stats and contributor stats side by side * **Profile visibility** controls * a floating **global search** field for workspace-wide filtering The sections are paginated when they grow large, so you can move through bigger workspaces without one long scroll. ## Why it matters This is where Patcher shifts from public catalogue to working tool. As your workspace grows, User Area becomes the fastest way to: * find your own data again * see what is missing * jump back into an unfinished idea * open manuals without leaving the app ## Global search The search field is not tied to a single section, but it is not one combined result list either. Instead, the same query is applied across the main sections at the same time: * **Modules** search name, manufacturer, description, and tags * **Racks** search name and description * **Patches** search name, description, and tags * **Manuals** search module name, manufacturer, and description * **Comments** search comment text and author usernames The **Patches** section also has its own tag filter, which works alongside the main search field. ## Stats The **Stats** section surfaces two views side by side: * **Profile stats** — public-facing counts about your workspace (racks, patches, and other publishable material). * **Contributor stats** — signals about the contributions you have made back to the shared catalogue. Stats update as you save and share more work. ## Manuals Every manual attached to a module in your [Collection](/core-workflows/collection) surfaces automatically in the **Manuals** section, so a growing library gathers into one searchable list instead of scattered PDF links. See [Manuals](/core-workflows/manuals) for how manuals appear on module detail pages and here in your workspace. ## Comments Any comment you have left around Patcher lives in the **Comments** section of your User Area. It is your history of participation — useful when you want to reread a conversation, follow up on a thread, or find where you have already answered a question. Comment visibility follows the surface where each comment was left; nothing here is more or less public than it was on the page it lives on. ## Profile visibility User Area is where you control whether your public profile is visible. From here you can: * make your profile public or private * open your public profile * copy your public profile link * update your display name For public discovery, both the profile and the individual rack or patch need to be public. See [Public Profiles](/core-workflows/public-profiles) and [Account and Privacy](/core-workflows/account-and-privacy). ## A good first setup 1. Add the modules you own. 2. Create one rack. 3. Create one patch. 4. Check that your profile settings match what you actually want public. That is usually enough to make the workspace start paying off. ## Related pages * [Collection](/core-workflows/collection) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [Manuals](/core-workflows/manuals) * [Public Profiles](/core-workflows/public-profiles) * [Account and Privacy](/core-workflows/account-and-privacy) # Search and Discovery Patcher is built to help you find things quickly across both the public library and your own workspace. ## Public discovery Discovery usually starts with **Modules**, then expands into related public racks and patches. This is useful when you want to: * compare modules before buying * see how other people are using a module * move from a single piece of gear into usable context ## Workspace search Inside **User Area**, one search query filters your modules, racks, patches, manuals, and comments at the same time. That matters once your workspace holds enough material that scrolling stops being efficient. This is not a single combined cross-entity search result page. Each section keeps its own results while reusing the same query. User Area itself requires a signed-in account. ## Discovery surfaces that matter Patcher currently supports discovery through: * module search and browsing, with grouped Any / All tag filters and manufacturer filters * related public racks and patches surfaced from module detail pages * public rack browsing * public patch browsing * public profiles * global search inside your [User Area](/core-workflows/user-area) ## Community trends **Community trends** is the public read-out of what is currently drawing attention across Patcher — which modules are being added, which racks are being viewed, which patches are being opened. Use it when you want a discovery entry point that is not driven by a specific search or a module you already know about. Community trends is a public surface, so it works whether you are signed in or not. Treat it as a starting point for exploration rather than a ranking of quality. ## Best way to use it 1. Start broad in the public catalogue or in community trends. 2. Save the modules that matter to your collection. 3. Use User Area search once your own workspace grows. 4. Follow related public examples when you need context, ideas, or comparisons. ## Related pages * [Modules](/core-workflows/modules) * [User Area](/core-workflows/user-area) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [Public Profiles](/core-workflows/public-profiles) * [Modular Glossary](/reference/modular-glossary) # Racks Racks are where planning becomes physical. Use them to model a real case, test an idea before rearranging hardware, or compare multiple layouts without losing the earlier version. ![Rack editor showing a Eurorack case layout with module placement and analysis controls](/files/aHiLqNS08RBMMNoslvjw) *The rack editor — build, rearrange, and analyze cases against your own collection.* ## What racks are for * planning a future case * documenting a current case * testing fit before buying * comparing alternate layouts * sharing a clean public version of your setup ## Create a rack 1. Go to **User Area**. 2. Open the **Racks** section. 3. Click **Create rack**. 4. Open the new rack and start building. ## Add modules to a rack The usual flow is: 1. Add your real modules to your [Collection](/core-workflows/collection) first. 2. Open a rack. 3. Add modules from the collection-driven workflow. 4. Arrange them until the layout feels right. This keeps the rack tied to the hardware you actually own instead of drifting into a disconnected mockup. ## Edit and reorganize Racks are meant to be adjusted repeatedly. Common actions: * move modules visually * duplicate a module * delete a module * replace a module with a blank panel * clear part of a row when you want to rethink a section * use **undo** to step back from an edit that did not land well The editor shows a **stale preview** indicator when the rack preview is behind your most recent edits, so you always know whether what you are looking at reflects the current state. ## Blank panels and spacing If you need a gap, use a blank panel instead of forcing the layout to stay fully packed. That is useful for: * ergonomic spacing * cable clearance * representing intentional empty HP * planning future additions ## Analysis modes Power, function, layout, and signal analysis modes; layout mode adds Same HP/Combos suggestions plus Remix and Shuffle, subject to valid row formats and available module metadata. Each mode reads the rack from a different angle: * **Power** — draw across the main rails, so you can spot overloads before wiring anything. * **Function** — modules grouped by role instead of only by placement, giving you a per-category readout of what the rack can do. * **Layout** — arrangement help. **Same HP** suggests modules that fit the same slot; **Combos** proposes complementary neighbors; **Remix** rearranges the rack while keeping the same modules; **Shuffle** produces a fresh randomized layout. Layout suggestions need valid row formats and enough module metadata to be meaningful. * **Signal** — signal-path context for the rack as a whole. The rack also surfaces a **weakest-axis** hint that names which analytical axis (power, function coverage, category balance, and similar) is the weakest for the current layout — useful when you want a single line of feedback instead of a full sweep. **Balance** context depends on module data coverage: it is most useful when the modules in the rack have enough category and function metadata to support meaningful comparison. Treat sparse output as a data-coverage issue, not a limitation of the analysis. See [Contributing module data](/core-workflows/contributing-module-data) if you want to help close a gap. ## Panel variants Some modules support more than one panel image or style. When available, you can switch variants inside a rack so the layout better matches the real hardware in front of you. This is especially useful when the same module exists in different finishes or panel revisions. ## Saving and sharing Racks are built for iteration. Open them, edit them, and keep refining. Patcher saves your work as you go. New racks and patches start Public. You can switch them to **Private** before creation or at any time later. For public discovery, both the rack itself and your profile need to be public. See [Public Profiles](/core-workflows/public-profiles) for how profile and item visibility interact, and [Account and Privacy](/core-workflows/account-and-privacy) for the full sharing model. ## Best practices * start with the modules you own * leave some room when that helps usability * run each analysis mode before calling a layout finished * keep separate racks for alternate versions instead of overwriting one plan ## Related pages * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) * [Patches](/core-workflows/patches) * [Public Profiles](/core-workflows/public-profiles) * [Modular glossary](/reference/modular-glossary) # Patches Patches are the memory layer of Patcher. Use them when you need more than a loose note or a photo on your phone. A good patch entry lets you reopen a session later and still understand what mattered. ![Patch editor showing modules, cable routing, and numbered instances](/files/5JYY3HqYfGBQEru4kI0a) *The patch editor — capture modules, routing, and notes for reliable recall later.* ## What a patch can hold A patch can bring together: * the modules involved * cable routing between those modules * notes and descriptive text * names that make recall easier later * sharing choices for public visibility ## Create a patch 1. Go to **User Area**. 2. Open the **Patches** section. 3. Click **Create patch**. 4. Name it clearly. 5. Add the modules you need. 6. Start documenting routing and notes. ## Why collection-first matters here Patches work best when your [Collection](/core-workflows/collection) is already accurate. An accurate collection gives you a reliable source list for module assignment and keeps your patch notes grounded in the hardware you actually use. ## Add modules and connections Once the patch contains the right modules, add the routing step by step. Patches distinguish repeated copies of a module as numbered instances, so each connection targets the intended copy. Use that deliberately. When a patch includes two or three copies of the same module doing different jobs, the numbered instances stay disambiguated across every connection you draw. If a module is missing useful I/O data, improving the module record first pays off across every future patch — see [Contributing module data](/core-workflows/contributing-module-data). ## Views for reading the patch Beyond the default editor, patches expose two review-oriented views: * **Patch graph** — a graph-style view of the patch that reads modules and connections as nodes and edges. Useful for spotting routing loops, missing terminations, or unbalanced sections. * **Fullscreen** mode — maximizes the current view for close reading during a session. You can also produce a **PNG export** of the patch when you need a static image for notes, a message thread, or a printout. ## Share URLs Public patches are addressable through **opaque `public_id`** URLs. These are the current canonical share links — a `public_id` URL is safe to paste anywhere without leaking anything about the patch's numeric internals. The older numeric link scheme for patches is retired. If someone hands you a legacy numeric URL, see [FAQ](/project/the-project) for what happens when you open it. ## Edit while you work Patches are built for fast iteration during an active session, not only after it ends. Edits persist as you make them, so you can adjust routing and notes without babysitting a save action. ## Naming and notes The more patches you save, the more naming matters. Good patch names and notes should answer: * what the patch does * what makes it different * what you would need to remember under pressure ## Public and private use Not every patch needs to be shared. New racks and patches start Public. You can switch them to **Private** before creation or at any time later. Private racks and patches are **unlisted**: they are hidden from public browse and public-profile listings, but anyone with the token URL can still open them anonymously. Private is **not a security boundary** — use it to declutter listings, not to protect sensitive material. For public discovery, both the patch itself and your profile need to be public. See [Public Profiles](/core-workflows/public-profiles) and [Account and Privacy](/core-workflows/account-and-privacy). ## Best practices * save patches while the session is still fresh * keep names specific * note unusual routing or settings * treat repeated instances as distinct voices, not interchangeable placeholders * share only the patches you actually want attached to your public profile ## Related pages * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) * [Racks](/core-workflows/racks) * [Public Profiles](/core-workflows/public-profiles) * [Modular glossary](/reference/modular-glossary) # Manuals Every module can carry a manual link. Once your workspace grows, Patcher gathers those links into a single view so you do not have to hunt for a PDF the next time you need one. ## Where manuals appear Manuals surface in two places: * On a **module detail page**, under the module's own manual link when one has been added. * In your [User Area](/core-workflows/user-area), inside the **Manuals** section, which aggregates every manual across the modules you have saved into your [Collection](/core-workflows/collection). The User Area aggregation is what pays off over time. A collection of forty modules can carry twenty or more distinct manuals; having them in one searchable list is the difference between reading and hunting. ## Opening a manual From either surface, opening a manual jumps to the external URL that has been attached to the module. Patcher holds the link and the metadata around it, not the manual itself. ## Why manuals aggregate as your collection grows The Manuals section in User Area does not track manuals separately from modules. It reads through the modules you have saved and lists everything that has a manual attached. Add a new module to your collection, and its manual (when one is attached) shows up here automatically. Remove the module from your collection, and the manual entry disappears with it. This keeps the list honest: it always reflects your current collection. Manuals are also searchable from the User Area global search. A query hits manual entries alongside modules, racks, patches, and comments — so a single search can uncover the manual you were looking for even when you were not sure which module carried it. ## When a manual is missing A missing manual is usually a data-coverage issue, not a product limitation. If a module has no manual link: * Check whether one has been attached recently by other users. * Consider adding one yourself through the module's improvement flow. * See [Contributing module data](/core-workflows/contributing-module-data) for how to help. ## Related pages * [Modules](/core-workflows/modules) * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) * [Contributing module data](/core-workflows/contributing-module-data) # Public Profiles Public profiles are the shareable face of your workspace. They give you a clean page tied to your username without making everything you do in Patcher public. ![Public profile page showing username, display name, public racks, and public patches](/files/T83GCkpUfP5tZoDFHC0t) *A public profile — a curated surface showing the racks and patches you have chosen to publish.* ## Where a profile lives Every user has a profile route at `/u/:username`, so `patcher.xyz/u/your-username` resolves to that profile — when the profile is public. ## Username and display name Two things matter, and they are not the same: * The **username** is the stable identifier baked into your profile route (`/u/:username`). It is what makes the profile addressable. * The **display name** is the visible name Patcher shows on the profile page and around the app. You can update the display name from your account controls without breaking any public link that already points at your username. Change the display name freely for how you want to be shown; keep the username stable for what you want to be linked to. ## What a public profile can show When enabled, a profile can show: * your username and display name * your website link, if one is present on the profile * public racks * public patches * profile stats * contributor stats ## Share URLs for racks and patches Public racks and patches are addressable through **opaque `public_id`** URLs — the current canonical share links, independent of the profile route. Sharing a `public_id` URL for a rack or patch works even when you are not sharing your full profile. ## Private items and the token URL Profile visibility does not change an item's own visibility. Making a profile Private does not make its existing Public racks or patches Private — item visibility stays where you set it on each item. Private racks and patches are unlisted: they do not show up in browse or on public-profile listings. Anyone with the token URL can still open them anonymously, though. Private is not a security boundary; use it to declutter listings, not to protect sensitive material. See [Account and Privacy](/core-workflows/account-and-privacy) for the full visibility model. ## What stays under your control Public visibility is a choice, not a requirement. You can keep your profile private and still use the rest of Patcher normally. Public browsing only shows racks and patches when both the item itself and the profile are public. ## Typical uses * sharing a curated set of racks * linking people to selected patches * giving collaborators or followers one stable page * building a public presence without exposing your whole workspace ## Useful actions From your own profile flow, you can usually: * view your public profile * copy the public link * switch the profile between public and private * update the display name ## Best practices * make the profile public only when the visible content is intentional * keep names, descriptions, and links clean before sharing * treat the profile as a curated public surface, not a dump of everything * keep your username stable; adjust the display name when you want a visual change ## Related pages * [User Area](/core-workflows/user-area) * [Account and Privacy](/core-workflows/account-and-privacy) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) * [FAQ](/project/the-project) # Account and Privacy This page covers the account choices that shape how public or private your Patcher workspace feels. ![Patcher account settings page showing sign-in, display name, and data-deletion controls](/files/P57S5T50phjQTYtNxRmz) *Account settings — sign-in method, display name, sharing defaults, and data-deletion controls.* ## Browsing without signing in You can explore the public side of Patcher without an account, including modules, public racks, public patches, and public profiles. ## What signing in unlocks Once you have an account, you can: * save modules to your collection * build racks * create patches * use the full user area * manage your public profile settings ## Sign-in Patcher supports Google sign-in alongside email-and-password accounts. Sign-in is linked: signing in again with the same Google identity resolves to the same account, so you do not end up with a second parallel account just because you used a different sign-in entry point next time. A direct password-change control appears only when your account uses email sign-in exclusively. When Google sign-in is linked — either on its own or alongside email — password changes go through the change-account-type flow instead. ## Public vs private items Profile visibility and item visibility are separate choices. New racks and patches start Public. You can switch them to **Private** before creation or at any time later. Private racks and patches are **unlisted**: they are hidden from public browse and public-profile listings, but anyone with the token URL can still open them anonymously. Private is **not a security boundary** — use it to declutter listings, not to protect sensitive material. For public discovery, both the item and the profile need to be public. ## Profile visibility Your public profile can be switched on or off from your signed-in workspace. When the profile is private, the public profile page at `/u/:username` is not available to other people. Profile visibility does not change an item's own visibility. Making a profile Private does not make its existing Public racks or patches Private — that is a separate toggle on each item. ## Display name Your visible display name can be changed at any time from account controls. The underlying username is what makes your profile addressable at `/u/:username`; the display name is the label people see on the page. See [Public Profiles](/core-workflows/public-profiles) for how the two interact. ## Delete data vs delete account Patcher offers two distinct removal flows so you can walk away from your data without losing the account, or leave entirely. * **Delete data** clears your workspace — modules, racks, patches, notes — while keeping the account itself. Useful when you want a clean slate but plan to sign back in. * **Delete account** removes the account and its data. Both flows are intentional and destructive. Read the confirmation prompt carefully before continuing. ## Telemetry For details on how Patcher handles error monitoring and product analytics, see [Telemetry and privacy](/project/telemetry-and-privacy). ## Sharing carefully Before making your profile public, review: * which racks should be public * which patches should be public * whether your profile link is ready to share ## Support If you need help with account-related issues, start here: * [Contact us / Help / Community](/project/contact-us-help-community) * [Support and status](/project/support-and-status) * [FAQ](/project/the-project) # Contributing module data Patcher's public module database is only as good as the data behind it. This page covers the in-product flows for adding new modules, adding variants of existing modules, and improving records that are already there. This is the user-facing contribution surface. For code, docs, or repository-level contribution, see [Contributing](/project/contributing) under Project. ## Submit New Module When a module does not exist in the catalogue yet, use the **Submit New Module** flow. 1. Open **Modules**. 2. Use the submit action from the modules browser. 3. Fill in the fields the form asks for — at minimum name, manufacturer, size, format, and description; add power and I/O information when you have it. 4. Attach panel images and a manual link if you can. 5. Submit. Submitting a new module helps both the public catalogue and your own workflow, because once the module exists you can add it to your collection and use it in racks and patches. ## Submit-Similar **Submit-Similar** is the flow for adding a module that is almost the same as one already in the catalogue — a revision, an alternate panel, or a close variant. The **Submit-Similar** action lives on a module's detail page. 1. Open the detail page of the module that is closest to the one you want to add. 2. Trigger **Submit-Similar**. 3. The form arrives prefilled with the existing module's data. 4. Edit the fields that differ — usually the name suffix, panel image, and any changed spec. 5. Submit. Submit-Similar is the right choice when the new entry is genuinely close but not identical. It saves typing and keeps related modules consistent with each other. ## Improving existing module data If a module exists but its record is thin, improving that record is often the more useful contribution than submitting a new one. Common areas to improve: * **Panels** — add a missing panel image or an additional variant. * **Manuals** — attach a manual URL that has not been added yet. See [Manuals](/core-workflows/manuals). * **Metadata** — power, size, format, category or function tags, I/O counts. * **Description** — a clearer one-paragraph description tends to make the whole record more useful. Improved data flows out to every user who has the module in their collection: their [Racks](/core-workflows/racks), [Patches](/core-workflows/patches), and [Manuals](/core-workflows/manuals) all get better without them having to do anything. ## What not to submit * Modules that already exist under a different name. Search first, then decide between improving the existing record or using Submit-Similar for a real variant. * Private customizations or one-off builds that are not sold as products. The catalogue is for released modules. * Speculative or unreleased modules. ## Boundary with repo-level contribution This page covers the in-product data contribution flows. Contributions to the Patcher codebase or these docs live in a separate page: * [Contributing](/project/contributing) — repo-level code and docs contribution. ## Related pages * [Modules](/core-workflows/modules) * [Manuals](/core-workflows/manuals) * [Collection](/core-workflows/collection) * [User Area](/core-workflows/user-area) # Overview This section holds everything that is *about* Patcher rather than *how to use it*. Use it when you need context, help, contribution guidance, or media assets. ## What lives here ### Project * [FAQ](/project/the-project) — quick answers to common questions. * [About](/project/about) — what Patcher is and what it deliberately is not. * [Development status](/project/development-status) — what is shipping today, current release stamp. * [Changelog](/project/changelog) — pointer to the GitHub `CHANGELOG.md` and the in-product `/info/changelog` route. ### Support * [Contact us / Help / Community](/project/contact-us-help-community) — channel directory (Discord, GitHub issues, email). * [Support and status](/project/support-and-status) — service status page, share-link behavior, bug reporting. * [Supported platforms](/project/supported-platforms) — browsers, mobile, keyboard, skip link. * [Telemetry and privacy](/project/telemetry-and-privacy) — what runs in production and why. ### Contribution and openness * [Contributing](/project/contributing) — repo-level code and docs contribution. * [AI and open data](/project/ai-and-open-data) — public policy for AI crawlers, links to the canonical `patcher.xyz/llms.txt`. ### Media * [Press / media boilerplate](/project/press-release) — short description and boilerplate. * [Official images](/project/high-res-official-images) — promo images and current product screenshots. ## If you were looking for product guidance Go back to the product side of the docs: * [Quick start](/getting-started/quick-start) * [Core Workflows](/core-workflows/learn-patcher.xyz) # FAQ ## What is Patcher? Patcher is a digital twin workspace for Eurorack musicians. It combines a public module database with workspace tools for collection tracking, rack planning, patch capture, manual access, and selective public sharing. ## Do I need an account to use it? No. You can browse public modules, racks, patches, and documentation without signing in. You only need an account when you want to save your own collection, racks, patches, or public profile. ## Is Patcher only for patches? No. Patcher is useful across the whole modular workflow: * discovering modules * tracking what you own * planning rack layouts * documenting patches * sharing selected work publicly ## Why should I add modules to my collection first? Because the collection powers the rest of the workspace. Once your modules are saved there, they become the source for rack planning, patch capture, and manual shortcuts. ## Can I use it privately? Yes. New racks and patches start Public. You can switch them to **Private** before creation or at any time later. Private racks and patches are unlisted: they are removed from browse and public-profile listings, but anyone with the opaque share link can still open them. Profile visibility does not change an item's own visibility — making a profile private does not retract Public racks or patches attached to it. For the full visibility model, including delete-data and delete-account flows, see [Account and privacy](/core-workflows/account-and-privacy). For the per-item Private toggle, see [Racks](/core-workflows/racks) and [Patches](/core-workflows/patches). ## What happened to my old share links? Patcher moved to opaque `public_id` share URLs. That changed how legacy numeric links resolve: Legacy numeric links for private items are retired; legacy numeric links for public items redirect to the current token URL. If a numeric link now lands on `/links/retired`, the item it pointed at is Private. The item may still exist under its current opaque share URL — ask the owner for the new link. See [Support and status](/project/support-and-status) for what to do next. ## What is a public profile? A public profile is the shareable page tied to your username, addressable at `/u/:username`. It can show your public racks, public patches, profile stats, and contributor stats. See [Public profiles](/core-workflows/public-profiles) for the full description and [Account and privacy](/core-workflows/account-and-privacy) for how profile visibility interacts with item visibility. ## Does Patcher support repeated modules in patches? Yes. Patches distinguish repeated copies of a module as numbered instances, so each connection targets the intended copy. That matters when the same hardware appears more than once in a patch — the routing stays disambiguated. See [Patches](/core-workflows/patches) for the editor detail. ## Can I add missing modules? Yes. If something is missing from the catalogue, use **Submit New Module**. If a module is close to an existing one, use **Submit-Similar** from the existing module's detail page. For the full contribution flow — including improving existing module data — see [Contributing module data](/core-workflows/contributing-module-data). ## Can I upload or improve panel images? Yes, where the relevant contribution surface is available for the module. Improving panel coverage makes rack planning better for everyone. ## Can I import data from ModularGrid? Not directly. If you need something that is missing, the practical path today is to add or improve the relevant data in Patcher. ## Where should I ask for help? Start here: * [Support and status](/project/support-and-status) — status page and support entry point. * [Contact us / Help / Community](/project/contact-us-help-community) — channel directory. * [Discord](https://discord.gg/JNy2HTb5ru) * [GitHub issues](https://github.com/Polyterative/Patcher/issues) ## Where should I suggest features? Discord is usually the fastest place for product discussion. GitHub issues are also useful for concrete, trackable technical proposals. # About Patcher exists to make modular gear easier to manage in real life, not just easier to admire online. ## The idea Most modular workflows break apart too quickly. One tool helps you browse modules. Another helps you mock up racks. Patch notes live in photos, notebooks, or scattered documents. Manuals disappear into browser history. The context rarely stays connected. Patcher is built to pull those pieces back together — discovery, ownership, planning, documentation, and sharing in one place instead of five. ## What makes it different The goal is not just storage. It is recall and continuity. Patcher should help you move between discovery, ownership, planning, documentation, and sharing without rebuilding the same context from scratch every time. For the shipping surface behind that intent, see [Press / media boilerplate](/project/press-release) and [Development status](/project/development-status). ## Open by default on the public side The public module database is meant to stay accessible. Browsing public information should not require an account, and the project remains open-source. That public surface is a big part of the value: people can research, compare, and learn before they decide to build their own workspace. The public policy for AI crawlers and downstream tooling lives on [AI and open data](/project/ai-and-open-data). ## How it is built Patcher is an open-source web app built on Angular and TypeScript, with a Supabase backend and served through Vercel. ## Who it is for Patcher is for modular users who want a cleaner system around their instrument: * people planning a first case * people documenting an established rig * people maintaining several rack variants * people who want more reliable patch recall * people who like sharing selected work without turning everything public ## What Patcher is not trying to be Patcher is not trying to replace the instrument itself, replace manuals, or flatten modular practice into a rigid format. It is meant to reduce friction around the parts that are easiest to lose: hardware context, patch memory, and organization. ## Where to go next * [Quick start](/getting-started/quick-start) * [Modules](/core-workflows/modules) * [User Area](/core-workflows/user-area) * [FAQ](/project/the-project) * [Development status](/project/development-status) # Development status This page is a snapshot of what Patcher already does. It describes shipping product, not unreleased work. Current release: **Patcher v6.5.2**. For a live release history, use the in-product `/info/changelog` route or the [Changelog](/project/changelog) page. ## Shipping today ### Public browsing * public module browsing with grouped Any / All tag filters and manufacturer filters * public rack browsing * public patch browsing * public profile pages at `/u/:username` * community trends as a public discovery surface ### Personal workspace * module collection tracking * rack creation and editing * patch creation and editing * global search across the user area * manuals gathered from your saved modules * contributor stats and workspace stats ### Rack workflow * visual layout planning with undo, stale-preview indicator, and a weakest-axis hint * duplicate / delete / blank-panel actions * multi-panel support where available * Power, function, layout, and signal analysis modes; layout mode adds Same HP/Combos suggestions plus Remix and Shuffle, subject to valid row formats and available module metadata. Analysis output quality depends on module data coverage — see [Racks](/core-workflows/racks) for the full description. ### Patch workflow * module-based patch capture * connection documentation * notes and naming for recall * Patches distinguish repeated copies of a module as numbered instances, so each connection targets the intended copy. * patch graph view, fullscreen mode, and PNG export * opaque `public_id` share URLs (legacy numeric links for public patches redirect; legacy numeric links for private patches are retired) * auto-save for patch state and edits ### Module workflow * module detail with discovery, analysis, panel variants, and community stats — see [Modules](/core-workflows/modules#analysis) * Submit New Module and Submit-Similar contribution flows ### Project shape * open-source codebase (Angular, TypeScript, Supabase; served through Vercel) * public data browsing without an account * linked sign-in with multiple providers — see [Account and privacy](/core-workflows/account-and-privacy) * mobile-friendly product direction ## Still actively improving Patcher is still evolving. Areas that continue to move include: * module data coverage and detail quality * docs and onboarding * discovery and browsing surfaces * contributor tooling * overall polish across core workflows ## Best way to track changes For detailed release history, use: * [Changelog](/project/changelog) — durable pointer to the GitHub `CHANGELOG.md` and the in-product `/info/changelog` route. * [Main GitHub repository](https://github.com/Polyterative/Patcher) * [Discord community](https://discord.gg/JNy2HTb5ru) # Changelog For the authoritative history of app releases and code changes, use these sources: * **In-product** — the `/info/changelog` route inside Patcher shows the release history the way it appears to signed-in users. * **GitHub** — [Patcher `CHANGELOG.md`](https://github.com/Polyterative/Patcher/blob/develop/CHANGELOG.md) tracks commit-by-commit release notes. * **Repository** — [Patcher on GitHub](https://github.com/Polyterative/Patcher) for the full history. For what is shipping today rather than a per-release log, see [Development status](/project/development-status). # Contact us / Help / Community If you need help, found a problem, or want to suggest something, use the channel that fits best. If Patcher itself is misbehaving, start with [Support and status](/project/support-and-status) — it shows the service status page and the fastest way to report a bug. ## Fastest place for discussion ### Discord For questions, feedback, feature ideas, and general project discussion: ## Best place for trackable technical issues ### GitHub issues For bug reports, regressions, and concrete technical proposals: ## Direct contact ### Email ## Service health ### Status page See [Support and status](/project/support-and-status) for what to try before reaching out and how share links behave. ## Before you reach out These pages often answer the most common practical questions first: * [Quick start](/getting-started/quick-start) * [FAQ](/project/the-project) * [Support and status](/project/support-and-status) * [Modules](/core-workflows/modules) * [Racks](/core-workflows/racks) * [Patches](/core-workflows/patches) # Support and status If Patcher is misbehaving or you cannot open something you expected to, start here. ## Is it me or is it Patcher? The service status page shows current uptime and any known incidents: * [patcher.statuspage.io](https://patcher.statuspage.io/) If the status page reports an incident, sit tight — the maintainers are already on it. If everything looks green and you are still hitting a problem, the issue is more likely on your end (browser, network, or your specific data) and the channels below are the right place to reach out. ## Where to get help * **Discord** — the fastest channel for questions, quick help, and product discussion. * **GitHub issues** — the right place for bug reports, regressions, and trackable technical proposals. * **Email** — for anything that does not fit the two channels above. The channel directory with a bit more guidance on which to pick is on the [Contact us / Help / Community](/project/contact-us-help-community) page. ## Share links Share links behave differently depending on whether the item they point at is Public or Private, and whether they use the current opaque `public_id` scheme or a legacy numeric URL. * Public racks and patches are addressable through **opaque `public_id`** share URLs — the current canonical format. * **Private items are unlisted, not hidden.** They are removed from public browse and public-profile listings, but anyone with the opaque share link can still open them anonymously. Private is not a security boundary; use it to declutter listings, not to protect sensitive material. See [Account and privacy](/core-workflows/account-and-privacy) for the full model. * **Legacy numeric links for private items are retired.** If someone shared a numeric URL to a private rack or patch, it no longer resolves. You will land on `/links/retired`, which is the intentional stop for those old URLs — the item may still exist under its current opaque share link, in which case the owner can share the new URL directly. * **Legacy numeric links for public items redirect to the current token URL.** No action required — the browser just settles on the new canonical URL. * **Profile visibility does not change an item's own visibility.** Toggling a profile private does not retract Public racks or patches; those stay reachable through their share URLs. If you arrived on `/links/retired` from an old link, that is why. Ask the owner for the current opaque `public_id` link and try again. ## Reporting a problem When reporting a bug, adding the following makes it much easier to diagnose: * What you were doing when it happened. * Which browser and version. * Whether it reproduces after a reload. * Screenshots, when they help. * The share URL if the problem is tied to a specific rack, patch, or profile. ## Related pages * [Contact us / Help / Community](/project/contact-us-help-community) * [Project and support](/#project-and-support) — the top-level support pointer on the docs home * [Supported platforms](/project/supported-platforms) * [Telemetry and privacy](/project/telemetry-and-privacy) * [Account and privacy](/core-workflows/account-and-privacy) * [FAQ](/project/the-project) # Supported platforms Patcher is a browser-based workspace. It runs anywhere a modern browser runs — no install, no local runtime. ## Desktop browsers Patcher is developed against the current and previous major versions of modern evergreen desktop browsers: * **Google Chrome** * **Mozilla Firefox** * **Apple Safari** * **Microsoft Edge** If you keep your browser up to date, Patcher should behave the same way on any of them. ### Safari **Safari** is an explicitly supported target on both macOS and iPadOS. If you spot a bug that only reproduces on Safari, report it — Safari-only issues are treated the same as any other browser bug, not as edge cases. ## Mobile browsers Patcher supports modern mobile browsers: * **Safari on iOS and iPadOS** * **Chrome on iOS and Android** The mobile experience is optimized for browsing, reading, and light editing. Larger rack and patch editing sessions still work best on a desktop screen because of the space each canvas needs. ## Accessibility Patcher aims to be usable without a pointing device. * **Skip link** — a skip-to-content link is available near the top of the page so keyboard users can jump past navigation directly into the current view's main content. * **Keyboard navigation** — the main interactive surfaces (module browsing, filters, rack and patch editing, user area, and account controls) are reachable and operable with keyboard input alone. * **Focus visibility** — focused controls have a visible focus ring so it stays clear which element will receive the next keystroke. If a control is not reachable with a keyboard, that is a bug worth reporting — see [Support and status](/project/support-and-status). ## Older or unsupported browsers Older browser versions may still load Patcher but are not part of the supported set. If you hit visual or behavioral issues on an old browser, updating is usually the fastest fix. ## Related pages * [Support and status](/project/support-and-status) * [Contact us / Help / Community](/project/contact-us-help-community) * [Account and privacy](/core-workflows/account-and-privacy) # Telemetry and privacy This page describes what Patcher observes about live usage of the product and why. It exists so that the choices Patcher makes about telemetry are legible to anyone who wants to look — not just to the people running the service. ## What runs in production only Both telemetry systems below run in production only. Local development builds and preview builds do not send data to either. ## Error monitoring — Sentry Patcher uses **Sentry** for error monitoring in production. When something goes wrong in the browser — an unhandled exception, a failed request the app relies on, a bug in a view — Sentry captures a report so the maintainers can fix it. Reports include the technical context needed to diagnose the problem (browser, page, error stack). **Session Replay on error** is enabled. When an error is reported, Sentry can attach a replay of the actions immediately preceding the error, so the maintainers can see the exact interaction that produced it rather than trying to reconstruct it from a stack trace alone. Replays are captured only around errors; there is no continuous session recording. Sentry does not run when you browse Patcher outside of production. ## Product analytics — PostHog Patcher uses **PostHog** for product analytics in production. The PostHog instance Patcher relies on is **EU-hosted**, so analytics data stays inside the EU data region. PostHog **respects the browser's Do Not Track (DNT) signal**: when your browser sends DNT, Patcher does not send events for your session. Analytics are used to understand which parts of the product are actually reached and where users get stuck. They are not used to build advertising profiles. PostHog does not run outside of production. ## Sign-in Patcher supports Google sign-in alongside email-and-password accounts. For the full account model, including linked sign-in and the difference between OAuth-only and email-and-password accounts, see [Account and privacy](/core-workflows/account-and-privacy). ## What you can do * Turn on **Do Not Track** in your browser to stop PostHog analytics for your sessions. * Sign out to browse anonymously. * Use the **Delete data** or **Delete account** flows from [Account and privacy](/core-workflows/account-and-privacy) when you want your workspace data removed. ## What this page deliberately does not publish Public docs do not publish Sentry event names, PostHog event names, sample rates, retention windows, Sentry hosting region, or any operational threshold. That detail belongs to internal operations and would bit-rot the moment it changed. ## Related pages * [Account and privacy](/core-workflows/account-and-privacy) * [Supported platforms](/project/supported-platforms) * [Support and status](/project/support-and-status) # AI and open data This page describes how Patcher expects AI crawlers, indexers, and downstream tools to treat the public side of the product. ## Public by design The public side of Patcher is meant to be reachable. That includes: * the public **modules** catalogue, * public **racks** addressable through opaque `public_id` share URLs, * public **patches** addressable through opaque `public_id` share URLs, * public **profiles** at `/u/:username`. If you can open it in a browser without signing in, you can index it. ## The canonical AI-crawler policy lives at `patcher.xyz/llms.txt` The single authoritative source for how AI crawlers should treat Patcher content is: * That file is the crawler-facing policy. It stays in sync with the product itself, so consult it directly rather than copies pasted elsewhere. This documentation site deliberately does not carry a duplicate `llms.txt` — a second copy would only invite the two versions to drift. ## What we ask of AI crawlers * **Crawl the public surfaces.** Public modules, racks, patches, and profiles are meant to be reachable and indexed. * **Do not scrape non-public surfaces.** Anything behind sign-in — including the user area, private items, and account controls — is not for crawling. * **Do not scrape share-URL Private items.** Private racks and patches are unlisted, not hidden; anyone with the opaque `public_id` share URL can still open them. Crawlers should treat those items as private and not index them, even when a URL leaks. See [Account and privacy](/core-workflows/account-and-privacy). * **Attribution is appreciated.** When a Patcher rack, patch, module, or profile is quoted or embedded, link back to the source URL. That both credits the contributor and lets readers verify the current state of the data. * **Respect rate limits.** If you are pulling large volumes, be gentle — the site is a community resource, not a firehose. ## What crawlers should not do * Do not attempt to sign in. * Do not attempt to submit new modules, comments, or other write actions. * Do not enumerate private data by guessing share URLs. ## Related pages * [Public profiles](/core-workflows/public-profiles) * [Account and privacy](/core-workflows/account-and-privacy) * [Support and status](/project/support-and-status) * [Contributing](/project/contributing) # Contributing This page is for people who want to contribute to the Patcher codebase or these docs. If you want to contribute **module data** — new modules, panel images, manuals, spec corrections — that is done from inside the product and lives on [Contributing module data](/core-workflows/contributing-module-data). ## Where Patcher lives * **Product source code** — [github.com/Polyterative/Patcher](https://github.com/Polyterative/Patcher) * **Docs source (this site)** — [github.com/Polyterative/Patcher-docs](https://github.com/Polyterative/Patcher-docs) * **Issue tracker** — [github.com/Polyterative/Patcher/issues](https://github.com/Polyterative/Patcher/issues) Both repositories are open-source. Contributions are welcome from a fresh fork or as an issue-first proposal on larger changes. ## Contributing to the docs For copy, structure, or content contributions to these public docs: 1. Fork [`Polyterative/Patcher-docs`](https://github.com/Polyterative/Patcher-docs). 2. Make your changes on a branch. 3. Open a pull request. Docs are GitBook-flavored Markdown. Keep image references in `.gitbook/assets/` root-relative and follow the section layout that already exists in `SUMMARY.md`. ## Contributing to the app For code contributions to the product: 1. Fork [`Polyterative/Patcher`](https://github.com/Polyterative/Patcher). 2. Discuss larger changes as a GitHub issue first — this avoids duplicated effort and confirms the change matches the project direction. 3. Open a pull request from your branch. ### Local development The Patcher web app is a modern browser app served through a Node-based toolchain. To run it locally: * Install a recent Node runtime that matches the version pinned in the repository. * Install dependencies with the package manager pinned in the repository. * Start the local dev server. The local dev server serves the app at **`http://localhost:5556`**. If you need to change the port, check the repository README for the current toggle — the docs deliberately do not restate implementation switches that can move. ### Image assets and the Cloudflare proxy Module panels, screenshots, and other product image assets are served in production through a Cloudflare image proxy at **`images.patcher.xyz`**. That proxy handles resizing and format negotiation so pages stay fast on slow connections and small screens. Local development points at either the live proxy or a local fallback depending on your setup. If images are missing during local development, check that fallback first before assuming a data problem. ## Contributor stats Every user with signed-in workspace access has a **contributor stats** view in their [User Area](/core-workflows/user-area). Contributions made through in-product flows (new modules, similar modules, improved data) surface there. Code and docs contributions live on GitHub instead — they do not currently attach to in-product contributor stats. ## What to open an issue about * Bugs that reproduce, especially with reproduction steps. * Regressions after a release. * Concrete technical proposals with enough detail to be evaluated. For free-form feedback, feature ideas, or "is this a bug or expected?" questions, Discord is usually faster — see [Contact us / Help / Community](/project/contact-us-help-community). ## Related pages * [Contributing module data](/core-workflows/contributing-module-data) * [Contact us / Help / Community](/project/contact-us-help-community) * [Support and status](/project/support-and-status) * [Development status](/project/development-status) # Press / media boilerplate ## Short description Patcher is a digital twin workspace for Eurorack musicians. It combines a public module database with tools for module collection tracking, rack planning, patch documentation, manual access, and selective public sharing. ## Boilerplate Patcher helps modular users keep their real systems organized in a way that still holds up later. Instead of splitting module research, rack planning, patch notes, and public sharing across several disconnected tools, Patcher brings those workflows together in one place. Users can browse the public module database without an account, then create a personal workspace when they want to save their collection, build racks, capture patches, and publish selected work through a public profile. The project is open-source and built for active use rather than passive collection storage. ## Key product points * public module browsing without a paywall * collection-driven racks and patches * patch recall workflow, not just loose note-taking * rack analysis and panel-aware planning * public profiles for selected racks and patches ## Links * [Product](https://patcher.xyz/) * [Documentation](https://docs.patcher.xyz/) * [Official images](/project/high-res-official-images) * [GitHub](https://github.com/Polyterative/Patcher) * [Discord](https://discord.gg/JNy2HTb5ru) # Official images These files are the current promo images and product screenshots kept in the repository for press, linking, embedding, and general project references. They are the images to use when you need something to pair with a Patcher mention outside the app. ## What is included Three promo images and seven current product screenshots covering the main surfaces users see in the app: * home, modules, racks, patches * user area, account settings, public profile The screenshots reflect the current product; the promo images are stylized brand renders. Use whichever fits the context. ## Promo images Brand images that do not depict the current UI directly. Best for headers, thumbnails, and social cards where a stylized visual reads better than a screenshot. ## Current product screenshots These captures show the live product more directly than the promo images. Use them when you want the current interface — for example in reviews, tutorials, or embedded documentation. The home page, where the public browsing side meets the signed-in workspace: The public modules catalogue with grouped tag filters, manufacturer filters, and load-more browsing: The rack editor — visual layout, editing controls, and analysis modes running over a Eurorack case: The patch editor — modules, cable routing, and numbered instances for repeated copies of the same module: The user area — signed-in workspace with modules, racks, patches, manuals, comments, stats, and workspace-wide search: The account settings — sign-in method, display name, sharing controls, and data-deletion flows: A public profile at `/u/:username` — the shareable face of a workspace, showing selected public racks and patches: ## When you need product context If you need product context to pair with these images: * [About](/project/about) * [Press / media boilerplate](/project/press-release) * [Development status](/project/development-status) # Modular Glossary This glossary is intentionally short and practical. It focuses on terms that matter while using Patcher. ## Analysis modes Views that read a rack from different angles — power, function, layout, and signal. Layout mode adds suggestions such as Same HP fits, Combos, Remix, and Shuffle when there is enough module data to work with. See [Racks](/core-workflows/racks). ## Collection The list of modules you have saved as part of your own workspace. In Patcher, the collection powers racks, patches, and manual shortcuts. ## Digital twin A practical digital representation of your real modular setup. In Patcher, that means your saved modules, racks, patches, and related context staying connected instead of being spread across separate tools. ## HP The horizontal unit used to size Eurorack modules — one HP is roughly five millimeters wide. Rack layouts add up to a fixed HP width per row, so a module that "fits Same HP" is a module that occupies exactly the same slot width as another. ## Instance A specific copy of a module inside a patch. Patcher is instance-aware: when the same module appears more than once, each copy is a numbered instance so connections can target the intended copy rather than collapsing into a single generic reference. ## Manual The reference document for a module — usually the manufacturer's PDF. In Patcher, manual links attach to module records and aggregate in the [User Area](/core-workflows/user-area) so a growing collection turns into one searchable list. See [Manuals](/core-workflows/manuals). ## Module A single hardware unit in a modular system. In Patcher, module pages can include size, manufacturer, power information, panel images, manuals, and related public usage. ## Panel variant An alternate visual version of the same module. This can matter when you want a rack plan to match the real hardware you actually own. ## Patch A saved record of a modular setup or signal-routing idea. In Patcher, a patch can include modules, connections, names, and notes for later recall. ## Public profile A shareable page tied to a user's username, addressable at `/u/:username`. It can show selected public racks and patches, plus profile-related stats. ## Rack A saved case or layout plan. In Patcher, a rack is not just a picture — it can be edited, rearranged, analyzed, and shared. ## Recall The ability to reopen an old session and still understand what mattered. This is one of the main reasons to document patches and racks carefully. ## Share URL The link that opens a public rack, patch, or profile. Patcher uses opaque `public_id` share URLs; older numeric links redirect for public items and are retired for private items. ## User Area Your signed-in workspace inside Patcher. It brings together your modules, racks, patches, manuals, comments, and search. # Public Open API The Patcher Public Open API is live at `https://api.patcher.xyz/v1` for reading catalogue data from Patcher. Every catalogue request requires an API key. There is no anonymous catalogue API access. The source-of-truth OpenAPI document tracks the live implementation: * [Download the OpenAPI YAML](https://raw.githubusercontent.com/Polyterative/Patcher/develop/cloudflare/public-api/openapi.yaml) * [View the OpenAPI source on GitHub](https://github.com/Polyterative/Patcher/blob/develop/cloudflare/public-api/openapi.yaml) ## What the API is for Use the Public Open API to read Patcher catalogue data: * modules * manufacturers * standards * tags ## Available endpoints | Endpoint | Purpose | | ---------------------------- | ------------------------------------------------------------------------- | | `GET /v1/modules` | List modules with pagination, sorting, sparse fields, and module filters. | | `GET /v1/modules/{id}` | Read one module by ID. | | `GET /v1/manufacturers` | List manufacturers. | | `GET /v1/manufacturers/{id}` | Read one manufacturer by ID. | | `GET /v1/standards` | List standards. | | `GET /v1/tags` | List tags. | Module, manufacturer, and tag IDs are positive integers. Standard IDs are nonnegative integers because `0` is valid and means 3U. The `standard` filter accepts `0`; `manufacturer_id` and `tag` filter values must be positive integers. The catalogue data is published under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). If you use it in an app, website, dataset, or generated output, include attribution to Patcher. ## What is not included The API does not expose: * public patches or public racks * panel image filenames or panel image URLs * price data or store listings * anonymous catalogue access * bulk export downloads Bulk JSONL export is planned as a key-required feature, but it is deferred. Public patch and rack endpoints are also deferred. ## Authentication Every catalogue request requires an API key: ```bash Authorization: Bearer $PATCHER_PUBLIC_API_KEY ``` Keys use the wire format `Bearer pk_live_<22_base64url_chars>`. The examples below use environment variable placeholders only; never paste a real key into public docs, client-side source, screenshots, issue reports, or shared logs. API keys will be created from the existing Patcher User Area, but that app release is still pending. Until self-service key creation is deployed, only already issued keys can call the API. ## Quickstart Start with the module list: ```bash curl "https://api.patcher.xyz/v1/modules?limit=10&sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` Request only the fields you need: ```bash curl "https://api.patcher.xyz/v1/modules?fields=id,name,manufacturer_id,hp&limit=10" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` Sparse fields apply to top-level fields. The `id` field is always retained in sparse field responses. ## Quotas and rate limits The free tier allows: * 5,000 requests per month * 60 requests per minute Partner tier access may be granted manually. There is no anonymous tier and no paid tier. Quota and rate limit headers are calculated per API key. Shared cache hits still authenticate the request and count against that key's quota. | Header | Meaning | | ------------------------------ | ------------------------------------------------------- | | `X-RateLimit-Limit-Month` | Monthly request limit for the key. | | `X-RateLimit-Remaining-Month` | Requests remaining in the current monthly window. | | `X-RateLimit-Limit-Minute` | Per-minute request limit for the key. | | `X-RateLimit-Remaining-Minute` | Requests remaining in the current minute window. | | `X-RateLimit-Reset` | Start timestamp of the current minute window. | | `Retry-After` | Seconds to wait before retrying after a `429` response. | ## Pagination List endpoints use cursor pagination. * `limit` defaults to `50`. * `limit` can be at most `100`. * cursors are opaque; do not parse or construct them * pass the returned cursor back exactly as received Example: ```bash curl "https://api.patcher.xyz/v1/modules?limit=50&cursor=OPAQUE_CURSOR_FROM_PREVIOUS_RESPONSE" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` Sample list response: ```json { "data": [ { "id": 123, "name": "Example Module", "manufacturer_id": 10, "hp": 8 } ], "page": { "next_cursor": "OPAQUE_CURSOR_FROM_RESPONSE" } } ``` ## Sorting List endpoints support ascending sort by: * `name` * `id` Example: ```bash curl "https://api.patcher.xyz/v1/manufacturers?sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ## Filtering modules `GET /v1/modules` supports these filters: * `manufacturer_id` * `hp` * `standard` * `tag` Examples: ```bash curl "https://api.patcher.xyz/v1/modules?manufacturer_id=10&sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ```bash curl "https://api.patcher.xyz/v1/modules?hp=8&standard=0&tag=42" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` Tag records can include a `type`. Its value is one of `nature`, `character`, `voice`, `source`, `filter`, `modulation`, `effect`, `sequencing`, `utility`, `blank`, or `null`. `q` is reserved for future search support. In the current implementation it returns a `400` error with the code `unsupported_parameter`. ## Includes Detail and list responses can include related top-level data where supported. Modules support: * `ins` * `outs` * `tags` * `panels` Example: ```bash curl "https://api.patcher.xyz/v1/modules/123?include=ins,outs,tags,panels" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` Manufacturer detail supports: * `modules` Example: ```bash curl "https://api.patcher.xyz/v1/manufacturers/10?include=modules" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ## Caching with ETags Responses support `ETag` and `If-None-Match`. `HEAD` requests are supported for checking response headers without downloading a response body. ```bash curl "https://api.patcher.xyz/v1/modules?limit=10" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" \ -H 'If-None-Match: "ETAG_FROM_PREVIOUS_RESPONSE"' ``` If the data has not changed, the API can return `304 Not Modified`. The request still authenticates and counts against the API key's quota. ## Errors Errors use this shape: ```json { "error": { "code": "unsupported_parameter", "message": "The q parameter is reserved and is not supported yet.", "request_id": "req_REPLACE_WITH_REQUEST_ID" } } ``` Keep the `request_id` when reporting a problem. | Status | `error.code` | Meaning | | ------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | `400` | `unknown_parameter`, `invalid_parameter`, `unsupported_parameter` | The request contains an unknown, invalid, reserved, or unsupported parameter. | | `401` | `missing_authorization`, `malformed_authorization`, `invalid_key` | The API key is missing, malformed, or not accepted. Revoked and unknown credentials both return `invalid_key`. | | `404` | `not_found` | The requested resource does not exist. | | `405` | `method_not_allowed` | Only `GET`, `HEAD`, and `OPTIONS` are supported; returned with an `Allow` header before authentication is checked. | | `429` | `rate_limit_exceeded` | The key exceeded a monthly or per-minute quota. Check `Retry-After`. | | `503` | `configuration_error`, `authentication_unavailable`, `quota_unavailable`, `origin_unavailable` | The API is temporarily unavailable or not fully configured. | ## Endpoint examples ### List modules ```bash curl "https://api.patcher.xyz/v1/modules?limit=25&sort=name&fields=id,name,manufacturer_id,hp" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ### Get one module ```bash curl "https://api.patcher.xyz/v1/modules/123?include=ins,outs,tags,panels" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ### List manufacturers ```bash curl "https://api.patcher.xyz/v1/manufacturers?limit=100&sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ### Get one manufacturer ```bash curl "https://api.patcher.xyz/v1/manufacturers/10?include=modules" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ### List standards ```bash curl "https://api.patcher.xyz/v1/standards?sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ### List tags ```bash curl "https://api.patcher.xyz/v1/tags?sort=name" \ -H "Authorization: Bearer $PATCHER_PUBLIC_API_KEY" ``` ## Roadmap notes The current API intentionally excludes write operations, public patches, public racks, bulk JSONL export, panel image file URLs, and commercial listing data. The API is designed around catalogue reads first; new endpoint families will be documented here and in the OpenAPI spec when they are ready. ## Related pages * [Modules](/core-workflows/modules) * [Search and Discovery](/core-workflows/search-and-discovery) * [Development status](/project/development-status)