Request, post 5.50 - FR for automation items, not automation containers (DONE)

[mccrabney]

this is a bummer for multiple reasons, foremost among them is that it
doesn't solve the issue of envelopes stealing one's ability to control
FX parameters by midi cc. from the beginning, the attractive idea behind
automation envelopes was that envelopes would be DISABLED while not contained
within an item, leaving the parameter able to be controlled by a midi CC
that was learned to the parameter. currently, as soon as you enable an
envelope, any learns that you have set up are overriden. this absolutely sucks
for live performance.

it's also a visual nightmare for the instances where you're applying a
track volume fadeout but you only need the envelope to be active/visible
at the start/end of the project. item envelopes are not an adequate solution
to this problem because of slicing etc, this isn't 90s, and items get cut
up a LOT.

this issue was raised, seconded, thirded, and discussed multiple times in
the pre-release forum, so here i am again. i'm sure that this is going to
be an issue for many people who expected one thing from these "Automation
items" and got something else -- automation containers, which are very well
implemented and useful in their own right.

however, these do not fulfill the request as discussed in the pre-release thread.

[schwa]

The major issue here, as discussed during the prerelease cycle, is that it would introduce non-deterministic playback. If you want the automated parameter to behave as if there were no envelope outside of automation items, then the project will sound different depending on what time position playback is started from, and potentially different when replaying from the exact same time position.

As a specific example: if a parameter's default value is 0, and there is an automation item starting on bar 3 containing a single point with value 0.5, then playing back the project from the start will cause the parameter value to be 0 for the first 2 measures, then change to 0.5 and stay there. If you then play the project back from the start, the parameter will remain at 0.5 and the project will sound different.

This behavior is not impossible to implement, but it does require introducing a new non-deterministic mode that is really only useful for live performance.

[EvilDragon]

What if...

