EventGhost

I have written a plugin that changes the volume by small amounts, instead of setting it in a single shot. The effect is like quickly sliding the volume up or down. I used threading because I don't want EG to have to wait for it to finish.

I will always put the latest version in this post

jitterjames,
it's a very good idea and I agree that it should be integrated into the existing plugin System/Sound Card.

My notes:
1. Inside the plugin should not use variables of type eg.globals
They are designed primarily for use in scripts
2. For killing (stopping) thread is used flag, which called Event.
Look at some of the Bitmonster's plugins how it is used.
Perhaps a good example can be found in mine plugin FileOperations.
A good tutorial is here.
Pay particular attention to the "Signaling between threads with Event objects" .
3. Instead eg.plugins.System.SetMasterVolume(tempVol) would be better to use
eg.WinApi.SoundMixer.SetMasterVolume(tempVol)
In this case it is unnecessary to call from plugin another plugin.
4. Perhaps it would be good to give users the possibility to choose the speed. For me, your preset speed is too high.
Pako

thanks Pako. That's a great resource. I knew using globals was a bad idea but I was having trouble figuring it out. Now with that link I think I can do it. I wanted to see how far I could get without asking for help!

Pako wrote: Instead eg.plugins.System.SetMasterVolume(tempVol) would be better to use
eg.WinApi.SoundMixer.SetMasterVolume(tempVol)

great. Is there also one to check the volume? I guess I can find it myself if I look around. edit: OK, looks like it is eg.WinAPI.SoundMixer.GetMasterVolume()

Pako wrote: 4. Perhaps it would be good to give users the possibility to choose the speed. For me, your preset speed is too high.
Pako

I agree. Once I fix the threading, I plan to add 2 options to the config. Volume step: 1 to 20 (right now it is 8.) and Delay per step (in milliseconds).

I will also add special function "Smooth Mute", which obviously works like mute but by lowering volume, and "Smooth Unmute" to restore the volume.

For the "Smooth Mute", I'd also like to give the option to do a partial mute, so you could set it to lower the volume down to 5% instead of 0%.

I will be using this with my voice recognition program, to lower the volume when I want to speak to the computer.

ooops!

eg.WinApi.SoundMixer.SetMasterVolume(tempVol) doesn't seem to work. I think it is setting the volume for eventGhost, not setting the master volume!

It is strange, for me it works absolutely correctly. What is your OS?
I have XP and you have perhaps Vista or Seven?
This topic did you know.
I did not read the whole, but it is marked as [FIXED].
It is possible, that for the calling through eg.WinApi the patch not working.
I'm sorry, but it I did not yet couldn't know before.
Pako

yes, I am using Vista. It seems that the system.volume plugin checks for vista and if needed it uses the vistavolume.dll.

I could put a copy of the dll in my folder, or I could reference the dll in the \EventGhost\plugins\System folder. But I'm not sure that's so much better than just calling the other plugin.

There is quite a bit of code going on there. I'm not sure if it's worth the trouble for now.

Pako:

thanks for your suggestions. I have added version 0.2 to the first post in this topic.

Take a look when you have the time. I left the call to the volume plugin alone, but I changed the threading to use event() and added the configurable options for stepsize and delay.

jitter

1. If you write "from threading import Thread, Event",
then do not have to use "threading.Event()", but just "Event()".
One of the lines "import threading" and "from threading import Thread, Event" is redundant.
If you delete "import threading" will not work "threading.Event()", but only "Event()". Is that clear?
2. It is unnecessary to define the Event() inside PluginBase class and then sent as a parameter.
Programming is cleaner (at least I think) to define a function (eg) KillThread inside the Thread class and call afterward from PluginBase class.
3. For integer is in EG SpinIntCtrl, it may not then use "fractionWidth = 0" as in SpinNumCtrl
4. Instead time.sleep in the loop of thread is used to wait the wait() method
5. Construction of try/except could be replaced as follows:
a) into the function __init __ in PluginBase class add a line self.mythread = None
b) instead of try/except to use:Pako

Thanks for your help/suggestions. I respond using your question numbers:

1: OK

2: OK, I will try.

3: OK

4: I don't understand. I want to pause for a small amount of time. Everywhere I look, including the tutorial you mentioned, using time.sleep to do this. It seems that wait() is used to wait until a flag is set, but that is not what I want to do. I am only using the flag to kill the thread.

5: OK, thanks, I was just being lazy. (but also I don't really know what I am doing! This is how to learn...)

jitterjames wrote:4: I don't understand. I want to pause for a small amount of time. Everywhere I look, including the tutorial you mentioned, using time.sleep to do this. It seems that wait() is used to wait until a flag is set, but that is not what I want to do. I am only using the flag to kill the thread.

Inside the plugin FileOperations this timing-method is used as well.
Or see the python - documentation:
Event.wait([timeout])

Block until the internal flag is true. If the internal flag is true on entry, return immediately. Otherwise, block until another thread calls set() to set the flag to true, or until the optional timeout occurs.

When the timeout argument is present and not None, it should be a floating point number specifying a timeout for the operation in seconds (or fractions thereof).

Pako

ok, so if I replace time.sleep(delay) with Event.wait(delay)

it will work exactly the same, but will kill the thread slightly faster. Assuming delay is 4 milliseconds, then it will kill the thread between 0 and 4 milliseconds faster.

correct?

True.
So here, of course, does not matter so much.
But on principle. Sometimes you may need to take such a timeout one hour or one day ...
Pako

I didn't read the entire thread, but it sounds like a good idea to me.

Pako wrote:True.
So here, of course, does not matter so much.
But on principle. Sometimes you may need to take such a timeout one hour or one day ...
Pako

This is still the better way to do it, maybe someone wants to do a very slow fade...

I just wanted to make sure I understood. Anyway I have done the change and it is working well. The only thing I still need to do is make the function to set the event flag instead of passing it.

when that is done I will upload the .py

then I will add "smooth mute/unmute"

if everything looks ok then I will try to incorporate it into the system plugin. Do I need to check with bitmonster or someone before I do this? I might need some help there too.

phase one is complete!

Please post any bugs or suggestions. I'll add the mute/unmute next.