I made a jacket similar to this some years ago (~640 LEDs, 40000mAh battery, various sensors), running about 70 FastLED patterns on it. I totally agree that being able to power it with a PB would have made it far easier to create better and more complex patterns, and I wish the PB had been around at the time as I’m sure it would have saved me a lot of late nights!
That said… after having gone from that jacket project to another couple that do use a PB, I’m still quite torn between the tradeoffs required. Here’s a few examples of where I’ve encountered hurdles with the PB:
- All code on the PB is per-pattern only. I’ve found this hugely limiting at times. Examples:
- Code reuse. My jacket codebase is around 12,000 LoC, with a lot of shared functionality across patterns (e.g. geometry, boids, global palettes, fonts, scrolling etc). No way I’d want to cut’n’paste (and maintain…) that on a PB.
- PB can’t skip or navigate between patterns programmatically or based on external events. E.g. my jacket has a flame sensor. When it detects a cigarette lighter it can switch to a flame effect
. Similarly, there’s a gesture sensor which allows switching to a pattern that flows in the direction your hand was waved. Also has a rotary encoder to skip forward/back/reset. - Crossfades and other types of behaviours that operate a level above individual pattern code (speed controls, palette changes, …) aren’t possible.
- Can’t reuse the same pattern multiple times with different parameters (though with the existing playlist functionality this might be quite easy to add?).
- PB has only one global map. Sometimes I wanted my jacket to behave as a cylinder, sometimes a flat matrix, sometimes custom mapping.
- The sensor expansion board microphone doesn’t have auto-gain. I get frustrated mucking around with PID controllers in each sound reactive pattern. My jacket had a MAX9814, which does a great job of dealing with that in hardware.
- PB has no ability to manage/throttle max power output. This has caused me frustration with certain patterns that momentarily draw too much power at a certain point in their cycle. Rather than beef up the power supply (in my case expensive and impractical) or reduce global brightness just to cater to these brief peaks, I usually end up changing the pattern code until it isn’t as bright, which can be a somewhat time consuming process.
- Can’t access the underlying LED buffer on the PB. For some situations this is really useful, e.g. whenever multiple passes/layers are required, for applying global effects (e.g. blur/fade/scroll), for blending patterns.
- Bitmaps, fonts etc. I realise there are hacks to achieve this on PB but they’re not what I’d call practical.
- Source control of pattern code is painful on the PB.
Now, please don’t take the above as me hating on the PB! Quite the opposite, I love the wonderful balance of power and simplicity PB brings. I also realise Rome wasn’t built in a day and that a fair few of the points I’ve listed above have workarounds or are on the roadmap. But if I were to start a project like this again today, I’d still have to consider long and hard the trade-offs required if I wanted to benefit from the easy to use, powerful programming model and live coding goodness that we’ve all come to love 
.
As far as the difference in programming difficulty between e.g. FastLED and PB goes, I’ve found it really depends a lot on the type of pattern. For pixel/bitmap oriented stuff I’ve found it can go either way. E.g. the “Spiral Twirls” and “Spectrum Analyser” in the Pattern Library were ported from my jacket code, plus there’s various PB patterns I’ve ported the other way, all without too much difficulty. Where PB really starts to shine (excuse the pun) is with irregular pixel layouts, 3D maps, and shader-like patterns. It’s great to see people like you and zranger1 starting to explore more in this direction.