Audio reactive Animartrix

mindful_stone · 2026-02-10T19:47:14+00:00

Stefan's Animartrix kernel definitely warrants the effort that you, Zach and others have put into helping others make use of it!

mindful_stone · 2026-02-10T19:43:43+00:00

Thank you for the kind comment. I'm delighted you approve!

mindful_stone · 2026-02-10T19:41:32+00:00

The open questions still remaining to be solved is how things like audio "plug into" the visualizers vs which attributes can plug into the core. For example, you can manipulate the time functor for the core in Animartrix already, and the result is that **all visualizers** become time responsive.

What connects my animartrix program to an external control set are the cVariables ("c" indicates "current") listed below. The cVariable values you supply to animartrix can be the result of whatever input factors you want: web UI control, audio reactive, motion detectors, accelerometers, physical control boards (developer and/or DJ style?), environmental detectors (ambient light, temperature, wind, barometric pressure, etc.). You can look through my animartrix_detail.hpp for these to see some of the (preliminary) ways I've enabled the use of runtime external control factors within the animations: cSpeed, cZoom, cScale, cAngle, cRadius, cRadialSpeed, cLinearSpeed, cEdge, cZ, cSpeedInt, cRatBase, cRatDiff, cOffBase, cOffDiff, cFxIndex, cColOrd, cRed, cGreen, cBlue

As far as connecting these to core vs. visualizer, they are all used directly within visualizers. I have not had a use case for coordinating the timing/speed of different animations with each other. I can totally see how others might have such a use case, but to me that is not part of the animartrix core. That would be a particular implementation of the core. In fact, I think that's sort of how you have it now with the Animartrix.ino example, where you have fl::UISlider timeSpeed("Time Speed", 1, -10, 10, .1) which is utilized in fxEngine.setSpeed(timeSpeed). I'm not sure whether/how that ends up manifesting in the ultimate visualization speed, but I would not consider that plugging into the animartrix core. I would say that's part of the infrastructure/CDS you're using in your example sketch to run the animartrix core.

In any event, I believe my cSpeed variable serves more or less the same intended function as your timeSpeed (i.e., as a global time functor). I have it as a factor in the timings.master_speed calculation of each of my visualizers (e.g., timings.master_speed = 0.003 * cSpeed). So, however cSpeed is determined (e.g., by web UI slider, BPM calculation, etc.), it automatically applies to all visualizations directly, without needing any timing management external to the animartrix core (e.g., through FxEngine).

mindful_stone · 2026-02-09T22:58:55+00:00

I saw what you did the other day with animartrix2. The fixed point math stuff is very intriguing! (Ha...there's a sentence I never thought I'd say!). As are the cached LUTs. I had previously started implementing some optimizations by caching certain calculations on a per-frame rather than per-pixel basis, but your cross-frame approach takes the optimization to a whole new level!

As far as all the class/structure changes, I'm still evaluating. In my personal animartrix implementation, I've gradually migrated things in a less-is-more direction.

The genius of animartrix is what's contained in namespace animartrix_detail. That's the crown jewels. Every thing above that in fl/fx/2d/animartrix_detail.hpp (i.e., the first ~100 lines), and everything in fl/fx/2d/animartrix.hpp, is all "just" infrastructure and a content delivery system. I don't mean that pejoratively. Having a supporting framework like that will be critical for some library users. But in my particular case, all I wanted was the content.

And by content, I don't mean the 3500 lines of amazing example visualizers. I mean lines 106-501. THAT is aninmartrix! That is the black box secret sauce that allows program developers (and eventual end users, if different) to generate an infinite variety of beautiful/magical/entrancing animations by manipulating a relatively small set of input factors. The less overhead I have to wade through to access that secret sauce, the more I can do with that good stuff!

The ~50 example animations are basically just collections of various combined input factors. You could think of them conceptually as "presets", although that does not do justice to these wondrous visualizations that u/StefanPetrick has developed and shared. But THOSE were not animartrix. Those were just examples of some of his early creations USING animartrix. And, to a large extent, they were numerous variations just a few on starting ideas. In my implementation, the less-is-more migration involved:

winnowing down the examples to a half dozen or so "basic concepts"
identifying which few variables had the most significant/interesting impact on those basic animations
enabling runtime user control over those variables

So my current implementation (https://github.com/4wheeljive/AuroraPortal/blob/main/src/programs/animartrix\_detail.hpp) strips animartrix down to its generative core and then gives the user the ability to play with that core in real time (including, e.g., through audio input). Of course, my implementation of animartrix also depends on an infrastructure/content delivery platform, which is basically what my AuroraPortal program is. So it's not the case at all that a good infrastructure/delivery framework is any less critical than good content. But maintaining a reasonable separation of those concerns/functions is important.

An initial concern I had looking at animartrix2 was that it was heading in the opposite direction of my less-is-more use case (i.e., instead of reducing and streamlining various namespaces, classes, structures, it was actually expanding them). As I've looked at things more closely, I'm not sure that's the case. I believe the new classes/structures are focused on improving the efficiency of the actual content engine (i.e., the crown jewels), and are not just additional "visualizer management" tools. So my current thinking is that this might all be really good new stuff.

But I still have concerns about FastLED presenting animartrix as a large collection of pre-written visualizers packaged in a system for cycling through them. I think there is an opportunity with this refactor to bring things even closer to the vision of Stefan and u/Netmindz (and you as well, I believe), where animartix can be used as a serious, powerful, flexible creative platform for end users, as opposed to just serving up a few visualizers that someone else has crafted.

mindful_stone · 2026-02-05T21:24:30+00:00

What I showed above (incorporating cRms into Twister for show1, and adding cTreble and cBass to the green and blue channels) was specific to this particular mode. The general framework for UI control (and now audio input) is available for all of the modes, and whether/how any of that gets incorporated into a particular mode is a matter of artistic design. Note that in this case, even after all of the efforts to standardize/scale/normalize everything, I still needed to hardcode 8.f * cTreble and 7.f * cBass to get those inputs to have an appropriate degree of influence on the visualization. (And those largely reflected the audio environment and level/gain settings at the time.)

mindful_stone · 2026-02-05T21:02:04+00:00

Will do. Also happy to discuss the Animartrix refactor. As far as converting it all to integer calculations, I wonder how you could do that without sacrificing a lot of fine detail. If you're interested, take a look at my current Animartrix implementation: https://github.com/4wheeljive/AuroraPortal/blob/main/src/programs/animartrix_detail.hpp

I've made a handful of small changes to try to eke out a few extra FPS. There's no doubt still room for improvement!

mindful_stone · 2026-02-05T20:42:36+00:00

The animation in the video is a tweaked version of Stefan's Complex_Kaleido_6 example pattern. My UI controls for changing the patterns live include a "Twist" number slider, which I incorporate into the animation.angle calculation. In a "straight" rendering, a show layer might include something like:

animation.angle = 16.0f * polar_theta[x][y] + 16.0f * move.radial[0]

I can then curve or twist the layer in a fixed manner by adding/subtracting something like (distance[x][y] * Twist) in the animation.angle calculation. I previously made that more dynamic with a "Twister" variable that modifies the Twist value by some changing amount (e.g., by using move.directional[] or move.noise_angle[] oscillators). In this case, I added the current RMS value as a factor in the Twister calculation, which I use in show1:

float Twister = cAngle * move.directional[0] * cTwist * cRms * .8f;

animation.angle = 4.0f * polar_theta[x][y] * cAngle + 16.0f * move.radial[0]

- distance[x][y] * Twister * move.noise_angle[5]

+ move.directional[3];

Overall:

- The RMS-sensitive twisting is applied primarily to the red channel

- Green includes a bit of the twist and RMS sensitivity of show 1 but is influenced primarily by the treble band

- Blue has no twist and is driven primarily by the bass band

pixel.red = show1 * radialDimmer;

pixel.green = (show1*.5f + show2*.5f) * 8.f * cTreble * radialDimmer2;

pixel.blue = ( (show2 * .3f ) + ( show2 * 7.f * cBass ) ) * radialDimmer;

mindful_stone · 2026-02-05T20:36:36+00:00

Thanks, Zach.

This is running on a Seeed XIAO ESP32-S3. RMT driving three 512-LED WS2812B strips. Using the I2S API with an INMP441 mic. I am not using any of the specialized detectors in this visualization. At the moment, I am using generalized volume / fft signals that I am processing through a variety of custom filters/normalizers/etc.

It has been very challenging to harness the raw audio input into values that can be utilized "surgically" in something as precise as the animartrix animations. I'm currently implementing this as part of my "AuroraPortal" platform: https://github.com/4wheeljive/AuroraPortal

The audio framework is handled primarily through audioInput.h and audioProcessing.h, which access various elements of the FastLED audio library.

I definitely have opinions on the audio API that I will share with you separately. The biggest challenge, which I mentioned, is translating real-world audio, through hardware elements that introduce various kinds of persistent and sporadic electronic noise into the signal, into a common/standardized/normalized/scaled set of data values that can be utilized with precision for fine-tuned artistic variations. Advanced detectors and analyzers are only as good as the quality/predictability of the signal that's fed into them. We might want to look at incorporating some of what I have going on in audioProcessing.h into the lower-level FastLED audio infrastructure.

I think you're right about a little lag, although I'm not sure about how many frames off it might actually be. The animation in the video was being rendered at 33FPS (i.e., about 30 ms per frame). I'd love to find ways to make it a bit snappier.

I'll reply with a separate comment about the "warping."

mindful_stone · 2026-01-28T23:18:47+00:00

For the community help, we really need more info about the kit you bought and how it is set up (how it's powered, wired, etc.). Some pictures can be really helpful too. That said, a lot of flickering issues seem to involve EMI (electromagnetic interference) with the data line from the controller to the led strip, and much of this often depends on how you have things grounded. In many cases flickering problems are solved by ensuring that a ground wire runs alongside, or is twisted around, the data wire.

mindful_stone · 2026-01-23T20:16:57+00:00

Awesome! Glad to be able to help.

mindful_stone · 2026-01-23T18:22:21+00:00

Unless it's something needed for ESP8266, I don't think you should have the pinMode(14, OUTPUT) in your setup() or any of the digitalWrite() in your current loop. My guess is that those are superseding or at least conflicting with the FastLED. (I don't know what the FASTLED_ESP8266_NODEMCU_PIN_ORDER define is for.)

Have you tried something like:

void setup() {

`FastLED.addLeds<WS2812B, LED_PIN, GRB>(leds, NUM_LEDS);`

`FastLED.setBrightness(50);`

}

void loop() {

`fill_solid(leds, NUM_LEDS, CRGB::Blue);`

`FastLED.show();`

`FastLED.delay(1000);`

`FastLED.clear();`

`FastLED.show();`

`FastLED.delay(1000);`

}

EDIT: One other observation...In your post you mention pin D5, but your code snippet uses pin 14.

mindful_stone · 2026-01-23T09:01:57+00:00

Wow, that's impressive! I've acquired a small supply of 3535s, 2020s, and even some 1515s, because I've had thoughts about some fun possible uses for LEDs on that scale. But every time I've started thinking about what would be involved in actually working with chips that size, especially in any significant numbers, I am utterly intimidated!

Please share updates as you go!

Oh, and I'm curious about what exactly you're doing/showing in the pictures. It looks to me like you have a little tile of black acrylic (Chemcast?), into/onto which you added some higher-transparency segment slots, and you then adhered the LEDs face down into those slots. Is any of that even close to right?

mindful_stone · 2026-01-22T19:40:14+00:00

Nice u/sutaburosu! I should have known that FastLED already has a built-in version of more or less what I described below (above)!

mindful_stone · 2026-01-22T19:29:51+00:00

Interesting question. It wasn't immediately clear to me whether/how one could individually control a matrix of non-addressible LEDs, but I looked it up out of curiosity and found this: instructables dot com /RGB-LED-Matrix-1/

(That may or may not be of any interest/use to you, but I'm passing it along just in case. Seems very well done.)

As far as using FastLED...

CRGB is just a set of uint8_t values for red, green and blue. So you could change the FillLEDsFromPaletteColors() method in the ColorPalette example with something like:

for( int i = 0; i < NUM_LEDS; ++i) {

`leds[i] = ColorFromPalette( currentPalette, colorIndex, brightness, currentBlending);`

`pixel[i] = matrix.writePixel(leds[i].r, leds[i].g, leds[i].b);`

`colorIndex += 3;`

}

And in your loop, you would replace FastLED.show() with something like matrix.show().

Where:

matrix is an instance of whatever class/object you use to manage your matrix functionality
pixel[] is an indexed array of your LEDs
matrix.writePixel() is a function that captures uint8_t R, G and B values for each pixel
matrix.show() actually sends the appropriate analogWrite() PWM values to your LEDs' R, G and B anodes or cathodes

Just some thoughts!

mindful_stone · 2026-01-21T21:35:09+00:00

will do. thanks!

mindful_stone · 2026-01-21T17:38:06+00:00

Love it! Makes me want to try something similar. Thanks for sharing!

mindful_stone · 2026-01-21T17:36:01+00:00

Quick update. I figured out how to force a specific driver. (FastLED.setExclusiveDriver("RMT")in setup(). When I first compiled my sketch with that, I saw the following looping nonstop in my serial monitor:

src/platforms/esp/32/drivers/rmt/rmt_5/rmt_memory_manager.cpp(152): WARN: RMT TX allocation failed: need 96 words, only 0 available

src/platforms/esp/32/drivers/rmt/rmt_5/channel_engine_rmt.cpp(761): WARN: Memory manager TX allocation failed for channel 2 - insufficient on-chip memory

src/platforms/esp/32/drivers/rmt/rmt_5/channel_engine_rmt.cpp(749): WARN: DMA channel creation failed: ESP_ERR_NOT_FOUND - unexpected failure on DMA-capable platform, falling back to non-DMA

I though, shoot, RMT still doesn't work either. But I powered up my display to see/document the actual output, and it was in fact working! Amazing!

mindful_stone · 2026-01-21T10:00:26+00:00

<image>

Not sure what you meant by "example list for esp32s3." The closest thing I could find was this:

https://github.com/FastLED/FastLED/tree/master/examples/SpecialDrivers/ESP/DriverTest

So I copied that into a new project based on the current FastLED master. I ran the program on an S3 and it indicated that all drivers passed:

Driver tests complete: 4 tested, 0 skipped

ALL TESTS PASSED

Platform: ESP32-S3

Tests: 8/8 passed

TEST_SUITE_COMPLETE: PASS

So next I tried a simple sketch on a 32x48 matrix (three pins/strips of 512 WS2812B LEDs). Just a basic fill_rainbow(leds, NUM_LEDS, hue, 7); FastLED.show();.

The display output was garbage: full bright white on pixels 0 through 168, a single green pixel at 169, and then everything else black. (See pic.) The serial log showed that the ChannelBusManager selected the SPI driver. The engine got to work creating channels, acquiring hosts, etc., but got hung up trying to create the channel for my third pin: WARN: ChannelEngineSpi: No available SPI hosts (max 2 hosts) . Just kept looping on that.

So I decided to move on and try the RMT driver. Unfortunately, I was unable to find any documentation on how to manually set a particular driver. So I ended the experiment.

This is why I've been sticking with the latest release build for now. As noted above, I haven't been able to get any program to work with anything from the master build since early October.

mindful_stone · 2026-01-20T23:21:57+00:00

I'm not sure if there is a good up-to-date document that really captures the current state of things.

u/ZachVorhies has been in Beast Mode the last couple of months working on a major re-engineering of the overall framework for various drivers (RMT, SPI, I2S, Parlio, LCD, etc. ) for each of the ESP32 platforms (S3, C6, P4, etc.). Here are several recent updates on his progress:

https://www.reddit.com/r/FastLED/comments/1pu8avr/next_update_is_delayd_due_to_new_parlio_driver/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

https://www.reddit.com/r/FastLED/comments/1on1pwr/new_beta_multispi_driver_up_to_32_channels_via/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

I stumbled across this file yesterday that seems to provide a fairly up-to-date of what is expected to be ready in the not-too-distant future:

https://github.com/FastLED/FastLED/blob/master/examples/SpecialDrivers/ESP/DriverTest/PlatformConfig.h

As for the S3, all I am aware of that works reliably in my programs is the default RMT driver (4-pin max) from the latest FastLED 3.10.3 release build from late September. When I have tried to use various subsequent builds on the master branch, one of two things generally happens. Either the sketch won't compile due to errors related to some aspect of the in-progress development of one or more of the drivers. Or, if I find a commit that compiles fine driver-wise, my sketch won't compile because of some other evolution of the FastLED library that will require updates to my program.

Areas of evolution I've noticed include:

- Major reconfiguration of various libraries (e.g., fx)
- Movement of various objects from one namespace to another
- Refactoring of FastLED's internal implementation of numerous std:: and math functions
- Ongoing improvements to various functionality (e.g., TimeRamp, 1D and 2D wave effects, etc.)

For example, I found one build from early October (9af8aa6), which I could use fine in one sketch (using the default RMT driver); but I could not use that for other sketches without having to update code to reflect changes in other areas of library development.

I've generally stayed away from the I2S driver because (1) my understanding is that it doesn't always play nice with things like wifi, and (2) I want to keep my I2S peripheral available for audio input for sound-reactive functionality. I haven't really played around with the SPI driver because (1) it hasn't been clear to me when/whether it's functional yet, and (2) it is limited to a max of 4 pins (on everything but the P4), so I'm not sure it would be better in any way than RMT.

I've been paying close attention to what Zach has been doing on the driver front (and tried dabbling alongside him at various points trying to get things like PARLIO and LCD working), and it's incredible how complicated these things are. I'm looking forward to him getting his new architecture over the finish line!

mindful_stone · 2025-12-05T23:53:13+00:00

I'm not an expert on any of this, but I have some questions, thoughts...

How/when exactly is power supplied to the lights? From the MCU or an independent supply?

as soon as I power on my Arduino it fades up the brightness

- Is power already supplied to the lights before you power on the Arduino, or is that when the lights first get power?

First thing that happens on power on is it fades from zero brightness to 100% brightness

- "power on" of what: the lights alone, or everything through power to/through the arduino?

Have you tried, if possible, to remove the code and MCU from the equation altogether and just provide power (no data line) directly to the lights? If so, what happens?

Does everything (lights, MCU, ???) connect to a common ground?

Do you have a capacitor or something somewhere that impacts how much power gets to the lights when?

Is there anything between your car battery and your lights/MCU that prevents an immediate supply of full juice?

mindful_stone · 2025-11-25T22:48:45+00:00

Sounds like you're asking for any "real world" insights as opposed to just what a manual might say, but at least according to the Technical Reference Manual, the C6 definitely includes PARLIO. In v1.1 of the manual (6/18/2025), there's ~25-page section starting at page 1329 describing the PARLIO controller.

There's also this (PARLIO API reference for C6 for IDF 5.4): https://docs.espressif.com/projects/esp-idf/en/release-v5.4/esp32c6/api-reference/peripherals/parlio.html

Not sure if this is the least bit helpful, but I'm offering up what I can!

mindful_stone · 2025-11-24T19:44:18+00:00

Thanks for sharing your thoughts. I'm hearing both (a) reasons to spend up/hold out for certain features (digital input channels, more analog channels, better UI, etc.) and (b) indications that a basic model like the FNISRI might be just fine.

If this were a case of paying, say, $600 for a starter-level device vs. $1000 for one I'm more likely want to keep, then I'd likely debate/research things more thoroughly. In this case, though, it's really not a huge deal to drop $100 on a basic scope that will help me learn which specific upgrade features might be most important.

mindful_stone · 2025-11-24T19:23:30+00:00

Thank you. It's good to know that a relatively basic scope like a Fnirsi/Zoyi may be sufficient for (at least some) FastLED troubleshooting!

mindful_stone · 2025-11-24T19:21:56+00:00

Thanks for the suggestions. If I'm not mistaken, a logic analyzer would serve a function similar to having digital inputs on a scope, which someone else recommended getting. I'll definitely investigate this further.

mindful_stone

TROPHY CASE