MultiPROG-Ultimate-Kit/01_Knowledge_Base/MULTIPROG_ARCHITECTURE.md

Multi-PROG Architecture and Script Execution Model

This article expands on the platform model summarized in 01_Knowledge_Base/README.md. It is written from public manuals/tutorials plus general embedded-tooling knowledge, and marks anything host-specific as unverified.

Two execution surfaces

Multi-PROG scripting exposes two related but distinct surfaces:

Local Script

• The authoring/editing surface: create, open, modify, save, run, and debug a script directly inside the running Multi-PROG instance.
• Intended for development and one-off/bench use. A Local Script is not automatically visible to other users or other installs.
• The built-in Help attached to the Local Script editor is the authoritative, version-specific API reference (see 01_Knowledge_Base/README.md → "Recommended development lifecycle", step 2). Nothing in this repository substitutes for that Help; everything here is discovery notes pending verification.

Released Feature

• The distribution/consumption surface: a script that has gone through some form of packaging/"release" step becomes importable and runnable by other Multi-PROG users without needing the source open in the Local Script editor.
• Implies a lifecycle boundary: Local Script (mutable, source visible, debuggable) → Released Feature (packaged, distributed, run-only from the consumer's point of view).

Script execution model (working model, unverified in detail)

1. Load — the script module is loaded by the host process running inside/alongside Multi-PROG.
2. Registration phase — top-level script code runs once; this is where UI registration such as AddFunctionButton (see 17_MultiPROG_SDK/docs/UI_API.md) is expected to happen.
3. Idle — after registration, the script is inert until the operator interacts with a registered control (e.g. clicks a toolbar button).
4. Callback execution — a callback runs synchronously (assumed; unconfirmed) in response to the UI interaction, with access to whatever device/buffer context the host currently has selected.
5. Teardown — unconfirmed whether scripts receive any unload/cleanup hook, or whether unloading is purely host-managed (e.g. on closing Multi-PROG or unloading the script).

This maps directly onto the 6-step lifecycle already documented in 18_Documentation/MULTIPROG_SCRIPT_LIFECYCLE.md (research → offline prototype → synthetic validation → host adaptation → test/document → release/archive) — that document covers the development process; this article covers the runtime model the developed script eventually executes under.

Script deployment, locking, and publishing (conceptual)

Public tutorials and the manual mirrors referenced in 02_Resource_Catalog/links.csv describe — without full technical detail — that scripts can be:

• Locked — distributed in a form that prevents casual viewing/editing of the source, presumably to protect author IP when sharing a Released Feature. Exact mechanism (obfuscation vs. a real lock/permission flag vs. compiled bytecode) is unconfirmed.
• Published — made available as a Released Feature for import by other users, as distinct from keeping it as a private Local Script.

Practical implication for this repository

Because "locked" script internals cannot be inspected without the original source, any locked/opaque script obtained from a forum or unknown-origin source (see 08_Collected_MultiPROG_Scripts/Unknown_Origin/) should be treated per the existing trust model in 01_Knowledge_Base/README.md ("Trust model for downloads") — do not run an opaque locked script against a production module without independently understanding its effect, e.g. by testing on a spare/synthetic target first.

Released Features system vs. Local Script system — summary table

Aspect	Local Script	Released Feature
Source visibility	Full (editable)	Possibly locked/obfuscated (unconfirmed)
Intended audience	Author/developer	Other Multi-PROG operators
Debuggable	Yes (host debugger, per manual references)	Unconfirmed
Distribution	Manual (file sharing)	Through Multi-PROG's own release/import mechanism
Toolbar registration	Same AddFunctionButton mechanism assumed for both	Same (unconfirmed)

Open verification items

1. Exact mechanism and reversibility of script "locking."
2. Whether Released Features can call the same full API surface as Local Scripts, or a reduced subset.
3. Whether there is a script versioning/update mechanism once published.
4. Whether multiple Local Scripts can run concurrently, or only one at a time.

Related documents

• 01_Knowledge_Base/README.md — platform model summary and safety lifecycle
• 18_Documentation/MULTIPROG_SCRIPT_LIFECYCLE.md — development-process lifecycle
• 17_MultiPROG_SDK/docs/UI_API.md — AddFunctionButton reference
• 13_Research_Expansion/SCRIPT_DEVELOPMENT_GUIDE.md — recommended script structure