Add E_PaintBrush.sc DMX/Network: store in layers and status control

Doc updates

Live scripts
==========
- Add E_PaintBrush.sc

Backend
=======
- Live scripts: add drawLine3D and blur2D and sqrt, file Update: no requestUIUpdate
- LayerManager: check for old style presets
- DMX in / Network in: store layers in virtualChannels
- Network in/out: add status

Author: ewowi

CLAUDE.md

@@ -161,3 +161,11 @@ MoonLight periodically merges upstream ESP32-sveltekit changes. To keep merges c
 **Memory** — On S3/P4 with PSRAM, `operator new` is overridden in `main.cpp` to prefer PSRAM for allocations above a threshold. On ESP32-D0 (no PSRAM), heap is very tight; watch flash usage too (target <3MB firmware).
 
 **Logging** — Use `EXT_LOGD` / `EXT_LOGI` / `EXT_LOGW` / `EXT_LOGE` (not `Serial.printf` directly in module/node code). Tag constants: `ML_TAG` (MoonLight), `MB_TAG` (MoonBase).
+
+## Additional Reference Documents
+
+Supplementary guidance for AI assistants lives in `/misc/instructions/`:
+
+- **`MoonLight.md`** — project philosophy, architectural goals, future roadmap, and broader context not covered above.
+- **`GEMINI.md`** — structural overview of the upstream [ESP32-sveltekit](https://github.com/theelims/ESP32-sveltekit) repo (services, file layout, key dependencies). Useful when touching upstream-derived code.
+- **`svelte.instructions.md`** — Svelte 5 development guidelines. Applies **only** to moonbase-specific frontend files (`src/routes/moonbase/`, `src/lib/components/moonbase/`, `moonbase_utilities.ts`, `moonbase_models.ts`). Do not apply runes patterns or reformatting to upstream files.

docs/moonlight/drivers.md

@@ -113,10 +113,10 @@ Sends pixel data over the network to LED controllers and DMX fixtures. Supports
 * **FPS Limiter**: Maximum frames per second sent. Art-Net spec recommends ~44 FPS; higher rates (up to ~130 FPS tested) work with most controllers.
 * **Universe size**: Channels per universe (max 512). Match the setting on your controller.
 * **Used channels** *(read-only)*: Channels actually used per universe after rounding down to a whole number of lights (e.g. 510 for RGB at 512-channel universes). Always at least one light's worth of channels — if **Universe size** is set smaller than the channels per light, one full light is still included per universe.
-* **#Outputs per IP**: Number of physical outputs per controller. When all outputs for one IP are filled, sending continues on the next IP.
-* **Universes per output**: How many universes each output handles, determining the maximum lights per output.
+* **#Outputs per IP**: Number of physical outputs per controller. When all outputs for one IP are filled, sending continues on the next IP. E.g. the Club Lights 12 Pro Artnet Controller (see below) has 12 outputs.
+* **Universes per output**: How many universes each output handles, determining the maximum lights per output. (check total universes)
 * **Total universes** *(read-only)*: Universes required to transmit all lights.
-* **Channels per output**: Channel budget per output.
+* **Channels per output**: Channel budget per output. Make sure it matches the number of lights per output (check total channels)
 * **Total channels** *(read-only)*: Total channels sent across all outputs and IPs.
 
 !!! tip "Controller settings"

docs/moonlight/effects-tutorial.md

@@ -266,8 +266,6 @@ void loop() {
 }
 ```
 
-... watchdog due to expensive inoise8 function, only on cube, not on panel ...
-
 Each slice through the cube looks like a shifting 2D noise field. The z offset in the noise coordinates makes adjacent layers look related but distinct — like a 3D fire or fog.
 
 ![E_Noise3D](../media/moonlight/effects/E_Noise3D.gif)

livescripts/Effects/E_PaintBrush.sc

@@ -0,0 +1,51 @@
+// E_PaintBrush.sc - Paintbrush
+// Audio-reactive animated lines driven by beatsin8 and audio bands.
+// Works in 2D (drawLine) and 3D (drawLine3D) based on the layer depth.
+// oscillatorOffset: speed of oscillation (1-16)
+// numLines: number of simultaneous lines (1-40)
+// fadeRate: trail fade speed (0=no fade, 128=fast)
+// original idea: @TroyHacks
+
+uint8_t oscillatorOffset = 4;
+uint8_t numLines = 20;
+uint8_t fadeRate = 40;
+
+void setup() {
+  addControl(&oscillatorOffset, "oscillatorOffset", "slider", 1, 16);
+  addControl(&numLines, "numLines", "slider", 1, 40);
+  addControl(&fadeRate, "fadeRate", "slider", 0, 128);
+}
+
+uint8_t hue = 0;
+
+void loop() {
+  hue++;
+  fadeToBlackBy(fadeRate);
+
+  for (uint8_t i = 0; i < numLines; i++) {
+    uint8_t bin  = i * 16 / numLines;
+    uint8_t band = bands[bin];
+
+    uint8_t x1 = beatsin8(oscillatorOffset * 1 + band / 16, 0, width - 1,  band, 0);
+    uint8_t x2 = beatsin8(oscillatorOffset * 2 + band / 16, 0, width - 1,  band, 0);
+    uint8_t y1 = beatsin8(oscillatorOffset * 3 + band / 16, 0, height - 1, band, 0);
+    uint8_t y2 = beatsin8(oscillatorOffset * 4 + band / 16, 0, height - 1, band, 0);
+
+    CRGB color = ColorFromPalette(i * 255 / numLines + hue, 255);
+
+    if (depth > 1) {
+      uint8_t z1 = beatsin8(oscillatorOffset * 5 + band / 16, 0, depth - 1, band, 0);
+      uint8_t z2 = beatsin8(oscillatorOffset * 6 + band / 16, 0, depth - 1, band, 0);
+      float dx = x2 - x1;
+      float dy = y2 - y1;
+      float dz = z2 - z1;
+      float len = sqrt(dx * dx + dy * dy + dz * dz);
+      if (len > 1) drawLine3D(x1, y1, z1, x2, y2, z2, color);
+    } else {
+      float dx = x2 - x1;
+      float dy = y2 - y1;
+      float len = sqrt(dx * dx + dy * dy);
+      if (len > 1) drawLine(x1, y1, x2, y2, color);
+    }
+  }
+}

misc/instructions/MoonLight.md

@@ -30,4 +30,4 @@
     - MoonLight should run on all ESP32 devices. Mainly used and tested now on ESP32-D0 (standard dev MCU’s), ESP32-S3 and ESP32-P4. Running MoonLight on ESP32-D0 is a challenge as heap is pretty much used up, and Flash size is limited. We currently use a 3MB flash partition so 4MB boards cannot do OTA at the moment. In the future we plan to implement a minimal OTA partition (as investigated at Tasmota/ESPHome …), so also small flash size boards (4MB) can do OTA.
     - Optimize on the critical process: running effects / modifiers (producers) and displaying them on leds (direct via pins on the board using led drivers or via Art-Net over the network). So code for the critical process should compile to minimal assembler code and checks on code should be minimal. (Example use int instead of unsigned int as no need to control if it is negative if the developer should ensure it is possible, or do not check if a const char * is null as it’s the developer responsibility to make sure this is the case). In short: the code should not be resilient to developer mistakes, the developer must solve the mistakes.
     - Non critical processes can run in reasonable time, in general 20ms response time for UI is more than enough.
-    - See also GIMINI.md in /misc/parking for info about upstream sveltekit
+    - See also GEMINI.md in /misc/instructions for info about upstream sveltekit

misc/instructions/svelte.instructions.md

@@ -0,0 +1,220 @@
+---
+description: 'Svelte 5 and SvelteKit development standards and best practices for component-based user interfaces and full-stack applications'
+applyTo: '**/*.svelte, **/*.ts, **/*.js, **/*.css, **/*.scss, **/*.json'
+---
+
+(original https://github.com/github/awesome-copilot/blob/main/instructions/svelte.instructions.md)
+
+# Svelte 5 and SvelteKit Development Instructions
+
+Instructions for building high-quality Svelte 5 and SvelteKit applications with modern runes-based reactivity, TypeScript, and performance optimization.
+
+## MoonLight-Specific Constraints
+
+> **Important:** MoonLight periodically merges upstream [ESP32-sveltekit](https://github.com/theelims/ESP32-sveltekit) changes. Upstream files use Svelte stores (not runes) and must **not** be reformatted or modernised to avoid merge conflicts.
+>
+> Apply these guidelines **only** to MoonLight-specific files:
+> - `interface/src/routes/moonbase/`
+> - `interface/src/lib/components/moonbase/`
+> - `interface/src/lib/stores/moonbase_utilities.ts`
+> - `interface/src/lib/types/moonbase_models.ts`
+>
+> Do **not** migrate upstream files to runes, reformat them, or change their store patterns.
+
+## Project Context
+- Svelte 5.x with runes system ($state, $derived, $effect, $props, $bindable) — moonbase-specific files only
+- SvelteKit for full-stack applications with file-based routing
+- TypeScript for type safety and better developer experience
+- Component-scoped styling with CSS custom properties
+- Progressive enhancement and performance-first approach
+- Modern build tooling (Vite) with optimizations
+
+## Core Concepts
+
+### Architecture
+- Use Svelte 5 runes system for all reactivity instead of legacy stores
+- Organize components by feature or domain for scalability
+- Separate presentation components from logic-heavy components
+- Extract reusable logic into composable functions
+- Implement proper component composition with slots and snippets
+- Use SvelteKit's file-based routing with proper load functions
+
+### Component Design
+- Follow single responsibility principle for components
+- Use `<script lang="ts">` with runes syntax as default
+- Keep components small and focused on one concern
+- Implement proper prop validation with TypeScript annotations
+- Use `{#snippet}` blocks for reusable template logic within components
+- Use slots for component composition and content projection
+- Pass `children` snippet for flexible parent-child composition
+- Design components to be testable and reusable
+
+## Reactivity and State
+
+### Svelte 5 Runes System
+- Use `$state()` for reactive local state management
+- Implement `$derived()` for computed values and expensive calculations
+- Use `$derived.by()` for complex computations beyond simple expressions
+- Use `$effect()` sparingly - prefer `$derived` or function bindings for state sync
+- Implement `$effect.pre()` for running code before DOM updates
+- Use `untrack()` to prevent infinite loops when reading/writing same state in effects
+- Define component props with `$props()` and destructuring with TypeScript annotations
+- Use `$bindable()` for two-way data binding between components
+- Migrate from legacy stores to runes for better performance
+- Override derived values directly for optimistic UI patterns (Svelte 5.25+)
+
+### State Management
+- Use `$state()` for local component state
+- Implement type-safe context with `createContext()` helper over raw `setContext`/`getContext`
+- Use context API for sharing reactive state down component trees
+- Avoid global `$state` modules for SSR - use context to prevent cross-request data leaks
+- Use SvelteKit stores for global application state when needed
+- Keep state normalized for complex data structures
+- Prefer `$derived()` over `$effect()` for computed values
+- Implement proper state persistence for client-side data
+
+### Effect Best Practices
+- **Avoid** using `$effect()` to synchronize state - use `$derived()` instead
+- **Do** use `$effect()` for side effects: analytics, logging, DOM manipulation
+- **Do** return cleanup functions from effects for proper teardown
+- Use `$effect.pre()` when code must run before DOM updates (e.g., scroll position)
+- Use `$effect.root()` for manually controlled effects outside component lifecycle
+- Use `untrack()` to read state without creating dependencies in effects
+- Remember: async code in effects doesn't track dependencies after `await`
+
+## SvelteKit Patterns
+
+### Routing and Layouts
+- Use `+page.svelte` for page components with proper SEO
+- Implement `+layout.svelte` for shared layouts and navigation
+- Handle routing with SvelteKit's file-based system
+
+### Data Loading and Mutations
+- Use `+page.server.ts` for server-side data loading and API calls
+- Implement form actions in `+page.server.ts` for data mutations
+- Use `+server.ts` for API endpoints and server-side logic
+- Use SvelteKit's load functions for server-side and universal data fetching
+- Implement proper loading, error, and success states
+- Handle streaming data with promises in server load functions
+- Use `invalidate()` and `invalidateAll()` for cache management
+- Implement optimistic updates for better user experience
+- Handle offline scenarios and network errors gracefully
+
+### Forms and Validation
+- Use SvelteKit's form actions for server-side form handling
+- Implement progressive enhancement with `use:enhance`
+- Use `bind:value` for controlled form inputs
+- Validate data both client-side and server-side
+- Handle file uploads and complex form scenarios
+- Implement proper accessibility with labels and ARIA attributes
+
+## UI and Styling
+
+### Styling
+- Use component-scoped styles with `<style>` blocks
+- Implement CSS custom properties for theming and design systems
+- Use `class:` directive for conditional styling
+- Follow BEM or utility-first CSS conventions
+- Implement responsive design with mobile-first approach
+- Use `:global()` sparingly for truly global styles
+
+### Transitions and Animations
+- Use `transition:` directive for enter/exit animations (fade, slide, scale, fly)
+- Use `in:` and `out:` for separate enter/exit transitions
+- Implement `animate:` directive with `flip` for smooth list reordering
+- Create custom transitions for branded motion design
+- Use `|local` modifier to trigger transitions only on direct changes
+- Combine transitions with keyed `{#each}` blocks for list animations
+
+## TypeScript and Tooling
+
+### TypeScript Integration
+- Enable strict mode in `tsconfig.json` for maximum type safety
+- Annotate props with TypeScript: `let { name }: { name: string } = $props()`
+- Type event handlers, refs, and SvelteKit's generated types
+- Use generic types for reusable components
+- Leverage `$types.ts` files generated by SvelteKit
+- Implement proper type checking with `svelte-check`
+- Use type inference where possible to reduce boilerplate
+
+### Development Tools
+- Use ESLint with eslint-plugin-svelte and Prettier for code consistency
+- Use Svelte DevTools for debugging and performance analysis
+- Keep dependencies up to date and audit for security vulnerabilities
+- Document complex components and logic with JSDoc
+- Follow Svelte's naming conventions (PascalCase for components, camelCase for functions)
+
+## Production Readiness
+
+### Performance Optimization
+- Use keyed `{#each}` blocks for efficient list rendering
+- Implement lazy loading with dynamic imports and `<svelte:component>`
+- Use `$derived()` for expensive computations to avoid unnecessary recalculations
+- Use `$derived.by()` for complex derived values that require multiple statements
+- Avoid `$effect()` for derived state - it's less efficient than `$derived()`
+- Leverage SvelteKit's automatic code splitting and preloading
+- Optimize bundle size with tree shaking and proper imports
+- Profile with Svelte DevTools to identify performance bottlenecks
+- Use `$effect.tracking()` in abstractions to conditionally create reactive listeners
+
+### Error Handling
+- Implement `+error.svelte` pages for route-level error boundaries
+- Use try/catch blocks in load functions and form actions
+- Provide meaningful error messages and fallback UI
+- Log errors appropriately for debugging and monitoring
+- Handle validation errors in forms with proper user feedback
+- Use SvelteKit's `error()` and `redirect()` helpers for proper responses
+- Track pending promises with `$effect.pending()` for loading states
+
+### Testing
+- Write unit tests for components using Vitest and Testing Library
+- Test component behavior, not implementation details
+- Use Playwright for end-to-end testing of user workflows
+- Mock SvelteKit's load functions and stores appropriately
+- Test form actions and API endpoints thoroughly
+- Implement accessibility testing with axe-core
+
+### Security
+- Sanitize user inputs to prevent XSS attacks
+- Use `@html` directive carefully and validate HTML content
+- Implement proper CSRF protection with SvelteKit
+- Validate and sanitize data in load functions and form actions
+- Use HTTPS for all external API calls and production deployments
+- Store sensitive data securely with proper session management
+
+### Accessibility
+- Use semantic HTML elements and proper heading hierarchy
+- Implement keyboard navigation for all interactive elements
+- Provide proper ARIA labels and descriptions
+- Ensure color contrast meets WCAG guidelines
+- Test with screen readers and accessibility tools
+- Implement focus management for dynamic content
+
+### Deployment
+- Use environment variables for configuration across different deployment stages
+- Implement proper SEO with SvelteKit's meta tags and structured data
+- Deploy with appropriate SvelteKit adapter based on hosting platform
+
+## Implementation Process
+1. Initialize SvelteKit project with TypeScript and desired adapters
+2. Set up project structure with proper folder organization
+3. Define TypeScript interfaces and component props
+4. Implement core components with Svelte 5 runes
+5. Add routing, layouts, and navigation with SvelteKit
+6. Implement data loading and form handling
+7. Add styling system with custom properties and responsive design
+8. Implement error handling and loading states
+9. Add comprehensive testing coverage
+10. Optimize performance and bundle size
+11. Ensure accessibility compliance
+12. Deploy with appropriate SvelteKit adapter
+
+## Common Patterns
+- Renderless components with slots for flexible UI composition
+- Custom actions (`use:` directives) for cross-cutting concerns and DOM manipulation
+- `{#snippet}` blocks for reusable template logic within components
+- Type-safe context with `createContext()` for component tree state sharing
+- Progressive enhancement for forms and interactive features with `use:enhance`
+- Server-side rendering with client-side hydration for optimal performance
+- Function bindings (`bind:value={() => value, setValue}`) for two-way binding
+- Avoid `$effect()` for state synchronization - use `$derived()` or callbacks instead

platformio.ini

@@ -57,7 +57,7 @@ build_flags =
     -D BUILD_TARGET=\"$PIOENV\"
     -D APP_NAME=\"MoonLight\" ; 🌙 Must only contain characters from [a-zA-Z0-9-_] as this is converted into a filename
     -D APP_VERSION=\"0.9.1\" ; semver compatible version string
-    -D APP_DATE=\"20260402\" ; 🌙
+    -D APP_DATE=\"20260403\" ; 🌙
 
     -D PLATFORM_VERSION=\"pioarduino-55.03.37\" ; 🌙 make sure it matches with above plaftform
 

src/MoonBase/LiveScriptNode.cpp

@@ -75,9 +75,11 @@ static void _setPalEntryHSV(uint8_t index, uint8_t h, uint8_t s, uint8_t v) { if
 static void _setHSV(uint16_t indexV, uint8_t h, uint8_t s, uint8_t v) { currentNode()->layer->setRGB(indexV, CHSV(h, s, v)); }
 static void _setHSVXY(int x, int y, uint8_t h, uint8_t s, uint8_t v) { currentNode()->layer->setRGB(Coord3D{x, y}, CHSV(h, s, v)); }
 
-// 2D drawing
+// 2D/3D drawing
 static void _drawLine(uint8_t x0, uint8_t y0, uint8_t x1, uint8_t y1, CRGB color) { currentNode()->layer->drawLine(x0, y0, x1, y1, color); }
+static void _drawLine3D(uint8_t x1, uint8_t y1, uint8_t z1, uint8_t x2, uint8_t y2, uint8_t z2, CRGB color) { currentNode()->layer->drawLine3D(x1, y1, z1, x2, y2, z2, color); }
 static void _drawCircle(int cx, int cy, uint8_t radius, CRGB color) { currentNode()->layer->drawCircle(cx, cy, radius, color, false); }
+static void _blur2d(uint8_t blur_amount) { currentNode()->layer->blur2d(blur_amount); }
 
 // time of day
 static uint8_t _lsHour = 0;
@@ -181,6 +183,7 @@ void LiveScriptNode::setup() {
   addExternal("uint8_t inoise8(uint16_t,uint16_t,uint16_t)", (void*)(uint8_t (*)(uint16_t, uint16_t, uint16_t))inoise8);
   addExternal("uint8_t beatsin8(uint16_t,uint8_t,uint8_t,uint32_t,uint8_t)", (void*)beatsin8);
   addExternal("uint8_t beatsin16(uint16_t,uint16_t,uint16_t,uint32_t,uint8_t)", (void*)beatsin16);
+  addExternal("float sqrt(float)", (void*)(float (*)(float))sqrtf);
   addExternal("float hypot(float,float)", (void*)(float (*)(float, float))hypot);
   addExternal("uint8_t beat8(uint16_t,uint32_t)", (void*)(uint8_t (*)(uint16_t, uint32_t))beat8);  // saw wave
   addExternal("uint8_t triangle8(uint8_t)", (void*)triangle8);
@@ -229,9 +232,11 @@ void LiveScriptNode::setup() {
   addExternal("int gravityY", &sharedData.gravity.y);
   addExternal("int gravityZ", &sharedData.gravity.z);
 
-  // 2D drawing
+  // 2D/3D drawing
   addExternal("void drawLine(uint8_t,uint8_t,uint8_t,uint8_t,CRGB)", (void*)_drawLine);
+  addExternal("void drawLine3D(uint8_t,uint8_t,uint8_t,uint8_t,uint8_t,uint8_t,CRGB)", (void*)_drawLine3D);
   addExternal("void drawCircle(int,int,uint8_t,CRGB)", (void*)_drawCircle);
+  addExternal("void blur2d(uint8_t)", (void*)_blur2d);
 
   // time of day
   _updateTime();