Do you know if this compatible with the GS8206 driver?

Howdy! I'm trying to write some patterns for a buddy's cube, and I've written something to help me test locally, but I'm still unsure of language limitations.

I see that array literals aren't permitted, but does array.length exist?
Can arrays be of variable size at all?
When you create a new array with array(10), what are the initial values of that array?

I'd like to play around with it. If not, no worries.

I have a string of WS2801's (bought from adafruit a few year ago) that aren't working. Do have to do something to this 2811 trace on the bottom of the board?

Hi is the firmware open source? cheers

Greetings!

I'm wondering if you would be willing to provide native implementations of simplex 2d and 3d noise functions in the Pixelblaze function API. These functions are so useful for creating "natural" feeling patterns and randomness that are difficult to accomplish otherwise.

It would be possible to use a pure JS implementation, but performing, say, 3 calls to a noise function for every pixel for every frame, starts to get expensive for higher pixel counts.

Here is an example JS implementation: https://github.com/josephg/noisejs/blob/master/perlin.js
Here is an example in C: https://github.com/smcameron/open-simplex-noise-in-c

Let me know your thoughts! I think it would be a great addition to the library.

Awesome work, by the way.

I have a few questions about how garbage collection and memory management works in functions.

When I do something like

var banana = 1;

function multiplyBanana(banana) {
  var multiplicand = 12;
  return banana * multiplicand;
}

1. Is another unreclaimable part of memory allocated for the banana inside the function?
2. Is another unreclaimable part of memory allocated for the multiplicand inside the function?

One of the more interesting RGB LED chips - to me at least - the NS108 / HD108 style LED, which has support for 16 bit per pixel and has a protocol somewhat similar to APA102-style LEDs. Would it be possible to support those, too?

I have a very simple piece of demo code that just pushes the correct few bits out to the LEDs, but in the end it's just a bunch of shiftOut calls.

Here's the datasheet: https://addressableledstrip.com/uploads/20200605/3cc6b3c4b37d1544ed0c4a320947d9d5.pdf
Page 7 is where the protocol is described.

It would be helpful if there were a handful of test patterns that could be used to validate that the configuration of the strips are set up correctly; RGB in the right order, all pixels addressable as expected, etc.

Maybe only 3 (RGB) or 4 (RGBW) are needed where each exercises only one color channel.

Possibly, two pixels at the start/end, one pixel at 10,20,30,40,etc....

Might also be helpful to have a white "dot" that starts at 0 and goes to the end of the strip?

And I'd love to help incorporate it with
Espixelstick https://github.com/forkineye/ESPixelStick

And Hyperion
https://github.com/hyperion-project/hyperion.ng

Is the source available ? I can only find docs and images.

Have you considered adding support for controlling pixelblaze over MQTT?

My use-case is connecting it to Home Assistant, which supports controlling lights over MQTT. Right now I'm using a small python bridge between MQTT and the pixelblaze websocket: pixelblaze_mqtt_bridge (shameless plug)

Although the source code isn't available yet. Would you be willing to release the firmware as a binary blob so that others may flash it to their own ESP8266 to give it a try?