It is currently June 18th, 2024, 3:01 pm

[Feature] Dynamic audio detection processing

Report bugs with the Rainmeter application and suggest features.
dethknite
Posts: 15
Joined: May 7th, 2021, 3:19 pm

[Feature] Dynamic audio detection processing

Post by dethknite »

Bear with me on the intro... I have a meter / measures that processes audio / updates skin (which seems that the majority of skins that do so are CPU intensive when actively processing). To handle this when no audio is playing, a couple of the more popular skins will unload the skin / load the skin based on audio output. Now that is fine as a workaround, but I went the route of coding a measure to handle changing the UpdateDivider for the measures based on when audio is active. This works well.

My thought / suggestion is that implementing an option to enable something like this for audio measures could be something to greatly help the community as a whole. Something like the DynamicVariables on a measure... adding it would flag processing to automatically idle the updates when audio is not active and ramp up when it is.

Code: Select all

[MeterBeat]
Meter=Line
MeasureName=Audio
LineWidth = 1.8
DynamicVariables=1
; Normal updates (active audio)
UpdateDivider=100
; Dynamic updates (idle audio)
DynamicAudioIdleUpdateDivider=10000
Another idea would be a global option in the settings to do so for all audio processing measures / meters in skins.
User avatar
Yincognito
Rainmeter Sage
Posts: 7448
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Dynamic audio detection processing

Post by Yincognito »

dethknite wrote: May 10th, 2023, 2:21 amTo handle this when no audio is playing, a couple of the more popular skins will unload the skin / load the skin based on audio output. Now that is fine as a workaround, but I went the route of coding a measure to handle changing the UpdateDivider for the measures based on when audio is active. This works well.

My thought / suggestion is that implementing an option to enable something like this for audio measures could be something to greatly help the community as a whole. Something like the DynamicVariables on a measure... adding it would flag processing to automatically idle the updates when audio is not active and ramp up when it is.
How do you know beforehand when no audio is playing? The fact that you don't get the artist / track doesn't (necessarily) mean that there is no sound, now does it? And even if you use the RMS value or something similar to test that, this represents only moments in the (recent) past, it can't anticipate the (equally recent) future, if you know what I mean... :???:

Other than that, a dynamic (or higher) update divider on either measures, meters or both is a good way to tackle this, and it will work for animations (including audio based ones), but you can already do that using the current options / dynamic variables. So I guess my question is, how such an addition to Rainmeter would help in practice, since: a) one can already do that via dynamic / higher update dividers, or global options like DefaultUpdateDivider; b) one cannot possibly anticipate whether audio will be playing the next moment (or if analyzing the RMS value, one has to wait till the 10000 millisecond to resume the "active audio" 100 millisecond update divider, like in your code schematics)?

One other thing, in case you're not aware of it (yet): lowering the update rate for audio related measures does help with CPU usage, but how often the skin redraws itself also matters. The higher CPU usage in case of visualizers is partly based on a higher update rate for audio measures, and partly based on a higher frequency of skin redraws to simulate "animation" / "activity". Acting on just one of these won't produce the expected result if the other is still happening at a higher frequency.
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
dethknite
Posts: 15
Joined: May 7th, 2021, 3:19 pm

Re: [Feature] Dynamic audio detection processing

Post by dethknite »

I appreciate the reply.

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.

In terms of what that looks like on measures:

#Active audio
* Measure would use the configured UpdateDivider value (or default if not specified).

#Idle audio
* Measure would use the configured DynamicAudioIdleUpdateDivider value if specified (otherwise would continue to use the above).

True this can all be accomplished with current available measures with some thought and proper configuration, but from personal experience, it took me weeks of hacking through to get it to work on my skin, and I am only making a suggestion as to how this could be made easier to implement for more beginner skin creators to not only help them, but to help the end users who use the skins since this would keep cpu usage during idle at a minimal level.

The point of the suggestion is to help with the measures with low UpdateDividers that need to redraw themselves a lot during audio processing to simulate animation and activity (keep the fps and fluidness up for things such as eq bands and such). I probably noticed this more in my example as I have a few measures that process this and act upon it both for animation, and for overall visibility (the skin opacity and having it fade away when audio stops).
User avatar
Yincognito
Rainmeter Sage
Posts: 7448
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Dynamic audio detection processing

Post by Yincognito »

dethknite wrote: May 10th, 2023, 8:01 pmWell, 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...
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth
dethknite
Posts: 15
Joined: May 7th, 2021, 3:19 pm

Re: [Feature] Dynamic audio detection processing

Post by dethknite »

In this example, you are correct, I am looking to see if a media player "WebNowPlaying in particular" is playing back anything. That isn't to say that it wouldn't be helpful to do so in other situations perhaps, such as global audio if that is something desired in a skin. I am mostly making a suggestion based off my understanding and current experience dealing with updating measures based on audio from the NowPlaying plugin.

In one such skin, I use a NowPlaying measure for detection, and an AudioLevel measure to act upon the UpdateDivider dynamically (with a Measure=Calc) with a conditional IfTrueAction, IfFalseAction. It works well for this use case... but implementing it was quite a lot of trial and error and took quite a lot of time, research, testing, and such... and I feel it might be a helpful way bring "play nice functionality" in general without having to dig around so much. You are right, though--there is a missing piece of having to provide what source of audio one wishes to act upon as well.
User avatar
Yincognito
Rainmeter Sage
Posts: 7448
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: [Feature] Dynamic audio detection processing

Post by Yincognito »

dethknite wrote: May 11th, 2023, 10:09 pm In this example, you are correct, I am looking to see if a media player "WebNowPlaying in particular" is playing back anything. That isn't to say that it wouldn't be helpful to do so in other situations perhaps, such as global audio if that is something desired in a skin. I am mostly making a suggestion based off my understanding and currently experience dealing with updating measures based on audio from the NowPlaying plugin.

In one such skin, I use a NowPlaying measure for detection, and an AudioLevel measure to act upon the UpdateDivider dynamically (with a Measure=Calc) with a conditional IfTrueAction, IfFalseAction. It works well for this use case... but implementing it was quite a lot of trial and error and took quite a lot of time, research, testing, and such... and I feel it might be a helpful way bring "nicer play functionality" in general without having to dig around so much. You are right, though--there is a missing piece of having to provide what source of audio one wishes to act upon as well.
Ah, I see, that explains it - all clear now. For the record, it didn't have to be hard to do it - you can always ask here on the forum and I'm sure you would have reached a proper solution easier. Of course, you shouldn't depend on it and things should be made easier for the user by default, but as I said, while in your particular case you were able to use the value of a measure from a different "plugin" to achieve the objective, the general case doesn't benefit from that advantage. ;-)
Profiles: Rainmeter ProfileDeviantArt ProfileSuites: MYiniMeterSkins: Earth