Hi, maybe this was already discussed, I think Wled is really a top project for led stripes, with all its features it’s much more than anyone can imagine…
it just misses a way to upload easly a new effect, probably taking advance of the internal flash of the board (for example Wemos mini has 4MB), adding this feature in my opinion will boost up the popularity involving more and more people, more effect developers, and sharing effects, beautiful.
It also helps to debug and improve more quickly the effect itself.
Upload from Wled web like for OTA is a good idea in my opinion, or maybe by FTP too… it just be necessary to define a file format. To avoid wled check for syntax and compile you may decide to use Arduino IDE for it, somehow. Maybe it can be necessary to define a new “virtual board” which instruct IDE how to compile it, without include what it’s already present in Wled,making the result smaller to upload.
Thank you for your kind attention
AirCookie posted a survey a while back that indicated he wanted to build something to let users create their own effects, possibly even a live effect editor.
this is what will push Wled to the sky
How would you “describe” effects?
The different led programs, defined under “effects” tab of Wled app, for example Solid, Android, Aurora…
Right, but what sort of language/format would be used to define the effects?
A couple of ideas: If there is a standard already, for example another project similar wled, then it will be smart to take advance of that work… and chances are many effects can be already available.
Another choice may be write them in Arduino IDE language compatible, in this way it would be possible to compile it on IDE filtering all possible mistakes. The trick may be, if it’s not complicated, to create a “Wled board”, with all features/limitations the programmer should respect when generating effects.
The tool would need to define some mathematical equation for each of the available adjustments for each effect:
- how effect changes with time
- how brightness changes with time
- how colors change with time
Then how the various WLED adjustments interact with the effect. How do adjustments for speed, brightness, intensity vary the effect. Is it 0-100% linear, or non-linear in some way, or some other way?
As far as the effect math, the “WLED effect builder tool” might use things like “number of pixels for base effect = xxxx”, “effect repeats ? Y | N”, “blank pixels between effect repeats = 0, 1, 2…”, “color / brightness / speed shift for repeated sections”, which could then generate effect logic suitable for importing as a json blob.
Just random thoughts, since you asked.
IMO anything that can be orchestrated using GUI tools is going to be:
- bloated consuming a lot of flash/RAM memory
- useless and replicated more efficiently in C/C++ code
If you are talking switching from C/C++ code to some other language, then my answer is simple: C is one of the simplest languages with clear and straightforward logic. If you are a programmer then it will be easy to convert JS, Python or any other language to C/C++.
The problem I can see with current state of FX development is lack of information of what certain variable and/or function does. Including FastLED, NeoPixelBus and other librarires used for FX creation.
In my opinion the most difficult part for wled will be to check the effect code to avoid any problems, an uncorrect code may compromise the work and settings of the actual installation, or siply loose control of it. Develope those checks needs time, occupy space on ESP and cpu resources, for this reason it’s desiderable to compile and check it externally, IDE environment is familiar, it has ESP libraries and probably enought for a good result.
How FastLED NeoPixelBus manage new effects?
They don’t, they are just libraries.
-
You could already write effects in the source code and then compile a new bin and upload via OTA. So I assume we aren’t talking about that. There is plenty of interesting solutions if we are talking about making that easier. The yaml/lambda functions in ESPHome are a good example. But even making a clean stub and guide for making new patterns would be fun. Maybe a tool that could build the patterns you created into a simulator/emulator ao I don’t have to sit outside to test them.
-
There is a solution similar to the turtle language. Where comands would be in plain text. Things like
rotate
,setBrightness
,setColor
would be obvious. But you have to have a pretty extensive language to support stuff likesin(total_leds / 3 * 2 * pi)
Look at this site for an example of turtle:
This also feels similar to micropython, which would be very hard to replicate in the wled, I think.
- It sounds like some of you are advocating for writing in C, compiling (and by compiling, I am including other steps in C/C++, like linking) it, and then uploading it to the esp via the web interface. The challenges I see to this approach are:
- The memory and bloat of having the compiler built into the web interface. If this was only possible on an internet connected WLED, then we could load the compiler client side, from a resource on the web.
- There are plenty of security problems. Any pointer can point to anywhere and change the code. It would be nearly impossible to sanitize a binary blob from the client. It would need at least the same security as the OTA upload. I would also hate if I accidentally broke the ability to flash via OTA, or worse, if I affected the bootloader.
- There are functions the code needs to call, and those may be in different places on different builds or versions of WLED. If your C code called
getSegmentLength()
, that function may be at address X or Y in the flash. How would the compiler (well, the linker) know where that function was in the binary on the esp, from a compiler in memory on the client? - After we have saved this blob to the esp, can we even execute it? Will the esp let us execute code stored in the eeprom?
Very interesting topic!
I’ve been considering a few effects myself - some as tweaks and some new. I’ve also been looking at what it would take to be able to add at least a few additional effect controls (besides speed and intensity) generically for effects that could benefit from them.
I do feel that, while the ESP is amazing for what you can cram into it (I did a project last year driving 15,360 WS2812 LEDs with a ESP32 at about 20FPS using 15 separate I2S driven output lines and it still had RAM, flash and CPU to spare - amazing!), putting any sort of language on-board is likely to be too much.
I’d love it if there was a way to develop an external effects language and compiler that generated position independent code that could be dynamically loaded, but I do think this would require a re-work of what existing FX code as there would have to be a huge amount of what is currently compile time context passed in. It might also be tough to keep API/internal locations consistent across version. In short, dynamical code loading might also be a too bit much.
In the past, when faced with a semi-similar need (well, not really, but I’m stretching), what we did was produce a tool that was part custom, domain-specific language (one around effects, oriented toward effects needs and power, possibly “abstracting” some of the fiddly bits under the hood in this case) that would produce C code under the hood (combination of direct translation and template stuff).
That could be coupled with a “custom WLED image” generator. This would likely have to be a hosted system that build a WLED image for you and allowed you to opt in/out of things (like drop FXs you don’t want and, more importantly, include in custom effects). You would “save” a config (or configs) on the site and press Generate and it would create a header file (behinf the scenes) with various defines (and possible code additions) to be compiled and downloaded to the user. You could then do an OTA update to load it.
It would allow for making a reasonably useful/powerful effects DSL, allowing easy-to-maintain custom WLED builds, provide reasonably easy updatable builds as the compiles would come from the various github trees, wouldn’t require WLED instances to have internet access or have heavy weight code in them that they don’t need.
Further (future) support for doing things like producing a WLED instance with a minimal UI (vs full, for API driven WLED installs), add/drop things kike MQTT, DMX, E.31, etc as needed (likely very useful for ESP-01 builds and/or some hypothetical “large scale” effects like 2D and 3D support that wouldn’t otherwise fit without tradeoffs). Not suggesting all that “just happens”, but you can imagine adding appropriate #defines to control those build options over time.
And for most folks, the standard WLED downloads are still available via OTA or the WLED installer (freaking brilliant, incidentally) with agree don “base” config/setup similar to todays.
But for folks who want to build a custom one and/or provide a way to incorporate more dynamic FX authoring, distribution, etc, this would make it pretty straightforward to make those additions/choices without over-filling the ESP and letting the WLED firmware do what it does best.
Gerry
There are news about this? I’m looking for a way to include “art effects”, I mean somthing really useful into a home, for relax… soft effects that appers after some long time, in a soft way and not really perceptible.
I don’t see them now, all are very funny and spectacular, not a bad thing, but not all that is possible to achieve with WLED.
There is any simple way to create and test an effect without assembly and OTA it to ESP just to test it? Thank you!
Just the other day, Aircookie posted a paper in the Discord server about a browser-based live effects editor, so there’s definitely progress happening with this. Hopefully soon it will make it into WLED