reasampler/src/app/CLAUDE.md

src/app — REAPER extension entry point

Scope

Contains only main.cpp. Since the Phase Q hoists (Q-W3 onward), this TU is ONLY pointers + entry + dispatch — the actual capture/panel/persist/action orchestration lives in shell/. main.cpp owns: receiving REAPER's dispatch struct (ReaperPluginEntry), resolving the REAPER API function pointers (REAPERAPI_LoadAPI), the globals other files reference via extern (g_hInst, g_rec), the ReaSamplerSession instance, its own bindable-action family via the Q-W6 data-driven registration table (shell/actions/action_registry), and invoking the other action families' (design_view / bank / ingest) own register/handle/unregister triples at load and unload.

Exactly one translation unit defines REAPERAPI_IMPLEMENT — that is main.cpp. Every other .cpp includes reaper_plugin_functions.h without the define and gets extern declarations for the global API function pointers.

See root CLAUDE.md's "REAPER extension contract" section for the full four-step action-registration contract (command_id / gaccel / hookcommand / unload mirror-unregister) that both this file's own action-table rows and the other families' register/handle/unregister triples follow.

Modules

• main.cpp — the REAPER extension's entry point and the sole REAPERAPI_IMPLEMENT TU; see root CLAUDE.md's "REAPER extension contract" section for the registration contract this file implements.

Gotchas

• This is intentionally a thin TU post-Phase-Q. Adding a new bindable action to main.cpp's own family means adding one row to its ActionTableRow table and a flat handler function — do not hand-roll a parallel register/hookcommand/unregister mechanism alongside the table.
• Never let a second .cpp define REAPERAPI_IMPLEMENT — that would double-allocate the global REAPER API function pointers.