Open tlambert03 opened 1 year ago
btw, this isn't really a pull request obviously :) the _xtouch.py
file might have something generalizeable in it, but otherwise this is just here for discussion
another btw... the rather verbose btn_1
, btn_2
, etc... on the subclass is there for two reasons: 1) it makes for nicer static typing and IDE experience and 2) it kinda gives an immediate visual impression of all of the things one could connect to... e.g. x.events.knob_1.connect(some_callback)
. But that could also all be dynamically generated if you don't care so much about those things
Cool! I'm physically separated from my xtouch this week, but I wanted to see if I could bring the phone control stuff into this library so I'm going to try this pattern with the phone controller.
I'm physically separated from my xtouch this week
that must be very hard for you both. my thoughts are with you
hey @kephale ... just got my xtouch :)
here's a pattern I was playing with.
BaseMidi
is a class that creates an input/output for pygame midi and maps(status, data1)
keys (as would be emitted from pygame.midi read events) to names on a dataclass field. Subclasses then declare themselves like this:see
example.py
for two variants, one in which we don't care where the psygnal is emitted (meaning it will usually be emitted directly from the thread in which the polling occurs), and then another example using a customQueueRelay
object designed for Qt. The idea here is that we always kinda need to have some awareness of the main event loop we're running in. TheQueueRelay
object is a simpleQTimer
subclass that lives in the main thread, and just watches some Queue object, and emits eventson_q
events in the main thread whenever it sees something in the Queue. (This would be most like Qt's Queue'd connection pattern). This is the kind of object that could live in superqt (or psygnal could offer this sort of adapter for a variety of common event loops, like Qt, asyncio, etc...)