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
Received on Sun Aug 7 00:15:04 2005
This archive was generated by hypermail 2.1.8 : Sun Aug 07 2005 - 00:15:05 EEST