View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004265ardourbugspublic2011-08-12 22:132012-06-18 16:21
Assigned To 
PlatformOSOS Version
Product Version 
Target Version3.XFixed in Version 
Summary0004265: Touch and automation issues
DescriptionSeveral functionality issues.
1) Touch mode does not record "touches" from midi control surface -only from GUI.

2) While looping in touch mode, end of loop should "apply" any touch changes to the automation curve like pressing stop and then looping again does.

3) When a track is in MANUAL or WRITE mode, feedback to that midi CS fader should be disabled - the fed-back values create a feedback that cause the user to need to fight the fader motor (or maybe an option to disable the output in these states).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
paul (administrator)
2011-08-13 09:25

the main set of devices for which Ardour's generic MIDI support was designed to support do not send any information that would allow touch to be supported - you cannot tell when the user has started and ended a "move".

supporting devices that can do this (i.e. they send separate messages to say "i've been touched", "value change", "i've been untouched") is a work in progress.

the other two items would be much better off broken out into their own bug reports. item (2) will be very hard to "correct" with the current design for automation, because updating the automation information is inherently a non-realtime safe thing, and so cannot be done as part of audio processing.
lhm100 (reporter)
2011-08-13 13:11

OK, I'll move #2 and #3 to their own requests.
As for the touch functionality, how about an algorithm like this for touch mode:

Play the existing automation curve (just like it does now).

Save the CS supplied "new" fader data in a separate buffer. This data will have the "commanded" data from the "play" as echoed back through the midisend-motor-resolver-midireceive loop. AND iw will contain any "Touched" data where the user overrode the fader motor and forced another setting. (The capture of this data is exactly what WRITE mode does now - just to a different "touch buffer")

When the transport is stopped, compare the new fader record with the original, and anywhere they differ by more than some "delta" counts, the new values overwrite the old. And this merged result becomes the new automation curve.

In an ideal world you could just use the new record- as it would have the old and new data. However, the resolvers can dither between counts, and there is a
time lag during transitions, so every time you did a touch pass, the "original" values would change a little bit and corrupt the original curve.

Ardour would need to sense the condition that "transport just stopped and at least one track was in touch mode" in order to cue the data merge.

Hope I expressed this idea in a comprehensible way... I know what I mean!
paul (administrator)
2011-08-13 16:23

what you've described won't work for an awful lot of generic MIDI control surfaces. they are (1) not motorized (2) don't send back incoming values.
lhm100 (reporter)
2011-08-13 16:32

Absolutely true... My thought was for motorized faders only...

- Issue History
Date Modified Username Field Change
2011-08-12 22:13 lhm100 New Issue
2011-08-13 06:13 cth103 cost => 0.00
2011-08-13 06:13 cth103 Target Version => 3.0-beta1
2011-08-13 09:25 paul Note Added: 0011326
2011-08-13 13:11 lhm100 Note Added: 0011331
2011-08-13 16:23 paul Note Added: 0011333
2011-08-13 16:32 lhm100 Note Added: 0011334
2011-11-15 07:13 cth103 Target Version 3.0-beta1 => 3.0
2012-06-18 16:21 cth103 Target Version 3.0 => 3.X

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker