View Issue Details

IDCategoryLast Update
0007360bugs2020-04-19 20:18
ReportersapistaAssigned Toovenwerks 
Status closedResolutionfixed 
PlatformLinuxOSArchLinuxOS Version
Product Version5.X git (version in description) 
Fixed in Version 
Summary0007360: OSC fader automation not working for touch mode
DescriptionBug discovered in the new 5.9 version, the first one providing automation through OSC.
When a track is set to Touch automation mode Ardour doesn't accept any incoming message to control the fader and overwrite the automation curve. The purpose of touch mode should be to override a part of an automation curve as long the fader is touched. The current implementation doesn't allow to modify the fader position.
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 1
4. Then test that ardour faders are capturing fader osc messages, for example:
    oscsend localhost 3819 /strip/fader if 1 0.5
5. Set a fader to touch mode and play an automation curve.
6. test again to set fader valu to overwrite the automation curve, for example:
    oscsend localhost 3819 /strip/fader if 1 0.2

The result, ardour faders don't modify the automation curve
TagsNo tags attached.



2017-05-15 22:29

reporter   ~0019700

/strip/fader/touch has yet to be added. It is coming though.


2017-05-16 14:07

reporter   ~0019703

commit f2aac0bca adds /strip/fader/touch, /strip/gain/touch, /select/fader/touch and /select/gain/touch. I can not think of any reason to add feedback for touch.


2017-05-22 20:52

reporter   ~0019730

Just testing this feature and I'm not able to control the touch mode using the given commands in ardour 5.9.13 (downloaded today from nightly). I've been trying:
/strip/gain/touch i strip_ssid
/strip/gain/touch if strip_ssid 0 or 1 to enable or disable the touch for a given channel

Ardour log response is always "Unhandled OSC message"

Please can you provide more details about the osc touch messages?


2017-05-22 21:21

reporter   ~0019732

Try /strip/gain/touch ii ssid touch
or /strip/gain/touch/<ssid> i touch
where touch is 1 for start touch and 0 for end touch.


2017-05-24 20:34

reporter   ~0019738

Still not working here using the last nightly build (5.9.2)
OSC fader automation is working perfectly in all modes except the touch message. Ardour log reports the following line:
[INFO]: Unhandled OSC message: /strip/gain/touch i:1 i:1

The same tested for fader mode instead of gain mode produces the same results:
[INFO]: Unhandled OSC message: /strip/fader/touch i:1 i:1

I'm missing some configuration or something?


2017-05-24 21:03

reporter   ~0019739

commit 1e95ccf fixes this. touch was working, but the logger was wrongly showing "Unhandled" even though the message had been handled correctly.


2017-05-29 22:14

reporter   ~0019758

Tested today using Ardour 5.9-41 from nightly and still having the "unhandled" message for touch osc messages. Moreover, I think that the touch mode is still not working correctly.

When you draw a fader automation curve (for example using write mode) then this curve is reproduced properly under touch mode and an OSC controlled fader. However, when fader is touched (/strip/fader/touch ssid 1 send) to modify the automation curve it only works for a while. In my opinion, the expected behavior should be:
1- A fader automation curve is being played in touch mode.
2- The sound engineer realizes that the fader must be changed for a passage, so he touches the fader.
3- The /strip/fader/touch message is send to alert Ardour that a fader is being touched.
4- The sound engineer moves the fader in order to overwrite a part of automation curve while the fader is being touched. Here many /strip/fader messages are send to Ardour with new fader position values.
5- The sound engineer released the fader and the /strip/fader/touch ssid 0 message is send, so Ardour keeps playing the previously recorded automation curve.

What is actually happening: Steps 1 to 4 are working fine, but after a few seconds Ardour starts to play back the previous automation curve long time before than receiving the /strip/fader/touch ssid 0 message. I'm missing something? Should I send a "/strip/fader/touch ssid 1" message before every "/strip/fader ssid value"? This make no sense to me because, when a fader is touch, it is touched for a while, a song passage, the chorus part or whatever.

Please, can this be checked? Or in case I'm wrong, can you explain me how the touch mode is supposed to works? Thank you so much.


2017-05-30 17:14

reporter   ~0019760

Someone asked me to add fake touch... that is in touch mode a fader move even without touch will act as if touch had been sent and will release after a time out. A true touch signal _should_ disable this action and the fader control remain in touch until a touch = 0 is received. I think I need to add a "has_touch" variable to each surface. I have only been able to test this with oscsend/oscdump so far and with those it seemed to work as it should even if the touch message gets sent after the first fader move. My testing program does have touch added, but I have not DL a new version yet. I will do more testing when I do.


2017-05-31 15:17

reporter   ~0019762

Can I assume you are using open stage control? I just down loaded and built open stage control with touch on the faders. What I found was the same problem as you were having. After trouble shooting what I have found is that open stage control sends /strip/gain/touch as ff rather than ii. With 1 and 0 there is no problem... (touch on/off), but with the ssid I get a huge number and so no valid strip. I am pretty sure the author of open stage control would be willing to fix it... however, It doesn't matter if ssid and/or touch are int or float for this purpose so I will change Ardour to accept both.


2017-05-31 16:23

reporter   ~0019763

Noop, I'm actually trying it with my own python code. Just a quick and easy way to test OSC using GTK buttons and sliders. I'll verify this issue with ff or ii. As long as python is not a strongly typed language it may be some issue with that. Anyway, if Ardour accepts both it will be fantastic.


2017-05-31 16:47

reporter   ~0019764

Commit d35dfa9c9 should allow both ssid and touch to be either float or int. This works for me. Please test.


2017-06-21 19:09

reporter   ~0019802

Just tried it out again in Ardour 5.10 and I'm afraid to say that is still not working properly.
I'm still getting the message: "Unhandled OSC message: /strip/fader/touch i:1 i:0" in Ardour's log, doesn't matter if I send an int or a float value. But, the worst part is that it seams to be working even worst than before.

The /strip/fader/touch seams to do nothing. Instead, I can manipulate the automation curve due to the fake-touch thing. However, when the timeout kicks in the ardour fader goes to its previous value no matter if I send the /strip/fader/touch before or not. Moreover, it is even more strange. Because when I release the fader (sending /strip/fader/touch ssid 0) then the ardour's fader jumps to the last real-fader value. It seams that there is a mess between the fake timeout and the real touch events.

Please, consider testing it more carefully by just drawing an automation curve, and then manipulating it with the touch-fader system. To present the issue more clearly, I made a drawing from an screenshot, please check it out at:


2017-06-21 21:37

reporter   ~0019803

Unable to view the screen shot.
It does for sure work with floats here:
[INFO]: OSC: /strip/gain/touch f:4 f:0
[INFO]: OSC: /strip/gain/touch f:4 f:1
And int:
[INFO]: OSC: /strip/fader/touch i:4 i:0
[INFO]: OSC: /strip/fader/touch i:4 i:1
[INFO]: OSC: /strip/fader/touch f:4 f:0
[INFO]: OSC: /strip/fader/touch f:4 f:0
[INFO]: OSC: /strip/fader/touch f:4 f:1
fails to work with mixed:
[INFO]: Unhandled OSC message: /strip/fader/touch i:4 f:0
[INFO]: Unhandled OSC message: /strip/fader/touch i:4 f:1
and it does not handle two touches in a row:
[INFO]: OSC: /strip/fader/touch i:4 i:1
[INFO]: Unhandled OSC message: /strip/fader/touch i:4 i:1
because it finds out we are already touching.
Mixed float and int (either way) should work that is a bug.

However you say you were using ii which does work. Perhaps the messages you are seeing are a result of sending two (or more) touch on messages in a row.

I have done most of my testing with /strip/gain/touch ff and the fake touch does not interfere with the touch signal at all. I can touch, move and hold the fader and automation will stay at the held level. Releasing touch will go to the previously written automation. (yes I did test this before) If I did the same without touch, moving and holding the fader would timeout as expected. As long as the touch signal is less than a second after a fader touch, no fake touch things happen. Testing just now using oscsend shows /strip/fader/touch works as well. No mess between touch signal and fake touch working at all. The fact that "Moreover, it is even more strange. Because when I release the fader (sending /strip/fader/touch ssid 0) then the ardour's fader jumps to the last real-fader value." seems to indicate that touch is working correctly in your case as well. The fact that the fader "jumps" to the last written value when you release touch with no delay is both correct action (touch released is = play) and no delay means no fake touch. your assertion: " I can manipulate the automation curve due to the fake-touch thing." seems incorrect.

If you expect the fader to stay at the last touched level when released, then write mode seems to be what you would use because if the fader stays at the last touched level that would indicate that the fader level is continuing to write.


2017-06-21 23:13



2017-06-21 23:22

reporter   ~0019804

After some more deep testing and reading your comments I've been able to track down the issue. /strip/fader/touch ssid 1 is only working properly if both values are floats, same for /strip/gain/touch.

I've tested it using oscsend and my one code using pyliblo. Same results:

This works properly:
$ oscsend localhost 3819 /set_surface fffff 0 7 3 1 0 0
$ oscsend localhost 3819 /strip/fader/touch ff 1 1
$ oscsend localhost 3819 /strip/fader if 1 0.5
$ oscsend localhost 3819 /strip/fader/touch ff 1 0

This also works properly:
$ oscsend localhost 3819 /set_surface fffff 0 7 3 0 0 0
$ oscsend localhost 3819 /strip/gain/touch ff 1 1
$ oscsend localhost 3819 /strip/gain if 1 0.5
$ oscsend localhost 3819 /strip/gain/touch ff 1 0

But using int instead of float doesn't work:
$ oscsend localhost 3819 /set_surface fffff 0 7 3 0 0 0
$ oscsend localhost 3819 /strip/gain/touch ii 1 1
$ oscsend localhost 3819 /strip/gain if 1 0.5
$ oscsend localhost 3819 /strip/gain/touch ii 1 0
This produces the same behavior as described in the attached picture (now I've attached it at the top of that thread)

At least now I can make it work properly using float numbers. Another strange thing is related with /set_surface message. Since Ardour 9.10 I'm not able to config the surface using that message and integers anymore. But with floats is working fine. Is this a bug?

Thank you so much for your work.


2020-04-19 20:18

developer   ~0023751

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 21:05 sapista New Issue
2017-05-15 22:29 ovenwerks Note Added: 0019700
2017-05-16 14:07 ovenwerks Note Added: 0019703
2017-05-16 14:07 ovenwerks Status new => resolved
2017-05-16 14:07 ovenwerks Resolution open => fixed
2017-05-16 14:07 ovenwerks Assigned To => ovenwerks
2017-05-22 20:52 sapista Note Added: 0019730
2017-05-22 21:21 ovenwerks Note Added: 0019732
2017-05-24 20:34 sapista Note Added: 0019738
2017-05-24 21:03 ovenwerks Note Added: 0019739
2017-05-29 22:14 sapista Note Added: 0019758
2017-05-30 17:14 ovenwerks Note Added: 0019760
2017-05-31 15:17 ovenwerks Note Added: 0019762
2017-05-31 16:23 sapista Note Added: 0019763
2017-05-31 16:47 ovenwerks Note Added: 0019764
2017-06-21 19:09 sapista Note Added: 0019802
2017-06-21 21:37 ovenwerks Note Added: 0019803
2017-06-21 23:13 sapista File Added: osc_touch_mode_failure_ardour9.10.png
2017-06-21 23:22 sapista Note Added: 0019804
2020-04-19 20:18 system Note Added: 0023751
2020-04-19 20:18 system Status resolved => closed