Run a health check across every transport channel (host / CakeScript / WM_COMMAND / surface bridge / realtime MIDI / UIA click), each with a verdict and a remedy. THE tool to run first after a SONAR upgrade: it names which paths degraded and what to update.

Check SONAR host, which automation transports this build supports, and what to use. Run this first.

List modal windows (the Assistant / command-palette panel) that block menu commands.

Close transient panels. Standard dialogs, including unsaved-work prompts, are preserved by default. Dismissing them may discard work and requires closeDialogs:true and confirm:"closeDialogs".

How to drive SONAR's own UI with a computer-use runtime: which parts are reachable, which are not, and how to recover when a JUCE modal dialog blocks the app. Measured, not guessed — notably, synthetic keystrokes do not reach SONAR and the menu bar is reachable via AXExpand.

What WM_COMMAND can actually drive in this SONAR build, measured. Working commands are main-frame ones (Preferences, About, Assistant, Video Engine, Reset MIDI/Audio). The 视图 menu, CakeScript and per-track mixer commands are registered but not dispatched, so posting them does nothing — this tool says so up front instead of leaving you to discover it.

Re-measure which command ids do something on the running SONAR, by posting each and watching the window list. Use after a SONAR update to refresh the working/inert split. Defaults to the two safe view commands when a project is open; nothing without a project. Only a fixed view/dialog allowlist is probed, even for explicit ids. A modal stops the survey and is left open. No insert, recording, mute, solo or document lifecycle probes. Cost, measured: each probe takes about 15s (two bridge round trips plus a settle delay), so the full 21-command survey is roughly five minutes and NO budget makes it quick — a short budget buys one or two probes, which is a much weaker claim than a complete survey. probed says how many were actually measured; give it time if you want the measurement.

List SONAR commands. source="live" (default) lists ids that cw_run_command can actually post, read from the running build's menu bar. source="index" searches SONAR's command-palette index (broader, but those ids are not postable).

Run a SONAR menu command by numeric id via WM_COMMAND. Version-independent: works on any build whose menu exposes the command. Get ids from cw_list_commands. Returns whether the window list changed, so a registered-but-unhandled command is distinguishable from a working one.

Whether SONAR has a document open, read from the window title — the one piece of project state this process can see. This gates a lot: with no project the menu bar has only the application-level menus and the track controls do not exist, which makes view and document commands look broken. With a project open the menu tree is 270 entries and the track strips appear.

How to read and change tracks through SONAR's accessibility tree, which is the working path on builds with no CakeScript. Gives the element naming ("音量 on Track 17"), which controls each strip type has, and which action each takes. The elements are only reachable from a computer-use runtime — this server ships the contract, it cannot read them itself.

Commands that open SONAR views, with the caveat that matters: a view opening inside the existing frame produces NO new window, so cw_run_command reports "none-observed" for all of them even when they worked. Verify a view by reading the accessibility tree or a screenshot.

Summarise the plugins SONAR has registered: counts, categories, and any registered plugin whose file is missing. Reads SONAR's own scan result, so it works whether or not SONAR is running.

Search registered plugins by name. Covers effects and instruments; instruments are the ones to load into a track. Each result carries its CLSID, its file path, and whether the file is still present.

How far plugin insertion can be driven on this build: discovery works (open the browser, list categories, read which plugin is selected), insertion does not (click, double-click and drag all leave the FX bin empty). Read this before promising a plugin can be attached.

Instruments available for songwriting, grouped by the role each suits (drums, bass, keys, guitar, strings, synth), best pick first. Derived from the registered instruments.

Add a track to the open project via SONAR's 插入 menu. kind: midi | audio | bus | folder | aux. Requires a project to be open — the 插入 menu does not exist without one. Reports whether the project title gained its modified marker, which is the only insert confirmation available without a computer-use runtime.

Add the tracks a simple arrangement needs: drums, bass, keys, guitar, strings, synth — in that order, one MIDI track each. Pass roles to add only some. Each track gets SONAR's default instrument; loading a specific plugin is a separate UI step. Cost, measured: one insert takes ~19s (a menu post plus a verification wait), so the full six-track skeleton needs roughly two minutes. Pass roles and a matching budgetMs together rather than asking for all six.

Every 插入 (Insert) command SONAR exposes, with its id. Reference for cw_run_command when you need something cw_add_track does not cover, e.g. a track template.

