6 Aug
2005
6 Aug
'05
12:12 p.m.
Rob Fell wrote:
Peter Brinkmann wrote:
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
> 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.