Rob,
> 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.
Let's see whether I got this right: You have two producers of events,
your MIDI hardware and your GUI. You want to have one consumer of events
that favors hardware events and only processes GUI events when no hardware
events are available.
If this interpretation is correct, then my first idea is to set up
your threads to reflect this structure: Take two queues, q1 and q2,
(in the sense of thread-safe FIFO from the Python package Queue, not
ALSA queues). The MIDI thread of pyseq writes to q1 (and doesn't do
anything else), and the GUI thread writes to q2.
Now you take a third thread that consumes events from q1 as long as
q1 isn't empty, and consumes events from q2 only after exhausting q1.
Is this closer to what you have in mind?
You say you want to stall GUI interaction while real events are available,
but I don't see how this would work in practice. Since the computer can
process events at a much higher rate than the MIDI hardware protocol can
deliver them, there should always be time for the GUI to squeeze in an
event or two.
Peter
Received on Sat Aug 6 20:15:11 2005
This archive was generated by hypermail 2.1.8 : Sat Aug 06 2005 - 20:15:11 EEST