View Issue Details

IDCategoryLast Update
0007405bugs2017-06-30 22:11
ReporterribanAssigned Toovenwerks 
Reproducibilityalways 
Status resolvedResolutionno change required 
Platformx86-64OSWindowsOS Version7
Product Version5.10 
Fixed in Version 
Summary0007405: OSC feedback sending wrong values for /strip/name
DescriptionOSC 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 ReproduceConfigure 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 Information2nd value is actually the value of the fader.
3rd value is actually the value of strip Trim.
TagsNo tags attached.

Activities

riban

2017-06-27 15:59

reporter   ~0019818

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"?

ovenwerks

2017-06-30 00:58

reporter   ~0019832

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.

riban

2017-06-30 07:52

reporter   ~0019834

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).

ovenwerks

2017-06-30 22:11

reporter   ~0019839

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 History

Date Modified Username Field Change
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