dethknite wrote: ↑May 10th, 2023, 8:01 pm
Well, to detect when there is audio, one can use the NowPlaying plugin. Based on its state, it can affect all the DynamicAudioIdleUpdateDivider (on/off). This would allow all measures with this value set to "switch" to using the its value until the NowPlaying state changes back to show a State value of audio available.
Alright, but there's one thing I don't understand: are you referring exclusively to the NowPlaying
measures when talking about dynamic audio detection processing, or do you have AudioLevel
measures in mind as well? I'm saying this because you mentioned using NowPlaying to detect whether "audio" (which is actually only a track in a supported media player and doesn't cover the overall audio in the system like AudioLevel is, or even Win7Audio
to a certain extent) is playing, but you're looking to ease the resource impact of skins using AudioLevel measures - at least that's my impression so far.
It's not that I'm against your suggestion, since I'd also love to minimize the resource impact of the latter, but these (NowPlaying and AudioLevel) are two different things, there are people and skins that use one, the other or both, and there is already an option that does what you mentioned, i.e. UpdateDivider, that can be controlled for any section, not just audio related sections. Can you post a short, simplified code sample to illustrate what you mean exactly? Because I have the feeling that you're mixing things here: the PlayerType=State
option from NowPlaying does not
measure whether there's audio signal
from an audio device in your system (i.e. when the visualizer / equalizer is drawing those bars and such), it measures whether the audio player
(and only if it's a supported one) is playing a track / audio file or not, and that's an entirely different thing...