Envelopes could "chase" the values like CCs do? Areas outside of automation items in this case would be in perpetual touch mode (if I'm understanding correctly), so touch would work in tandem with chase - if you move the automated parameter via MIDI or otherwise, that's the new value to be chased, until the next playback pass, at the very least.

[mccrabney]

Originally Posted by schwa

it would introduce non-deterministic playback.

midi ccs already do this, and have since the 80s. but that's not the point, even though it is already the case in REAPER, so it shouldn't be a conceptual problem...

If you want the automated parameter to behave as if there were no envelope outside of automation items, then the project will sound different depending on what time position playback is started from, and potentially different when replaying from the exact same time position.

deterministic solution, as discussed during the prerelease cycle -- seek previous envelope value and play from there. envelope is disabled in-between, and allow midi ccs to continue to control the parameter as learned.

This behavior is not impossible to implement, but it does require introducing a new non-deterministic mode that is really only useful for live performance.

the request isn't necessary for non-deterministic behavior, though that shouldn't be as wild as it seems to be given that again, midi sequencers have been doing non-deterministic parameter control since the 80s. but again, that's not the request. the request is and has been disabled envelopes in between automation data so that our midi cc learns aren't useless.

[mccrabney]

can we just forget this whole non-deterministic mode sidetrack??? that whole thing is a secondary FR to the main FR, which is automation items that only provide automation data within the automation bounds -- otherwise there IS NO AUTOMATION and your midi learns can do their job.

that was the FR and that is why the automation items FR has not been fulfilled yet.

[schwa]

Originally Posted by mccrabney

can we just forget this whole non-deterministic mode sidetrack???

It's not a sidetrack. In order for playback to be deterministic, parameter values would need to be chased on seeking or restarting playback. There is a fair amount of non-trivial logic in REAPER to ensure that MIDI CCs are chased properly in this situation. That logic would need to be added to FX parameter automation, and would be even less non-trivial, because parameter automation is affected by parameter modulation, parameter linking, etc.

It really isn't just a matter of turning off envelopes outside of automation items -- the other piece needs to be added, or playback will no longer be deterministic. It's not a red herring, honest.

[mccrabney]

Originally Posted by schwa

In order for playback to be deterministic, parameter values would need to be chased on seeking or restarting playback.

good, perfect, do it! and leave non-AI territory uninhibited by automation! chase it! this was the FR to begin with.

There is a fair amount of non-trivial logic in REAPER to ensure that MIDI CCs are chased properly in this situation.

props to fighting that battle, i didn't know that. anyone coming from a background of hardware midi sequencing wouldn't expect deterministic interpretation of ccs. added bonus. i haven't discovered that because i shirk from using ccs in reaper because i prefer using automation for a variety of reasons. and thus, i'm back to the same issue that i started this FR with.

chase previous value. that was the FR, if it was ever unclear. DISABLE envelopes in between AIs, seek previous automation data for deterministic playback, and don't show an envelope where one is not active.

do this:



don't make me fill the entire bathtub. let me use the ccs i learned. please. that was the FR. dare i say, this is the AI FR for the entire electronic genre.

again, schwa, let me say that your automation editing platform is GREAT. i really hope that my issues don't override how much i like and truly admire the work you've done. i don't want to be the analogy guy but i asked for a shovel and you provided a terrific trowel, i'm truly going to love using it but it isn't the shovel i hoped for.

[EvilDragon]

Paramter modulation/linking IS going to fill the bath tub, if it's used. No matter what - can't chase in that case. Just hope you're aware of that.

[jm duchenne]

Originally Posted by mccrabney

as promised, i'm here to complain that the automation items provided
in REAPER 5.5 do not fulfill the feature request.

here is a metaphor to help explain what's wrong here:

imagine that your reaper project is a bathtub and that your automation
item is a cup of water that you can move around inside the project.
here is the expectation. you can put your cup of water in the bathtub
and do whatever you want in the space around this cup of water.

and here is what we got with REAPER's automation items: you have to
fill the entirety of your bathtub with an amount of water in order to
even consider putting the cup in there.

this issue was raised, seconded, thirded, and discussed multiple times in
the pre-release forum, so here i am again. i'm sure that this is going to
be an issue for many people who expected one thing from these "Automation
items" and got something else -- automation containers, which are very well
implemented and useful in their own right.

however, these do not fulfill the request as discussed in the pre-release thread.

+ 1000 !

I was happy to see some work on "automation items", but very dispointed that they were NOT automation items, just boxes to give a better control on Automation Lanes (which is obviously usefull for many users).
So I am glad to see that the discussion is not closed

But for me, I continue to use CC MIDI items, which are not perfect, but work as I expect : items that contain all the automation informations in one single object, that can be easily and freely moved, resized, splitted, time-stretched, duplicated, that can share the same track with the audio items with which it can be grouped or not, and that can be unfolded to the full screen for precise editing of its automation lanes.

[HighVoltage]

Originally Posted by mccrabney

this is a bummer for multiple reasons, foremost among them is that it
doesn't solve the issue of envelopes stealing one's ability to control
FX parameters by midi cc. from the beginning, the attractive idea behind
automation envelopes was that envelopes would be DISABLED while not contained
within an item, leaving the parameter able to be controlled by a midi CC
that was learned to the parameter.

THIS!!!! A THOUSAND TIMES THIS!!!

I was so happy for this new feature and then found out as soon as i enable any automation my FX parameter gets stuck! It's just absolutely unintuitive. This just kills the automation items incredible potential.

I understand why this is happening, but there should be at least an option for people who hate this behavior.

I have one solution in mind:
If you enable an automation lane for a parameter, but haven't written anything to the lane:
There is only one single point of automation and that is at the exact point of the start. At absolute 0. Reaper would interpret this as there is no automation yet, so it lets you move the parameter, and the line moves with it. Basically you can control the zero point's value with the knob (or CC).
A soon you write to the Envelope lane, things gets fixed. But if you decide to delete every point, but only leave the 0 point (which you have to anyway) Then you gain back the control.
Reaper could show this as a dashed line, or something to get even visual feedback.

It wouldn't break the current workflow for anyone, cause if they just want a static envelope, they would not use automation anyway just leave the parameter alone.
Or in extreme or unknown cases, they will just add another point the lane at the beginning, or better yet, just move the zero point from 0.

Option 2:
Just have an option somewhere in the envelope menu, to disable/bypass non-automation envelopes.

[MikComposer]

This is the effect of reaper team trying very hard to reinvent the wheel. I really wish they'd just check how other teams did it, and copy with improvements. But as it is right now, frankenreaper's code is not flexible enough. I wish the guys would rewrite reaper for r6, designing its code from ground up to be as modular as possible, so they can implement new features in complete forms, cause right now from what I am seeing everything is added trough finding a way around some other design limitations. Latest update is the first reaper update I am skipping in fear it will make things even more convoluted.

[EvilDragon]

Wow, you're so wrong

You don't HAVE to use automation items. Old behaviors still apply.

Also recoding 10+ years worth of code for v6 just isn't going to happen.


Also, it's like you're not reading what schwa said that the request mccrabney posted is impacted by other features like parameter modulation, so it isn't as straightforward or "how other guys did it" as you think.

[deeb]

Originally Posted by EvilDragon

Wow, you're so wrong
..
Also recoding 10+ years worth of code for v6 just isn't going to happen.

since you are not one of the coders ! probably you don't know what you are saying

[EvilDragon]

Recoding means working from scratch. You cannot make 10+ years worth of code in one year, it doesn't take one to be the actual coder of the program to make that statement and for that statement to be true. But actually I do know a few things about programming, since I do a form of it for living as my dayjob, so I do know what I'm saying.

So yes - it's NOT going to happen.

[deeb]

Originally Posted by EvilDragon

Recoding means working from scratch. You cannot make 10+ years worth of code in one year, it doesn't take one to be the actual coder of the program to make that statement and for that statement to be true. But actually I do know a few things about programming, since I do a form of it for living as my dayjob, so I do know what I'm saying.

So yes - it's NOT going to happen.

Well i know coding too but i don't agree with you.

[MikComposer]

Most of those 10 years was spent figuring out how to implement new features within program limitations they themselves created when designing reaper without proper design plan, and then cleaning up bugs that mostly were caused by those overdone implementations. They could rewrite all of it in a new way, once they do proper design document with properly designed, streamlined features, within 6 months.

[deeb]

Originally Posted by MikComposer

Most of those 10 years was spent figuring out how to implement new features within program limitations they themselves created when designing reaper without proper design plan. They could rewrite all of it in a new way, once they do proper design document, with properly designed features, within 6 months.

i don't agree either! Reaper is the best DAW i found just a small stones in the shoes here and there but is ridiculously well done. Nobel for Reaper Heads!

[schwa]

[mccrabney]

that's one nice looking cup in a nice looking tub.

[MikComposer]

Originally Posted by deeb

i don't agree either! Reaper is the best DAW i found just a small stones in the shoes here and there but is ridiculously well done. Nobel for Reaper Heads!

I wouldn't not say reaper is ridiculously well done. Cpu use is good, which obviously is due to programmers knowing how to write efficient software, but on the ux side sound related side, its one of the worst programs I have ever used. And in a short deadline real life scenario that really is bad.

[EvilDragon]

So why the fuck are you still using it then

Originally Posted by MikComposer

Most of those 10 years was spent figuring out how to implement new features within program limitations they themselves created when designing reaper without proper design plan, and then cleaning up bugs that mostly were caused by those overdone implementations. They could rewrite all of it in a new way, once they do proper design document with properly designed, streamlined features, within 6 months.

Sorry, but that's bullshit.

[mccrabney]

don't answer that, and everyone stop derailing an important thread.

[MikComposer]

Are we going personal again?

It's not a bs, it's true. You can see it trough the way it is designed.

[HighVoltage]

Originally Posted by schwa

This is great(!!), but i would very much prefer that Reaper would remember the last parameter position if NOT over an Automation Item. (in your case it would snap back to ~260Hz after the item is over)

Example:

I have cutoff set to 0.3 manually
An automation item overrides this, but it's last point is 0.8
As soon as the item is out of play cursor, the cutoff resets to 0.3
This way it solves the non-deterministic issue too.

At least this is my real life scenario:

Im working on a part of a song, and i have decided to make the bass in the chorus with high resonance and more saturation. I could add those tweaks as automation items, and yet i can still tweak my parameters, cause i'm undecided for the rest of the track.
With this case every time i play that part, it would mess up my "default" settings for the rest of the song.
So i agree with you on the deterministic aspect, but my solution would be simply reaper remembering the parameters position, and jumping back if the automation item is over.

Another example is if i want just one little part of the vocal to have a huge delay send, so i put an automation item there. But im still working on the track and the mixing, and i'm undecided about how much delay the rest and most parts of the vocals would have, so this way i'm not locked to the automation lane.

I think this is the way Live and Bitwig works, but i can't check now.

Sorry for the long post.

[schwa]

Originally Posted by HighVoltage

This is great(!!), but i would very much prefer that Reaper would remember the last parameter position if NOT over an Automation Item.

You can have that behavior now, if you set "automation items do not connect to the underlying envelope" and set the underlying envelope to a flat line at 0.3 (or 0.5, I think you have a typo in your post).

This suggested behavior would really only be for live performance.

[EvilDragon]

Of course, what you showed there, schwa, won't be possible as soon as parameter modulation is in the picture, yeah? How about parameter linking?

[schwa]

Originally Posted by EvilDragon

Of course, what you showed there, schwa, won't be possible as soon as parameter modulation is in the picture, yeah? How about parameter linking?

If parameter modulation or linking is enabled, then I think this option ("envelope does not exist outside of automation items" or whatever) would be disabled.

[EpicSounds]

would someone really use automation items and parameter mod at the same time?

[EvilDragon]

I guess not, yeah.

[vitalker]

Originally Posted by schwa

...

Great! Now it behaves as expected.

[mpl]

Just read the thread...

So it looks closer to FL studio automation in these points:

• allow AI to latch value at their right edge
• allow AI overwrite in real time ParamMod, Learn
• disable visually underlying envelope (or make it uneditable, transparent and following latched values from right edges of AIs)
• add an option to set init value for parameter (to solve non-deterministic area problem before first automation item)
• when recording, and envelope armed, write automation item
  

If so, I would use that mode.

[Sju]

Originally Posted by mpl

disable visually underlying envelope (or make it uneditable, transparent and following latched values from right edges of AIs)

I was also hoping that this could be implemented somehow. I tend to accumulate a lot of envelope lanes, and the rows upon rows of (unused) sections of automation lanes kinda clutter up the arrange view.

[mccrabney]

Originally Posted by Sju

I was also hoping that this could be implemented somehow. I tend to accumulate a lot of envelope lanes, and the rows upon rows of (unused) sections of automation lanes kinda clutter up the arrange view.

agreed, and even if this is merely cosmetic, it is a reason why this will be useful/preferable in more than just live performance use cases.

If parameter modulation or linking is enabled, then I think this option ("envelope does not exist outside of automation items" or whatever) would be disabled.

makes one wonder if "Parameter Modulation Items" would be a good feature companion for Automation Items. PMIs would be items wherein parameter modulation is active for a specified parameter. outside of these items, behavior would be similar to that requested in OP.

though really, i foresee automation items (with above requested behavior) taking the place of about half of my usage of parameter modulation.

[Scoox]

In FL Studio each automated parameter has to be initialized to determine its value before the first automation item. After the first automation item, in the absence of automation items the parameter value is the last value of the last automation item.

Here's my solution: Have a checkbox to enable/disable "Hybrid automation mode" (HAM). It goes like this:

HAM enabled:

With HAM enabled, Reaper works like it does now, that is, the main envelope and automation items coexists happily on the same track, with automation items always taking precedence.

HAM disabled:

1) Reaper hides the main automation envelope from view. The envelope is not deleted though, and can be displayed again later by re-enabling HAM.

