DRAFT · SPECULATIVE
Glass Snipler: Device Specification
Version 0.0.2-draft · Status: speculative draft · Updated 2026-11-10 · As of Bollawax 0.2.4 and Bollard SDK 0.1.0
Speculative draft. No Pop Boll hardware has shipped, and nothing on this page has been built or validated on hardware. Dimensions, key maps and protocols will change without notice, and nothing here is an offer, a commitment or a promise of compatibility. We would love to hear about partnership, OEM and dev-kit ideas: use the contact form on this site.
Note: The band's brain is a removable cart, the Bolltridge. It lives in the ball, and the same cart can also go into other docks, such as the Glass Snipler. In the Glass Snipler the cart stands in the back of the slab, so the same band moves between the ball and the slab. The Glass Snipler is a proprietary product: this page describes what it does and the interfaces a developer meets, not how it is built.
The Glass Snipler is the first device in the PWHAMSS family: a glass-topped slab you play, type and cut on, with the Pop Boll's band listening to everything you do. Where the Boll writes songs by itself, the Glass Snipler is a place where a person and the band work on the same material. This page describes the design for people who want to build software for it, or simulate it, before any hardware exists. The overview page introduces the wider Pop Boll ecosystem.
1. What it is#
The Glass Snipler is a slab whose whole face is one display under one sheet of glass, and everything on top of that glass is transparent: four clear ring knobs, four diamond mode buttons, 48 clear keys and six tall side keys. The display draws what each of them means right now, with a touch strip called the Workshop across the top and a pad of lights between the knobs. The controls sit on a removable clear plate, the Control Layer (§2.1). The slab has no computer of its own: a Bolltridge cart docks in its back and runs Bollawax, the same song factory that runs in the Pop Boll, so the sixteen virtual musicians, the seven judges and the licensed corpora are all present. What is new is the person at the keys.
Everything you make on the Glass Snipler is a sniplet: a piece of MIDI with a length in bars, a tempo, a key and a handful of settings. Sniplets come in four musical kinds (a stemlet, which is a song-length stem; a riff; a loop; a beat) plus a macro kind that records what you did with the keys. You pull sniplets out of songs, cut them on the Workshop, play them with the keys and file them in your library.
The band you jam with is the Boll's band. While you work, the musicians listen to what you cue up, and when a sniplet is finished and public they may steal it into their own riff books, exactly as they trade riffs with each other today, and may gift riffs back. So the Glass Snipler closes a loop that the Boll alone cannot: songs from the corpora become sniplets, sniplets become yours, and your sniplets become the band's. This is the Pop Boll flywheel with a person inside it.
The build order is deliberate. First a web simulator at popboll.com/pwhamss that runs the real engine on real corpus material; then sound in the browser; then audio stems; then the band's trades; then hardware. The simulator and the device share one state machine, so everything on this page is being built now, in software, and the slab is the last renderer of it.
2. Layout#
Layout A is the working layout. An earlier layout B (the Workshop wrapping the pad, knobs on the edges, a 2 × 2 mode cluster) is kept as the alternative and may come back if layout A fails in the hand.
+------------------------------------------------------------------+
| WORKSHOP full-width touch strip |
| popboard lanes . bar ruler . loop window . transport . band |
+------------------------------------------------------------------+
(S) (M) <K> <P> [ pad: a 16 x 26 matrix ] <S> <A> (L) (H)
+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+ +-----+
| ESC | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | + | = | | ? |
+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+ +-----+
| BKSP| |MAC| Q | W | E | R | T | Y | U | I | O | P | / | | ENT |
+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+ +-----+
| UNDO| |POP| A | S | D | F | G | H | J | K | L | ; | ' | | TAB |
+-----+ +---+---+---+---+---+---+---+---+---+---+---+---+ +-----+
|PUT| Z | X | C | V |SPC|SPC| B | N | M | , | . |
+---+---+---+---+---+---+---+---+---+---+---+---+
48 clear keys; the display under them draws every legend
| Element | What it is |
|---|---|
| Workshop | the touch strip across the top of the display. Always visible, in every mode. Holds the popboard, the transport and the band's listening log |
| Knobs S, M, L, H | four endless clear ring knobs with detents: Small, Medium, Large, Huge. The display draws each knob's value arc and label under it. Their meaning follows the mode and the selection, each can also be clicked, and any knob can be bound by the user in any layer |
| Pad | a touch pad over a 16 × 26 matrix of lights that the display draws under a clear window. The matrix shows idle animations, the XY position and cursors; the frame carries every pixel |
| Mode diamonds | four clear diamond keys, K and P to the left of the pad, S and A to the right. The display tints the one that is active |
| 48 keys | four rows of twelve clear keys. The display under them draws each key's current legend, tint and state, so the meaning of a key can change with the mode and the layer. How a key is sensed depends on the Control Layer (§2.1) |
| Side keys | six tall keys, three each side of the key field: left ESC, BKSP, UNDO; right ?, ENT, TAB in K mode, with other meanings outside it |
No dimension is fixed. The simulator draws layout A at its own proportions, the first hand-built slabs and the later design differ in size, and the key pitch follows the slab (§11).
2.1 The Control Layer#
The Control Layer is the clear plate that carries every physical control: the keys, the side keys, the knobs and the diamonds. It lifts off.
- With the Layer off, the slab is a bare touch display running the same software in a simpler tap interface (tablet mode).
- With the Layer on, its keys, knobs and diamonds send the events of §10 and the display draws the same frames under them.
- Two kinds of Layer are planned. On the first hand-built slabs a key is down or up, with no pressure reading. A later Control Layer adds a pressure reading on every key, and with it velocity and aftertouch.
This page says "Control Layer" for the plate and "layer" for a keymap layer (§4). They are different things.
3. Modes#
The four diamonds choose a mode. The mode decides what the 48 keys, the knobs and the side keys do, and the display redraws every key to match.
| Mode | Letter | Tint | For |
|---|---|---|---|
| Keyboard | K | #7FB2FF | typing, naming, searching, macros |
| Play | P | #FF9A3C | performing and editing the selected sniplet |
| Sniplets | S | #9BE26B | the user library, paged |
| Audio | A | #FF5C7A | songs and their stems from the corpora |
Keys are numbered 0 to 47, row-major: key = row × 12 + column, row 0 at the top and column 0 at the left.
3.1 K mode: the keyboard#
Layer 0 in K mode is a QWERTY keyboard with three Pop Boll keys down the left column and two SPACE keys under the thumbs.
| Row | Keys, column 0 to 11 | Layer + short press |
|---|---|---|
| 0 | 1 2 3 4 5 6 7 8 9 0 + = | ! @ # $ % ^ & * ( ) - _ |
| 1 | MACRO-REC Q W E R T Y U I O P / | upper-case letters, / becomes ? |
| 2 | SNIP-POP A S D F G H J K L ; ' | ; becomes :, ' becomes " |
| 3 | SNIP-PUT Z X C V SPACE SPACE B N M , . | , becomes <, . becomes > |
SPACE is transport play and stop in every mode. MACRO-REC starts and stops recording a macro sniplet. SNIP POP lifts a sniplet out of whatever is selected; SNIP PUT drops the clipboard onto the popboard. Typing from a real keyboard in the simulator arrives as text events and lands in the same place.
3.2 P mode: play#
| Region | Keys | Function |
|---|---|---|
| Steps | rows 0 and 1, columns 0 to 7 | a 16-step sequence; step = row × 8 + column. Tint #F3E97A |
| Drum pads | rows 0 to 3, columns 8 to 11 | 16 pads; pad = row × 4 + (column − 8). Row 0: KICK, SNARE, CLAP, CH. Row 1: OH, TOM, RIM, CYM. Rows 2 and 3: the same eight as alternate variants. Tint #F08A9B |
| Chromatic row | row 2, columns 0 to 7 | ARP · chromatic · chromatic · BEND/GLIDE · chromatic · chromatic · PITCH DOWN · PITCH UP. PITCH DOWN and PITCH UP held together are the mod control. Tint #FFB36B for notes, #C9B6FF for controls |
| Degrees | row 3, columns 0 to 7 | scale degrees 1 to 8 of the sniplet's key. Row 2's chromatic keys sit between row 3's degrees like the black keys of a piano |
On a Control Layer with a pressure reading, pressure is velocity on note-on and aftertouch while a key is held. On a Layer without one, a key is down or up and notes play at one velocity.
3.3 S mode: the library#
| Row | Kind |
|---|---|
| 0 | sniplets |
| 1 | riffs |
| 2 | loops |
| 3 | beats |
A column is a slot on the current page, twelve per page, and one page index is shared by all four rows. Empty slots show as empty cards. Selecting a card and pressing ENT opens its guts (the note grid) in the Workshop and switches to P mode. Knob L turns pages when nothing is selected.
3.4 A mode: songs and stems#
| Row | Content |
|---|---|
| 0 | the song in that column (twelve songs of the current corpus page) |
| 1 | its drums stem, tint #FF5C7A |
| 2 | its bass stem, tint #FFA05C |
| 3 | its music stem (every pitched non-bass role), tint #D45CFF. With the layer key held: vocals, tint #FFC46B |
In v0.0.1 the vocals row shows the song's lead-melody transcription when it has one, otherwise an empty card. You may hold up to four stem keys at once; each is marked held with an order badge. Releasing them together, or pressing SNIP PUT while holding, puts them on the popboard.
3.5 Side keys#
| Index | K mode | P, S and A modes | Hold (about 600 ms) |
|---|---|---|---|
| 0 | ESC · escape, exit module | LAYER DN | layer 0 |
| 1 | BKSP · no, reject, back | NO / BACK | clear selection |
| 2 | UNDO · previous page, undo, backfork | SNIP POP | pop as a new-kind chooser |
| 3 | ? · another similar, more details | LAYER UP | layer picker in the Workshop |
| 4 | ENT · yes, confirm, enter | YES / ENTER | open guts |
| 5 | TAB · next page, redo, forefork | SNIP PUT | put and play |
Backfork and forefork are undo and redo seen as a tree: backfork steps back to the previous state of the board, forefork steps forward along the branch you were on. Outside K mode, layer + side 2 and side 5 are previous and next page, and layer + side 1 and side 4 are undo and redo.
4. Layers and keymaps#
The Glass Snipler has a keymap system built in from the start, in the spirit of open keyboard firmware such as QMK.
Layer 0 is the default keymap: the K-mode QWERTY of §3.1 plus its shift level, and the P, S and A maps of §3.2 to §3.4. It is always present and cannot be deleted.
The layer key is both SPACE keys held together, within 150 ms of each other (estimate). It has exactly two gestures:
- Layer + short press of a key (under 600 ms): that key's shift or alternate function, or its shifted character. In K mode that is the second row of the table in §3.1.
- Layer + hold of a key (about 2 seconds): switch to that key's layer. Layer + 1 held goes to layer 1; layer + Q held goes to layer Q; layer + 0 held returns to layer 0.
There are 35 custom layers, one for each letter A to Z and each digit 1 to 9. In every layer each of the 48 keys may hold a command, a character or a macro, and each of the four knobs may be bound to a parameter. A key with no binding in the current layer falls through to layer 0, the way a transparent key does in QMK. Layers apply to every mode, so a layer may remap the P-mode pads or the S-mode rows as well as the typing keys.
Macros are sniplets of kind macro: key presses, side keys and knob moves recorded by MACRO-REC against the transport, replayable on any board. A macro bound to a key in a layer plays when that key is pressed.
On a Control Layer with a pressure reading, pressure curves are named per layer, so a drum layer can have a hard actuation and a typing layer a soft one. Outside K mode the layer modifier also lives on the side keys (LAYER DN and LAYER UP) because the SPACE keys are busy playing.
5. Sniplets#
A sniplet is the unit of everything on the device, whatever its kind. The longest kind is the stemlet.
| Kind | What it is |
|---|---|
stemlet | a song-length single-stem transcription (one role of one song), or any longer piece of MIDI with full instrumentation |
riff | a monophonic melodic phrase |
loop | polyphonic material of fixed length, drums optional |
beat | drums only, fixed length |
macro | a recording of what you did with the keys and knobs, against the transport |
Any song can be snipped in one step: one of yours on the Boll, or a MIDI file you bring. It cuts into one stemlet per stem plus the first loopable window of each (a riff, loop or beat by role), filed straight into your crate for mixing and matching.
Every sniplet carries these fields:
| Field | Meaning |
|---|---|
| bars | its length in bars (beats per bar defaults to 4) |
| BPM and lock | its native tempo, and whether it stretches to the board's tempo (locked) or pulls the board to its own when soloed (unlocked) |
| key | tonic and mode, for pitched material |
| Groove | a render-time groove pool (pattern, swing, humanise) applied when it plays, never baked into the notes |
| Guild (Family) | a group signifier: a derived or user-defined family the sniplet belongs to. Today it is a label; when sniplets are shared over a HAMS guild link, that link becomes the field's default |
| Instrument | a program in the device's soundfont (§8) |
| AGI | "looping is A Good Idea": set by you, guessed on import, and graded over time by the judges. Your setting wins |
| private | a private sniplet is never visible to the band and never leaves the device except in your own HAMS sync |
| finished | an unfinished sniplet is a draft. By default only finished, public sniplets are stealable; a setting opens unfinished ones |
Stamps. Every sniplet derived from a corpus song carries that song's stamp: a 2 × 2 block of four pictograms drawn from a house set of 64, always the same four for that song. The pictograms are our own monochrome glyphs rather than emoji, so they render identically on the keys, the matrix and the web. Stems and derived sniplets of one song share its stamp, so you can see at a glance which pieces on the board came from the same place.
Easy mode is on by default. It chops or truncates material on the fly so that everything fits the board: lengths are multiples of 2 bars, with 1-bar loops allowed, and a longer piece is cut at the loop window. With easy mode off, nothing is quantised to even bars; the device must then make sniplet length easy to manage directly, and odd lengths and polyrhythms become possible. Easy mode is a convenience, not a format: a sniplet's bars field is whatever it is, and only the fitting rules change.
Identity. A sniplet's id is a fingerprint of its content: sn_ followed by 12 hex characters derived from its kind, role, bars, beats per bar, tonic, mode and notes. Filing the same notes twice yields one sniplet, and any later library can give back the exact notes a song or a macro referred to. This is the same rule the band's riff books use for riffs.
6. The Workshop#
The Workshop is the touch strip across the top of the slab, visible in every mode. What is on it is the popboard: a set of lanes, each holding one sniplet, under a single bar ruler.
Transport. One bar ruler runs across every lane. A loop window sits on it and you drag either end with a finger. SPACE plays and stops; layer + SPACE records. The board runs at the device tempo; each lane's sniplet is locked (stretched to the board) or unlocked (soloing it pulls the board to its native tempo). Ticks from the renderer advance the playhead; the Snipler never reads a clock of its own.
Fitting rules. Sniplets of different lengths audition together. A shorter sniplet loops if its AGI flag says looping is a good idea, otherwise it plays once at its entry bar. A longer sniplet is cut at the loop window. With easy mode on, lengths are also brought to the nearest multiple of 2 bars. Every lane shows how it was fitted: loop, one-shot or cut, with its repeat count and entry bar.
SNIP POP and SNIP PUT. POP on a selection makes a new sniplet of exactly what is heard inside the loop window: the fitted, stretched, grooved result, not the sources. PUT drops the clipboard onto the board at the playhead, snapped to the grid and transposed to the board's key. Holding SNIP POP opens a chooser so the popped material can be filed as a different kind (a beat from a loop, a riff from a stem).
Cue. A tap on a lane cues it; a long press solos it. The cue stream is what you are working on, as opposed to what the band is playing. A single crossfader-style meter in the transport shows cue against band, and the M knob rides it when M is bound to mix. By default the cue replaces the band on the main output until released. Headphone cue is a setting.
The band listening. The band listens to the cue stream. A musician who likes a finished, public sniplet may steal it: a riff-book trade from your library into that musician's personal library, non-destructive, logged, and shown on the device page the way trades between musicians are shown today. The Workshop's band panel lists who is listening and what they took. In v0.0.1 the library records these events and the frame shows them; the musicians' own trading code is wired in later.
Gifts back. Musicians may also gift riffs into your library. A gift arrives as a new, unfinished sniplet with the musician's name on it, and you decide whether to keep it.
7. Pipeline#
Material enters the Glass Snipler from corpora, from your own playing and from your own recordings.
- Browse official corpora. Corpora are licensed song collections published through bollawax.org. In A mode you page through the songs of the corpora on the device, twelve at a time.
- Pull songs. A song's derived MIDI (its morpus) is already split into role stems: drums, bass, chords, lead, pad, arp, fx. A mode's rows 1 to 3 present those stems as drums, bass and music; stem MIDI lands on the popboard as song-length sniplets.
- Stems come with the corpus. Audio stem separation and the per-stem MIDI transcription are done once per song, when a corpus is built, and delivered as corpus assets. Devices download them like any other corpus asset.
- User recordings. Material that never went through the cloud, such as your own recordings or local files, has to be separated for you. Where that work runs (on the cart or on a service) is not settled (§11).
- Cut, play, file. You cut on the Workshop, play in P mode, file in S mode. Finished, public sniplets become stealable.
Nothing in this pipeline creates corpora, and the device plays corpus audio only as the licence of that corpus allows; the corpus terms on bollawax.org are unchanged by the Glass Snipler.
8. Sound#
v0.0.1: one soundfont. Every sniplet plays through one General MIDI soundfont with a per-sniplet program. The intended default is a synth-rock, arcade-pop bank, with a standard GM bank as the known-quantity fallback. A later system screen lists soundfonts and makes one active at a time.
The three house synths. Alongside the soundfont the device has three synthesizers of its own:
| Synth | Voices | For |
|---|---|---|
| Drum synth | 8 voices: kick, snare, clap, closed hat, open hat, tom, rim or click, cymbal or noise FX | the sixteen P-mode pads (eight sounds and their alternates) |
| Mono lead/bass | 1 | riffs and bass lines with glide and bend |
| Poly | a modest number of voices (estimate: 6 to 8) | loops and chords |
The simulator and the device are meant to sound the same: the same notes produce the same sound on both.
Later: audio sniplets. Audio playback of stems, and stacks that pair an audio stem with its MIDI, are the next increment after sound in the browser. Nothing in the sniplet format forbids them; the frame already carries a per-lane preview that can be either.
9. Inside#
The slab is a dock. Its computer is the cart that stands in it.
| Part | Role |
|---|---|
| Bolltridge cart | the computer. It runs all of Bollawax: the band, the judges, the Snipler, the user library and the sound. It holds the corpora, the only radio, and a secure element that carries the cart's edition and its licences, signs what the device exports and verifies what it imports. In this round the cart is built on an Arduino Uno Q; the Raspberry Pi family stays in the open Bolltridge specification for other makers and later rounds |
| Bollport | how the cart meets the slab: one USB-C connection. The cart is the USB host, power flows from the slab into the cart, and the cart sends DisplayPort to the slab's display |
| The slab | the display under its glass, the Control Layer, the audio output and a battery. It has no computer and no radio of its own |
One cart, two homes. The same cart moves between a Pop Boll and a Glass Snipler, and the band, the library and the device serial move with it. The cart runs one Bollawax image and picks what to be from the dock it lands in: in a ball it is the Boll, and in a Glass Snipler it starts the Snipler. That switch is decided and not built: there is no cart image yet.
The Snipler files are a separate layer. They are not part of the image a Pop Boll cart ships with. A cart that docks in a Glass Snipler fetches them from the place its image updates come from, with no account, no purchase check and no key to type, and keeps them from then on, updating them with the image. If there is no network at the first dock, what the cart already has keeps working and the Snipler files arrive when the network does. Bollawax 0.2.4 built the first half of this: the Pop Boll image no longer carries the Snipler, and a Boll fetches the layer when its owner asks for it. A device fetches and runs the Snipler files under the Snipler Use Grant. Signed releases and layers are planned.
Updates. A Bollawax image is published with a latest.json release record. The device fetches the record, verifies the image, boots it, keeps the previous image and rolls back by itself if the new one fails its health check.
Offline first. Everything the device needs runs on the cart. Corpora, stems and the soundfont are cached; the library is kept on the cart; the band works without a network. When online, the cart fetches new corpora and, later, syncs the person's library through HAMS so the same sniplets follow them to any device they use. HAMS sync of the user library is not built.
10. Architecture: one state machine, two renderers#
The architectural bet of the whole build is that the device is one pure state machine with several renderers.
events (keys, side keys, knobs, pad, touch, ticks) frame (JSON, one per change or tick)
browser / slab ----------------------------------> Snipler ------------------------------> renderer
no clock of its own, and no
randomness outside a seeded source
|
v
user library . board . keymap
- Every input is an event: a JSON object with a
typeand at_mstimestamp on the renderer's monotonic clock. Key down, key up and key pressure (0 to 1), side key down and up, mode, knob delta in detents, pad down, move and up (0 to 1 in each axis), Workshop touch, tick, and text. Unknown events are ignored. - Every output is a frame: one JSON object with the mode, the layer, a status line, 48 key cards, 6 side cards, 4 knob states, the Workshop (view, tempo, key, transport, lanes, guts, picker, text, band), the 16 × 26 matrix as a hex string, the selection, the held keys and an optional toast. A card is a glyph, a sub-legend, a label, a tint, two 0-to-1 field values, a state and optional stamp and marks, and a renderer draws a card from those fields alone.
- Event summary. The frame is the whole display state, so a renderer never needs to remember the previous one. Nothing a renderer shows may be invented locally; if it is not in the frame it is not on the device.
- Determinism. Time enters only through
t_ms. Randomness enters only through a seeded source, and the seed is recorded in whatever it produced. A frame is therefore a pure function of the event history, which is what makes the browser canvas and the slab's screens show the same thing, and what makes the whole device testable from a list of events.
The Boll's lights already work this way: since Bollawax 0.2.4 the device and the browser draw their frames with one open engine from the Bollard SDK, pinned by shared test vectors. The Glass Snipler extends the pattern to a whole device. The SDK also carries draft JSON Schemas for the Snipler's events and frame (snipler-events and snipler-frame); they are drafts until they have been checked against frames the engine produces. The PWHAMSS page carries the developer-facing summary of the contract with examples.
11. Status and open items#
Nothing on this page has been built in hardware. The state of the design on the date above:
| Area | State |
|---|---|
| Modes, key maps, side keys | decided for v0.0.1 (§3) |
| Layers and the two-gesture rule | decided (§4) |
| Knob names and knob mapping | decided: Small, Medium, Large, Huge, context dependent and user-bindable |
| Sniplet kinds, fields, ids, stamps | decided (§5) |
| One display under glass, clear controls, the removable Control Layer | decided (§1, §2.1) |
| The cart as the computer, docked through the Bollport | decided (§9) |
| Layout | layout A chosen; layout B kept as the alternative |
| Slab dimensions, key pitch, battery | not fixed |
| Simulator | running at popboll.com/pwhamss for superusers, on real corpus material |
| Cart image, the switch on the dock, HAMS sync, hardware | not built |
| Signed releases and layers | planned |
Planned for developers, and not available yet:
- What third parties will be able to make: data (keymap layers, macros and sniplet packs), external renderers and controllers, and sandboxed apps that own a Workshop view. These wait for the deck service, the sandbox and the registry described on the bollardeck page.
- Simulators: an open stub in the Bollard SDK that replays schema-valid frames, and the real engine hosted on popboll.com for signed-in developers. The engine itself stays closed and runs only on our server and on carts.
Not decided:
- Dimensions. The first hand-built slabs and the later design are different sizes, and the simulator draws its own proportions. No number on this page is a hardware dimension.
- Velocity on the first slabs. Their Control Layer has no pressure reading. Whether it sends a fixed pressure or a rough estimate in the
pressurefield of §10 is not decided. - A larger external screen. The hinged screen of the first design is dropped. Whether a separate screen attaches to the slab is not decided.
- Local recordings. Where stem separation of a person's own recordings runs (§7).
- Easy mode off. How sniplet length is edited directly, and how odd lengths and polyrhythms are shown on the Workshop, has not been designed.
- Default knob bindings per mode. The knobs are context dependent; which parameter each one takes in each mode by default is the builder's call for now and will be written down here when it settles.
- Guild (Family) derivation. How a derived family is computed for a sniplet that the user has not labelled.
- Stealing unfinished work. The setting exists in the design; its default is off.
- Headphone cue versus main-out cue as the default on hardware.
- Audio sniplets and audio-plus-MIDI stacks: the sniplet format leaves room for them; nothing is specified.
Changes#
- 0.0.2-draft (2026-11-10). Rewritten for the decisions of 2026-11-09: one display under glass with clear controls, the removable Control Layer, the Bolltridge cart as the computer, the Snipler files as a separate layer. The computer inside the slab, the real LED matrix, the external LCD and the references to the retired cartridge class are gone. The page describes what the Glass Snipler does and its published interfaces, not how it is built.
12. Licence#
This page's text is CC BY 4.0: it may be quoted and shared with credit. The Glass Snipler itself (its software, its design and its drawings) is all rights reserved for now, and this page grants nothing about building it. The open code a developer needs to talk to it is in the Bollard SDK under Apache-2.0. None of this covers the project's names and logos.