Thanks for your continued help on this, Pietro. Here is a very basic look at what the program does: 1. At a specified time, tune the radio and launch ecasound to make a recording. 2. After the recording has finished, tune the radio to another frequency and launch ecasound again.
The version of the program I had been using launched ecasound in a thread so that the GUI would not be blocked. gobject.timeout_add() was used to stop the program from immediately re-tuning and trying to record again before the previous recording was finished. This happens hourly plus an additional 0-4 schedules within each hour. When I tried to add another schedule within the hour, I couldn't get gobject.timeout_add() to work with it. The threaded version uses os.system() to launch ecasound. I've been experimenting with subprocess.Popen and subprocess.call in the non-threaded version, but I don't understand those too well, and they both block the GUI. I understand that nobody has suggested that I block the GUI, but I can live with that as long as the rest of the program works. How I monitor the clock: Every 5 seconds I call time.gmtime() and check the hour and minute. When those correspond with the waiting schedule, the tuning a recording sequence starts. westli --- On Sat, 1/23/10, Pietro Battiston <[email protected]> wrote: > From: Pietro Battiston <[email protected]> > Subject: Re: [pygtk] gobject.timeout_add() > To: "PYGTK" <[email protected]> > Date: Saturday, January 23, 2010, 5:51 AM > Il giorno ven, 22/01/2010 alle 21.44 > -0800, dj ha scritto: > > Thank you John and Pietro for your observations and > advice. > > > > Because of them, I did some rethinking of my > program. Threading has > > worked okay for a couple of years in this > program as I continually > > improved it. But the GUI I started with > had to be useful while > > recordings were taking place. I use the to > tune a radio receiver > > according to a schedule and record what was > found there, and I needed > > to be able to make adjustments on the fly. > I use a different radio > > and GUI now, and except for Start and Quit > buttons, the GUI is just to > > supply information. So I don't need > threading or the timeouts to > > pause the program until the recording is > finished. I'm not thrilled > > with seeing the GUI go dark during recording, > but it's okay. > > Notice I was not at all suggesting to you to block the > GUI... How do you > call your external processes? > > > > Now > > there is only one 5-second timeout to check the > clock between > > scheduled recordings. > > > > Is there a better way to monitor the clock? I > have to use time-of-day > > rather than time periods, and I haven't figured > out a better way than > > executing time.gmtime() every 5 seconds. > > > > I unfortunately cannot understand _what_ type of monitoring > you need, > and hence how you are currently implementing it. > > Pietro > > > westli > > > > --- On Thu, 1/21/10, Pietro Battiston <[email protected]> > wrote: > > > > > From: Pietro Battiston <[email protected]> > > > Subject: Re: [pygtk] gobject.timeout_add() > > > To: [email protected] > > > Date: Thursday, January 21, 2010, 1:56 PM > > > Il giorno gio, 21/01/2010 alle 08.56 > > > +0100, John Stowers ha scritto: > > > > On Wed, 2010-01-20 at 21:22 -0800, dj > wrote: > > > > > I hope this is the right place to ask > this... > > > > > > > > > > I have a python program (using Glade to > create > > > the gui) that periodically launches ecasound to > make audio > > > recordings of various lengths. In order to > keep the > > > gui viable, ecasound runs in a separate > thread. In > > > order to keep the program from getting ahead of > itself and > > > trying to launch ecasound before the current > recording > > > process has finished, I use gobject.timeout_add() > for the > > > length of the recording (plus a second or two for > safety). > > > > > > > > > > Most of the calls to > gobject.timeout_add() are in > > > separate functions with different > intervals. All but > > > one of them work. The last one only works > if > > > gobject.timeout_add(..., ...)/return False is > appended to > > > the end of the function that needs it, rather > than calling > > > it. > > > > > > > > This doesn't sound like a particuarly nice > design, > > > > > > More specifically: are you sure you need threads > at all?! > > > subprocess.call will block the GUI, but > subprocess.Popen > > > won't. > > > > > > Pietro > > > > > > _______________________________________________ > > > pygtk mailing list [email protected] > > > http://www.daa.com.au/mailman/listinfo/pygtk > > > Read the PyGTK FAQ: http://faq.pygtk.org/ > > > > > > > > > > > > > _______________________________________________ > > pygtk mailing list [email protected] > > http://www.daa.com.au/mailman/listinfo/pygtk > > Read the PyGTK FAQ: http://faq.pygtk.org/ > > > _______________________________________________ > pygtk mailing list [email protected] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://faq.pygtk.org/ > _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
