done: option: disable "return speed" and leave envelope at last-changed value

[mccrabney]

RESOLVED in Reaper 6.76! thank you!
toggle OFF: Options/Preserve trailing values when recording automation

__EDIT__
for those reading, you can track other posts on this issue here:

the most detailed post in tips/tricks: https://forums.cockos.com/showthread.php?t=252010
a bug report: https://forum.cockos.com/showthread.php?t=273056
another bug report, from 2017: https://forum.cockos.com/showthread.php?t=192204
a post in general: https://forum.cockos.com/showthread.php?t=254798
a feature request: https://forum.cockos.com/showthread.php?t=251752
a "why is this happening" thread: https://forum.cockos.com/showthread.php?t=190663
a post in newbieland: https://forum.cockos.com/showthread.php?t=274395
__END__



i just stumbled on the "return speed" setting in the Automation preferences and realized that i reported a "feature, not a bug."

https://forum.cockos.com/showthread....80#post2343980

FR: an option to disable this "return" option: return OFF.

if i'm recording automation, i don't want a return to the previous value -- i want the parameter to stay where i left it.

[mccrabney]

so nobody is latch recording automation directly into AIs?

why does REAPER assume that the user wants their automation data to start/end at the same value?

[mccrabney]

this "return speed" setting is such a bizarre choice for default behavior. i see the singular use case (recording in the middle of a project, where a user wants to return to the exact previous setting), but that seems like it should defer to the user's choice. shouldn't it be at least a toggle behavior, as opposed to the only behavior?

in the simple example of a user recording a fadeout, why would the user expect a "return" to the starting value? in that case, there would be no return. if the user brings the fader down to position 0, that's where the automation should stay.

conversely, if i'm recording a pass where i'm increasing a one-instance reverb wetness from 0 - 100%, i wouldn't want the automation curve to zip back down to 0 after i'm done.

[mccrabney]

imagine if midi CCs did this in the MIDI editor when you tried to record them from a controller

[mccrabney]

imagine if when you were recording audio, it recorded a second "into the future" and overwrote any audio you already had in your project

[mccrabney]

here, i have an existing AI that i don't want touched. it exists immediately after a time selection/loop, in which i want to record a volume AI.

note what happens when the "return speed" option extends beyond the loop bounds: the existing AI gets overwritten, even though the play cursor never reaches that area.



i cannot overstate how weird it is to have content recorded ahead of the record cursor and to have that be the only option.

[deeb]

Hope they get this fixed !

[airon]

+1

I assume you'd like a separate setting for automation items and normal track/fx envelopes. Sounds good to me, judging by your examples.

[mccrabney]

Originally Posted by airon

I assume you'd like a separate setting for automation items and normal track/fx envelopes. Sounds good to me, judging by your examples.

i just want what i record to be accurately reflected, and not suffixed by this weird assumption that i want to "Return" to my starting value.

edit: i made this graphic, i hope it helps to demonstrates the problem:

[mccrabney]

can't record a fadeout AI - the simplest of automation shapes, and we can't record it because it gets suffixed with automation return nonsense...

[deeb]

reaper is amazing .. strange in some simple things and workflow and that's odd.

[mccrabney]

here's something you can't do using automation record that you CAN do in the MIDI editor.



we just want it to behave like this. no return speed. no floating value ahead of the cursor. the value stretches from current write position to next CC position or end of project. simple. sensible.

forgive my frustration, but it's legitimately alarming that this has been the case in REAPER forever -- and that so few users are in the position to complain about it. i've got mountains of controllers with controls i can't use with REAPER's automation.

the forum noise about this issue is disproportionately low vs how big of a problem it is.

[mccrabney]

worse than strange. automation recording in REAPER is essentially broken.

i don't see how anyone is recording small (NOT project-wide) automation movements, even when they're not recording directly to AI. "Automation: Write current values for all writing envelopes to [position option]" is not a good solution.

recording automation should write whatever point you've left it at, horizontally, until the next automation point or the end of project automatically. just like midi ccs. any additional "return speed" feature should be optional for those ten people that want it, and who had the dev-ear when this was being worked on ~ten years ago

[deeb]

This is just one issue , there are several similar odd things. Automation editing is very painful.. meanwhile developement is always going on but with no look back. Dots are missing. And consistent workflow is super precious.

