Notice: This forum has been recovered from an old backup, so some content, links, and dates may be outdated. The forum is currently read-only while we restore sign-in and registration functionality. Details
If you find this forum valuable and would like to help keep it online, donations to help cover hosting and domain costs are greatly appreciated, but never expected. You can support the forum through Buy Me a Coffee or Ko-fi. Thank you for helping preserve the EventGhost community.
If you find this forum valuable and would like to help keep it online, donations to help cover hosting and domain costs are greatly appreciated, but never expected. You can support the forum through Buy Me a Coffee or Ko-fi. Thank you for helping preserve the EventGhost community.
New Events - Volume, Mute and Unmute (Vista/7)
New Events - Volume, Mute and Unmute (Vista/7)
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
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
Last edited by hotbuddha on Sun Feb 26, 2012 3:02 pm, edited 2 times in total.
Re: New Events - Volume, Mute and Unmute (Vista/7)
nice! Looking forward to trying it out
setup... XBMC, W7MC for DVR & Live OTA TV, JRMC for multi-zone audio, EG, MiCasaVerde Vera3, USB-UIRT IR receiver, Harmony remote, 5.2 home theater system
- Pako
- Plugin Developer
- Posts: 2294
- Joined: Sat Nov 11, 2006 1:31 pm
- Location: Czech Republic
- Contact:
Re: New Events - Volume, Mute and Unmute (Vista/7)
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
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
Re: New Events - Volume, Mute and Unmute (Vista/7)
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).
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).
- Attachments
-
- VistaVolEvents.zip
- (23.44 KiB) Downloaded 526 times
- Pako
- Plugin Developer
- Posts: 2294
- Joined: Sat Nov 11, 2006 1:31 pm
- Location: Czech Republic
- Contact:
Re: New Events - Volume, Mute and Unmute (Vista/7)
Oh, that I did not know before.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.
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
Re: New Events - Volume, Mute and Unmute (Vista/7)
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.
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.
- Pako
- Plugin Developer
- Posts: 2294
- Joined: Sat Nov 11, 2006 1:31 pm
- Location: Czech Republic
- Contact:
Re: New Events - Volume, Mute and Unmute (Vista/7)
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
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:
Code: Select all
print repr(round(0.1 + 0.2, 2))Re: New Events - Volume, Mute and Unmute (Vista/7)
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.
Re: New Events - Volume, Mute and Unmute (Vista/7)
Glad you like it. And yes looks like this was included in the latest release.
Re: New Events - Volume, Mute and Unmute (Vista/7)
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.
- Pako
- Plugin Developer
- Posts: 2294
- Joined: Sat Nov 11, 2006 1:31 pm
- Location: Czech Republic
- Contact:
Re: New Events - Volume, Mute and Unmute (Vista/7)
This is some misunderstanding.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 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
- Luca Brasi
- Experienced User
- Posts: 262
- Joined: Sat Oct 11, 2008 12:39 pm
Re: New Events - Volume, Mute and Unmute (Vista/7)
Hi guys,
could you please have a look at this one:
viewtopic.php?f=2&t=3949
It is VistaVolEvents related....
Thanks
Luca
could you please have a look at this one:
viewtopic.php?f=2&t=3949
It is VistaVolEvents related....
Thanks
Luca
Win10 x64 Prof. / Eventghost latest / MCE Plugin / MCE RC6 Receiver / Logitech Harmony Hub / MediaPortal / kodi
Re: New Events - Volume, Mute and Unmute (Vista/7)
Hi,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
Try the following and see if it fixes the problem... Copy VistaVolEvents.pyd to the plugins\system folder.
- Attachments
-
- VistaVolEventsModified.rar
- (181.25 KiB) Downloaded 830 times
- Luca Brasi
- Experienced User
- Posts: 262
- Joined: Sat Oct 11, 2008 12:39 pm
Re: New Events - Volume, Mute and Unmute (Vista/7)
Hi scissors,
thanks! looks good, eg didn't crash on first tests.
thanks! looks good, eg didn't crash on first tests.
Win10 x64 Prof. / Eventghost latest / MCE Plugin / MCE RC6 Receiver / Logitech Harmony Hub / MediaPortal / kodi
Re: New Events - Volume, Mute and Unmute (Vista/7)
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!