Hybrid OSI model graph for SavingCaustic DAW

march25.md

flowchart TD
    %% Define color styles
    classDef baseLayer fill:#d4f1f9,stroke:#05a,stroke-width:2px
    classDef coreLayer fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    classDef derivedLayer fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    classDef routerLayer fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    classDef platformLayer fill:#f5f5f5,stroke:#666,stroke-width:2px

    %% Platform Layer
    subgraph "Layer 1: Webview Container"
        L1["/static/frame.html"] --> Webview["Browser/WebView"]
        Webview --> Scaling["UI Scaling"]
    end
    class Layer1 platformLayer

    %% Base Layer
    subgraph "Interal Layers"
        subgraph "Layer 3: Internal UI"
            InternalUI["$lib/internal"] --> UIKnobs["Knob Components"]
            InternalUI --> UIButtons["Button Components"]
            InternalUI --> UISliders["Slider Components"]
        end

        subgraph "Layer 4: Module"
            L4["Module Files"] --> FunctionalUnits["Functional Units"]
            FunctionalUnits --> Synths["Synthesizers"]
            FunctionalUnits --> Effects["Audio Effects"]
            FunctionalUnits --> Processors["MIDI Processors"]
        end
    end
    class BaseLayer,Layer3,Layer4 baseLayer

    %% Derived Layer
    subgraph "External Layers"
        subgraph "Layer 5: Page / Module Host"
            L5["Page Files"] --> ModuleHost["Module Host"]
            ModuleHost --> StateData["State Management"]
            ModuleHost --> DynamicModules["Dynamic Module Loading"]
            ModuleHost --> LayoutManagement["Layout Management"]
        end

        subgraph "Layer 6: Window Manager"
            L6["Window Manager Files"] --> WindowSystem["Window System"]
            WindowSystem --> Modals["Modal Windows"]
            WindowSystem --> DraggableWindows["Draggable Windows"]
            WindowSystem --> Overlays["Overlays"]
        end

		%% Static Assets
    subgraph "Layer 2: Static Assets & Response APIs"
        Assets["Static Assets"] --> InteractionTypes
        CSS["CSS Stylesheet"] -- apply UI styles at build time --> WebApp
        WebApp["Browser DOM entry point app.html"] --> TouchEvents["Multitouch Events"]
        TouchEvents --> InteractionTypes["Touch Interaction Types"]
        InteractionTypes --> Knobs["Knobs (delta-X/Y)"]
        InteractionTypes --> Keys["Keys (on/off)"]
        InteractionTypes --> Sliders["Sliders"]
    end

    end
    class DerivedLayer,Layer2,Layer5,Layer6,Layer7 derivedLayer

    %% SvelteKit Router
    subgraph "SvelteKit"
        Router["Router"] --> Routes["+page.svelte"]
        Preprocessor -- serve static files on build --> Assets
        Router --> AppServerFiles
        Layouts --> WebSockets["WebSocket Communication"]
        Router --> Layouts["+layout.svelte"]
        Router --> APIRoutes["API Routes"]
        Routes --> DynamicRoutes["Dynamic Routes [slug]"]

		subgraph "Layer 7: App Definition"
            AppServerFiles["Web App Server"]
            AppServerFiles --> Navigation["Navigation Flow"]
            AppServerFiles --> UXConsistency["UX Consistency"]
        end
    end
    class SvelteKitRouter routerLayer

    %% C++ Backend
    subgraph "Core Layer: C++ Backend"
        CPP["C++ Engine"] --> AudioEngine["Audio Processing"]
        CPP --> MIDIEngine["MIDI Processing"]
        CPP --> SocketServer["WebSocket Server"]
    end
    class CoreLayerCBackend coreLayer

    %% Connections between elements
    Scaling -- guard for cross-platform responsiveness --> WebApp
    WebSockets <--> SocketServer
    TouchEvents --> InternalUI
    InternalUI --> FunctionalUnits
    FunctionalUnits --> ModuleHost
    ModuleHost --> Router
    WindowSystem --> ModuleHost
    Router --> ModuleHost
    CPP <--> L4

Loading

New Draft (March 17th 2025) of OSI Layers grouped into Web App parent-layer concerns

