I’ve just posted code for a Python 3-based sACN proxy to my repository here:
Here’s video of lightshowpi on a pi 3b+ running 8 channels of normal lights plus a spectrum analyzer on a 16x16 Pixelblaze matrix via the proxy.
At this point, the proxy code is basically a library+example code in a single script. Some technical knowledge is a must. There’s no UI, but with a little rearrangement of the code, you can drive multiple Pixelblazes from the same proxy instance, or run multiple instances forwarding different sets of DMX universes. It supports up to 480 RGB pixels per Pixelblaze, and allows you to manage network and Pixelblaze bandwidth by regulating the outgoing frame rate.
lightshowpi configuration is a fairly complicated thing on its own. I’ll be improving the docs over the next couple of days to help with this, and I can probably answer some questions, but most likely I’ll be doing the same thing you will – staring at those very verbose configuration files, making my best guess, test, rinse repeat… (and now I have no more excuses. time to go hang those lights!)
This is a great post to see … I’ve just looked through your github repos and see so many rad things for pixelblaze! Thank for all you share here.
I’ve gotten the RGB SACN Listener running on my pixelblaze, but was hoping to send the SACN signal from regular desktop lighting software that supports SACN (E1.31) … I’m new to this ecosystem tho, and wanted to ask if something like this is possible via what you’ve written? Do I have to run sacnproxy.py locally on my laptop and just route my lighting software there or is it more complex ?
Good catch, @scruffynerf! The proxy code requires a relatively recent Python 3. That line of code uses a Python 3.x-only feature to merge two dictionaries.
Python’s versioning situation is strange. Official Python is on version 3.9.x now, but the legacy 2.7.x versions are still absolutely everywhere because there’s so much existing code that requires them. I don’t know what versions of Python come with Macs, but like most Unix-ish things they may well have both a 2.7 and a 3.x version.
One way to find the Python version is to use the terminal command: python --version
If it returns something like Python 2.7.15 , try the command: python3 --version
to see if you’ve got Python 3 installed. To run the proxy, it’ll need to be 3.4 or newer. (Newer is better - I actually wrote it using 3.7.7, the latest release is 3.9.something…)
If you do have Python 3, just start the proxy by typing python3 sacnproxy.py instead of python ... If you don’t, you can get it from www.python.org.
just a recommendation: if you have a mac and doing CLI things (or even non-CLI things), using https://brew.sh/ is game changing. In this case, you can install python directly via brew, BUT I’d recommending using pyenv (so install pyenv via brew, then use pyenv to install python 3.x.
Pyenv allows you control which python you use where, install multiple versions, and more.
So you can easily add support for this proxy to use a particular version that works for it, and not worry about some other code you use elsewhere that requires a different version.
A quick question… will this allow me to control multiple pixelblazes independently? I know with ArtNet, I can send to individual IP’s, but am not sure if I can with SACN yet… And if so, would I just specify multiple IP’s on line 323 of sacnproxy.py?
My goal is having the pixelblazes controllable as separate fixtures…
The Python proxy code is a proof-of-concept. It’s meant as a springboard to give interested programmers an idea what might be possible, and a basic framework to build on. So, yes it is possible to get it to send data to multiple destinations. But it would take a moderate amount of programming to do it. If I were trying to run a show or an installation from a single central program that sends Artnet/SACN/DMX data, I would definitely not do it this way.
Given a bunch of Pixelblazes, I would get one of these: Pixelblaze Arduino Programmer, and reflash the Pixelblazes with WLED, LedFX or something else that explicitly supports the protocol you want to use. (All these programs come with instructions for flashing. One thing though – if you go this route, be sure to save the original Pixelblaze software image in case you want to restore it at some point.)
The Pixelblaze’s software is designed as a standalone user programmable controller. It is kind of awesome that way. There’s really nothing else like it, but it is not a good fit as a simple data receiver. However, Pixelblaze hardware still has many advantages - flexible power management, polarity protection, excellent LED driver circuitry - even if used with different software.
(Another possibility, if you decide to keep the Pixelblazes as they are, and need to synchronize and control patterns across multiple Pixelblazes, is of course, Firestorm)
They do exist! The amazing folding screwdriver/hammer! (from my grandfather’s tools - probably dates from the mid 1950’s. Pretty good screwdriver, not-so-great hammer)
@aiotea ,
Keep in mind E1.31 is in the future for Pixelblaze. Possibly another network protocol first, like Open Pixel Control. You aren’t alone in wanting a high quality LED controller like Pixelblaze but with direct pixel capabilities.
DDP is being talked about in many circles (WLED and LedFx for example) as less limited than e1.31
Also Dave of Dave’s Garage just released his NightDriver code, haven’t yet looked at protocol he picked. Looks like he rolled his own. But that said, his open source plan is take contribution so I suspect support for the other standards will likely happen, just because they are standards.
To revive this discussion: I am also looking for a way to use PB as a simple pixelpusher in addition to the pattern engine. This would allow me to use the same hardware for two different architectures, which would be awesome.
I would be willing to do a PR for a UDP-based pixelpusher protocol (would most probably be DDP or Artnet, right?), as this would be much more efficient, right? It should be possible to make PB act as an DDP/Artnet receiver, or are there some difficulties with that?
Thanks for pointing me to where to start.
@zranger1, which framerate did you achieve with your proxy solution?
@wakazong, this version of the proxy was written for Pixelblaze v2, which had a slower processor – it’s artificially capped at 30 fps in the Python code.
On a v3 Pixelblaze, with the cap removed, it’d be dependent on LED count. I’m reasonably sure you could drive a few hundred LEDs at 60fps or close to it.
Reviving this, I just did some design to try to do something similar to what @aiotea was talking about with a lighting installation involving 4 pixelblazes which should be acting as simple pixel receivers. I have no knowledge of other protocols, I’m still pretty new in the lighting world, but my requirements are that I want the system to be able to set itself up and be able to be tolerant in the face of possible rain / weather related issues like a Pixelblaze losing power gracefully, and to be able to catch a new pixelblaze if it starts back up without me having to take out my computer.
I decided to try to take the pixelblaze discover code out from Firestorm and to write an orchestrator to spin up / tear down sACN proxies, like this:
Note the part at the bottom that says “Pixelblaze Fleet Orchestrator”. The idea was that then my friend’s DMX source will be sending Multicast sACN and we can predetermine which poles are using which universes. We haven’t figured out if the sACN stream should be over Ethernet or WiFi and figured we’d experiment but any guidance here would be welcome.
@zranger1 does this seem like the right idea? I could try to flash the Pixelblaze like you said but that’s a scary proposition with only a month and a half, including holiday season, to put this together, and sACN is nice in that it’s widely supported and the pixel data will be coming from TouchDesigner, which natively supports sACN.