[TonE]

I like threads, if the starting situation is explained clearly and fully, so there is no room for guessing. Then, anyone can try to give suggestions, improvement ideas, alternatives, workarounds. If not, readers need to do guesswork first, this might be correct or not, also usually not fun doing guesswork at all, and so on.

Anyway. I would like to know for example.
1. What are your track settings?
2. What are your global automation recording settings?
3. Is looping on? Meaning will you loop multiple rounds, and do automation recording there, all the time, and want a specific behaviour also for this looping scenario?
4. What is working so far well, for your scenario?
5. What is not working so far, from your experience so far (it could be wrong used techniques, or missed techniques, ignored alternatives and so on)?
6. Improvement suggestions, from your perspective?
7. Screenshots, gifs, youtube of all above.

[TonE]

Originally Posted by mccrabney

so nobody is latch recording automation directly into AIs?

For me also most used scenario is usually latch automation recording, also in looping scenarios. And here I still need to find some workarounds, against "overwriting previous automation recordings", but still being able to loop, and staying in flow of latch automation writing. Maybe I need this feature, return to automation, which is kind of disturbing in your situation?

[mccrabney]

Maybe I need this feature, return to automation, which is kind of disturbing in your situation?

if you're loop recording automation using a time selection, your "return" is outside of your loop bounds, because that's where REAPER inserts automation -- ahead of the record cursor. regardless of what is already there.

there are plenty more screenshots, gifs and documentation in the bug report thread linked in the first post of this thread, answering your questions.

there's also more on this issue posted here:

https://forum.cockos.com/showthread.php?t=252010

including this gem that shows how broken this is for loop recording:

[TonE]

Yeah, this loop recording scenario looks like my problem as well. If I record a performance, it could be 8 minutes or longer, recorded in real-time, on all hardware controls. I would like to loop this entire thing, then, doing live automation "adjustments" here and there. But most importantly: Without destroying the original, previous performance (all the written automation). Thus, there needs to be an automation return function. I found a solution. Whenever you trigger latch automation and want to reset it, just hitting pause, then play, will reset latch automation, it will wait for next controller, without overwriting previous automation. I thought, maybe there is an internal Reaper setting, which does something like this automatically. Resetting latch, after each "latch entering, if for some amount of time, there is no control input", it should reset latch, waiting for new control input, without overwriting.

My main point is more "entering latch", then after some time in control inactivity, auto-resetting latch, thus no overwriting of automation then.

To make life and understanding of devs easier, it would help, showing two parallel diagrams, left (how it is behaving currently, the problem), right (how it could be, solution idea). For each step, having left and right sides. So devs would exactly know what they should implement, or not, or if possible to solve, or not.

[mccrabney]

TonE, that isn't the issue we're talking about here. sorry.

[mozart999uk]

+1 for this please!

[airon]

Originally Posted by mccrabney

i just stumbled on the "return speed" setting in the Automation preferences and realized that i reported a "feature, not a bug."

https://forum.cockos.com/showthread....80#post2343980

FR: an option to disable this "return" option: return OFF.

if i'm recording automation, i don't want a return to the previous value -- i want the parameter to stay where i left it.

I suggest the automation return function not be used on automation items being newly created. When you're recording a new item, what are you returning to ?

Lose the automation return on new automation items and make that thing optional, including a toggle action whose state can be indicated on a toolbar button. And I'd suggest adding such a toggle action for vanilla automation recording as well.

[vitalker]

This behavior is highly unexpected.

[airon]

For folks recording to automation items by default, this request would actually make that workflow far more efficient and usable.

The transition time of automation items already takes care of "going back" if need be.

The automation return time is quite useless for automation items when newly recording them. Removing this hangover bit adds a chore for the user. The request makes this better.

[mccrabney]

the request goes for normal, full pressure, track wide envelopes, too - having the value snap back to the original value only fits a very narrow workflow. otherwise, the forums would be full of requests for MIDI CC recording to behave the same way - they're not, because people don't want that. i can't find one request for "CC return"

automation is no different in regards to user expectation. it's too bad that the wheel got re-invented, but this is wrong.

this is a lamp that only stays on when you're holding the switch.

[Croquis]

Bumping this and vouching for this once again. I think the 'lamp that only stays on when you're holding the switch' analogy is a perfect explanation of the issue here.