Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 06-13-2018, 12:25 PM   #41
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Holy smokes, I just remembered another possible help for Andy -- he can use Take Envelopes. It actually behaves the way you want in the sense that the envelope is ATTACHED DIRECTLY to the item/take, so it will ONLY move if the item moves.... RIPPLE ALL TRACKS mode does NOT affect it the same way... see image below:

fetidus is offline   Reply With Quote
Old 06-13-2018, 12:30 PM   #42
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
Could you describe one? I can't think of any.
VCA, bus and FX automation where there is NO item attached. But agree it is a finely edged sword.
Quote:
Originally Posted by EricTbone View Post
If you draw a volume envelope under vocal line A, then through ripple editing it gets dragged underneath vocal line B, when is that ever going to be what you want?
In that case you split, use PER-ITEM ripple, subprojects, or item/take envelopes!


Quote:
Originally Posted by EricTbone View Post
It has a rule that can be described that lets you predice what will happen, but wouldn't say it's logical to move automation out from other the data it was drawn for.
Ha! I like the way you think. But there's a cruel and perfect logic to it the way it is. If it is a piece of data, WHATEVER it is, it gets moved, if it shows up AFTER the leading edge of the selected item. I like that. Simple. Clean. There's no mystery. Yes, it can cause headaches. Use the power with caution. The other things we're talking about are great *options* IMO.
fetidus is offline   Reply With Quote
Old 06-13-2018, 12:52 PM   #43
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by fetidus View Post
VCA, bus and FX automation where there is NO item attached.
Right, but always moving all affected data (including partial items) handles that case, too.

What we're talking about is the case where there is an item and Reapers move automation data out from under that item. You said "there are scenarios when it makes great sense". I'm trying to think of some and can't.

Quote:
Originally Posted by fetidus View Post
he can use Take Envelopes
That's a great idea, but not a slam dunk solve because they are more limited:
  1. Can't be used for track FX.
  2. Gluing items destroys track envelopes.
  3. Can't use automation items or LFOs.
  4. Editing them can be a bit quirky. I routinely put ReaControlMIDI on MIDI items so I can draw pitch changes via a take FX envelope, and run into issues likes node not getting deselected when they should. I have to use right-click menu far more when editing take envelopes. Fairly minor issue, though.
EricTbone is offline   Reply With Quote
Old 06-13-2018, 01:07 PM   #44
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
Right, but always moving all affected data (including partial items) handles that case, too.

What we're talking about is the case where there is an item and Reapers move automation data out from under that item. You said "there are scenarios when it makes great sense". I'm trying to think of some and can't.
Right, but you can also have stuff INSIDE the bus/folder/vca tracks if you want to (or by accident), due to the agnostic track system in Reaper (which is great BTW), in which case we run into the scenario when there MAY or MAY NOT be items inside the track, and so the condition that it currently sets is to universally move any data that starts AFTER the leading edge of the selected item, period. So for me, it makes complete sense as-is.


Quote:
Originally Posted by EricTbone View Post
That's a great idea, but not a slam dunk solve because they are more limited:
  1. Can't be used for track FX.
  2. Gluing items destroys track envelopes.
  3. Can't use automation items or LFOs.
  4. Editing them can be a bit quirky. I routinely put ReaControlMIDI on MIDI items so I can draw pitch changes via a take FX envelope, and run into issues likes node not getting deselected when they should. I have to use right-click menu far more when editing take envelopes. Fairly minor issue, though.
All great points, and I agree, take envelopes are not a slam dunk for Andy. Just another option to help out.

And he could move some track fx to item/take FX BTW... and yes, they are more fiddly, and yes, they would require some changes to his workflow.

There is no perfect solution.

I think the FR for an option is a great direction though. Like I said, adding more power to the Ripple Edit modes is awesome, I'm all for it. I do like your suggestion of the auto-split as an option... that's pretty good. But it will create its own set of headaches and messes. Lots of little bits and pieces of items all over the place if you get sloppy.

In any case, bottom line is that there are several ways to skin a cat, and you/we have to pick the workflow that works best for us. I guess I'm so used to the way the Ripple Edit modes work, that I've just got into the habit of splitting, being very careful at edit points, double-checking things (incl automation if I have a lot of it), using the different ripple modes, etc... when I contrast this to doing something similar in Cubase, for example, Reaper is MUCH faster and less prone to headaches. But it's not perfect.
fetidus is offline   Reply With Quote
Old 06-13-2018, 01:34 PM   #45
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by fetidus View Post
the condition that it currently sets is to universally move any data that starts AFTER the leading edge of the selected item, period.
This data is not being moved, and it breaks automation:



To recap the chain of discussion, so you can better understand what I'm asking:

I said that moving automation data away from the item data it was written for is bad behavior.

You said "there are scenarios when it makes great sense".

I asked if you could describe one, because I couldn't think of any.

You said "where there is NO item attached".

