View Issue Details
|ID||Category||Date Submitted||Last Update|
|0007405||bugs||2017-06-25 10:36||2020-04-19 20:18|
|Status||closed||Resolution||no change required|
|Fixed in Version|
|Summary||0007405: OSC feedback sending wrong values for /strip/name|
|Description||OSC messages with strip name are sent three times (in my session), once with the name of the strip (correct) then twice more, each time with a float encoded as a string.|
|Steps To Reproduce||Configure OSC to send strip (name) messages.|
Connect OSC client.
Observe /strip/name messages.
Expected behaviour: /strip/name/1 message contains string with strip name.
Actual behaviour: 3 /strip/name/1 messages. 1st with string value containing strip name, 2nd with string value "1.66", 3rd with string value "20.00".
|Additional Information||2nd value is actually the value of the fader.|
3rd value is actually the value of strip Trim.
|Tags||No tags attached.|
||I haven't inspected the source code in detail but could it be OSCRouteObserver::send_trim_message() and OSCRouteObserver::send_gain_message() which both seem to use "/strip/name"?|
||Yes, that is by design. When you move the fader or the trim control, both of which are positional, the strip name temporarily changes to the dB value of the control. After a timeout, the name is again displayed. When banking, as a new strip is displayed both the fader and trim value are effectively changed and so display briefly at that time.|
I see this behaviour in the OSC messages but I question its validity. Is this coded to work with a specific OSC surface / application / workflow?
In the OSC application I am developing, I want to keep the channel name showing and if I wanted to implement the functionality described here I could do so using the gain / fader messages and an timer within the OSC app. The current behaviour seems to force a control surface to behave one way which may not be ideal for all control surfaces.
If you are adamant that this current behaviour must be retained then may I suggest a switch be added to enable this behaviour as it is not necessarily intuitive or expected behaviour and I have not seen it documented elsewhere? Such a switch could be added to the feedback configuration (including set_surface).
||Use db values (/strip/gain -- gain mode 0) and this is switched off. I will look at making it switchable. The way I look at it, someone who is using fader position values has no feedback as to what the actual gain value is. Temporarily changing the name to gain value gives this feedback. (the mackie control and others use this method as well) Those who are using /strip/gain are setting and getting feedback in dB values already. Most people feel this is important information, I guess you have an application where this is not the case.|
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.
|2017-06-25 10:36||riban||New Issue|
|2017-06-27 15:59||riban||Note Added: 0019818|
|2017-06-30 00:58||ovenwerks||Note Added: 0019832|
|2017-06-30 00:58||ovenwerks||Status||new => resolved|
|2017-06-30 00:58||ovenwerks||Resolution||open => no change required|
|2017-06-30 00:58||ovenwerks||Assigned To||=> ovenwerks|
|2017-06-30 07:52||riban||Note Added: 0019834|
|2017-06-30 07:52||riban||Status||resolved => feedback|
|2017-06-30 07:52||riban||Resolution||no change required => reopened|
|2017-06-30 22:11||ovenwerks||Note Added: 0019839|
|2017-06-30 22:11||ovenwerks||Status||feedback => resolved|
|2017-06-30 22:11||ovenwerks||Resolution||reopened => no change required|
|2020-04-19 20:18||system||Note Added: 0023757|
|2020-04-19 20:18||system||Status||resolved => closed|