Banks And Patches

Banks and Patches

A bank always contains 128 numbered slots, matching the range of a MIDI Program Change message. This fixed address space keeps program numbers stable for DAW automation, sequencers, controllers, and set lists.

An empty slot remains addressable. In the browser it loads the Init sound and remains available to previous/next navigation, so it can be selected as a write destination. Plugin Program Change behavior for empty slots is documented in MIDI control.

---

The strip

Along the foot of the panel:

‹ ›	previous and next slot, wrapping at both ends
the name	which patch is loaded, and out of which bank — click it to open the browser
WRITE	put the sound you have into a slot
CONFIG	what the controllers do, and the manual
VOL	master volume, which is not a patch parameter

---

The browser

Click the patch name. Banks down the left, slots down the right in numbered columns filling downward — 000–063 in the first column, 064–127 in the second — so a run of numbers stays vertically adjacent and "somewhere in the forties" is findable by eye.

Click a slot to load it, double-click to load it and close. Search filters the bank list by name; with a hundred and seventy-five banks open that is the difference between a list and a haystack.

Three buttons above the bank list:

• New — an empty bank, 128 slots with nothing in them, to write into.
• Add — a bank from a file: a .json bank, a .zip of patches, or one .sy1.
• Folder — a directory of .sy1 files, which is how the reference keeps its own banks.

And along the foot:

• EXPORT — write the open bank to a file you choose. In a plugin that means your Downloads folder.
• KEEP — make the open bank the one this instrument comes back to. Plugins only; see where things are kept.
• DONE — close.

---

Writing a sound into a slot

Select WRITE to enter write mode. In normal browser mode, selecting a slot loads it. In write mode, selecting a slot chooses the destination without loading it; this preserves the sound currently being edited.

Review the proposed patch name before confirming. The name describes the current sound, not the sound previously stored in the destination. The destination is shown in amber and may differ from the currently loaded slot.

Caution: Writing replaces the selected destination slot.

---

What it reads

Five input forms are supported:

.json	a quesynth.bank or quesynth.patch document — this project's own format
.zip	an archive of .sy1 files: one bank
a folder	a directory of .sy1 files: one bank, ordered by file name
.zip of .zips	the published collection — a hundred and seventy-five banks in one file
.sy1	one patch. It arrives as the sound you are playing, not as a bank

File names are compared numerically, so 10 Gamma sorts after 2 Beta rather than between 1 and 2. Sorting them as plain text is what puts a bank's hundredth patch third, and the numbering in those names is the point of them.

An archive of archives is listed, not read. Opening all of them would be eleven megabytes of inflating and some twenty thousand patches built in order to show a hundred and seventy-five names, and only one is ever wanted at a time — so each row keeps the bytes of its own archive and opens it when it is picked. Listing the collection takes about 3 ms; opening one of its banks about 80 ms.

---

Where things are kept

Persistence follows the ownership model of each host.

In a browser

The browser uses local storage for four items:

• Current sound — restored after a page reload.
• Factory bank working copy — retains sounds written into the supplied bank.
• MIDI desk map — retains assignments created through CONFIG.
• Master volume — restores the browser output level.

Clearing site data removes these values. Export a bank before clearing browser storage or moving work to another browser profile.

Banks you opened from a file are not kept. They are already on disk, under their own names.

In a plugin

The current sound is saved by the host, into the project, through the mechanism each format provides for it — getState/setState in VST3 and CLAP. That is what a DAW expects, and a panel that also wrote its own copy would be a second version of the same state, restored in an order neither side controls.

The bank is a file, because nothing in either plugin format saves one. A bank is not part of a song; it is part of the instrument, the way it is on hardware.

%LOCALAPPDATA%\Quesynth\user-bank.json

VST3 and CLAP share this file so a slot written in one format appears in the other. Concurrent writes use last-writer-wins behavior; avoid writing a bank from multiple plugin instances at the same time.

What gets written, and when

The panel tells the plugin about the bank whenever it changes — loaded, switched, written into — because a plugin selecting programs out of a bank the panel is not showing means one program number is two different sounds.

Writing to the file is a separate question with a different answer:

• Writing a patch into your own bank saves it.
• Opening somebody else's bank does not. Browsing a .zip should not overwrite what you had.
• KEEP designates the open bank as the persistent user bank.

If the file is missing or unreadable, the bank compiled into the plugin is used and the file is left alone — refusing to start an instrument over a convenience file would be worse than forgetting.

---

← The panel · MIDI control →