View Issue Details

IDProjectCategoryView StatusLast Update
0007359ardourbugspublic2020-04-19 20:18
Reportersapista Assigned Toovenwerks  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSArchLinuxOS Versionup2date system
Product Version5.X git (version in description) 
Summary0007359: OSC feedback for fader automation not working properly on fader mode.
DescriptionThe following has been tested on Ardour 5.9 obtained as the binary installer from ardour.org site.

When a OSC control surface is set to use /strip/gain instead /strip/fader using the OSC message /set_surface with last parameter set to 0 the automation feedback is not working as expected:
 - For Manual and Write modes ardour can be controlled using /strip/gain ssid level_dB. The ardour osc feedback is also reporting the correct values of dB through the message /strip/gain

- For Play and Touch mode, ardour's feedback is always through the message /strip/fader independently of the selection made by /set_suface command. Also, if the surface mode is set to gain, the feedback in these automation modes reports the correct gain level but using the /strip/fader message, which is wrong to report dB values.
Steps To ReproduceIt can be easily reproduced using the oscsend and oscdump commands:
1. Start a terminal and open a oscdump session: oscdump 8000
2. Start Ardour and configure the OSC surface properly.
3. Start a second terminal and send the osc setup message:
    oscsend localhost 3819 /set_surface iiii 0 159 3 0
4. Then test that ardour faders are capturing gain osc messages, for example:
    oscsend localhost 3819 /strip/gain if 1 -10
5. Set a fader to play or touch mode and play an automation curve. It can be seen in the oscdump output as fader movements are send in the described wrong format. This is using the /strip/fader instead of /strip/gain
TagsNo tags attached.

Activities

ovenwerks

2017-05-16 00:44

reporter   ~0019702

Commit fee4b7b3ea6079c should have fixed that. It would have been in 5.9... but we had power out and the router here did not boot when the power came on.
Please test a nightly tomorrow.

sapista

2017-05-22 20:53

reporter   ~0019731

I confirm that this has been fixed in 5.9.13. Thank you!!!

ovenwerks

2017-05-22 21:23

reporter   ~0019733

Commit fee4b7b3ea6079c fixes this.

system

2020-04-19 20:18

developer   ~0023750

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.

Issue History

Date Modified Username Field Change
2017-05-15 20:56 sapista New Issue
2017-05-15 22:34 ovenwerks Status new => assigned
2017-05-16 00:44 ovenwerks Note Added: 0019702
2017-05-16 00:44 ovenwerks Status assigned => feedback
2017-05-22 20:53 sapista Note Added: 0019731
2017-05-22 20:53 sapista Status feedback => new
2017-05-22 21:23 ovenwerks Note Added: 0019733
2017-05-22 21:23 ovenwerks Status new => resolved
2017-05-22 21:23 ovenwerks Resolution open => fixed
2017-05-22 21:23 ovenwerks Assigned To => ovenwerks
2020-04-19 20:18 system Note Added: 0023750
2020-04-19 20:18 system Status resolved => closed