Feature requests!

Feature Ideas + Requests
1

Here are two things I’ve thought of while working on my project. Not crucial features, but they’d make my life (and maybe others’?) a bit easier.

  • I’d love to be able to make global changes to LEDs in code separate from the pattern code. My use case: I’m making a swinging art piece, and I want the patterns I create to be gravity reactive (so that the pattern is always vertically oriented even as the LEDs swing). I’m currently doing this by adding code to my patterns that rotates the map based on the accelerometer, but this only works for patterns that I write myself. It would be nice to make the gravity adjustment code “global”, so that it’s automatically run before any selected pattern.

You could imagine other use cases, like adjusting the global brightness level based on sound/light, for example. I’m envisioning a separate “Preprocessing” tab that allows you to write a limited version of the beforeRender function that you could select in the same way you select patterns.

  • Would be convenient to be able to run the pixelblaze stack directly on my laptop, and not have to remotely connect to a running PB instance. I don’t need the ability to power LEDs from my laptop, but it would be nice to be able to interact with the web UI. The in-browser 3D simulations are really good, so often I would want to just iterate for a while in my browser before testing it out with LEDs - would be nice to be able to do that on my laptop without hooking up the PB.

Thanks for all the work you do! Happy to clarify these more if it’s not clear.

6 Likes
2

100% agree. I two have a situation that would benefit from a global code tab. I have some fairly complicated ON/OFF timing involving a light sensor and motion sensor. Any time I want to update this code I need to paste it into the top of all my 45+ patterns. I have the name corresponding with the version of this “global code” and a variable to help me track the changes. @wizard, I know when this was requested before you had some concern about sharing code and not having it work. It could have the global code added to the top of the pattern code with some type of comments.
//---- GLOBAL ----
Global code
//---- PATTERN ----

If it was done in a way where the pattern code required unique names from the global code this should work ok.

1 Like
3

Yeah I’ve hacked together a #include style approach for my own work that works fine, but it’s a bit hacky and requires me to edit any pattern I want to use. My thought was that the two different components (pattern and “global code”) could execute in two different environments so that there’s no way for the two to directly interact. If that’s not possible, maybe there’s some other way to enforce isolation (e.g. reserved symbol names for global code, mangling symbol names by adding some complicated prefix, etc)

1 Like