I replied that this is not relevant to the question, which is specifically about item data (non-item data, aka automation, already moves, so it's not a problem).

I can see the value in always moving all data together. What I can't see is the value in moving some of the data. I'm trying to think of scenarios where this makes sense and can't, but you said there are scenarios where it makes sense.

Can you share one?
EricTbone is offline   Reply With Quote
Old 06-13-2018, 02:00 PM   #46
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
This data is not being moved, and it breaks automation:

Maybe I misunderstand what you're referring to, and I looked back on the gif on the previous page... but this makes complete sense to me... the data that is NOT moved is the audio item part of a loop, which is part of the item that begins BEFORE the item selected on the lower track. So the automation data moves (since there is a point in the right range), but the looped material itself does NOT move, since it's part of a item that is outside the range.

I totally understand how this is not optimal in many scenarios -- or perhaps most scenarios that you might use.

Quote:
Originally Posted by EricTbone View Post

To recap the chain of discussion, so you can better understand what I'm asking:

I said that moving automation data away from the item data it was written for is bad behavior.

You said "there are scenarios when it makes great sense".

I asked if you could describe one, because I couldn't think of any.

You said "where there is NO item attached".
Right, that is poor wording on my part, and an incomplete thought. I tried to clarify in my follow-up response that sometimes there are items on those bus/VCA/folder tracks due to the track-agnostic nature of Reaper. Hope that makes more sense.

Quote:
Originally Posted by EricTbone View Post



I replied that this is not relevant to the question, which is specifically about item data (non-item data, aka automation, already moves, so it's not a problem).

I can see the value in always moving all data together. What I can't see is the value in moving some of the data. I'm trying to think of scenarios where this makes sense and can't, but you said there are scenarios where it makes sense.

Can you share one?

I'll do a gif... give me a few minutes... but again, bus/VCA/folder automation that is on a bus/VCA/folder track WITH an item.
fetidus is offline   Reply With Quote
Old 06-13-2018, 02:08 PM   #47
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

This is an example of where this makes sense as-is.... the parent folder track (bus) has its own automation but ALSO has an item in it. Tracks 2 and 3 are part of the folder... and the parent track automation moves WITH the split contents of the child tracks.

EDIT: And BTW, the items IN the parent track (or VCA, bus, etc.) might be in that track muted, for alignment (I love using it for alignment with the semi-transparent background of the whole folder contents!), or by accident. In all cases, the ALL TRACKS ripple mode moves just the same stuff every time, no worries.

Again, I'm totally for the FR of adding options!


Last edited by fetidus; 06-13-2018 at 02:16 PM.
fetidus is offline   Reply With Quote
Old 06-13-2018, 03:07 PM   #48
andyp24
Human being with feelings
 
Join Date: Mar 2016
Posts: 549
Default

Here's my take on it....

If an envelope point on a track lane is underneath (ie occupying the same moment in time) as an Item, then it "belongs to it" and should always move with the item whether that move is manual or the result of a Ripple. This applies whether the item moves left to right (ie in time) or up and down (from track to track).

If an envelope point on a track is not underneath an Item, then it is "free" and should Ripple according to the current rule. This works in the case of your Buss/Folder FX described above.

There will be some "edge cases" such as where two items on a track occupy the same point in time (e.g. a crossfade or complete overlap). Simple logic could be applied here - e.g. the envelope point belongs to the item that begins first. Also what happens if an Item is placed over a "free" point - does the item remain free, or get inherited by the item (I prefer the first).

But despite these complexities I think this would be a much better solution overall.
andyp24 is offline   Reply With Quote
Old 06-13-2018, 03:12 PM   #49
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by Judders View Post
This is an example of where this makes sense as-is.... the parent track automation moves WITH the split contents of the child tracks.
But we've already established that the automation should move, and it already does, so it's not what I'm asking about.

The question is when it's desirable to not also move the item data associated with that automation.

For example, let's say I've drawn some volume data over notes to make them decay more rapidly than normal. This is contrived, but an example of how automation is something you draw to against audio data to achieve an effect:



Now, if ripple worked as I proposed, where automation and data always move together, it would look like this:



Resulting in this:



To me, that seems like what you'd always want.

Instead what happens is that my automation data is moved out of correlation with the data it was written for:



Resulting in this:



I can't come up with a scenario where you'd actually want this. The only situation I can think of is if the automation data was something like an LFO, where it didn't correlate with the audio at all, in which case it's not that it would actually be preferable, it's just that you wouldn't care.

Anyway, that's the question. You said there are "scenarios when it makes great sense" and I'm just trying to imagine what they are.
EricTbone is offline   Reply With Quote
Old 06-13-2018, 03:38 PM   #50
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
But we've already established that the automation should move, and it already does, so it's not what I'm asking about.

The question is when it's desirable to not also move the item data associated with that automation.

For example, let's say I've drawn some volume data over notes to make them decay more rapidly than normal. This is contrived, but an example of how automation is something you draw to against audio data to achieve an effect:



Now, if ripple worked as I proposed, where automation and data always move together, it would look like this:



Resulting in this:



To me, that seems like what you'd always want.

Instead what happens is that my automation data is moved out of correlation with the data it was written for:



Resulting in this:



I can't come up with a scenario where you'd actually want this. The only situation I can think of is if the automation data was something like an LFO, where it didn't correlate with the audio at all, in which case it's not that it would actually be preferable, it's just that you wouldn't care.

Anyway, that's the question. You said there are "scenarios when it makes great sense" and I'm just trying to imagine what they are.

Right, did you see my last post? I already posted a GIF with one of the scenarios. That GIF shows a parent folder track/bus WITH an item in it, and also WITH bus automation that I DO want to follow along with the ripple, but I do NOT want the item inside the parent folder track/bus to move.

With your change, the default behavior would then make the automation in the parent folder track/bus NOT move. That is NOT the behavior I want.

And BTW, I have NO problem with what you are suggesting as an OPTION. I can see using it both ways.

Last edited by fetidus; 06-13-2018 at 03:45 PM. Reason: damn spelling
fetidus is offline   Reply With Quote
Old 06-13-2018, 03:45 PM   #51
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by andyp24 View Post
Here's my take on it....

If an envelope point on a track lane is underneath (ie occupying the same moment in time) as an Item, then it "belongs to it" and should always move with the item whether that move is manual or the result of a Ripple. This applies whether the item moves left to right (ie in time) or up and down (from track to track).

If an envelope point on a track is not underneath an Item, then it is "free" and should Ripple according to the current rule. This works in the case of your Buss/Folder FX described above.

There will be some "edge cases" such as where two items on a track occupy the same point in time (e.g. a crossfade or complete overlap). Simple logic could be applied here - e.g. the envelope point belongs to the item that begins first. Also what happens if an Item is placed over a "free" point - does the item remain free, or get inherited by the item (I prefer the first).

But despite these complexities I think this would be a much better solution overall.
I disagree with changing the default behavior, and it does NOT work with my example scenario GIF I posted. However, like I've said a few times, I'm totally for adding this behavior as an option.

IMO, the automation data does NOT belong to the item... in fact, technically, those are NOT items guys... those are *TAKES*. The automation we have been talking about belongs to the TRACK. And thus, as TRACK data, it makes complete sense the way it works now. Your workflow just doesn't have an optimal use case for it as-is, so I totally understand having an option that works better for your common workflows. But it will break other workflows. I've already shown one example that will be broken by your workflow change, so it should be optional. And I do like the option very much.

If you want automation to belong to a TAKE, then you can use TAKE envelopes, which WILL behave like you want (although, with limitations as Eric has rightly pointed out).

As for "edge cases," those are not edge cases for me... those are common cases for me. Right now, the logic for breaking up envelopes and automation data (and even automation items) is very logical. But again, I'm totally for your option.

Last edited by fetidus; 06-13-2018 at 03:50 PM.
fetidus is offline   Reply With Quote
Old 06-13-2018, 03:51 PM   #52
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by fetidus View Post
also WITH bus automation that I DO want to follow along with the ripple, but I do NOT want the item inside the parent folder track/bus to move.
Sorry, you didn't say that so I had no idea that's what you meant.

That still doesn't answer the question, which is why you don't want that data to move? What real world scenario would result in you wanting to ripple edit your entire project, rearranging audio data across all tracks along with its automation data, but have one piece of audio that should not move with respect to everything else?

My example is a real world scenario, what I have to imagine is by far the most common case.

Quote:
Originally Posted by fetidus View Post
I disagree with changing the default behavior.
You appear to be taking this as antagonism, but I'm honestly just trying to understand that. As I said, I can't think of a scenario where you'd want that default behavior. Your answer, if you think about it, has simply been to say "but imagine I wanted that behavior? Then I'd want it." I'm trying to understand why you'd want that behavior. What real world ripple-editing workflow would result in you wanting to move automation data independent of the audio it's affecting? What's in that data? Presumably this has actually happened to you. What was the situation?

I'm not saying that scenario doesn't exist, only that I can't think of it.

Last edited by EricTbone; 06-13-2018 at 04:01 PM.
EricTbone is offline   Reply With Quote
Old 06-13-2018, 04:08 PM   #53
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
Sorry, you didn't say that so I had no idea that's what you meant.

However, the question remains. Why wouldn't want that to move? What real world scenario would result in you wanting to ripple edit your entire project, rearranging audio data across all tracks along with its automation data, but have one piece of audio that should not move with respect to everything else?

My example is a real world scenario, what I have to imagine is by far the most common case.



You appear to be taking this as antagonism, but I'm honestly just trying to understand that. As I said, I can't think of a scenario where you'd want that default behavior. Your answer, if you think about it, has simply been to say "but imagine I wanted that behavior? Then I'd want it." I'm trying to understand why you'd want that behavior. What real world ripped editing workflow would result in you wanting to move automation data independent of the audio it's affecting?
Not taking it as antagonism at all, apologies if it comes across that way. This is just an intelligent discussion about a feature.

As for having no idea that's what I meant -- I had posted the GIF so I thought it would show enough detail with the folder, etc... and again, apologies for not being more detailed in my description before. I hope it's more clear now.

Like I mentioned, there are definitely scenarios where this current behavior is fine and valuable as-is -- I showed one already. It's more common with my projects than perhaps other people, but I tend to nest folders/buses, and buses can contain items/takes as well. I use that for alignment (really great for lining up transients), I might have a video clip or other reference track in there that I don't want to move, which could prove *disastrous* if I accidentally move the whole track, knocking my project out of alignment, and yet I still want to move the automation in the track. So it's working great as-is. Or perhaps I might have *accidentally* moved something into that folder/bus parent track and then that would then force the automation data NOT to move if the default behavior was as you want. And so forth with VCA too, etc. I can probably come up with grouping examples, automation item examples, etc...

And again, I stress that the automation data is NOT attached specifically to an item or take... technically it is attached to the TRACK. So as track data, it is independent of the items/takes. It just so happens that quite a bit of our workflows assume they are integrally related, so it has a nice default behavior when you move an item, the automation underneath moves. But that's still not fully the item's automation, even if we perceive it as such. When you ripple, the demarcation point is absolute at the beginning of the selected item, and ALL TRACK ripple mode does *exactly* that -- it ripples ALL TRACK data... and thus all data flows from that initial point. It's track data, not item or take data, so it should ripple. And it's logical that way, at least to me, and it's been the default behavior for many years. You guys seem to be very focused on the idea that the automation data belongs exclusively to the item/take. But again, it's track data.

Sure, your scenario make sense as well, and that's why I would be really happy to have the option you are talking about. You guys can set up your Reaper to have that as your default option, and you'll be happy. I can keep the old behavior and I'll be happy. If I want to switch modes, I'll go trigger your mode. There's really nothing lost here. I'm not misunderstanding what you want, why you want it, or its worth. I'm just disagreeing that it should replace the current behavior or be default behavior (unless you select it in your settings to be your personal default).

Last edited by fetidus; 06-13-2018 at 04:15 PM.
fetidus is offline   Reply With Quote
Old 06-13-2018, 04:45 PM   #54
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by fetidus View Post
I had posted the GIF so I thought it would show enough detail with the folders, etc...
Sorry, you said you didn't want the item on the bus to move, but not why, which was my question.

I'm trying to understand how this applies to the real world.

Quote:
Originally Posted by fetidus View Post
I might have a video clip or other reference track in there that I don't want to move, which could prove *disastrous* if I accidentally move the whole track, knocking my project out of alignment, and yet I still want to move the automation in the track.
That's a "why"! That finally gives me idea of what you're talking about.

However, if you really have an item that must remain inviolable, like a film that you're scoring and not allowed to rearrange, I think it would be much better to not run audio through it, lock it, and choose "locked items are unaffected by ripple" in the options.

"Ripple edit all tracks" rearranges data across all tracks. It moves all audio data and automation. If you insert or delete data, it will carve right through your reference track with no regard for your desire to keep it safe:



To me, cutting an item while rippled editing so that all data across all tracks is moved (unless the data is locked) would be far more consistent with the current insert/delete behavior and would be conceptually simpler. All data to the right of the selected item moves, rather than "all data to the right of the selected item, unless that data is part of an item that extends even one pixel to the left of the selected item, in which case none of that data moves."

Quote:
Originally Posted by fetidus View Post
So it's working great as-is.
Yeah, I guess we're just going to have to disagree on that. IMO, the behavior is so bad in the general case that I thought for sure the OP's report was a bug, and I still can't think of a scenario (yet) that wouldn't be better solved by others means.

Just my opinion. *shrug*
EricTbone is offline   Reply With Quote
Old 06-13-2018, 05:38 PM   #55
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by EricTbone View Post
Sorry, you said you didn't want the item on the bus to move, but not why, which was my question.
I did say why -- "alignment," explicitly. It's right up there in that post. I wrote the post at 5:08pm, and then edited it at 5:16, but maybe you missed it. You replied at 6:12, but maybe you had a cached version in your browser. So let's assume you missed it.

Quote:
Originally Posted by fetidus View Post
(I love using it for alignment with the semi-transparent background of the whole folder contents!)

Quote:
Originally Posted by EricTbone View Post

I'm trying to understand how this applies to the real world.
That example was real-world, but now we're going in circles. I mentioned it at least twice, but apparently we're having communication difficulties. I take full responsibility for at least 50% of that problem.

Quote:
Originally Posted by EricTbone View Post

That's a "why"! That finally gives me idea of what you're talking about.
We're getting somewhere!

Quote:
Originally Posted by EricTbone View Post

However, if you really have an item that must remain inviolable, like a film that you're scoring and not allowed to rearrange, I think it would be much better to not run audio through it, lock it, and choose "locked items are unaffected by ripple" in the options.
Sure, there are many ways to do many things in Reaper, with tons of workflows. We don't all do things the same way. What you are suggesting overall seems to be to *replace* an old behavior that has been there for many years (as a bug by your reasoning) with a *new/different* behavior. I have no problem with your *new/different* behavior in principle as I've said many times... but just as an *option*, not as a *replacement*. No problem here. Not sure why we can't bridge this gap.

Quote:
Originally Posted by EricTbone View Post

"Ripple edit all tracks" rearranges data across all tracks. It moves all audio data and automation. If you insert or delete data, it will carve right through your reference track with no regard for your desire to keep it safe:
Right. I actually don't use ripple editing for inserting stuff very often, but it is totally logical behavior when it splits and pushes everything out of the way. In that case, you are correct, it would create problems with the reference track. I'm used to that. I simply switch to PER TRACK ripple and repair that reference track. And as I've mentioned, you can multi-select with PER TRACK mode, and deal with several tracks at once. Not a biggie for me.

However, the key word is "track" and the automation we're talking about is explicitly called "track automation envelopes" and the behavior makes sense (again, to me) since the ripple feature in question is called "ripple editing all tracks" -- what's confusing about that?

And again, each TAKE has its own set of automation that behaves basically like you want with "take envelopes," so why do we need TWO "take envelopes"? Because you are in effect wanting to change existing behavior of how ripple editing handles "track envelopes" into how it already handles "take envelopes." To me, that's illogical. But again, we're going in circles.

Right now the behavior doesn't make sense to you. But it does make sense to me, etc. So we don't agree, but are we really at an impasse? Obviously, Justin thought about this feature when he wrote it years ago, he must have thought it was logical at some point. But I also like your idea, so why not have both behaviors available?

Quote:
Originally Posted by EricTbone View Post

To me, cutting an item while rippled editing so that all data across all tracks is moved (unless the data is locked) would be far more consistent with the current insert/delete behavior and would be conceptually simpler. All data to the right of the selected item moves, rather than "all data to the right of the selected item, unless that data is part of an item that extends even one pixel to the left of the selected item, in which case none of that data moves."
I respectfully disagree here for default behavior, because to me, just moving items with ripple editing does not imply a cut. It only implies a cut when pasting at a point that would naturally split something. And you can still manually split something and get what *you* want. Again, I refer back to the concept that the automation data is track data, not item/take data. And again, why not have both behaviors?


Quote:
Originally Posted by EricTbone View Post

Yeah, I guess we're just going to have to disagree on that. IMO, the behavior is so bad in the general case that I thought for sure the OP's report was a bug, and I still can't think of a scenario (yet) that wouldn't be better solved by others means.

Just my opinion. *shrug*
Agreed, we'll just have to disagree. No biggie of course. I'm still for a FR though. What I don't understand is why you haven't indicated that you're open to having both as an option? Even if you find the "old" behavior as a perplexing, bug-like, illogical "bad" mess, it's already been in there for many years and some people are very used to it, so you'd disrupt their normal usage. I've simply said several times, I like the behavior you're talking about as an option. There is plenty of precedent in Reaper for preserving old behavior as options and/or introducing new behavior as options. So what's the problem with that?

Last edited by fetidus; 06-13-2018 at 05:52 PM.
fetidus is offline   Reply With Quote
Old 06-13-2018, 08:56 PM   #56
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by fetidus View Post
Sure, there are many ways to do many things in Reaper, with tons of workflows.
The implication is that they're all equally effective, which is not always true.

Quote:
Originally Posted by fetidus View Post
What you are suggesting overall seems to be to *replace* an old behavior that has been there for many years (as a bug by your reasoning) with a *new/different* behavior.
Appeal to tradition carries no weight with me. More to the point, I never argued that it should be a new default, which you seem to be taking me to task for.

For the record, I do think it would have been a much better default -- because it's conceptually simpler (provable; the behavior definition has fewer terms) and its more consistent with ripple insert and deletes -- however, it's a potentially breaking change now for people expecting the previous behavior, so it should be a non-default option.

Quote:
Originally Posted by fetidus View Post
the key word is "track" and the automation we're talking about is explicitly called "track automation envelopes"
This is a weak argument, IMO. Tracks don't make sound on their own. Media items do. Even on a bus, automation is modifying the audio at a position on the track, which is a function of media items on that track (or bussed to it) at that position. If you move audio and automation independently, it's almost always going to break the automation.

Your scenario -- where you have a reference track that you don't want changed -- is an exception, not the rule.

Quote:
Originally Posted by fetidus View Post
so why not have both behaviors available? Why not have both behaviors?
Why not? I never suggested otherwise.

Anyway, I think Remotemaster's best bet is just to hit S with no media items selected before doing a ripple edit.

Another tool that might help him is regions. It's not the same thing as rippled editing, but if the goal to move some data with its automation intact, it'll do the trick.

Here I'm selection the area I want to move, hitting SHIFT+R to create a region, dragging the region, then ALT+clicking the region to remove it:


Last edited by EricTbone; 06-13-2018 at 10:08 PM.
EricTbone is offline   Reply With Quote
Old 06-13-2018, 09:10 PM   #57
Remotetoaster
Human being with feelings
 
Join Date: Jun 2018
Posts: 9
Default

Thank you EricTbone -

I'm still here by the way, just not quite on the same level as you and fetidus in terms of just how well you both seem to know the ins and outs of Reaper.

I have been picking up on all of these concepts that I was less than familiar with before I started this whole thread - so I thank all of you immensely for the well thought out, obviously well-informed replies all around.

I was thinking of organizing my projects better by using regions, so thank you for placing me on the right path for now.

If you, EricTbone or fetidus are still willing to lend an ear, I didn't want my question from earlier to get lost.

My question was in regard to "track-wide envelopes" and how several users, including fetidus, indicated that my method of placing an effect on a track, then placing a bypass envelope, then placing a new effect whenever needed later on in the track is something of a convoluted way of going about my sound edit/design.

I've been soaking up all the information I can on automation items as a replacement method for my current one, but I'm failing to see how to best use them for my intended purposes.

If someone who's more experienced in using automation items is willing to lend me a hand here, I'd be super grateful - as this thread has already been more than fruitful in my Reaper knowledge and benefiting my overall workflow.

Thank you,
Tom
Remotetoaster is offline   Reply With Quote
Old 06-13-2018, 11:04 PM   #58
EricTbone
Human being with feelings
 
Join Date: Feb 2013
Posts: 230
Default

Quote:
Originally Posted by Remotetoaster View Post
My question was in regard to "track-wide envelopes" and how several users, including fetidus, indicated that my method of placing an effect on a track, then placing a bypass envelope, then placing a new effect whenever needed later on in the track is something of a convoluted way of going about my sound edit/design.

I've been soaking up all the information I can on automation items as a replacement method for my current one, but I'm failing to see how to best use them for my intended purposes.
Sorry, just realized that our little debate was kicked off by andyp24's post, not yours, and has derailed the thread. Your issue doesn't appear to have much to do with ripple editing.

If your primary issue is just the proliferation of automation points, you can run my script to fix that.

As for how automation items could help, they're pretty powerful -- you can stack them, you can save/load them, run LFOs on them, etc. -- but I rarely use them for those reasons. The main reason I use them is that they're often a bit easier than fiddling with a bunch of individual points.

For instance, if I want to reduce the volume under a section of a track, you have to draw several points. To extend the side you have to drag-select all the points on that side. To move the whole thing, you have to drag-select all the points.



In that case, I'll use an automation item because you can draw it instantly and it's easier to manipulate:



It's less helpful for bypass envelopes.
EricTbone is offline   Reply With Quote
Old 06-13-2018, 11:24 PM   #59
Remotetoaster
Human being with feelings
 
Join Date: Jun 2018
Posts: 9
Default

Thank you for the reply, EricTbone

I will certainly be using automation items in the future over four points.

I will also be using sub-projects on a scene by scene basis for the rest of my work for films as to minimize convolution of envelopes and envelope points as fetidus suggested way back.

As far as you can tell for my current workflow, do you think my current method of adding an FX to a track, then a bypass envelope for said effect, then moving on to whatever desired next effect/action is the best method by your judgement? Or do you think there is a better way to do this?

The bypass envelope method I'm using was taught to me by sound editing Prof in Pro Tools, so that's why I use it. However I am more than aware that Reaper is far more flexible program and there may be a way to streamline this process further with the help of some power users out there.

That being said, if you think my method is all fine and good, then cheers.

Thanks for all the help once again,
Tom
Remotetoaster is offline   Reply With Quote
Old 06-14-2018, 12:07 AM   #60
andyp24
Human being with feelings
 
Join Date: Mar 2016
Posts: 549
Default

Hi all

Yes, it's true - I did derail the thread, but (at least partly) with the best of intentions.... to draw to the OP's attention that there are workflow problems with Automation in Reaper far beyond the one he or she asked about, which may well bite the OP at some point to come.

FWIW I also believe in having "options" for Ripple behaviour with automation. The current behaviour is a nightmare for Radio style editing, frankly, but if it works for some people (perhaps doing bar and beat-based music work?) then fair enough.

What I would actually suggest as a Holy Grail would be something like this:

Another property is added to the definition of an Envelope point (along with its value, shape etc) and that is its "ownership". There could be a Preference which allows the default ownership of a new point to be "Free" (ie as it is currently, related to the track but not items). But there could also be an option to allow points to be assigned ownership intelligently - ie if it is on a track with no item/take above it, then it is Free; if placed on a track underneath an item/take then it is owned by that item/take and always stays in sync with it when the item/take is moved. (There would have to be a logic to decide which of two or more overlapping items to assign it to if they occur on the track).

Additionally, you could Edit the property of any point at any moment, just like you could with its shape etc. So you could right click on it, and "Make point Free", "Give ownership of point to concurrent Item on track", "Give ownership of point to Selected Item" for example. Then if you've created Free points on a Buss track, and later want to tie them to an item you place on the track you could do that.

I think such a system would potentially allow ALL the desired workflows.

To re-iterate - currently Take Envelopes are absolutely NOT the solution to my problem, for several reasons.

- they do not apply to track FX, eg setting the EQ for a collection of items.

- they are individual to each item/take, whereas I might want to use envelopes to set the volume/pan (and automate the parameters) for a section of audio containing 100 items (speech which has been heavily edited for example). To do this with Take Envelopes, I'd need to create one (individually) for each audio item, and set each one. Creating curves which extend across item boundaries is extremely fiddly.

Adding FX to Takes instead of tracks is also not the solution, for similar reasons. Not only do I not want to instantiate 100 copies of every plugin I need on that track for that section, but if I then have to change parameters for all 100 items....? Or introduce more audio to the track and then have to copy the FX from existing items to those new ones without missing anything...? Not workable.

A potential other option which would help in all this though would involve

1) extending the definition of Take FX to allow control of any track FX parameters as well, and

2) creating a proper "non-destructive glue" feature, whereby a load of items could be stuck together in such a way that they appear and act as a single item - have a single shared volume and pan value etc and also a shared take envelope which spans the "glued" items. Unlike actual glued items, though, this could be instantly unglued for later re-editing if need be (which would of course destroy the shared properties, but you can't have everything).

Any or all of these ideas would make Reaper hugely more efficient for people doing my kind of work.

Andy
andyp24 is offline   Reply With Quote
Old 06-14-2018, 12:19 AM   #61
andyp24
Human being with feelings
 
Join Date: Mar 2016
Posts: 549
Default

@RemoteToaster

I've also done film work in Reaper, and agree that a sub-project per scene can be a very useful way to go, both in controlling the problems of large multi-track projects with automation as discussed here, and also reducing CPU count etc when you've got a lot of Reverbs etc required.

You do need to plan carefully though - what about musical cues or FX which go across scene boundaries - where are you going to place those? Do you put the music in the Master Project?

How do you manage the situation when a director wants to tweak the transition between two scenes and you've got them as separate projects? Each tweak to the balance of one scene requires a re-render before you can play the director the transition....

Not saying these are showstoppers, but give it some careful thought how you'll manage this kind of situation before you jump in.

Beware of Automation Items also... if cutting/Rippling you will find they also do some unhelpful things for this kind of work (eg you will suddenly find that an AI for a 10dB volume dip has been split in half, the latter half has Rippled, and where they overlap they add up to a 20dB dip). I really hoped I could use AIs to solve a lot of the problems with "standard" envelope rippling, but I have to say it's not a lot easier - just different difficulties!

As for your bypass workflow - hard to say without seeing examples, but it may be that you can just create new tracks for each different combination of FX rather than automating changes/bypassing - Reaper is rather lighter on its feet CPU wise than PT. Or if it's singe large chunks of audio you need to process, use Item FX to add them specifically to those instead of the track.
andyp24 is offline   Reply With Quote
Old 06-14-2018, 12:39 AM   #62
Remotetoaster
Human being with feelings
 
Join Date: Jun 2018
Posts: 9
Default

Quote:
Originally Posted by andyp24 View Post
@RemoteToaster

I've also done film work in Reaper, and agree that a sub-project per scene can be a very useful way to go, both in controlling the problems of large multi-track projects with automation as discussed here, and also reducing CPU count etc when you've got a lot of Reverbs etc required.

You do need to plan carefully though - what about musical cues or FX which go across scene boundaries - where are you going to place those? Do you put the music in the Master Project?

How do you manage the situation when a director wants to tweak the transition between two scenes and you've got them as separate projects? Each tweak to the balance of one scene requires a re-render before you can play the director the transition....

Not saying these are showstoppers, but give it some careful thought how you'll manage this kind of situation before you jump in.

Beware of Automation Items also... if cutting/Rippling you will find they also do some unhelpful things for this kind of work (eg you will suddenly find that an AI for a 10dB volume dip has been split in half, the latter half has Rippled, and where they overlap they add up to a 20dB dip). I really hoped I could use AIs to solve a lot of the problems with "standard" envelope rippling, but I have to say it's not a lot easier - just different difficulties!

As for your bypass workflow - hard to say without seeing examples, but it may be that you can just create new tracks for each different combination of FX rather than automating changes/bypassing - Reaper is rather lighter on its feet CPU wise than PT. Or if it's singe large chunks of audio you need to process, use Item FX to add them specifically to those instead of the track.
Thanks Andy,

You're totally right, I really need to plan as much as I can to make each project go smoothly, but also not treat every project as the same. Every project requires a slightly different approach to be done right, as you aptly put when it comes to what may seem like small details (scene transitions and musical cues, re-rendering for every minute change, etc) but are really not small details at all.

Guess I'll just have to see how all these things (automation items, ripple editing, sub-projects, etc) work for me so that I can eventually learn when and when not to use them depending on the project/situation.
Remotetoaster is offline   Reply With Quote
Old 06-14-2018, 10:02 AM   #63
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

@Remotetoaster

First, apologies for going off on a tangent in the thread -- glad we can bring it back to your questions.

Re: your questions -- IMO it's really all about finding a workflow that works best for your specific situation. No single workflow will address your needs.

Your professor taught you a workflow that works fine in Pro Tools, but not every workflow maps well from Pro Tools to Reaper. We could "insert other DAW name here" and the points would be similar. Consider this:

Reaper has essentially FOUR families of automation approaches --

1) track automation envelopes
2) item/take automation envelopes
3) automation items
4) parameter modulation (which we haven't discussed in this thread, but is great for fx LFO automation in sound design)

On top of that, Reaper has fully-featured Take FX (which can use #2 item/take automation envelopes.).

Add to that each track is totally agnostic, but even more than that, every track can contain *multiple* types of content on the *same* track, and can do *multiple* things at once... kind of scary, but it has its creative uses.

Pro Tools doesn't get close to that kind of flexibility.

The list goes on and on, and when you factor in things like two ripple edit modes, subprojects, and endless scripting capability, it starts to get insane what you can do.

In other words, for a sound designer, we're talking a completely and utterly different ball game than Pro Tools. So why limit yourself to Pro Tools workflows?

One of the challenges that all this flexibility and power presents to Reaper users is really feature overload! What is the *best* way to do things? Truth is, the best way is the way YOU come up with. And that can be frustrating because there are limitations and trade-offs here and there that you have to find the right balance for.

My sincerest recommendation for your situation is to take some time to get a really good feeling for the above features, and also their drawbacks. Then, build yourself a workflow that takes into account the whole project life cycle from inception to delivery. It will be different than mine. It will be different than your professor who is using Pro Tools (for sure!).

Going back to what your professor mentioned, in my case I wouldn't be following that technique. Honestly, it's old school by now, very prone to issues as we have discussed, lots of limitations, and doesn't take advantage of any of the really cool features of Reaper. For what you describe, I'd personally build my work around Subprojects, Take FX and Take envelopes and use automation items when it makes sense. All that together will be a killer combination, but you'll have to find the right balance with other more traditional features like track automation, etc.

Keep in mind BTW, that you may have to really re-think how you build your projects. If you have repeated sound design elements that need different effects for each instance, then it will be tempting to rely on "old school" methods to do it. I'll give one example:

OLD SCHOOL WORKFLOW:

Let's say you have a laser beam sound you need for a film. It's used over and over, and you obviously need to have variations of it, plus it will be heard in different locations in the film, so you'll need different fx, etc... So one of the old school methods would be to place the same core laser sounds on a track, then automate fx for the different situations/scenes. You could change fx parameters, disable fx plugins, etc. That works, and it leaves a trail of very messy automation behind, plus it's actually tricky to keep track of what is what sometimes. You might need to blow that out to a few more tracks for variations, composites, etc., you might bounce some of them down for variations, then import them, layer them, etc... with still more automaton all over the place... and if you have to make changes to a similar instance of that effect project-wide it can become a nightmare. The project timeline itself looks like a mess, it becomes really hard to "reverse engineer" your own sound design element because you're now generations beyond the first iteration. Just for the laser sound! Obviously, I'm simplifying for this example, but you get the point. Pro Tools users have been working like this for years, and some are really good at it.

So take that laser beam scenario and apply Reaper's amazing and unique tools. There are a dozen ways to do it, but here's one approach I use, which I have found very productive and helps with creativity. I like to break it down into "levels" where I can manipulate the sound in each one of those levels, and always be able to dig back into how I built the sound, while easily changing it and replicating it across the project higher up the chain.

Laser beam example:

NEW SCHOOL POSSIBLE REAPER WORKFLOW:

LEVEL 1 - First, I create the core laser beam sound as a subproject. Inside the subproject I might create 5 copies of that initial core laser beam WAV file and place them on the timeline, spaced about 10 seconds apart. So WAV + 10 seconds of silence + WAV + 10 seconds of silence + WAV + etc., etc... The subproject therefore starts out as the most simple of projects -- 5 copies of a single WAV file on the timeline! Nothing special. These 5 copies of the same core sound will serve as placeholders for creative work later on. I call this file laser1-core. Of course, you can also create five different subprojects too, if you want. I find with sound design, that I like grouping some similar sounds together in the same subproject though. You might like a different approach.

LEVEL 2 - Then, I insert that project into a parent project as a subproject, and it is placed on the timeline as a proxy WAV file with the 5 laser sounds from the subproject. But due to the magic of subprojects, I can then split the proxy WAV file into 5 different items... they now become laser1-1, laser1-2, laser1-3, laser1-4, laser1-5. Those 5 little chunks now serve as the initial starting sound design elements for my laser sounds.

Just from using LEVEL 1 and LEVEL 2 alone, I've already abstracted my laser sound into 5 basic placeholders... I can in fact start copying and pasting those 5 sounds as-is all over the parent project if I want to... again as placeholders.

Then at any time I want to start getting more creative, I can simply open up the LEVEL 1 subproject laser1-core file, and begin some creative awesomeness on each one of the 5 placeholder sounds. Each time I save the subproject -- ALL the placeholders in the parent project -- each instance of each slice of the proxy files -- get updated! Voila, easy, amazing. I can replace every instance of the subproject's proxy file so I can design and automatically replace all related instances without breaking a sweat. I can go crazy inside the subproject and add layers and layers of effects to the sounds, and it all gets replicated out perfectly into the parent project, while keeping the parent project clean and organized.

LEVEL 3 - Back in the parent project, I can then separate out the laser sounds into various tracks/folders, organized approximately by environment. For example, like sounds live with each other, nested in folders/buses as necessary. So I can take advantage of track fx, track automation, buses, etc... like I normally would do with a typical Pro Tools project. So I'll use a bus or track as a place where I set a track fx like a big fancy reverb for when the laser is hear outside. But in another folder/bus/track, I might have a different track fx when the laser is fired indoors. I don't have to do much automation in that case... keep things simple... and at any time I drill back into the subproject to get more creative if needed, and that all replicates right back into the parent project.

LEVEL 4 - But then I can go even further. I can then apply Take FX and Take automation to individual laser shots in the parent project! So at this level, we're literally managing multiple levels of magic... at the take level, the track level, and deep down in the subproject level. The sky is the limit!

But it gets even crazier... let's say I've created an amazing composite of laser effects on level 3 and level 4... it's starting to get wild for a big scene that I then need to replicate for another scene later in the movie, and it's starting to get too messy in the main project. Easy solution... I can select those elements and then bump them out to another subproject... thus nesting subprojects within subprojects! Then I can use, slice, dice, timestretch, and add more fx to THAT proxy file. How amazing is that? I can then reuse my composite (subproject with nested subprojects) anywhere else in the main parent project and keep things nice and organized.

OR, let's say I need a whole new round of laser effects... easy... I can just copy the level 1 subproject, laser1-core, and create laser2-core. Then I can go do all the above with a whole new set of laser sounds. The possibilities are endless. In any one of those levels, you can make use of all four families of automation -- track, take, AIs, and parameter modulations. And if you keep things really organized in your main parent project, user regions, groups, careful use of ripple editing, etc., you won't have to worry about all that automation anxiety crap we've been talking about in this thread. Your parent project will be relatively clean and simple, and you hide the messy creative awesomeness inside the subprojects.

Hope that all makes sense. This is how I approach it, but you could come up with something entirely different. Which you should. I haven't even talked about all the crazy scripting things you can do. The stuff I mentioned above is STOCK REAPER, with NO scripts.

Anyway, good luck with it. Have fun, get creative. And don't take what your professors say as gospel for sure. They have a lot of good things to say, but Reaper development moves faster than college class curriculum.

Last edited by fetidus; 06-14-2018 at 10:08 AM.
fetidus is offline   Reply With Quote
Old 06-14-2018, 10:22 AM   #64
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

@ Andy and Eric -- If you guys create a FR, I'll put in my humble little upvote, for whatever that's worth. I'm a huge fan of options. As long as we aren't replacing default behavior, but rather adding new functionality or options, I'm all for it. I've considered us pretty spoiled to have TWO ripple modes, when many DAWs still don't even have one. Studio One just added a basic ripple mode similar to PER-TRACK. But even DAWs like Cubase still don't have it for some bizarre reason. I've put in many feature requests at Steinberg but they just seem to fall on deaf ears.

Anyway, the fact we're talking about the nuanced details of enhancing features in Reaper is great, and so please let us know what you cook up for a FR.
fetidus is offline   Reply With Quote
Old 06-14-2018, 11:23 AM   #65
Remotetoaster
Human being with feelings
 
Join Date: Jun 2018
Posts: 9
Default

Wow, thank you, fetidus.

I really do need to learn every little feature Reaper has to offer.

I'm sure I'm not alone in saying that as I said at the beginning of this thread, I've put close to 400 hours into Reaper and I still feel like I haven't scratched the surface yet.

Forgive me for sounding repetitive and sugary, but I'm blown away by the depth of your response and the feedback of this community as a whole (and this is only my first post lol).

I feel like using Reaper and posting here will the best humbling experience I've had.

I will be referring back to this response to help level me out when I'm feeling lost in a project or if I find myself leaning on old methods too much.

So, not to simplify to much, but when it comes to how you use subprojects, you essentially use them any chance you can as to make the project easy to reverse engineer and keep the parent/master project all the more clean?

I know I'm probably just restating exactly what you said already, but it's just never something I would've considered on my own - but it makes so much sense.

My instinct tells me to not make so many subprojects because it would take up room and get disorganized. But if I just put them in the right folders I won't have to worry. Not to mention Reaper's files are minuscule when compared to every other DAW.
Remotetoaster is offline   Reply With Quote
Old 06-14-2018, 11:41 AM   #66
fetidus
Human being with feelings
 
Join Date: Sep 2007
Posts: 546
Default

Quote:
Originally Posted by Remotetoaster View Post
Wow, thank you, fetidus.

I really do need to learn every little feature Reaper has to offer.

I'm sure I'm not alone in saying that as I said at the beginning of this thread, I've put close to 400 hours into Reaper and I still feel like I haven't scratched the surface yet.

Forgive me for sounding repetitive and sugary, but I'm blown away by the depth of your response and the feedback of this community as a whole (and this is only my first post lol).

I feel like using Reaper and posting here will the best humbling experience I've had.

I will be referring back to this response to help level me out when I'm feeling lost in a project or if I find myself leaning on old methods too much.

So, not to simplify to much, but when it comes to how you use subprojects, you essentially use them any chance you can as to make the project easy to reverse engineer and keep the parent/master project all the more clean?

I know I'm probably just restating exactly what you said already, but it's just never something I would've considered on my own - but it makes so much sense.

My instinct tells me to not make so many subprojects because it would take up room and get disorganized. But if I just put them in the right folders I won't have to worry. Not to mention Reaper's files are minuscule when compared to every other DAW.
Yeah, the community here is very unusual, and the expertise level available is higher on average than other DAW forums IMO. I use several DAWs, and I am frequently impressed by the folks here in terms of their depth of knowledge compared to others. I have learned a ton recently, after I decided to take a deep dive, with some great help from forum users. I am grateful for their help, so I feel like I can share a bit too. I think it's part of the spirit and vibe of Reaper in general. This thread went off the rails a bit (in a good way), so it's not super typical, but then again, I've seen plenty of threads get into the weeds like this.

Anyway, you'll find the right balance for your projects. You may decide to use subprojects less than I do, maybe more. Like I mentioned in the example, I tend to cluster similar things together in one subproject (like 5 laser sounds instead of one per subproject) because you can slice and dice the proxy files, and it keeps everything cleaner. But you may find a different balance. For example, if you do scoring, Reaper's subprojects are ideal to organize your project based on cues. For sound design maybe the unit will be clusters of sound design elements... or maybe you'll start to like Take FX so much that you'll just save subprojects for the fancy stuff. Some hard core composers who use Reaper still don't use subprojects yet! They're comfortable with older workflows, so that's cool too. I for one can't imagine a DAW universe without subprojects now, and it's hard for me to live without them when I use another DAW.

Follow your instincts, and above all, be open to discover and change perspectives while using Reaper. Someone else here might have a totally different angle that might work for you. Also, the developers are kind of sneaky how they introduce power features without any fanfare, so when you get the time, start paying attention to the changelogs and watch some Youtube videos on new features... there are some real gems that pop up out of nowhere sometimes, and other DAW developers would have charged a big upgrade fee for them. Subprojects, for example, showed up in Reaper 5.11 and it took forever for me to even realize they were there.

Good luck, take it slow, and don't be afraid to challenge old school workflow models.

Last edited by fetidus; 06-14-2018 at 11:47 AM.
fetidus is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 06:47 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.