# Pixelblaze-client: Python 3 library for Pixelblaze

**URL:** <https://forum.electromage.com/t/pixelblaze-client-python-3-library-for-pixelblaze/756>\
**Category:** Patterns and Code\
**Created:** [November 24, 2020, 2:50am UTC](https://forum.electromage.com/t/pixelblaze-client-python-3-library-for-pixelblaze/756 "2020-11-24T02:50:20Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![wizard](https://forum.electromage.com/user_avatar/forum.electromage.com/wizard/32/4_2.png) [@wizard](https://forum.electromage.com/u/wizard)\
**Post date:** [November 24, 2020, 7:36pm UTC](https://forum.electromage.com/t/pixelblaze-client-python-3-library-for-pixelblaze/756/10 "2020-11-24T19:36:52Z")

</div>

@Scruffynerf,  
Fair enough, and I get asked about that often.

You can implement a poor version now, but it will be limited in capabilities.

The setVars websocket API supports arrays. You can push either an unpacked `[r,g,b,...]` or maybe a packed array with 16.8 bits: `[(r<<16 | g<<8 | b) / 256, ...]` and a simple pattern can render the array to pixels.

```auto
p = pixels[index]
var r = p >>8, g = p & 0xff, b = (p * 256 + .5) & 0xff
rgb(r, g, b)

```

There will be scale and FPS limitations though, I think it would work for a few hundred pixels perhaps.

Now a non-json binary protocol for variables/controls, perhaps over UDP could be much more efficient. This bleeds in to some other ideas on the backburner. Obviously a standards compliant network pixel protocol would be ideal, but sharing variables/control data over the network could open up all kinds of fun stuff, like broadcasting an expansion board’s data, sharing data between PBs, and things like that.

---

_[View the full topic](https://forum.electromage.com/t/pixelblaze-client-python-3-library-for-pixelblaze/756)._
