Crate dspk_app_core 

DSP App core: the workbench for any multichannel signal, and the plugin interface domain plugins extend (electrophysiology: dspk-app-synapse). The dspk-app binary is this core plus the plugins it is built with.

Layout (Kotlin Compose Multiplatform style, as lumen-app): commands (every action, declared once for kitchen-shell’s menus, keys, search and agents), di (wiring), data (recording, shared store, preferences, work pool, jobs), domain (plain models: session document, commands, timeline), navigation (routes, actions), screens/<feature> (state, events, view model, screen, components), ui (theme, plot primitives, widgets), plugin (what plugins add: formats, channel layouts, trace overlays, workspaces, panel sections).

Modules

app

The root view: kitchen-shell’s frame (title bar with the DSP App menu, Help, the workspaces (Explore · Sorting · Pipeline · Curation · Analytics), the recording and where the app runs; the workspace’s menu row; the workspace as a card; the status bar with the jobs and this computer’s load; Settings; the search) around dsp-kitchen’s workspaces, as lumen’s. Every action is a command of one registry (crate::commands), so the menus, the keys, the search and an agent see the same list. Without a recording Explore shows the start screen.

commands

dsp-kitchen’s commands, declared once (kitchen-shell’s Registry): each has an id, a title, an icon, a line saying what it does, a group, a key, when it can run (and why not) and what it does. The menus, the keys, the search (Ctrl+K) and an agent’s tools all come from this list.

data

Data layer: the open recording and its sources (recording), the shared app state (store), what is remembered between runs (preferences), and the background services (work_pool, services), and the servers it works with (remote). Screens reach it through view models only.

di

Dependency wiring: installs the services every screen shares (render work pool, hover reader) as GPUI globals. The shared state (data::store::Store) is created by main and handed to the root view.

domain

Plain models shared by the screens and the data layer.

navigation

Navigation: the routes (workspaces of the title bar) and the app’s actions and key bindings.

plugin

What a domain plugin adds to the core app (electrophysiology: dspk-app-synapse). The core works on any multichannel signal; a plugin brings its domain:

screens

Feature screens in Kotlin Compose Multiplatform style: each folder owns its state, events, view model, screen and screen-local components.

ui

Design system: theme (plot palette), plotting primitives (plot), shared widgets, assets.