2) The automation value to the right of an automation item is always the last value of said item. This value stays fixed indefinitely or until another automation item is encountered further down the timeline. The fixed value is represented by a horizontal segment.

3) The value to the left of the first automation item is always equal to the first value of said item. If no automation items exist yet, the automation track is deemed to be uninitialized (it literally contains no data), and its effect on the target parameter is identical to the effect of the automation track not existing at all, in other words, the target parameter is not affected until some automation points exist.

4) If an automation item is drawn using the mouse over a section of an empty automation track (Alt+Drag), again, no data points exist yet therefore the conditions described in 3) still apply. Parameter automation is effective if and only if at least one automation point is present.

5) If all points are subsequently deleted, automation for this parameter returns to the uninitialized state and the target parameter remains at the value that was in place at the the instant the last automation point was deleted. Obviously, users are able to manually tweak the parameter (with the mouse etc while in the uninitialized state).

I'm sure I'm missing something but as far as I can see this approach could work.

[ferropop]

Originally Posted by mpl

Just read the thread...

So it looks closer to FL studio automation in these points:

• allow AI to latch value at their right edge
• allow AI overwrite in real time ParamMod, Learn
• disable visually underlying envelope (or make it uneditable, transparent and following latched values from right edges of AIs)
• add an option to set init value for parameter (to solve non-deterministic area problem before first automation item)
• when recording, and envelope armed, write automation item
  

