So there's a base class that doesn't do much, there's duplication of the midi message config accross the subclasses, it's unclear what self.value is for esp vs. self.last_read that some subclass maintain, etc...
I'm happy to help clean that up (ie, write the code), this issue is to discuss what the end result should look like.
I would suggest having a more comprehensive controller base class that has the basic support for setting/sending midi messages, getting/setting a "value" and notifying handler via callback of changes.
A "value" could be the enabled state for a footswitch, the analog value for analog controllers, etc...
Is there any reason why set_value does nothing on analogmidicontroller (and value changes aren't reflected in self.value) ? Note: the test backend currently exploits this "feature' but it's a hack, i would rather add a callback.
So there's a base class that doesn't do much, there's duplication of the midi message config accross the subclasses, it's unclear what self.value is for esp vs. self.last_read that some subclass maintain, etc...
I'm happy to help clean that up (ie, write the code), this issue is to discuss what the end result should look like.
I would suggest having a more comprehensive controller base class that has the basic support for setting/sending midi messages, getting/setting a "value" and notifying handler via callback of changes.
A "value" could be the enabled state for a footswitch, the analog value for analog controllers, etc...
Is there any reason why set_value does nothing on analogmidicontroller (and value changes aren't reflected in self.value) ? Note: the test backend currently exploits this "feature' but it's a hack, i would rather add a callback.