Closed netmindz closed 2 months ago
As this a branch pull request rather than a pull request from a fork, my intention was that you @troyhacks could make any changes you wished as well, I was looking just to handle replacing your hard coded values with the right usermod UI bits, the actual analysis side is up to you 😀
As this a branch pull request rather than a pull request from a fork, my intention was that you @troyhacks could make any changes you wished as well, I was looking just to handle replacing your hard coded values with the right usermod UI bits, the actual analysis side is up to you 😀
Perfect, thank you!
Testing right now and it seems to be working in theory - but the automatic changes are happening MUCH more quickly in your implementation. Debugging that now. :)
As this a branch pull request rather than a pull request from a fork, my intention was that you @troyhacks could make any changes you wished as well, I was looking just to handle replacing your hard coded values with the right usermod UI bits, the actual analysis side is up to you 😀
Ok, it's all done and working! Thank you for this - just what I needed to get it across the finish line.
Pulling the volume into the usermod was super useful too - I was able to stop the analysis from going crazy during silence.
Overall the "Troy's extra data" in the AR usermod havebeen thoroughly tested and vetted and ensured it's doing what it's supposed to and with the correct values. zeroCrossingCount
I think was almost a made-up number before (oops) - but now it's exactly what it says.
The one issue I had was bridging the data via um_data
- I could NOT get the nested "extra" array to work, so I passed the values individually instead. C++ syntax is kinda voodoo to me so that might be my fault - if you wanna take a stab and putting it back, go nuts. Works for me as it is. 😄
I added the AutoChange tuning parameters to the usermod data. Save the usermod once after updating it and the new data should be populated when you go back into it.
Ok, I'm pleased with this.
AutoChange been tested with my line-in systems and with a board with an INMP441 microphone. Surprisingly it works well under both!
The AutoChange analysis and the change threshold scaling seem to be working as expected after many hours of testing and also just letting it run on its own to make sure it's not crashing if left alone.
@netmindz - Things to be tested, I think still a bit buggy:
Often when I change the music playlist, I need to reboot the board to get it to use the new playlist ID.
I think that can be made smoother?
Sounds like you have made good progress.
Audio-Sync will still need to be updated, as it's not just a single 16 bit int, there might be space without needing a new format, but certainly easier now we only need the one extra value
Loading the IDs for the playlist is a little janky due to know how the loading is async, but I'll take a look to see if I can improve at all
Sounds like you have made good progress.
Audio-Sync will still need to be updated, as it's not just a single 16 bit int, there might be space without needing a new format, but certainly easier now we only need the one extra value
Loading the IDs for the playlist is a little janky due to know how the loading is async, but I'll take a look to see if I can improve at all
Yeah, I don't see AutoChange being used against network Audio Sync packets - there's potentially too much real-time analysis going on to make it work, but will be fun to find out.
What would it take to get AutoPlaylist to have an on/off button like AutoSave and AudioReactive?
What would it take to get AutoPlaylist to have an on/off button like AutoSave and AudioReactive?
I tried, it's position would be under the Audio Reactive info. For some reason it wasn't working for me so I removed it for now. Can look to add that again, possibly in later PR.
If you wanted to try and debug, just revert the commit called remove button
If you wanted to try and debug, just revert the commit called remove button
This is fixed - mostly. Now it's just logic needed.
We're using "enabled" fairly liberally - including when we switch between playlists, etc.
I think what's left is just tracing the logic to figure out enabled/disabled.
The button works now, saving the usermod config works - but there's some issue with it not disabling anymore when you change playlists - this is likely because of the external "enabled" button?
We just need some better logic on the current states.
So reviewing the code again, it seems the button is working as expected - but the logic now is:
Currently, going back to the music playlist doesn't re-enable the usermod, as it did before. I don't see an easy way to retain that functionality AND the on/off button.
We could consider "button_enabled" as a separately tracked state bool, and add that to the logic mix? Or just scrap the on/off button and revert to the original logic?
I'd removed the button partly because it wasn't working, but also wondering if it was more intuitive to just swap back to music, especially if using an app like WLED+ where getting to the info panel is a few clicks away.
The downside is that if you never want to use auto playlist, but just manually select the music playlist how to handle that so it doesn't drop into ambient unexpectedly
Good shout on WLED+, as somehow I missed that entirely.
Yeah, agreed. The button will be removed and return back to the original logic. Maybe figure out some other data we can put in the info box to help visibility into what's going on, like the current state of the usermod - in silence, in music, auto change running, etc.
I'd removed the button partly because it wasn't working, but also wondering if it was more intuitive to just swap back to music, especially if using an app like WLED+ where getting to the info panel is a few clicks away.
The downside is that if you never want to use auto playlist, but just manually select the music playlist how to handle that so it doesn't drop into ambient unexpectedly
The only outstanding issue I see now is that there's no clear way to really disable AutoPlaylist. If it's compiled in, it becomes active if you pick the music playlist - unless you undefine those (or set them to something non-existent) in your settings.
Added new logic for functionality_enabled
which differs from enabled
enabled
now tracks the overall state of the usermod from settings - if you disable it in settings, it stays disabled.
functionality_enabled
tracks the internal state of the usermod functionality, so we can disable ourselves internally without disabling the entire undermod.
Using functionality_enabled
also allows some instances where we can "go thru the motions" of the AutoChange logic without actually changing presets. This allows the AutoChange data to stay hot when audio is present even when functionality_enabled
is false.
When the AutoChange data is kept fresh, there's less frantic changes when we go back into AutoChange mode.
Accepted what @softhack007 has suggested - honestly most of the numbers were pulled out of thin air originally, so any scrutinized numbers should be better - and tested fine too.
I'm good with this as it stands if everyone else is.
@troyhacks glad i did't actually "kill the magic" with my changes :-)
From my side, i'm still looking for a way to "halt" a running playlist when auto-change is active. So that the auto-change progress is not gettig in conflict with the playlist mechanism that has its own timers for changing / shuffling / repeating.
Small info page rework.
Old:
New:
New usermod to automatically flip between your "ambient" or "music" playlist when the music starts
Also optional to flip which music effect is running based on audio data rather than fixed time interval