On 2013-11-12 19:18, Paul D. DeRocco wrote:
I'd like to use PyGTK as the basis for a cross-platform (Win/Mac/Linux)
controller for MIDI keyboards, but there's no built-in MIDI support, so
I'll need to write my own, which will of course involve writing three
different C modules, one for each platform. What I'd like to know is how
to deal with the issue of making asynchronously received data present
itself as some sort of event.
In Linux, this is pretty easy, because the MIDI input has a file
descriptor, which one can monitor with gdk_input_add. But neither MacOS or
Windows represent MIDI devices by file handles which can be monitored this
way. MacOS uses a callback function which is executed in the context of
some other thread, and Windows can use a callback function or can send
MIDI messages to a window or thread.
I suppose a callback could write the data to a pipe that is monitored at
the other end with gdk_input_add, which might handle the MacOS case, but I
have a sneaking suspicion that that isn't well-supported in Windows, since
there is no kernel function analogous to poll() or select() for anything
but sockets.
So does anyone have any experience trying to shoehorn non-standard forms
of asynchronously arriving input data into the GTK or PyGTK event loop, on
the Mac or Windows?
You can call g_idle_add from the callback on Mac and Windows. This will
schedule a function and arguments that you provide to be run on the main
thread. This also gets everything nice and serialised into one thread,
making race conditions easier to avoid.
Note that you should avoid interacting with the UI directly from the
background thread on Windows, as it will cause a lock up. It's generally
better to avoid it on non-Windows platforms as well.
--
Tim Evans
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