Selection, navigation and marker commands: selectAll | selectNone | selectByTime | selectFromNow | selectToNow | selectToEnd | goToNextMeasure | goToPrevMeasure | goToPrevMarker | goToNextMarker | insertMarker | setProjectStart | setProjectEnd | setProjectRange | toggleProjectMarkers | removeProjectStart | removeProjectEnd | removeProjectRange | showMarkerView. Reports whether the result is a readable dialog or a drawn change this process cannot confirm.

Everything about markers: the dialog (which IS writable, unlike SONAR's own controls), the commands, and how to read the marker list back. This is the working pattern for a drawn surface that has a command opening an MFC dialog behind it.

Run an editing command: quantize | grooveQuantize | transpose | splitClips | splitAtNow | splitMidiNotes | mergeClips | gain | normalize | reverse | removeSilence | fadeEnvelope. Every one needs a selection, which this tool satisfies first — that precondition is the difference between "the command does nothing" and "it opens its dialog".

The editing layer: the commands, their preconditions, the dialogs behind them, and the three-cause taxonomy for "a probe reported nothing happened".

How note-level editing actually works: notes cannot be READ through any automation surface, but they can be EDITED through the dialog behind 处理 > 量化, and the exported .mid file is what proves it. Carries the measured field labels, the two mistakes that produced wrong conclusions, and the full verification round trip.

The exact plan for a quantize: which dialog fields to write, with what values, and how to prove afterwards that it landed. This process cannot perform the accessibility writes itself — a computer-use runtime does that — so this states the plan rather than pretending to run it. Pass the settings you want to get the concrete values.

The exact plan for a transpose: which 移调 dialog fields to write, with what values, and how to prove the commit landed. Transpose is the one note operation that changes PITCH, and it works on a free licence — no CakeScript needed. This process cannot perform the accessibility writes itself (a computer-use runtime does that), so this states the plan rather than pretending to run it.

CAL is SONAR's legacy macro language and it is NOT behind the membership paywall, unlike CakeScript. It reads and writes note data directly, so on a free licence it is the only way to CREATE, DELETE or READ notes — the dialogs can only transform existing ones. This returns the language reference (fields, operators, builtins), the run procedure, the generated programs, and the traps that cost real time to find.

Delete the CAL script files cw_cal_run wrote, and their .bak copies. Running CAL leaves a file in the real CAL folder alongside the 37 shipped scripts, so this exists to put the folder back. Only names matching the generated MCP-.CAL pattern are removeable — this will not touch a script you wrote by hand.

Rewind the most recent operation. Undo opens no window and changes no element, so this process CANNOT confirm it — expect effect "none-observed", which is the SUCCESS case, not a failure. To check it worked, look at the data the operation had changed (a note count, an export), never at the screen. This is the adapter's only rewind, and it is what makes an uncertain write safe.

Reapply the operation most recently undone. Same silent behaviour as cw_undo — no window, no element change, so the result cannot be confirmed from the screen.

Open 编辑 > 历史 (0x8044) and report how to read and use the undo stack. The dialog lists every undoable operation as a row, OLDEST FIRST, which makes this the one place in this host where the write history is legible rather than inferred. Reading it changes nothing; choosing an older row and pressing 确定 rewinds TO that point and DISCARDS everything after it — so for a single step use cw_undo instead. Note the stack is depth-limited (measured 128) and old entries are dropped silently.

How undo/redo work here, the undo-stack dialog as measured, why the stack is the backstop for every irreversible write path, and the trap in verifying a rewind (a window diff sees nothing, so "none-observed" reads like failure when it is success).

Convert between ticks, bar:beat:tick and seconds. Pure arithmetic — it needs no project and works with SONAR closed, so a measurement already in hand can be converted without waking anything. Pass exactly one of: ticks | time ("1:01:000") | seconds | bar. Note the bases: bare numbers are BARS, and in bar:beat:tick only the final field is 0-based — 1:01:000 is the start of a project, which is what a freshly opened one reads.

The time units this project uses, the 1-based/0-based trap in bar:beat:tick, the grid note values in ticks, and what the conversions cannot do (tempo changes).

Read one background job by id: state, elapsed time, progress trail, result or error. Poll this after a slow tool returns a job id.

List recent background jobs, newest first, without their payloads.

Mark a background job abandoned so its result is discarded. This does NOT stop the work: a menu command already posted to SONAR cannot be recalled. It only stops this adapter from reporting the result.

Forget finished background jobs. Running jobs are kept so a caller does not lose track of them.

Why background jobs exist here, the states a job moves through, and the one thing the API deliberately cannot do (cancel work already sent to SONAR).

The exact plan for a CAL run: the script source, the dialog field to write, and how to prove the result from data. Pure — it writes no file and posts no command, so it is safe to call speculatively. Use cw_cal_run to actually do it.

Write a CAL program into the folder SONAR reads, select everything, and open 处理 > 运行 CAL 程序 (0x806A). CAL needs no licence, so this is how notes get CREATED, DELETED or READ on a free build — the edit dialogs cover only transformation. This process cannot click, so it stops at the open dialog and reports the exact steps an accessibility runtime must take. The script ends with a modal pause that has to be dismissed, and CAL reports only a count — prove the effect by exporting and parsing.

Judge a quantize from actual data instead of guessing. Give it the note ticks before the edit and the ticks the exported file now holds, and it computes what the settings should have produced and says whether they match and whether the notes landed on the grid. Pass before and after as tick arrays, or pass file paths to read them. The judgement is pure arithmetic, so it works without SONAR running.

The 量化 dialog as measured: every field, its accessible label, which element kind to write to, the values it accepts, and the traps. Kept separate from the plan so a caller can see the raw measurement the plan is built from.

Why a command can report "nothing happened", with how to tell the three causes apart. Only one of them is a limit of this adapter.

Whether the open project has unsaved changes, in the terms that matter before closing or opening something else. Read from the title's modified marker.

Run a document command: newProject | open | save | saveAs | close | exportAudio | importMidi | revert. The destructive ones (close, revert) refuse unless confirm is set to the command's own key, because they discard the session with no undo.

How to drive the file dialog a document command opens: the element names, and why this one IS scriptable when SONAR's own controls are not (it is standard MFC, not drawn).

Send a transport or timing command: play | stop | record | toggleLoop | setLoopSelection | metronomePlayback | metronomeRecord | showTempoView | showMeterView | insertTempoChange | insertMeterChange. Every one of these changes state WITHOUT opening a window, so this tool can post but not confirm — it returns what a computer-use runtime should look at.

How to set and read tempo and time signature. Writing them into a .mid and importing is the reliable route; inserting a change at the now-time is a different operation.

Which commands have been confirmed to work, which are unconfirmed and why. Unconfirmed does NOT mean broken: a toggle or a transport action never opens a window, so a window diff reports nothing. This says which witness would settle each one.

Run a menu command and report what this process could and could not establish, instead of claiming success from "nothing errored". Returns status confirmed | did-nothing | unconfirmed, with the evidence class behind it.

Parse a Standard MIDI File: per-track name, channels, note count, and any CC7/CC10 with the pan position spelled out. Use it to check what a file carries before importing it, or to read back a file SONAR exported.

Generate a Standard MIDI File (format 1) from note and CC events. Each track needs a MIDI channel; CC7/CC10 written at tick 0 become that track's initial volume and pan when SONAR imports the file. This is the reliable way to set mixer values and place notes, because the in-app controls are read-only through automation on this build.

Set a track's pan through the live MIDI cable (CC10). This is the path that actually works: the track strips' pan slider is read-only through accessibility on this build. channel is the MIDI channel the track listens on, not its position — read it from the strip's "MIDI 通道 on Track N" value.

Set a track's volume through the live MIDI cable (CC7). level is 0.0-1.0, or pass a raw CC value.

Set pan and volume for several channels in one round trip. mix is [{ channel, pan?, volume? }] with pan in -1..1 and volume in 0..1.

What a live MIDI mixer message can affect right now, and why. A CC reaches SONAR but only applies where a track is listening (armed, channel-assigned, or bound to ACT) — without a destination it is delivered and dropped, which is invisible unless you check.

What can and cannot set a track's volume or pan on this build, measured, with the survey behind it. Accessibility reads mixer state but does not accept it; MIDI writes do.

Measure what this adapter can actually do against the running SONAR, and how fast: every capability grouped by transport, with the confirmation method for each result. Use it after a SONAR update to re-establish the boundaries. Measured: a full sweep takes 70s+, and not only because of the plugin scan — the write cases post a command and then wait for the UI to settle, and four of them account for ~55s of it. So the default answers from the read half (a few seconds) and every expensive stage is opt-in and named in skipped. Pass full: true for everything. The write stages can start playback and send MIDI to the selected destination; they do not insert tracks or buses.

Per-operation latency profile: bridge round trips, menu commands, MIDI sends, plugin reads. The plugin-read stage is the slow one, so it is skipped by default for the same reason cw_benchmark is — a bare call must return, not time out.

Get a plan for reading project state on this build. Lists which SONAR surface carries each fact (track list, mixer values, notes) and the steps to capture it. Use when cw_get_* tools report CAKESCRIPT_UNAVAILABLE.

Send back what a computer-use agent observed, so later calls reuse it instead of re-probing. Shape the state like the CakeScript tools did: { tracks: [{index,name,type,volume,pan,mute,solo,arm,clips}], notes: [{track,pitch,velocity,time,duration}], now, tempo, loop, project }.

Read the most recent observation for a topic. Reports staleness and why it is empty when nothing has been observed yet.

List which project-state topics have been observed, and when.

Every SONAR UI surface that carries project state, and what can be read from each. Reference for writing a probe.

Read SONAR's MIDI port configuration (TTSSEQ.INI): which ports SONAR has enabled as inputs, outputs and echo. Use this to verify the receive side, which a send cannot confirm.

Enable a MIDI port in SONAR by writing TTSSEQ.INI, so the MIDI transport reaches SONAR without touching the UI. Idempotent. SONAR applies it at startup or when its MIDI Devices dialog is applied — not live in the current session.

Report the real-time MIDI transport: available ports, which one will be used, and the one-time step needed in SONAR (Preferences > MIDI > Inputs) to receive it.

List every MIDI device Windows reports, in and out.

Play a note on the live MIDI port. Use this to audition or to write into a record-armed track. millisecond latency; no CakeScript involved.

Play several notes at once on the live MIDI port, released together.

Send a MIDI control change on the live port. cc 7 = channel volume, 10 = pan.

Send a batch of raw MIDI messages in one round trip. Each message is [status, data1, data2]. Use this to lay down a phrase cheaply; pass channel to rewrite the low nibble of each status byte.

Send all-notes-off and reset controllers on every channel, then reset the port.

List all tracks in the active SONAR project. NEEDS CakeScript (T1), which this SONAR build cannot dispatch — on this build use the export route instead: cw_run_command 0xA659 (文件 > 导出 > 标准 MIDI 文件), then cw_read_midi_file on the result.

Get one track's properties. NEEDS CakeScript (T1), which this SONAR build cannot dispatch. cw_get_track_control reads a single strip control and works without it.

Set a track's volume (0.0 to 1.0+; 1.0 = unity). NEEDS CakeScript (T1), which this SONAR build cannot dispatch, and there is no drop-in replacement: SONAR's accessibility actions are inert on the fader (measured) and CAL has no volume builtin. cw_set_volume sends live CC7 on a MIDI channel instead — it reaches the engine but only moves a track that is listening to that channel. See cw_mixer_support for the survey.

Set a track's stereo pan (-1.0 = full left, 0 = centre, +1.0 = full right). NEEDS CakeScript (T1), which this SONAR build cannot dispatch — same limits as cw_set_track_volume. cw_set_pan sends live CC10 on a MIDI channel instead.

Mute or unmute a track. Works by driving the track strip's own 静音 button (a real click — SONAR's accessibility actions are inert), and reports verified from the value read back. Needs a project open and the track visible in the Track view.

Solo or unsolo a track, through the track strip's 独奏 button. Reports verified from the value read back. Needs a project open and the track visible.

Arm or unarm a track for recording, through the track strip's 录制 button. Reports verified from the value read back. Needs a project open and the track visible.

Read one track-strip control as SONAR currently shows it — any label, e.g. 音量, 声像, 手动静音, 独奏, 录制, 输入, 输出, 存档. Reading is accurate; writing is only available for the three toggles (cw_set_track_mute / solo / arm).

List the .cwx track templates SONAR has available, with their category. A template is a whole pre-built strip — instrument, FX chain, sends, routing — and inserting one is the verifiable way this adapter puts a plug-in chain into a project.

Insert a track template into the project by name (or full .cwx path), then confirm it by finding the new track in the strip accessibility tree. Needs a project open. Use cw_list_track_templates to see what is available.

Rename a track by editing its strip's name field (double-click, paste, Enter), and report verified from the name read back. Handles Chinese, unlike the CakeScript route this replaces. Needs a project open and the track visible in the Track view.

List clips on a track. NEEDS CakeScript (T1), which this SONAR build cannot dispatch.

Get the notes of a clip on a track (default clip 1). NEEDS CakeScript (T1), which this SONAR build cannot dispatch. The export route is the verified way to read note data on this build.

Send a transport command (play | stop | record | pause). Tries CakeScript first and falls back to SONAR's own menu commands, so it works on builds where T1 cannot be dispatched.

Move the now-time to a Bars/Beats position, e.g. "1:01:000". NEEDS CakeScript (T1), which this SONAR build cannot dispatch, and no menu command performs an absolute jump: cw_navigate moves by whole measures (goToNextMeasure / goToPrevMeasure) only. cw_convert turns a position into ticks if you need the number itself.