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
