Closed steeltrack closed 10 months ago
@ideoforms Thanks for all of the feedback. I've addressed the inline comments in my latest commit.
To your larger point, str_for_value is a conversion method, not a stored value. Therefore, human readable parameter value strings have no listeners of their own. This is why I grouped both values into one listener even though it increases the amount of network traffic. One alternative would be exposing the conversion method as its own OSC endpoint, but then you have the network traffic of sending the float value and getting the string response.
For what it's worth, I didn't notice performance issues. Also, I somewhat disagree with this point: "users will only want either the value or the value_string."
In order to replicate the Live control below, you must have the parameter float values to transact with the API, which you can then convert to a human-readable string. However, that human-readable string is not actionable (ie: it can't be sent back to the API to change a parameter).
Let me know your thoughts. Thanks again for the thorough review!
All of that sounds reasonable, and changes look good. Thanks, merging now!