I’m a new PixelBlaze user but have plenty of experience with Arduino/FastLED and programming in general. Loving the simplicity and well thought out design of the PixelBlaze so far!
I have a 16x24 LED grid and plan to create dozens of patterns to use with the sequencer. One thing I haven’t been able to figure out yet is whether it’s possible to have any shared data and code between patterns. For example, I’d like to have global functions for drawing circles and lines, as well as a global variables to control things like pattern speeds and palettes, or to pass other state from one pattern to the next. Can this be done?
I realise I could combine all patterns in to a single big one with my own scheduling code instead, but I’m worried about hitting resource limits, as well as the impact it would have on the web UI. I also see there’s a few global variables available with the sensor board and am mulling over how I might best use those.
This is a good question, and one that I’m not sure there’s a great answer to (at least in the shared functions realm). I personally copy-paste blocks of any shared utility functions to each pattern.
As far as performance goes, my largest patterns are about 250 LOC. Sometimes I’ve paid a price in terms of frame rate for an inefficient implementation, but I’ve never had the IDE slow down unless I was doing something that’s not a good pattern, like implementing my own sleep().
For sharing state between patterns, and to control the scheduling of patterns, I recently found the websockets API was much easier than I expected. I made a demo video on the documentation page. You gan get and set variables over the network. Your external controller could probably be easily derived from the Firestorm network controller, which includes instructions for installing on a Raspberry Pi.
Hope this helps a bit! @wizard might have some other clever ideas.
I should have been a bit clearer with my comment. I’m not worried about performance (I’m happy to say that seems just fine so far). By web UI impact I meant that I’d no longer be able to see and select individual patterns through the web UI - the “uber pattern” would become something of a black box as far as the web UI is concerned.
The websocket API is something I was aware of and certainly seems interesting. My current project is for a costume however and I wasn’t planning on creating a separate controller (or mobile app) for it - to minimise effort I’ve been hoping to get away with just PixelBlaze patterns plus the default web UI. Maybe I’ll need to rethink that a little
From the docs it’s not clear whether an exported variable or function is scoped to just the pattern that declares it, or across patterns. I’ve been assuming the former but if it’s the latter then maybe that’s what I need. I’ll give that a try when i get some time tomorrow.
Right now, your best bet to pass data is the super-pattern. Yes, that does bypass much of the UI benefits. You could add a UI control, like a slider, that could be used to slide between a handful of patterns/states within a larger pattern. There’s also the ADC so a potentiometer can be used as a physical control as well (with some hysteresis added) - this was my plan with a costume I’ve been making. I ran the sensor board externally, added a pot and a few buttons, then hide it in my cuff. That way I don’t have to pull out my phone to control things.
I’ve been thinking about multiple patterns ever since I made v2, and started using the ES6 export syntax. At some point, I will add support for multiple files/modules in a pattern, and even to include other patterns/modules. That would make it pretty easy to import a bunch of other patterns into a super-pattern and then call their various beforeRender/render functions as necessary, or to allow library modules that have utility functions and promote reuse over copy/paste.
I’ve also been thinking about global scripts that would be always active, and could possibly coordinate and pass data through to multiple patterns and trigger events and things. Maybe some kind of trivial data store as well, though with global scripts I imagine one could be coded ad-hoc. The idea is that you could combine sequencing, physical inputs, and maybe additional custom UI controls to do all kinds of neat things.
The sequencer as it exists today is pretty limited, and I’m thinking about the next generation of sequencer and how it could take advantage of these global scripts as well.
In terms of resource limitations, it hasn’t been an issue yet, though of course it is finite. The most complicated example patterns come out to about 1.5k, and you have about 12x that available depending on the size of the pixelmap and/or ws2812 buffer. So you should be OK, but if you run into problems let me know!
Thanks @wizard, that’s all really helpful and I’m glad to hear this is already on your radar.
I think what I’ll do is stick to individual patterns for now and copy/paste functions as required, that will be plenty to keep me busy for the time being. If that approach ends up being too limiting then I’ll consider merging everything into a single pattern and see where things go from there…
