Open kephale opened 1 year ago
but I suspect it is not desirable to grab a SignalInstance so directly.
that's fine actually! Signal
is just a thin descriptor that generates SignalInstance
s bound to specific objects. The logic for that SignalInstance creation happens here Signal.__get__
(as it appears you've already discovered yourself). So, you'd be much better off just directly calling SignalInstance(int, instance=self, name=f"knob_{idx}")
rather than using Signal(...).__get__(self)
.
SignalInstance
is a public class and will definitely remain so. The Signal
descriptor abstraction was mostly there to create API parity with what people are already used to in Qt signals/slots.
Another thing that might be useful here is to create a SignalGroup
... but let me take a closer look at the code and see if it would be better or just "different" :)
https://github.com/kephale/pulser/blob/e3ba65908f74254c411b6431a4a0568d2914a7f8/src/pulser/midi.py#L64
@tlambert03 I wanted to try to use a dict of
Signal
s, but the implicit instantiation that happens when a containing class is created does not work when theSignal
is in a dictionary (makes sense).Previously, I did start by having a single
Signal
for the midi device which works as a class attribute, but it wasn't very elegant to have to parse event information within eachconnect
ed function.The quoted approach currently works, but I suspect it is not desirable to grab a
SignalInstance
so directly.This is the code that I'm trying to support: