Rob Fell wrote:
> Peter Brinkmann wrote:
>
>>> Would this work for you?
>
> > Almost. I see no need (in my application) to ensure that the GUI
> > events are serialised at the correct time in the event stream.
> >
> > I favour a periodic callback since a timeout on poll() indicates that
> > there are no events pending - hence it would be a reasonable time to
> > handle GUI events.
>
> That's essentially what midiplayer.py does. Since most MIDI files
> contain a lot more events than can be scheduled at once, midiplayer.py
> just schedules a batch of a few hundred events at a time, followed by
> an echo event addressed to itself. Then it just sits around waiting
> for this echo event to arrive, at which time it schedules the next
> batch as well as another echo event, etc.
>
> In your situation, you may just want to set things up in such a way that
> the MIDI thread keeps sending itself echo events at regular intervals.
IIUC in the case of midiplayer.py, all the events are generated by
software: in my case I'm trying to merge a live stream from a physical
device with events generated either by other physical devices or via the
GUI. GUI interaction should stall whilst there are real events to
process - and the easiest way I see to handle this is to use the poll()
timeout.
I can try other means of thread synchronisation, but I fear that will
massively complicate the locking :(
R
Received on Sat Aug 6 20:15:08 2005
This archive was generated by hypermail 2.1.8 : Sat Aug 06 2005 - 20:15:08 EEST