6 Aug
2005
6 Aug
'05
3:12 p.m.
Peter Brinkmann wrote:
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.
Correct.
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?
Functionally that would produce the desired result.
Perhaps I've misunderstood the ALSA implementation, but a sequencer
client can't rely on the persistence of the event (snd_seq_free is
deprecated) - so it would have to be deep copied for queuing. The
embedded s/w eng. in me shies away from copying data unnecessarily.
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.
Enumerating large dictionaries containing patch data and song groups for
the GUI seems to be the most troublesome case, but probably as a
side-effect of my data structure design.
I think my app. needs a redesign.
cheers
Rob