EventGhost

I decided to rewrite the vista volume library to produce real sound events. This will only work for Vista and 7 (and the like) so no XP. You should get events whenever the volume level changes and for mute/unmute for the default playback device. It also works even if you change the default playback device. I've been using for a few days now and it seems to be rock solid.

Take the two files from this zip and place in the eventghost\plugins\system directory and restart EG.

UPDATE: updated files can be found in later post below

nice! Looking forward to trying it out

I currently tried it (Windows 7 Professional, 32).
With one exception, it seems that it works well.
The problem is shown in the following figure:I thing, that the line Main.System.Volume ... would not be there.
When will be the bug fixed, I'll integrate it into the next build.
I thank the author for improvement EventGhost.
I have, however, one more comment.
What is the reason to indicate the volume level to 15 decimal places ?
In my opinion it is completely pointless.
I would recommend to rounding to 2 decimal places (like actions Set Master Volume and Change Master Volume).
The ideal would be to rounding directly in the library VistaVolEvents.

Pako

Here you go Pako. Since the vista volume DLL and windows api both use float, the value in the payload was just being set to that float value which was why you saw so many positions to the right of the decimal. In order to do as you asked I had to format and pass it as a string.

This time I have included the source code and project files for VS10 (requires VS9 aka 2008 to compile since EG is built on VS9 dll's).

hotbuddha wrote:Since the vista volume DLL and windows api both use float, the value in the payload was just being set to that float value which was why you saw so many positions to the right of the decimal. In order to do as you asked I had to format and pass it as a string.

Oh, that I did not know before.
Here I see a small problem that someone already using it and he will probably be forced to adapt its configuration.
We can return to the original version of the VistaVolEvents.pyd and the rounding done only in the plugin (__init__.py).
This means that we at four locations instead of the volume variable used expression round(volume, 2).
What is your opinion on it?

Pako

It does not matter if you do the rounding in C++ or Python, a float is a float in any language and if a particular number cannot be represented exactly to the precision you specify by the systems FPU then it will give you the closest value up or down that it can use to represent the value. Here is exactly what happens if I change the DLL and plugin as you proposed doing round 2 in Python:

CODE:
def VolumeEvent(self,mute,volume):
try:
if mute:
self.TriggerEvent("Mute", round(volume*100,2))
else:
self.TriggerEvent("Volume", round(volume*100,2))
except:
pass

def MuteEvent(self,mute,volume):
try:
if mute:
self.TriggerEvent("Mute", round(volume*100,2))
else:
self.TriggerEvent("UnMute", round(volume*100,2))
except:
pass

RESULT:
09:34:33 System.Mute 59.619999999999997
09:34:35 System.UnMute 59.619999999999997
09:34:39 System.Volume 62.740000000000002
09:34:40 System.Volume 59.619999999999997
09:34:40 System.Volume 56.490000000000002
09:34:41 System.Volume 53.369999999999997

As you can see, python would also require the use of a string in order to store and represent exactly to the precision you desire seeing. Anytime you have ever seen a result different than this with a floating point value it is being printed and Python is auto-converting the value to a string for you. So, to get perfect print with the desired precision it has to be a string, and we are back to this new version since it will probably do the rounding and string conversion more efficiently in C++.

I think that the new version will be OK. I did not change the return format of SetMasterVolume or ChangeMasterVolumeBy... these still accept and return Float without any rounding exactly as before so they will remain backwards compatible. I only changed the new event's payload to string rounded to two places. Since the events are new no one will have backwards compatibility issues. It does look a little better in the logger, and I am sure it will be less confusing to people who are not programmers by nature. Also, I would predict that most uses for this event payload will be for OSD and volume synchronization scripts with serial control which will most likely use the string version directly anyway.

Finally... if we put this out there and later enough people provide reason to instead return the float, we can simply change it back at that time.

You're right and I totally agree with your conclusion.
I've done some tests before and I got "expected" results.
However, now I've done some more tests and I also got "unexpected" results (15 decimal digits after rounding to two digits).
I also read something about it.
BTW - who cares - try to execute this command:Pako

Very useful, thanks! I'm now using it for a simple volume OSD instead of 3RVX. I hope it does get included in the normal EventGhost releases.

Glad you like it. And yes looks like this was included in the latest release.

Thought I would take a look but does not work at all. I dropped it in the plugins folder and restarted and got nothing but errors. Had to delete it.

molitar wrote:Thought I would take a look but does not work at all. I dropped it in the plugins folder and restarted and got nothing but errors. Had to delete it.

This is some misunderstanding.
This functionality is already included in the installation file and does not need to do anything to make it work (only for Vista and Windows 7).

Pako

Hi guys,

could you please have a look at this one:
viewtopic.php?f=2&t=3949

It is VistaVolEvents related....

Thanks
Luca

Luca Brasi wrote:Hi guys,

could you please have a look at this one:
viewtopic.php?f=2&t=3949

It is VistaVolEvents related....

Thanks
Luca

Hi,

Try the following and see if it fixes the problem... Copy VistaVolEvents.pyd to the plugins\system folder.

Hi scissors,

thanks! looks good, eg didn't crash on first tests.

Thanks scissors. I would have helped but did not have a machine that could reproduce the problem. So glad someone actually made use of the source code I included!