This is a follow up to discussions in #595 and #608 and somewhat related to #296 but for the post change callbacks not validation stage which would be a 3rd callback type proposed.
It would be valuable to not rely on parameter events being published but use the internal node interface API to get the events in a callback for different interfaces. Along with that change if there was a more fully featured API for registering callbacks for parameter changes locally, the parameter event publishing could also be split out into a separate component that could obviate the need for a parameter to turn that functionality on and off in the constructor of the parameter, and avoid the dependencies on the clock and topics interface for the core parameter API.
This is a follow up to discussions in #595 and #608 and somewhat related to #296 but for the post change callbacks not validation stage which would be a 3rd callback type proposed.
It would be valuable to not rely on parameter events being published but use the internal node interface API to get the events in a callback for different interfaces. Along with that change if there was a more fully featured API for registering callbacks for parameter changes locally, the parameter event publishing could also be split out into a separate component that could obviate the need for a parameter to turn that functionality on and off in the constructor of the parameter, and avoid the dependencies on the clock and topics interface for the core parameter API.