engine-dj-mcp 0.9.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Mikhail Chereshnev
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,169 @@
+# engine-dj-mcp
+
+An MCP server that lets an AI assistant search and audit your **Engine DJ**
+libraries — the one on your Mac and the ones on your USB drives.
+
+> **Not affiliated with, endorsed by, or sponsored by inMusic Brands, Denon
+> DJ, or the Engine DJ product.** "Engine DJ" is used here only to name the
+> software whose library this tool reads. No logos or brand artwork from
+> inMusic or Denon DJ are used in this project.
+
+## What it does
+
+- **Smart search** (`search_tracks`) — full text with diacritics folded,
+  tempo windows, harmonic key matching, rating, and play history ("what have
+  I not played in six months?").
+- **Track lookup** (`get_tracks`) — full metadata for specific track ids.
+- **Cues, loops and beatgrids** (`get_track_performance`) — decoded from
+  Engine's `PerformanceData`, with a per-field decode status. The cue and
+  beatgrid layouts are reverse-engineered but **validated against a real
+  Engine library**; the loop layout is not fully validated — see
+  [Limitations](#limitations).
+- **Collection audit** (`audit_library`) — missing files, unanalysed tracks,
+  tracks without cues or beatgrids, duplicates, suspicious tempos, orphaned
+  playlist entries.
+- **Read-only SQL** (`run_sql`) — an escape hatch for anything the tools
+  above do not cover.
+- **Library and index introspection** (`list_libraries`, `refresh_index`) —
+  see what was discovered and force a search-index rebuild.
+
+It also exposes two MCP resources: `engine://schema` (the field semantics an
+assistant needs before writing SQL against the library) and
+`engine://libraries` (what was discovered, and whether each library's schema
+is supported).
+
+## Choosing a library
+
+Engine DJ keeps a library on your computer and another on every drive you
+export to, so more than one is usually connected at once. `list_libraries`
+reports each of them with a `uuid` and a `path`, and **every tool that reads
+library data takes an optional `library` argument** — `search_tracks`,
+`get_tracks`, `get_track_performance`, `audit_library`, `run_sql` and
+`refresh_index`. Pass either the `uuid` or the `path` exactly as
+`list_libraries` printed it; the `~/…` form it reports is accepted alongside
+the absolute one. A value matching neither comes back as
+`library_not_found`, listing the libraries you can actually choose from.
+
+Leave `library` out and the server uses **the supported library holding the
+most tracks**, ties broken by the order the drives were scanned in. That
+matters: the local library Engine DJ creates on install is scanned first and
+is often empty, so "the first one found" would hide the drive you actually
+work from.
+
+Each library gets its own search index and its own read-only connection,
+opened the first time you ask that library a question — mounting four drives
+does not cost four connections. Every query, audit and file-path check stays
+inside the library selected for that call. Comparing two libraries against
+each other — "what is on this drive but not that one?" — is **not** something
+this server does.
+
+## Safety
+
+Your library is opened **read-only at the operating-system level**, not by
+convention or by a `PRAGMA` that a query could turn back off. Writes are
+refused by SQLite itself, and no file is ever created inside your `Engine
+Library` folder. The server keeps its search index in `~/.engine-dj-mcp/`.
+
+`run_sql` accepts arbitrary SQL, but only ever the first statement of it is
+executed, and `VACUUM`, `ATTACH` and `DETACH` are rejected outright, so a
+chained or exfiltrating statement cannot slip past the read-only connection.
+
+If Engine DJ was closed uncleanly and left an unrecovered journal, this
+server will never open the library writably to "fix" it for you — that
+would break the one guarantee this project makes. It reports
+`library_needs_recovery` instead and asks you to launch Engine DJ once so it
+can recover the library itself.
+
+## Limitations
+
+Read this before deciding what to trust.
+
+- **Cue, beatgrid and waveform layouts are validated; the loop layout is
+  not.** The
+  binary layouts inside `PerformanceData` are reverse-engineered, so every
+  decoded field says which kind it is:
+
+  - `layout: "verified"` — **cues** (including the main cue), the
+    **beatgrid**, and the **waveform summary**. These were derived from and
+    checked against a real Engine DJ 3.0.x library of 281 analysed tracks:
+    cue offsets land inside the track, the beatgrid's implied tempo matches
+    `bpmAnalyzed` on all 281, and the waveform's declared point spacing
+    multiplies back out to the track's sample count on all 281. A
+    `status: "ok"` here is a claim about the values, not just the parse.
+  - `layout: "unverified"` — **loops**. The blob's slot structure is known
+    (eight slots, uncompressed, little-endian) and an empty one decodes
+    correctly, but not one track in that library had a loop saved, so the
+    meaning of a *populated* loop slot is untested. Do not report loop
+    bounds to a user as fact.
+
+  A `layout` marker is a claim about the **bytes** — which offset holds
+  which field, and what the number there means. It is not a claim about
+  every name this server puts on them. Three labels are inferred rather than
+  measured, and the code says so where each is defined: which of a cue's
+  four colour bytes is which channel (they are reported as stored, as one
+  32-bit value, with no channel claim attached); that the second beatgrid is
+  the one Engine calls "adjusted" (that it is the one Engine *plays* is
+  measured — on seven tracks the other grid runs at exactly half the
+  analysed tempo); that `main_cue.is_adjusted` is what its flag byte means;
+  and that the waveform's three bytes per point are the low, mid and high
+  bands in that order. None of these affects a value you get back.
+
+  Everything else the server reports — titles, artists, tempo, key, ratings,
+  play history, file paths — is read straight from the database and carries
+  no such caveat.
+- **`has_cues` and `no_cues` mean "a hot cue is set", and cost a little to
+  say so.** Engine writes a `quickCues` blob to every analysed track whether
+  or not any pad is used, so the cheap SQL test (`quickCues` present and
+  non-empty) answers a question about *analysis*: in the 281-blob reference
+  library all 281 would count as having cues, while two tracks (three rows,
+  one track being exported to a second library) actually do. The blob is
+  therefore decoded when the search index is built, and
+  `search_tracks(flags: { has_cues: true })` and `audit_library`'s `no_cues`
+  both read the decoded answer. That costs about 100 ms of extra rebuild
+  time at 50,000 tracks, and a rebuild only runs when your library changes.
+
+  The track's **main cue** does not count towards it: Engine sets that as a
+  playback start marker rather than the DJ placing it (it is set on 159 of
+  the 281 blobs, including every track the library records as played), so
+  counting it would answer a third question again. `has_beatgrid` and
+  `no_beatgrid` do still test for the blob — a `beatData` blob has no
+  "written but empty" state, and on all 281 real blobs presence and a usable
+  grid have never disagreed.
+- **It never writes to your library.** Not to add a cue, not to fix a tag,
+  not even to recover a journal Engine DJ left behind. The connection is
+  read-only at the kernel level, so a write is refused by SQLite itself
+  rather than by a rule this code could get wrong.
+- **It does not read play history.** `Track.timeLastPlayed` is used to answer
+  "what have I not played in six months?", but the separate Engine history
+  database — individual sessions, decks, what followed what — is not opened
+  at all.
+- **It does not build set lists**, reorder playlists, or suggest transitions.
+  It answers questions about the collection; the mixing is yours.
+- **Schema 3.0.0 through 3.0.2 only** (Engine DJ 4.5 and 5.x). Older and
+  newer libraries are listed with their version and reported as unsupported
+  rather than read on a guess.
+
+## Requirements
+
+- Node.js 22 or newer
+- Engine DJ with library schema 3.0.0–3.0.2 (Engine DJ 4.5 and 5.x)
+
+## Install
+
+```bash
+npx engine-dj-mcp
+```
+
+Claude Desktop configuration:
+
+```json
+{
+  "mcpServers": {
+    "engine-dj": { "command": "npx", "args": ["-y", "engine-dj-mcp"] }
+  }
+}
+```
+
+## Licence
+
+MIT — see [LICENSE](./LICENSE).

package/dist/blobs/index.d.ts

@@ -0,0 +1,337 @@
+/**
+ * Whether a field's binary layout has been checked against real Engine data.
+ *
+ * `"verified"` means the layout was derived from a real library and confirmed
+ * by predictions that could have failed: cue positions landing inside the
+ * track, a beatgrid whose implied tempo matches `Track.bpmAnalyzed`, a
+ * waveform whose declared bucket spacing multiplies back out to the track's
+ * sample count. `status: "ok"` on a verified field is a claim about the
+ * values, not merely about the parse.
+ *
+ * `"unverified"` still means what it always did: the bytes parsed without
+ * contradicting the layout, and nothing more. It survives on `loops` because
+ * no track in the 281 examined has a loop set, so while the slot structure is
+ * pinned down, the meaning of a *populated* slot is untested.
+ *
+ * The marker is about the *bytes*: which offset holds which field, and what
+ * the numbers there mean. It is not a claim about every English word this
+ * module attaches to them. Three labels are inferred rather than measured and
+ * say so at their own definitions — the cue colour's channel order, the
+ * beatgrid's `grid: "adjusted"` and `main_cue.is_adjusted` naming, and the
+ * waveform's low/mid/high band naming. Each names a field whose *value* is
+ * pinned by the evidence below; only the name is a reading of it.
+ */
+export declare const LAYOUT_VERIFIED: "verified";
+export declare const LAYOUT_UNVERIFIED: "unverified";
+export type LayoutStatus = typeof LAYOUT_VERIFIED | typeof LAYOUT_UNVERIFIED;
+export type Decoded<T, X = object> = {
+    layout: LayoutStatus;
+} & (({
+    status: "ok";
+    items: T[];
+    total: number;
+    truncated: boolean;
+} & X) | {
+    status: "empty";
+} | {
+    status: "unsupported";
+    detail: string;
+    bytes: number;
+} | {
+    status: "corrupt";
+    detail: string;
+});
+export interface Cue {
+    /** Hot-cue slot, 0-based: `index: 7` is the pad labelled "Cue 8". */
+    index: number;
+    label: string;
+    position_samples: number;
+    /** position_samples converted with beatData's sample rate; null if unknown. */
+    position_seconds: number | null;
+    /**
+     * The slot's four colour bytes as one big-endian unsigned 32-bit value.
+     * Which byte is which channel is NOT confirmed — see decodeCues.
+     */
+    colour: number;
+}
+/** The track's main cue (the CUE button), which lives in the quickCues blob. */
+export interface MainCue {
+    position_samples: number | null;
+    position_seconds: number | null;
+    /**
+     * The second of the blob's two main-cue doubles. Read as Engine's stored
+     * default, before any adjustment — see `is_adjusted` on why that reading is
+     * inferred rather than measured.
+     */
+    default_samples: number | null;
+    /**
+     * The single byte between the two main-cue doubles, as a boolean.
+     *
+     * Not verified: that "adjusted" is what the byte means. Its *position* is
+     * pinned (the layout parses to the last byte on all 281 blobs, and moving
+     * this byte would misalign the double after it), and it is 0 or 1 with no
+     * other value seen. The name comes from a correlation that mostly holds
+     * and does not quite: the byte is set on 10 of the 281 real blobs, and on
+     * 8 of those the two doubles differ — but on 2 it is set while they are
+     * identical, and on 17 more the doubles differ with the byte clear (25
+     * differ in total). Treat it as "a flag Engine sets about the main cue",
+     * not as a measured meaning.
+     */
+    is_adjusted: boolean;
+}
+export interface Loop {
+    index: number;
+    label: string;
+    start_samples: number;
+    end_samples: number;
+    start_seconds: number | null;
+    end_seconds: number | null;
+}
+export interface BeatAnchor {
+    /** Sample offset of the anchor; may be negative (Engine anchors before 0). */
+    sample: number;
+    /** Beat number at that sample; may be negative for the same reason. */
+    beat: number;
+    seconds: number | null;
+}
+export type CuesResult = Decoded<Cue, {
+    slots: number;
+    main_cue: MainCue;
+}>;
+export type LoopsResult = Decoded<Loop, {
+    slots: number;
+}>;
+export type BeatgridResult = Decoded<BeatAnchor, {
+    sample_rate: number;
+    sample_count: number;
+    duration_seconds: number;
+    /** Tempo implied by the anchors, or null if fewer than two anchors. */
+    bpm: number | null;
+    /**
+     * Which of the blob's two grids `items` holds: always the second one.
+     *
+     * Not verified: that "adjusted" is Engine's own name for it. That the
+     * second grid is the one Engine plays *is* measured — on 30 of the 281
+     * real blobs the two grids differ, and on seven of those the first runs
+     * at exactly half `Track.bpmAnalyzed` while the second matches it. The
+     * word is the standard one for that role in the reverse-engineering
+     * literature, not a string read out of the blob.
+     */
+    grid: "adjusted";
+}>;
+export type WaveformSummary = {
+    layout: LayoutStatus;
+} & ({
+    status: "ok";
+    /** How many peak values `profile` holds — one per bucket. */
+    peaks: number;
+    /** Waveform points the blob carries (1024 in every blob measured). */
+    entries: number;
+    /** Audio samples each point covers; entries × this is the track length. */
+    samples_per_entry: number;
+    /** Size of the decompressed waveform blob, in bytes. */
+    bytes: number;
+    /** Track length in seconds, from Track.length; null when unknown. */
+    duration_seconds: number | null;
+    profile: number[];
+} | {
+    status: "empty";
+} | {
+    status: "unsupported";
+    detail: string;
+    bytes: number;
+} | {
+    status: "corrupt";
+    detail: string;
+});
+/**
+ * quickCues — qCompress frame, big-endian, 129 bytes inflated for a track
+ * whose cue labels are all empty:
+ *
+ *   int64  slot count                                     (8 bytes, always 8)
+ *   per slot:  uint8 label length, label bytes,
+ *              float64 sample offset (-1.0 = slot unused),
+ *              4 colour bytes                    (13 bytes with an empty label)
+ *   float64 main cue, uint8 main-cue-adjusted flag, float64 default main cue
+ *                                                                   (17 bytes)
+ *
+ * Evidence. 8 + 8×13 + 17 = 129, the size of 278 of the 281 real blobs, and
+ * every one parsed to exactly its last byte. The remaining three inflate to
+ * 134: 5 bytes longer because one slot carries the 5-character label
+ * "Cue 8", which is only consistent with a *variable*-length slot — a
+ * fixed-stride layout cannot produce two sizes. The -1.0 sentinel appears at
+ * the offset this layout predicts in all 2245 unused slots, so the 13-byte
+ * stride is confirmed 2245 times over, not once. The three populated slots
+ * decode to 244.94 s of a 300 s track and 0.05 s of a 369 s track — inside
+ * the track, which a wrong offset would not be. The main-cue triple's first
+ * double distributes as: 122 blobs at the -1.0 sentinel, 51 at exactly 0,
+ * 105 at a positive offset inside the track, and 3 slightly negative — two
+ * at -1.455e-11 samples and one at -598.8 samples (-0.0136 s), all three
+ * within a beat of zero rather than anywhere random, which is what a
+ * misaligned read would produce. Its two doubles differ from each other on
+ * 25 tracks, which they could not if the layout had merged one field with
+ * its neighbour.
+ *
+ * Not verified: which of the four colour bytes is which channel. Reading
+ * them as (alpha, red, green, blue) makes the one slot carrying an unedited
+ * Engine default agree with djinterop's `pad_8` constant {0x15, 0x8E, 0xE2}
+ * on red and blue but not green, and the alternative reading gives a cue
+ * marker 12% opaque, so alpha-first is likely — but "likely" is not
+ * measured, and two colours from two tracks cannot settle it. The bytes are
+ * therefore reported as stored, as one big-endian u32, with no channel
+ * claim attached.
+ */
+export declare function decodeCues(buf: Buffer | null, sampleRate?: number | null): CuesResult;
+/**
+ * Whether this track actually has a hot cue set — the question "which tracks
+ * still need cue points?" is really asking.
+ *
+ * It exists because the cheap SQL answer is not an answer at all. Engine
+ * writes a full eight-slot `quickCues` blob to every analysed track whether
+ * or not a pad is used, so `length(quickCues) > 0` is true for all 281 blobs
+ * in the reference library while exactly 3 of them (two tracks, one of which
+ * is exported to a second library) hold a cue. A check that structurally
+ * cannot report a problem is worse than no check: it answers "none of your
+ * tracks need cue points" for a library where 255 of 257 do.
+ *
+ * The main cue is deliberately excluded. It is set on 159 of the 281 blobs,
+ * including all 71 tracks the library records as played and 88 that it does
+ * not — Engine writes it as a playback start marker, not as something a DJ
+ * placed. Counting it would make this flag answer a third question, closer
+ * to "has this been loaded on a deck" than to "has a cue been set".
+ *
+ * A blob that fails to decode answers `false`: an undecodable blob is not
+ * evidence that a cue exists, and the direction that errs toward flagging a
+ * track for a human to look at is the safe one for an audit.
+ */
+export declare function hasCueSet(buf: Buffer | null): boolean;
+/**
+ * loops — 192 raw bytes, uncompressed and unframed, little-endian:
+ *
+ *   int64  slot count                                     (8 bytes, always 8)
+ *   per slot:  uint8 label length, label bytes,
+ *              float64 start, float64 end (-1.0 = slot unused),
+ *              uint8 start-set, uint8 end-set, 4 colour bytes
+ *                                                (23 bytes with an empty label)
+ *
+ * Evidence for the framing and the slot grid: 8 + 8×23 = 192, the size of
+ * all 281 real blobs, every one of which parsed to exactly its last byte;
+ * the little-endian count reads as 8, and the little-endian -1.0 sentinel
+ * (`000000000000f0bf`) appears at the offsets this layout predicts in all
+ * 2248 slots. Reading the count big-endian gives 134217728, which is what
+ * made every real track decode as `unsupported` before.
+ *
+ * This layout keeps `layout: "unverified"`. Not one of the 2248 slots is
+ * populated — this library has no saved loops — so while the slot grid is
+ * pinned down by 2248 sentinels, the six bytes after each slot's two doubles
+ * are zero everywhere, and nothing here distinguishes start/end from
+ * end/start, or fixes the order of the flag and colour bytes. A populated
+ * loop is the one thing the available data cannot exercise, so it is not
+ * claimed as verified.
+ */
+export declare function decodeLoops(buf: Buffer | null, sampleRate?: number | null): LoopsResult;
+/**
+ * beatData — qCompress frame, 138 bytes inflated on every track measured,
+ * and mixed-endian:
+ *
+ *   float64 BE sample rate
+ *   float64 BE sample count
+ *   uint8      beat data present
+ *   int64   BE default-grid marker count, then that many markers
+ *   int64   BE adjusted-grid marker count, then that many markers
+ *   9 trailing bytes (zero on every track measured)
+ *
+ * A marker is 24 bytes and little-endian: float64 sample offset, int64 beat
+ * number, int32 beats until the next marker, int32 unknown.
+ *
+ * Evidence. 17 + 8 + 2×24 + 8 + 2×24 + 9 = 138 for all 281. The two leading
+ * doubles read big-endian as 44100 (276 tracks) or 48000 (5); read the other
+ * way they are denormals. sample count ÷ sample rate equals `Track.length`
+ * to within a second for all 281 — a check on both doubles at once that no
+ * other offset or endianness passes. Within a grid, the beat numbers of
+ * consecutive markers differ by exactly the preceding marker's "beats until
+ * next" field on all 281, which pins the marker stride and three of its four
+ * fields simultaneously. The tempo implied by the adjusted grid's first and
+ * last anchor matches `Track.bpmAnalyzed` to within 0.5 BPM on all 281 —
+ * across tempos from 102 to 170 and durations from 92 s to 602 s, a
+ * prediction a wrong offset or a wrong endianness has no way to satisfy.
+ *
+ * `items` holds the *adjusted* grid, which is what Engine plays. That choice
+ * is itself measured, not stylistic: the two grids are byte-identical on 251
+ * tracks and differ on 30, and on seven of those the default grid runs at
+ * exactly half `bpmAnalyzed` (85.0000 against 170, 80.0000 against 160)
+ * while the adjusted grid matches it. The trailing int32 of each marker is
+ * read and discarded:
+ * it holds 0-12 on first markers and 1 or 2 on last ones, with two tracks
+ * carrying values that look like float bit patterns, and nothing in the
+ * library explains it. Reporting a field nobody can interpret would be
+ * padding a model's context with noise.
+ */
+export declare function decodeBeatgrid(buf: Buffer | null): BeatgridResult;
+/**
+ * overviewWaveFormData — qCompress frame, big-endian header, 3099 bytes
+ * inflated on every track measured:
+ *
+ *   int64 BE   number of waveform points
+ *   int64 BE   the same number again
+ *   float64 BE audio samples per point
+ *   three bytes per point (three band levels)
+ *   three trailing bytes: the maximum of each band over the whole track
+ *
+ * Evidence. Both counts read 1024 on all 281 blobs, and 24 + 3×1024 + 3 =
+ * 3099 accounts for every byte. The overview is a fixed 1024 points
+ * regardless of track length, so it is the *spacing* that scales with
+ * duration, not the size: samples-per-point × 1024 equals the sample count
+ * in `beatData` on all 281 — for a 345-second track that is 14858.0 × 1024 =
+ * 15214592 samples, the same value beatData carries. The three trailing
+ * bytes equal the per-band maximum computed over the 1024 points on all 281,
+ * a prediction with 255³ ways to fail per track that failed on none. That
+ * last check is what makes the three-bytes-per-point *stride* measured
+ * rather than assumed, and it is why this field carries `layout: "verified"`
+ * like cues and the beatgrid.
+ *
+ * Not verified: that the three bytes per point are the low, mid and high
+ * bands, in that order. Three parallel level channels is what the byte
+ * evidence shows; naming them is a reading of Engine's own display, and
+ * nothing in the library distinguishes one ordering from another. Nothing
+ * downstream depends on it — `profile` takes the loudest of the three,
+ * which is order-independent — so the naming is kept out of the response
+ * rather than asserted in it.
+ *
+ * The raw waveform is never returned to the model; it is reduced to a coarse
+ * per-bucket profile (loudest band value in the bucket, normalised to 0..1).
+ * That bucketing now runs over the waveform points rather than over the
+ * decompressed bytes, which previously mixed the 24-byte header and the
+ * trailing maxima into the first and last buckets.
+ *
+ * `duration_seconds` still comes from Track.length rather than from the
+ * blob: the overview carries a sample *count* but no sample rate, so a
+ * duration derived from it alone would be a guess.
+ */
+export declare function summariseWaveform(buf: Buffer | null, buckets?: number, durationSeconds?: number | null): WaveformSummary;
+export interface PerformanceRow {
+    quickCues: Buffer | null;
+    loops: Buffer | null;
+    beatData: Buffer | null;
+    overviewWaveFormData: Buffer | null;
+    /** Track.length in seconds, if known; reported by the waveform summary. */
+    durationSeconds?: number | null;
+}
+/**
+ * Decodes every PerformanceData field independently. A failure in one field
+ * (e.g. a corrupt beatgrid) never prevents the others from decoding — each
+ * carries its own status rather than the call as a whole throwing or failing.
+ *
+ * The one dependency between fields is the sample rate, which only beatData
+ * carries and which cue and loop offsets need to become seconds. It is
+ * passed in as a value, so a beatData that fails to decode costs the cues
+ * their `position_seconds` and nothing else: `position_samples` is still
+ * reported, and the cue list still decodes.
+ */
+export declare function decodePerformance(row: PerformanceRow): {
+    sample_rate: number | null;
+    cues: CuesResult;
+    loops: LoopsResult;
+    beatgrid: BeatgridResult;
+    waveform_summary: WaveformSummary;
+};