Peter Brinkmann wrote:
> Here's how I would solve this problem, using
an ALSA idiom of sorts.
> ALSA sequencer events are more general than MIDI events, and you can
> use them to communicate with your MIDI thread. In particular, when
> new data is available in your queue, you can alert the MIDI thread to
> the new data by sending it an echo event. The file midiplayer.py in
> the PySeq distribution uses echo events in this fashion, so that you
> can glean the basic idea from it.
I had already considered that as an option - but not
being
knowledgeable about the ALSA seq API, I didn't know of the existence
of message types which could never originate from real equipment (it
would be a pity to hijack an event type which might later prove
useful).
I'll investigate these echo events.
> There are a few ways to extend this basic idea.
For instance, if you
> have several queues, then you can tag your echo events according to
> which queue currently has data. You could also add an intermediate
> thread that just waits for new data in a queue and fires off an echo
> message to the MIDI thread when needed. Like this, your top-level
> GUI code wouldn't have to be ALSA-aware.
>
> 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.