Note for @SavingCaustic : This diagram is my first attempt at making sense of this from a middleware (Sveltekit) and frontend UI (Svelte) point of view.

My main emphasis was separating Svelte and Sveltekit responsibilites. Feel free to ask further details to clear up everything. I'm unfamiliar with OSI communications model so I'd need your help on that end.

I suspect, in the end, it'd have to be a compromise between communications modelling and web server/browser client modelling to simplify this diagram into an actionable snapshot.

Redundancy

Layer 2 and Layer 7 might have too much overlap but that could also be me not knowing the OSI model.

Web App Build Questions (March 2025)

This is to try and save more time. Just some items to decide on ahead of building the middle and frontend, but don't let these questions rob us of any of the fun of just throwing things together.

Svelte 4 or 5?

Right now we're using Svelte 4 and you did mention you like the compiler-centric approach - Svelte 4 exemplifies that approach. I love it but it raises concerns about long-term support if code stops working. The Svelte ecosystem has already moved onto Svelte 5, including some third-party libraries we may want to make use of in the future.

There are also serious hidden concerns about Svelte 4 sometimes working off stale data (which Svelte 5 signals is meant to address). In a DAW that's heavy on event-management - that's a real concern where Svelte 5 may be the better answer.

What Should Manage the Web View + Touch Layers?

I didn't include it in the diagram but I'd consider adding either Capacitor.js or Tauri to handle UI scaling for all devices (desktop and mobile). Capacitor would be more lightweight than Tauri.

Alternatively, in a pure web app setup (just Svelte + Kit) there's Svelte Gestures library.

Should Sveltekit Handle the Routing?

I have a lot of love for Sveltekit and use it all the time but it's a file-base router for evaluating different +page.svelte routes at the end of the day. On the plus side, it also comes with a great number of preprocessing tasks like bundling and serving static files. So maybe Sveltekit IS what we're looking for.

On the flipside, in adapter-static mode we're only using one +page.svelte in the browser client. SK could be overkill.

There are alternative mini routers like Svelte Tiny Router where we'd just build the web app frontend with:

1. Single App.svelte parent component as the entry-point
2. All modules + child .svelte component configuration is handled by the tiny router

Hi and thanks for your reflections! Yes I realize i've got some Svelte 4 code in the project currently. I could pass the blame to ChatGPT who hasn't updated its recommendations to Svelte5. I took the tour in SvelteKit (that I thought i could be without - not needing SSR), but realize it's well worth understanding SvelteKit too. So update to Svelte 5 is on its way.

Regarding FE-layers, maybe work done in Firefox OS or Tizen could be relevant?

Sorry for the noob question, but that diagram - how do i zoom in on it?

hey! If you've worked on Tizen and Firefox previously then you're way ahead of me!

For Svelte 5 not having been trained into LLMs yet, I know what you mean. It's a frequently recurring thread on the Svelte Discord channels.

Two potential options for that:

1. LLM-friendly codified version of the Svelte docs: https://svelte.dev/docs/llms
2. ChatGPT specific Svelte docs to include in context: https://chatgpt.com/g/g-Knj6VxTpl-svelte-5-sveltekit-sage

I use Claude more than any other LLM so I can't say if either of the two options above are effective.

Sorry for the noob question, but that diagram - how do i zoom in on it?

No worries, I think I'm the one with a mermaid graph obsession.

It depends on the browser but usually on the Github website there should be controls in a bottom-right overlay on the diagram to move around and zoom in/out.

But honestly it's way more convenient to just copy the raw diagram code and paste it into a full-screen markdown editor (i mockup all my diagrams in Obsidian).

haha, no sorry haven't worked on neither of those places - just considering that they've might have concepts that one could jack in to. touch-interaction / display / events etc - Maybe back to Xerox PARC?! :) So finding the long-life concepts - and mapping those to Svelte bits. :)

haha, no sorry haven't worked on neither of those places - just considering that they've might have concepts that one could jack in to. touch-interaction / display / events etc - Maybe back to Xerox PARC?! :) So finding the long-life concepts - and mapping those to Svelte bits. :)

Ok gotcha, understood 👍