The best thing about competition is it shows you new things to improve on, add, or why your solution is already better.
Video of Soulmate firmware, which is ESP32 only, and uses FastLED… Nice app, allows BLE or Wifi control, has Android and iOS apps, and there is a nifty emulator.
I’ll definitely be trying this, on one of my QuinLed Quad units, and also plan on seeing what patterns in https://editor.soulmatelights.com/gallery
can be done in PB. (And if easier or harder to achieve)
Yeah its a neat setup. The in browser emulator + preview is interesting. 2D (and 3D) live previews and pure browser emulation are things I’m considering as well.
The simplification of tools for Arduino/fastLED is also pretty nice, though I don’t like that it relies on a cloud service and the compile + upload times are still about the same as if you were using an Arduino IDE locally. Previews are a little faster, which is cool.
Overall its a nice app wrapper around fastLED for sure.
For discussion about fastLED api compatibility and porting, see this thread:
@wizard, I’m sure you’re already thinking this, but please don’t feel compelled to add features from FastLED or anywhere else unless you’re sure they fit with the architecture. It’s ok – even great – to have different tools for different jobs. Here’s how I think about Pixelblaze and FastLED…
Pixelblaze speaks the language of the problem. It abstracts away hardware detail, so you can focus on whatever you’re trying to do, which usually translates easily into code. As an interpreted language, it’s very fast if you can lean on built in functions to do your work, quite a lot slower if you’re writing multiple for(;;) loops over an array of pixel values.
For me, optimizing on a Pixelblaze is sort of a mathematical game, like simplifying an equation. The cleaner my statement of the problem, the faster it runs.
FastLED speaks the language of the machine. Because of this design choice, and because it’s compiled, you can squeeze every last drop of performance out of a controller. It’s a great choice for algorithms that are unavoidably iterative – things that have to make multiple passes over the whole pixel array.
You own all the hardware issues right from the start though, from the cranky initialization templates, to (last I checked) no support for RGBW WS2812s, to properly scaling integer math that comes in various word lengths.
There’s the whole compile/upload cycle thing too. Even when it’s fast(ish), it still slows you down. Ever hit “Upload” and at that moment spotted a fatal bug? I have.
Bottom line: I’ll fire up Platform.io and go to the compiler when I have to, but for LED things, I’ve come to prefer Pixelblaze for its speed and fluidity of development. I love being in a time when we’ve got so many great choices though!
Well said @zranger1! I think PB (with it’s JavaScripty ways, mapping, and other details I won’t list) is an entirely different beast from WLED, Soulmate, and many other “led controllers”, for better or worse, and depends greatly on the person, skills, and task.
I think having competing methods to do the same basic idea [pretty lights!] is good for everyone, both users (new and experienced) and developers.
The “language of the problem” was exactly what I was going for, and I’ve made a lot of design decisions so that you can focus on just experimenting with the output.
Speed is an important factor of course, and we’re in the 3rd iteration of a faster engine from where I started. There are plans in place to bring further substantial speed enhancements (beyond just hardware), without imposing implementation complexity on the language.
While I don’t intend to copy for copying sake, if ya’ll have feature requests you’d like to see in Pixelblaze let me know what catches your eye
That’s actually why the challenge of “port all the patterns” is worthwhile, it helps to figure out where potential speed issues lay, or where the abstraction fails, etc.
Soulmate is tempting as a “free and runs on any esp32” but the biggest downside is it’s got a hidden infrastructure cost (they use a remote server) that might disappear next week/year and it’s got a lot of moving parts (multiple OS apps, firmware, remote server) to depend on.
With PB, if you stopped selling/supporting the esp8266 version of PB (for example), it remains not just functional but still highly programmable, unlike Soulmate’s.
So kudos on the “it’s all in the firmware” solution that is standalone.
As an example of PB doing it “a better way”, consider the mapping of LEDs in 2d or 3d:
PB allows you to use any matrix you want, and just tell it where the pixels are in 2d, 3d, or even polar or some other custom manner if you wanted it. It’ll normalize to 0…1 format for all values, all axes.
For FastLED, someone wrote a custom mapper webpage that in attempting to simplify things, shows how rigid it really is:
I mean, it’s totally usable, and this video shows how it does work. It’s probably pretty close, even if it’s slightly off. I suspect the skew given the non linear alignments would be adjustable if you truly cared enough to massage the output.
BUT imagine doing the exact same thing with PB: zero code changes to ANY 2D pattern available, change just your map. Your map is literally configurable to not just a grid but to whatever positions you wanted (have a pile of LED eyebrows, and around your lips? No problem!). How hard is it to define the matrix? Just use a ruler and pick a spot to call center, or zero… measure each spot twice, map once. Bingo, all mapped. If you want it in 3d, just as easy, just add a Z measurement.
And to be clear, I’m sure you could do this with FastLED too, but it would take some work. PB comes with it out of the box. Beginner level stuff, even.
So I wanted to make something similar to this a few years ago but didn’t have the coding know-how so gave up on it, I even found the perfect material. This is opening up ideas I thought I’d shelved for good:) Cheers for sharing this link @Scruffynerf I’m gonna check out the pixel mapper that Ben posted last week to have a go at something in the future:)
There are indeed so many choices. Madrix, FastLED, even LX Studio. When I had a small group together on my core project we tried a few of them… LX seemed the most powerful for our 3D mapping purposes but, well, we did not get to where it was stable, easy to work with.
All other nuances aside, Pixelblaze provides a GREAT context for working in including a GREAT community of support. Here’s to things both great and small with PB at the center.