If so, I would use that mode.

This is exactly how it should be.

I'm not 100% on the proposed option for initial value -- it should either assume zero, or the Left Edge of the First AI. If you wanted to force a different initial value, just put a tiny AI at the beginning to initialize to it.

[Scoox]

Originally Posted by ferropop

This is exactly how it should be.

I'm not 100% on the proposed option for initial value -- it should either assume zero, or the Left Edge of the First AI. If you wanted to force a different initial value, just put a tiny AI at the beginning to initialize to it.

As I proposed, there's no need for either an initial value. If no automation points exist yet, the target parameter is simply not affected. Also note that initially there are no AIs so you can't use thefirst point. Assuming zero (or any other fixed value) wouldn't be a good idea, since merely creating the automation track would cause the target parameter to jump to the init value, which in many cases could be undesirable.

[mccrabney]

or the Left Edge of the First AI

this is the one. otherwise if you seek mid-AI, your params may be different than you expect. unless i'm missing something in your post, Scoox, it doesn't account for this scenario (reacomp used as example)

this is the first AI in the project. note that clicking in the AI and then clicking outside of the AI results in the last AI value remaining in place.



(as option as always) i think the best behavior would be that clicks BEFORE the AI (marker 1-2) should result in chase to the first AI point on track (0). clicks AFTER the AI (and any subsequent AI til end of project) should result in last AI automation point (in this case 100% of param value)

this solves any issues with stopping/seeking in the middle of AI playback, solves any determinism concerns, etc.

[Win Conway]

Asked for this with the very first AI pre, finally !!!!!

[mccrabney]

^ i knew the nut would get cracked eventually. persistence, good communication, popular appeal, luck -- all of these things are worthless. it's all about bathtub metaphors and shitty illustrations, nas.

electronic genre / hip hop music producers are getting to be a larger userbase for REAPER
i have only produced full songs on 2 daws in my 16 years of music production. tried several daws, but only casually. i've only ever written completed music on Acid Pro 2.0, 3.0, 4.0, 5.0, and reaper 2.0, 3.0, 4.0, and 5.0

anytime i play alongside people, they're always excited to see something other than ableton being used.

[inarisound]

Originally Posted by mccrabney

^ i knew the nut would get cracked eventually. persistence, good communication, popular appeal, luck -- all of these things are worthless. it's all about bathtub metaphors and shitty illustrations, nas.

I need to try that!!!! maybe my <3 devs will take a look on my RF and we can improve Midi Editor once and 4 all !!!! xD