Open bitglue opened 7 years ago
- The receiver frequency has changed, so it can invalidate the current recording, thus avoiding reporting spots on one frequency which happened on another.
You can almost get this notification by implementing ITunableDemodulator
. The catch is that that only promises to notify you about the relative frequency, which can remain unchanged if in freq_linked_to_device
mode. In practice, it currently delivers notifications on any change, but I wouldn't propose relying on that.
I agree that all three of these are useful. I'll see about implementing them.
710e578fea36b75e04613f1da367096689a8c657 replaces ContextForDemodulator.get_absolute_frequency
with ContextForDemodulator.get_absolute_frequency_cell
, so you can subscribe for frequency changes.
I'm figuring to do the same thing (provide a cell from the context) for out-of-range, and maybe close/delete. The rationale is that this avoids obligating demodulators that don't need the information to implement several stub methods.
Does this sound like a good plan?
What's a cell? Looks like a value that can either be .get()
or somehow subscribed? Sounds good, though tangentially stuff in values.py
could use some docstings.
What's a cell? Looks like a value that can either be .get() or somehow subscribed?
That's correct. Each @exported_value
implicitly generates a cell (per instance, of course). Most of the code that works with cells explicitly is on the client side for UI generation and data binding.
…stuff in values.py could use some docstings.
Well, yes. It's a bit of a mess other ways, too.
For the WSPR demodulator (#82) I have use cases for three kinds of events:
wsprd
.There are ways I could work around these limitations, but none are especially elegant.
__del__
, but explicit.close()
methods are generally good practice.