From 56f2e3e30850b56198bb2db041ef8d0f07cced08 Mon Sep 17 00:00:00 2001 From: daniel-c-harvey Date: Thu, 23 Jul 2026 06:33:24 -0400 Subject: [PATCH] docs(design-view): parent visibility = descendant-derived OR own membership Untagged folder carrying its own FX/media shows in Arrange (its default) as well as any mode derived from its children. Parents still never parked. --- CONTEXT.md | 12 +++++++++--- docs/product/design-view.md | 24 ++++++++++++++++-------- 2 files changed, 25 insertions(+), 11 deletions(-) diff --git a/CONTEXT.md b/CONTEXT.md index 3d3db46..bc44626 100644 --- a/CONTEXT.md +++ b/CONTEXT.md @@ -197,9 +197,15 @@ enforces the separation **without ever destroying the user's real state.** - **Membership.** Default = Arrange; every untagged leaf belongs to it. Leaves **opt in** to Design (or any mode). No track appears in two modes at once except (a) via an explicit **show-both** toggle, or (b) parent/folder derivation. -- **Parents are derived, never tagged.** A parent appears in — and is never parked - in — every mode any of its descendant leaves belongs to. Rule of thumb: **tag - leaves; parents follow.** Master track is always visible and never touched. +- **Parents are derived, never tagged.** A parent/folder track is visible in mode M + if **either** (a) any descendant leaf is visible in M (descendant-derived), **or** + (b) the parent belongs to M by its **own membership** — and an untagged parent is + an Arrange member by default. So an untagged folder carrying its own FX/media + above all-Design leaves shows in **both** Arrange (its own default) and Design + (derived from its children). A parent is **never parked** in any mode it is visible + in. Rule of thumb: **tag leaves; parents follow** — the common case, since a + content-bearing folder still surfaces wherever its own membership places it. + Master track is always visible and never touched. - **N-mode model, two-mode UI.** The data model carries arbitrarily many modes; the UI ships **Arrange** + **Design**. A mode is (stable id, display name, ordinal). Arrange is special only as the default home for untagged leaves. diff --git a/docs/product/design-view.md b/docs/product/design-view.md index 8a02eac..480c473 100644 --- a/docs/product/design-view.md +++ b/docs/product/design-view.md @@ -90,10 +90,17 @@ home for untagged leaves — structurally it is just another mode. elsewhere. Untagged = Arrange. - **Leaves opt in.** You tag a *leaf* track into Design (or any mode). You never tag a parent. -- **Parents are derived, never tagged.** A folder/parent track appears in — and is - never parked in — every mode that *any* of its descendant leaves belongs to. If - a folder holds two Design leaves and one Arrange leaf, the folder shows in both - modes. Rule of thumb: **tag leaves; parents follow.** +- **Parents are derived, never tagged.** A folder/parent track's visibility is the + **OR of two sources**: (a) *descendant-derived* — it appears in every mode that + *any* of its descendant leaves belongs to; **or** (b) *its own membership* — an + untagged parent is an Arrange member by default, exactly like a leaf. If a folder + holds two Design leaves and one Arrange leaf, the folder shows in both modes by + descendant derivation. The case own-membership fixes: an **untagged folder that + carries its own FX/media** above leaves that are *all* tagged Design still shows in + **Arrange** (its own default) as well as Design (derived from its children) — + without the own-membership clause it would vanish from Arrange even though the + folder itself is an Arrange member. A parent is **never parked** in any mode it is + visible in. Rule of thumb: **tag leaves; parents follow** — still the common case. - **Master is always visible**, in every mode, and the tool never touches its flags. (REAPER's own SDK forbids driving `B_SHOWINTCP`/`B_SHOWINMIXER` on the master track — the invariant and the API agree.) @@ -101,10 +108,11 @@ home for untagged leaves — structurally it is just another mode. mode only via (a) the explicit *show-both* toggle, or (b) the parent-derivation rule above. Otherwise a leaf lives in exactly one mode. -The parent-derivation rule is why the pure model must be **folder-tree aware**. It -cannot answer "should this parent be visible in mode M?" from the membership index -alone — it needs the current parent↔child structure, which the shell reads from -REAPER's `I_FOLDERDEPTH` and feeds in. The tree is an *input* to the pure model's +The descendant-derived half of the parent rule is why the pure model must be +**folder-tree aware**. Own-membership (part b) is answerable from the membership +index alone, but descendant derivation (part a) is not — to know whether *any* child +leaf is visible in mode M, the model needs the current parent↔child structure, which +the shell reads from REAPER's `I_FOLDERDEPTH` and feeds in. The tree is an *input* to the pure model's visibility query, not something the model stores (folder structure is REAPER's truth and changes underneath us).