It is currently March 28th, 2024, 12:10 pm

AudioLevel

Share and get help with Plugins and Addons
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: AudioLevel

Post by dgrace »

jsmorley wrote:I suppose that in a perfect world the numeric value of a child measure with Type=DeviceList could be the count.

[MeterDeviceInfo]
Meter=String
FontColor=255,255,255
FontSize=11
AntiAlias=1
Text=Total Devices: [MeasureDeviceList:]#CRLF#[MeasureDeviceList]
DynamicVariables=1
That's pretty easy to implement, but the DeviceList call into Windows is really expensive. I'm thinking that if you want to use it at all, you'll want the device names that it returns. I'd be worried about people calling it twice, once to get the number of items, and a second time to get the values, and then blaming me when their CPU spikes. ;) :P

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: AudioLevel

Post by jsmorley »

dgrace wrote:That's pretty easy to implement, but the DeviceList call into Windows is really expensive. I'm thinking that if you want to use it at all, you'll want the device names that it returns. I'd be worried about people calling it twice, once to get the number of items, and a second time to get the values, and then blaming me when their CPU spikes. ;) :P

dave
Well, it wouldn't work that way, since you can return both the list and the numeric count at once with the plugin. You simply have to return the list as the string value and the count as the number value of the plugin measure. So there is no need for two measures, they can just use [MeasureName] to get the string value, and [MeasureName:] to get the number value.

However, on balance I think you are right. The other issue is that as you see, it's not just the total count of devices, but then which number in that count the current device is, and that is both a while different kettle of fish and could be expensive indeed if they are not careful about how they do it, since the active device can be changed while the skin is running.

I think the Lua script(s) are simple enough, just make use of the single call to the device list one time, and can be restricted to running only once when the skin is refreshed or the active device actually changes. I also really think this is an "edge case" anyway, as that arbitrary number isn't really terribly relevant 99% of the time.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: AudioLevel

Post by dgrace »

jsmorley wrote:Well, it wouldn't work that way, since you can return both the list and the numeric count at once with the plugin. You simply have to return the list as the string value and the count as the number value of the plugin measure.
Well sorta. Currently it only calls the expensive function if you call GetStringValue with a DeviceList type. Making the number available in GetValue would either mean calling the expensive function an extra time there, or calling it in Update and then returning the results in the GetValue/GetStringValue calls - which would slow down everyone with a DeviceList measure even if you never use the value.

Plus, like I always say, "Hard work pays off down the road; procrastination pays off right now!" ;)

dave
User avatar
Socks the Fox
Posts: 104
Joined: August 25th, 2015, 6:40 pm
Contact:

Re: AudioLevel

Post by Socks the Fox »

Is there a less or inexpensive way to detect changes in the device list? I had to implement simplistic file checks so that Chameleon wouldn't process the images every update/refresh, maybe something similar would work here.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: AudioLevel

Post by dgrace »

Socks the Fox wrote:Is there a less or inexpensive way to detect changes in the device list? I had to implement simplistic file checks so that Chameleon wouldn't process the images every update/refresh, maybe something similar would work here.
Not that I know of. It's this call that seems to really hurt: https://msdn.microsoft.com/en-us/library/windows/desktop/dd371400%28v=vs.85%29.aspx.

dave
User avatar
Socks the Fox
Posts: 104
Joined: August 25th, 2015, 6:40 pm
Contact:

Re: AudioLevel

Post by Socks the Fox »

What about using RegisterEndpointNotificationCallback to monitor changes? You'd enumerate when the plugin gets loaded to nab the initial state of things, then register a callback and only update whatever lists when the callback gets, well, called back. It looks like it will notify for the key events you might be interested in: adding, removing, and changing the default device.
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: AudioLevel

Post by dgrace »

Socks the Fox wrote:What about using RegisterEndpointNotificationCallback to monitor changes? You'd enumerate when the plugin gets loaded to nab the initial state of things, then register a callback and only update whatever lists when the callback gets, well, called back. It looks like it will notify for the key events you might be interested in: adding, removing, and changing the default device.
It's not a use case I personally want or need (or want to test/debug), but feel free to update the code and do a pull request. Everything's checked in: https://github.com/rainmeter/rainmeter/tree/master/Plugins/PluginAudioLevel.

dave
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: AudioLevel

Post by jsmorley »

dgrace wrote:It's not a use case I personally want or need (or want to test/debug), but feel free to update the code and do a pull request. Everything's checked in: https://github.com/rainmeter/rainmeter/tree/master/Plugins/PluginAudioLevel.

dave
dgrace, if someone does a change to your code, we would need you to give us approval to commit it to the build. You can do it in a comment on the users's pull request if you want. None of us have looked at your code in any depth, and we would need you to be happy with any changes.

Obviously the criteria for any change to the build code is that it does something actually needed, that it does it correctly, that the use is consistent with Rainmeter (more or less), that it doesn't unduly impact CPU or other resources without the user being aware of it and being allowed to "opt-in" to using it, and probably most of all that it does not cause backwards compatibility issues with existing skins.

Then we can blame you if it crashes Rainmeter... ;-)
User avatar
dgrace
Developer
Posts: 265
Joined: June 28th, 2014, 8:32 am
Location: Tokyo, Japan
Contact:

Re: AudioLevel

Post by dgrace »

jsmorley wrote:dgrace, if someone does a change to your code, we would need you to give us approval to commit it to the build.
Sure thing. I just don't have the time to work on it myself. The other option for Socks is to just grab the code and use it to make his own separate plugin (just rename it to something else so the DLL's dont overlap) and package his skin with that one.

dave
User avatar
Socks the Fox
Posts: 104
Joined: August 25th, 2015, 6:40 pm
Contact:

Re: AudioLevel

Post by Socks the Fox »

I don't have any skins that use this, I was just hoping to provide a solution to the issue of that one function being so expensive.
Post Reply