View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004265 | ardour | bugs | public | 2011-08-13 05:13 | 2012-06-18 23:21 |
| Reporter | lhm100 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Target Version | 3.X | ||||
| Summary | 0004265: Touch and automation issues | ||||
| Description | Several 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). | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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! |
|
|
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. |
|
|
Absolutely true... My thought was for motorized faders only... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-08-13 05:13 | lhm100 | New Issue | |
| 2011-08-13 13:13 | cth103 | cost | => 0.00 |
| 2011-08-13 13:13 | cth103 | Target Version | => 3.0-beta1 |
| 2011-08-13 16:25 | paul | Note Added: 0011326 | |
| 2011-08-13 20:11 | lhm100 | Note Added: 0011331 | |
| 2011-08-13 23:23 | paul | Note Added: 0011333 | |
| 2011-08-13 23:32 | lhm100 | Note Added: 0011334 | |
| 2011-11-15 15:13 | cth103 | Target Version | 3.0-beta1 => 3.0 |
| 2012-06-18 23:21 | cth103 | Target Version | 3.0 => 3.X |
