Skip to content

Commit 8785587

Browse files
committed
Update docs (layers, current status)
1 parent 5ad1ac8 commit 8785587

File tree

7 files changed

+12722
-12647
lines changed

7 files changed

+12722
-12647
lines changed

docs/develop/layers.md

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
# Layers
2+
3+
## Mapping model (🚧)
4+
5+
<img width="500" src="https://github.com/user-attachments/assets/6f76a2d6-fce1-4c72-9ade-ee5fbd056c88" />
6+
7+
* Multiple Nodes can be created (1)
8+
* Each node can have controls (compare controls in WLED / StarLight) ✅
9+
* Each node can run precompile code or Live scripts (with or without loop) ✅
10+
* Each node has a type:
11+
* Layout: tell where each light is in a 1D/2D/3D physical coordinate space (based on StarLight fixtures) ✅
12+
* Effect:
13+
* run an effect in a virtual coordinate space ✅
14+
* in the physical space if you want to run at highest performance, e.g. a random effect doesn't need to go through mappings ✅
15+
* Modifier: Mirror, rotate, etc, multiple modfiers allowed (projection in StarLight) 🚧
16+
* A modifier can also map lights dimensions to effect dimensions: change the lights to a 1D/2D/3D virtual coordinate space
17+
* e.g. if the light is a globe, you can map that to 2D using mercator projection mapping
18+
* if the light is 200x200 you can map it to 50x50
19+
* if the light is 2D, a 1D effect can be shown as a circle or a bar (as WLED expand1D)
20+
* Driver show: show the result on Leds (using FastLED, hpwit drivers), Art-Net, DDP, ...
21+
* Future situation: Nodes and noodles (2)
22+
* Replace the nodes table (1) by a graphical view (2)
23+
* Virtual Layer (MappingTable) (3)
24+
* Array of arrays. Outer array is virtual lights, inner array is physical lights. ✅
25+
* Implemented efficiently using the StarLight PhysMap struct ✅
26+
* e.g. [[],[0],[1,2],[3,4,5],[6,7,8,9]] ✅
27+
* first virtual light is not mapped to a physical light
28+
* second virtual light is mapped to physical light 0
29+
* third virtual light is mapped to physical lights 1 and 2
30+
* and so on
31+
* Virtual lights can be 1D, 2D or 3D. Physical lights also, in any combination
32+
* Using x + y * sizeX + z * sizeX * sizeY 🚧
33+
* set/getLightColor functions used in effects using the MappingTable ✅
34+
* Nodes manipulate the MappingTable and/or interfere in the effects loop 🚧
35+
* A Virtual Layer mapping gets updated if a layout, mapping or dimensions change 🚧
36+
* An effect uses a virtual layer. One Virtual layer can have multiple effects. ✅
37+
* Physical layer
38+
* Lights.header and Lights.channels. CRGB leds[] is using lights.channels (acting like leds[] in FASTLED) ✅
39+
* A Physical layer has one or more virtual layers and a virtual layer has one or more effects using it. ✅
40+
* Presets/playlist: change (part of) the nodes model
41+
42+
✅: Done
43+
44+
## Example
45+
46+
```json
47+
{
48+
"nodes": [
49+
{
50+
"name": "Lissajous 🔥🎨💡",
51+
"on": true,
52+
"controls": [
53+
{
54+
"name": "xFrequency",
55+
"type": "range",
56+
"default": 64,
57+
"p": 1065414703,
58+
"value": 64
59+
},
60+
{
61+
"name": "fadeRate",
62+
"type": "range",
63+
"default": 128,
64+
"p": 1065414704,
65+
"value": 128
66+
},
67+
{
68+
"name": "speed",
69+
"type": "range",
70+
"default": 128,
71+
"p": 1065414705,
72+
"value": 128
73+
}
74+
]
75+
},
76+
{
77+
"name": "Random 🔥",
78+
"on": true,
79+
"controls": [
80+
{
81+
"name": "speed",
82+
"type": "range",
83+
"default": 128,
84+
"p": 1065405731,
85+
"value": 128
86+
}
87+
]
88+
}
89+
]
90+
}
91+
```

docs/develop/modules.md

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,8 +4,6 @@
44

55
A module is a generic building block to create server and UI functionality which can be activated through the menu.
66

7-
MoonBase-Modules are inspired by WLED usermods, further developed in StarBase and now in MoonLight (using the ESP32-Sveltekit infrastructure)
8-
97
See [Lights Control](module/lightsControl.md) or [Devices](module/devices.md) for examples
108

119
Press the ? on any module to go to the documentation.

docs/develop/nodes.md

Lines changed: 57 additions & 145 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,8 @@ The core node functionality supports the following
1111
* Warning: type of controls
1212
* Firmware or live scripts
1313

14+
Nodes are inspired by WLED usermods, further developed in StarBase and now in MoonLight (using the ESP32-Sveltekit infrastructure)
15+
1416
MoonLight specific
1517

1618
* Node types: it is recommended that a node is one of the 4 types as described above. However each node could perform functionality of all types. To recognize what a node does the emojis 🚥, 🔥, 💎 and ☸️ are used in the name. The variables hasLayout and hasModifier indicate the specific functionality the node supports. They control when a physical to virtual mapping is recalculated
@@ -27,148 +29,58 @@ MoonLight specific
2729
* Effect nodes **set light**: Currently setRGB, setWhite, setBrightness, setPan, setTilt, setZoom, setRotate, setGobo, setRGB1, setRGB2, setRGB3, setBrightness2 is supported. In the background MoonLight calculates which channel need to be filled with values using the offsets (using the setLight function).
2830
* If offsetBrightness is defined, the RGB values will not be corrected for brightness in [ArtNed](https://moonmodules.org/MoonLight/moonlight/nodes/#art-net/).
2931

30-
## Archive
31-
32-
This page is 🚧, text below will be rewritten.
33-
34-
## Q&A
35-
36-
Collecting questions and answers (from [Discord](https://discord.com/channels/700041398778331156/1203994211301728296))
37-
🚧 !!
38-
39-
* I'm therefore wondering if esplive only supports xtensa ASM and not RISCV? we're actually not supposed to enable esplivescript on anything else than the s3. For the moment it’s esp32 , esp32 s2 esp32s3. I am revamping the compiler for it to be more compact and less memory hungry. Once that is done I will work on creating risc assembly language so it can be used with the esp32 C family and also I want to do arm for the pi pico.
40-
* Technically live scripts works on normal esp32, but MoonLight with live scripts is 103% flash size. I didn’t look into other partitioning (preferably keeping Ota working): note use esp32 16MB!!
41-
* why do some animations allow me to specifiy the LED strip pin but not others?
42-
* is there a wiki page I can read for me to understand pin mapping and LED strip physical format? there are layout nodes 🚥 (defining how the lights layed out in a matrix, cube etc. There you can define pins) effect nodes 🔥 (obviously) and modifier nodes 💎(modify an effect)
43-
* how does the lights control module interact with the animations module?
44-
* what does "snake" mean for a moving head configuration?
45-
* how do i specify which solid color i want? Added!
46-
* getting a few "Software reset due to exception/panic" depending on the effects i set 😄 but that might be my PSU
47-
* how I can specify the color order.... I see the define I want in fastled.h, i'm guessing it's passed somehow to the template through maybe the ML_CHIPSET define? oh.... it seems to require a modification of void LedsDriver::init
48-
sorry for the spam.... it also looks to me that even with the ML_CHIPSET=SK6812 define there's no support for RGBW as on a small LED strip, setting a solid color of red for example, i see green & white - blue - red - green & white - blue - red (eg: it's forgetting to send 4x 8b per LED)
49-
* is the monitor only available with the s3? I enabled "Monitor On" in the control tab oh that's interesting, the platform booted full white (when configured in solid animation) but went back to what was supposed to be when I started moving the control sliders. should be working on all platforms
50-
* not sure if this has been flagged, but when changing a selected node type, the parameters of the previous node will stay displayed and when switching node types, I did manage to get LEDs frozen (impossible to get them ot update again)
51-
it takes a platform reboot, and changing the movinghead number of LEDs in my case. it looks like some refresh isn't happening. even the platform reboot trick sometimes isn't happening... looking at the console output i'm seeing that my actions on the user interface aren't registered
52-
* how complex would it be to map several LED strips on several IOs to a virtual 2d matrix? I'm currently looking at the code, more particularly void mapLayout() and it seems the layout is reset every time that function is called, so it is not possible to increase the display size
53-
* [single line and row layouts](https://github.com/MoonModules/MoonLight/pull/19)
54-
* personally i'd make 2 different menus in the esp32 GUI.. a layout is more something you set and forget about as it is tied to a physical install
55-
* one layout to define all the lights is definitely a blocker for me (and I imagine more people) as physical installs have their own constraints. let me know what you think. I will add that possibility , I see ‘some’ usage, but I don’t understand why it is a blocker as in general the whole setup is a number of lights which you know in advance so then it is most clear to define that in one go ?
56-
57-
58-
## Technical
59-
60-
* Nodes
61-
* See Nodes.h: class Node
62-
* name(): name of the node
63-
* hasFunctions: enables features of the Node (Layout, Modifier)
64-
* on: (de)activates the node
65-
* constructor: sets the corresponding layer
66-
* setup: if layout sets channelsPerLight and request map
67-
* Nodes manipulate the LEDs / channels array and the virtual to physical layer mappings.
68-
* specify which functions (layout, effect, modifier): One node in general implements one, but can also implement all three (e.g. Moving Head... wip...)
69-
* layout
70-
* effect
71-
* modifier
72-
* Live scripts
73-
* See Nodes.h / nodes.cpp
74-
* Lights
75-
* Regular patterns (CRGB as default but also others like Moving Head ...)
76-
77-
* See [Modules](../modules.md)
78-
* Upon changing a pin, driver.init will rerun (FastLED.addLeds, PD and VD driver.init)
79-
* Uses ESPLiveScripts, see compileAndRun. compileAndRun is started when in Nodes a file.sc is choosen
80-
* To do: kill running scripts, e.g. when changing effects
81-
* [Nodes.h](https://github.com/MoonModules/MoonLight/blob/main/src/MoonLight/Nodes.cpp): class Node (constructor, destructor, setup, loop, hasFunctions, map, modify, addControl(s), onUpdate)
82-
* [Nodes.cpp](https://github.com/MoonModules/MoonLight/blob/main/src/MoonLight/Nodes.cpp): implement LiveScriptNode
83-
84-
* An effect has a loop which is ran for each frame produced. In each loop, the lights in the virtual layer gets it's values using the setRGB function. For multichannel lights also functions as setWhite or (for Moving Heads) setPan, setTilt, setZoom etc. Also getRGB etc functions exists.
85-
86-
### Mapping model (🚧)
87-
88-
<img width="500" src="https://github.com/user-attachments/assets/6f76a2d6-fce1-4c72-9ade-ee5fbd056c88" />
89-
90-
* Multiple Nodes can be created (1)
91-
* Each node can have controls (compare controls in WLED / StarLight) ✅
92-
* Each node can run precompile code or Live scripts (with or without loop) ✅
93-
* Each node has a type:
94-
* Layout: tell where each light is in a 1D/2D/3D physical coordinate space (based on StarLight fixtures) ✅
95-
* Effect:
96-
* run an effect in a virtual coordinate space ✅
97-
* in the physical space if you want to run at highest performance, e.g. a random effect doesn't need to go through mappings ✅
98-
* Modifier: Mirror, rotate, etc, multiple modfiers allowed (projection in StarLight) 🚧
99-
* A modifier can also map lights dimensions to effect dimensions: change the lights to a 1D/2D/3D virtual coordinate space
100-
* e.g. if the light is a globe, you can map that to 2D using mercator projection mapping
101-
* if the light is 200x200 you can map it to 50x50
102-
* if the light is 2D, a 1D effect can be shown as a circle or a bar (as WLED expand1D)
103-
* Driver show: show the result on Leds (using FastLED, hpwit drivers), Art-Net, DDP, ...
104-
* Future situation: Nodes and noodles (2)
105-
* Replace the nodes table (1) by a graphical view (2)
106-
* Virtual Layer (MappingTable) (3)
107-
* Array of arrays. Outer array is virtual lights, inner array is physical lights. ✅
108-
* Implemented efficiently using the StarLight PhysMap struct ✅
109-
* e.g. [[],[0],[1,2],[3,4,5],[6,7,8,9]]
110-
* first virtual light is not mapped to a physical light
111-
* second virtual light is mapped to physical light 0
112-
* third virtual light is mapped to physical lights 1 and 2
113-
* and so on
114-
* Virtual lights can be 1D, 2D or 3D. Physical lights also, in any combination
115-
* Using x + y * sizeX + z * sizeX * sizeY 🚧
116-
* set/getLightColor functions used in effects using the MappingTable ✅
117-
* Nodes manipulate the MappingTable and/or interfere in the effects loop 🚧
118-
* A Virtual Layer mapping gets updated if a layout, mapping or dimensions change 🚧
119-
* An effect uses a virtual layer. One Virtual layer can have multiple effects. ✅
120-
* Physical layer
121-
* Lights.header and Lights.channels. CRGB leds[] is using lights.channels (acting like leds[] in FASTLED) ✅
122-
* A Physical layer has one or more virtual layers and a virtual layer has one or more effects using it. ✅
123-
* Presets/playlist: change (part of) the nodes model
124-
125-
✅: Done
126-
127-
### Example
128-
129-
```json
130-
{
131-
"nodes": [
132-
{
133-
"name": "Lissajous 🔥🎨💡",
134-
"on": true,
135-
"controls": [
136-
{
137-
"name": "xFrequency",
138-
"type": "range",
139-
"default": 64,
140-
"p": 1065414703,
141-
"value": 64
142-
},
143-
{
144-
"name": "fadeRate",
145-
"type": "range",
146-
"default": 128,
147-
"p": 1065414704,
148-
"value": 128
149-
},
150-
{
151-
"name": "speed",
152-
"type": "range",
153-
"default": 128,
154-
"p": 1065414705,
155-
"value": 128
156-
}
157-
]
158-
},
159-
{
160-
"name": "Random 🔥",
161-
"on": true,
162-
"controls": [
163-
{
164-
"name": "speed",
165-
"type": "range",
166-
"default": 128,
167-
"p": 1065405731,
168-
"value": 128
169-
}
170-
]
171-
}
172-
]
173-
}
174-
```
32+
## Archive
33+
34+
This page is 🚧, text below will be rewritten.
35+
36+
## Q&A
37+
38+
Collecting questions and answers (from [Discord](https://discord.com/channels/700041398778331156/1203994211301728296))
39+
🚧 !!
40+
41+
* I'm therefore wondering if esplive only supports xtensa ASM and not RISCV? we're actually not supposed to enable esplivescript on anything else than the s3. For the moment it’s esp32 , esp32 s2 esp32s3. I am revamping the compiler for it to be more compact and less memory hungry. Once that is done I will work on creating risc assembly language so it can be used with the esp32 C family and also I want to do arm for the pi pico.
42+
* Technically live scripts works on normal esp32, but MoonLight with live scripts is 103% flash size. I didn’t look into other partitioning (preferably keeping Ota working): note use esp32 16MB!!
43+
* why do some animations allow me to specifiy the LED strip pin but not others?
44+
* is there a wiki page I can read for me to understand pin mapping and LED strip physical format? there are layout nodes 🚥 (defining how the lights layed out in a matrix, cube etc. There you can define pins) effect nodes 🔥 (obviously) and modifier nodes 💎(modify an effect)
45+
* how does the lights control module interact with the animations module?
46+
* what does "snake" mean for a moving head configuration?
47+
* how do i specify which solid color i want? Added!
48+
* getting a few "Software reset due to exception/panic" depending on the effects i set 😄 but that might be my PSU
49+
* how I can specify the color order.... I see the define I want in fastled.h, i'm guessing it's passed somehow to the template through maybe the ML_CHIPSET define? oh.... it seems to require a modification of void LedsDriver::init
50+
sorry for the spam.... it also looks to me that even with the ML_CHIPSET=SK6812 define there's no support for RGBW as on a small LED strip, setting a solid color of red for example, i see green & white - blue - red - green & white - blue - red (eg: it's forgetting to send 4x 8b per LED)
51+
* is the monitor only available with the s3? I enabled "Monitor On" in the control tab oh that's interesting, the platform booted full white (when configured in solid animation) but went back to what was supposed to be when I started moving the control sliders. should be working on all platforms
52+
* not sure if this has been flagged, but when changing a selected node type, the parameters of the previous node will stay displayed and when switching node types, I did manage to get LEDs frozen (impossible to get them ot update again)
53+
it takes a platform reboot, and changing the movinghead number of LEDs in my case. it looks like some refresh isn't happening. even the platform reboot trick sometimes isn't happening... looking at the console output i'm seeing that my actions on the user interface aren't registered
54+
* how complex would it be to map several LED strips on several IOs to a virtual 2d matrix? I'm currently looking at the code, more particularly void mapLayout() and it seems the layout is reset every time that function is called, so it is not possible to increase the display size
55+
* [single line and row layouts](https://github.com/MoonModules/MoonLight/pull/19)
56+
* personally i'd make 2 different menus in the esp32 GUI.. a layout is more something you set and forget about as it is tied to a physical install
57+
* one layout to define all the lights is definitely a blocker for me (and I imagine more people) as physical installs have their own constraints. let me know what you think. I will add that possibility , I see ‘some’ usage, but I don’t understand why it is a blocker as in general the whole setup is a number of lights which you know in advance so then it is most clear to define that in one go ?
58+
59+
60+
## Technical
61+
62+
* Nodes
63+
* See Nodes.h: class Node
64+
* name(): name of the node
65+
* hasFunctions: enables features of the Node (Layout, Modifier)
66+
* on: (de)activates the node
67+
* constructor: sets the corresponding layer
68+
* setup: if layout sets channelsPerLight and request map
69+
* Nodes manipulate the LEDs / channels array and the virtual to physical layer mappings.
70+
* specify which functions (layout, effect, modifier): One node in general implements one, but can also implement all three (e.g. Moving Head... wip...)
71+
* layout
72+
* effect
73+
* modifier
74+
* Live scripts
75+
* See Nodes.h / nodes.cpp
76+
* Lights
77+
* Regular patterns (CRGB as default but also others like Moving Head ...)
78+
79+
* See [Modules](../modules.md)
80+
* Upon changing a pin, driver.init will rerun (FastLED.addLeds, PD and VD driver.init)
81+
* Uses ESPLiveScripts, see compileAndRun. compileAndRun is started when in Nodes a file.sc is choosen
82+
* To do: kill running scripts, e.g. when changing effects
83+
* [Nodes.h](https://github.com/MoonModules/MoonLight/blob/main/src/MoonLight/Nodes.cpp): class Node (constructor, destructor, setup, loop, hasFunctions, map, modify, addControl(s), onUpdate)
84+
* [Nodes.cpp](https://github.com/MoonModules/MoonLight/blob/main/src/MoonLight/Nodes.cpp): implement LiveScriptNode
85+
86+
* An effect has a loop which is ran for each frame produced. In each loop, the lights in the virtual layer gets it's values using the setRGB function. For multichannel lights also functions as setWhite or (for Moving Heads) setPan, setTilt, setZoom etc. Also getRGB etc functions exists.

0 commit comments

Comments
 (0)