[premium script] Enable ripple edge editing

[amagalma]

Originally Posted by andyp24

This looks amazing, Amagalma, and thanks for the email. I'll try it out on Monday.

Thanks so much.
Andy

Great Andy!

[amagalma]

Added Automation Item support




Do you think that I should override the setting of the options "Automation items connect to the underlying envelope..." or let Reaper do its thing? I can see the advantages and disadvantages of both sides and can't decide.. (for the time being I left it up to Reaper)

[X-Raym]

Nice ! It seems good to me this way.




If I understand clearly you have finished the On tracks behavior... ? Unless you want to take care of the Locked Items reaper preference. :P

[andyp24]

I don't use AIs much at the moment tbh, but the demo video looks perfectly fine to me.
Andy

[amagalma]

Originally Posted by X-Raym

If I understand clearly you have finished the On tracks behavior... ? Unless you want to take care of the Locked Items reaper preference. :P

I would take care of them, but things could mess up with envelopes, but not because of me! "Move envelopes with items" is either buggy or not fully natively implemented for all Locked item ripple editing behavior. I have filed it as a bug.

See for yourself the gif in the bug report.

Therefore, although I wanted to support them, I won't before the correct native implementation is done. No point in spending time implementing something that will work when edge editing, but it doesn't work natively when dragging items..

[amagalma]

Ripple per-track edge editing has been fully implemented since many days (I won't support different locked item behaviors for the reasons mentioned above).

I will now go on to work implementing Ripple All tracks mode.

However, taking into account that 1) I have spent countless hours for this script and 2) there was no interest despite the low price (only two people bought it at its full 60€ price, none in the discounted price, and there haven't been any donations), the price scheme has to and will be changed:

Script will be offered at 80€ for anyone who buys it, before Ripple All tracks mode comes (hopefully before 6th December).

After that, it is going to cost 140€.

(Of course, the two people who have already supported me will get the full implementation at no extra cost, as was advertised at the time of their purchase.)

[X-Raym]

No problem for waiting for locked items !

2) there was no interest

Oh yes, there is interest :P

Though people are likely to wait for the all tracks version. This is the one most needed in full project editing (with marker support etc)



(Also, I hope this has been promoted a bit outisde ReaScript forum ! But your offer may have been oversight between all the current black Friday offers ^^)

[andyp24]

Seriously folks, just buy it and help Amagalma out here...

He's doing such a great job with this script, which various people have tried to implement before without this much success.

It's snappy to use (obviously there's a little bit of lag in the graphic display, but you can edit as fast as you like and it doesn't miss anything). Amagalma is trapping the few small bugs we're discovering as fast as possible, and is confident that the 'Holy Grail' of Ripple All Tracks mode will be just as reliable and quick to use.

I can't say it enough - IF YOU ARE DOING SPEECH EDITING, THIS SCRIPT WILL SAVE YOU TIME!! It also has other uses in video editing etc, as X-Raym has pointed out.

Don't let Amagalma become disillusioned with writing these kind of scripts. It takes an enormous amount of time and effort to achieve what he's done here. Please buy it, donate, advertise it, whatever you can do.

[amagalma]

Thank you Andy for the kind words and the support


Now.. on the Ripple All Tracks implementation:
Let's say you have the following and you grab and extend the edge of a single item:
Scenario 1:


What would you expect to happen in Ripple All Tracks mode? This? :
Behavior 1:

(item extends and all other items after it move)

Or this? :
Behavior 2:

(the first item of each track that is at or after the original item, gets selected and extends too)

And what would you expect in this scenario?
Scenario 2:


This? :
Behavior 3:


Or one of the previous behaviors? Or something else?

On Scenario 1, I think the expected behavior would be Behavior 1 (but should the other two red items move like in the pic or not?). But what on Scenario 2? I have no clue..

[X-Raym]

@amagalma
For first question, I would propose a 3rd scenario:





Though, is a marker is at right edge, it should probably moved.


Scenario 2 would be if multiple items at same right edge would be extended.



What do you think @andyp24 ?


And for non aligned multiple selection case, it should works as a succession of ripple edit all tracks. First resolve first pos edges, then the second one etc.


--
I know I haven't made donation so far cause hard times but I do hope my modest contributions for brainstorming this is helpful.

[andyp24]

Hi,

I'm on my phone at the moment, so can't mock up any images, but I'll try to describe my thoughts...

Re: scenario 1, I pretty much agree with X-Raym's suggestion. Ripple items which BEGIN at or beyond the edge that is being moved. However, in order to cope properly with crossfaded items (when speech editing, typically every edit will have a short crossfade) the "Ripple Point" (ie the time at or beyond which other items should Ripple) should be the START of the edge being dragged (ie the start of the fade out, in your picture above).

Re: scenario 2, it gets complicated, but I would propose (if it's possible) that if an item is selected for its edge to be dragged, it shouldn't itself be Rippled due to an earlier edge on another track moving. That might mean considering each track separately as a kind of "multiple Ripple single track" operation. Which then opens the question of how to decide which items will Ripple on tracks where no item is selected.

Does this help? 😁

[amagalma]

Originally Posted by X-Raym

@amagalma
For first question, I would propose a 3rd scenario:

Though, is a marker is at right edge, it should probably moved.

I see, so in Scenario 1 everything that starts *after the reference item's end/right edge* ripples (another Behavior). (PS. Let's stick to the terminology I used in order for me to not get confused!

Scenario 2 would be if multiple items at same right edge would be extended.

And now I got confused!

And for non aligned multiple selection case, it should works as a succession of ripple edit all tracks. First resolve first pos edges, then the second one etc.

Could you please show me? I attach the test project . Thanks!

I know I haven't made donation so far cause hard times but I do hope my modest contributions for brainstorming this is helpful.

They are! Thank you!

[amagalma]

Originally Posted by andyp24

Hi,

I'm on my phone at the moment, so can't mock up any images, but I'll try to describe my thoughts...

Re: scenario 1, I pretty much agree with X-Raym's suggestion. Ripple items which BEGIN at or beyond the edge that is being moved. However, in order to cope properly with crossfaded items (when speech editing, typically every edit will have a short crossfade) the "Ripple Point" (ie the time at or beyond which other items should Ripple) should be the START of the edge being dragged (ie the start of the fade out, in your picture above).

Re: scenario 2, it gets complicated, but I would propose (if it's possible) that if an item is selected for its edge to be dragged, it shouldn't itself be Rippled due to an earlier edge on another track moving. That might mean considering each track separately as a kind of "multiple Ripple single track" operation. Which then opens the question of how to decide which items will Ripple on tracks where no item is selected.

Does this help? 😁

Thanks Andy! I'll have to re-read this a couple of times because I just woke up and I was following this but at some point I lost it!
If you have some time later, I would appreciate a mock-up with the test project. "A picture is worth a thousand words"

[amagalma]

Originally Posted by andyp24

Re: scenario 1, I pretty much agree with X-Raym's suggestion. Ripple items which BEGIN at or beyond the edge that is being moved. However, in order to cope properly with crossfaded items (when speech editing, typically every edit will have a short crossfade) the "Ripple Point" (ie the time at or beyond which other items should Ripple) should be the START of the edge being dragged (ie the start of the fade out, in your picture above).

Show if we start with this:



We end with this:


Right?

(and another example)
Before:


After:

[amagalma]

Originally Posted by andyp24

Re: scenario 2, it gets complicated, but I would propose (if it's possible) that if an item is selected for its edge to be dragged, it shouldn't itself be Rippled due to an earlier edge on another track moving. That might mean considering each track separately as a kind of "multiple Ripple single track" operation. Which then opens the question of how to decide which items will Ripple on tracks where no item is selected.

So, starting with this:




We end with this? : (Behavior A)




Or with this?: (Behavior B)

Originally Posted by X-Raym

And for non aligned multiple selection case, it should works as a succession of ripple edit all tracks. First resolve first pos edges, then the second one etc.

And if I understood well X-Raym's suggestion, we could have this: (Behavior C)


PS. Sorry for forgetting to re-select the correct items in the mock-ups, but you get the idea..

[amagalma]

Is Scenario 2 a real world scenario? Is it something that one would encounter while editing?
If not, then there is no reason to try to find a solution. The script could easily unselect the offending items while dragging (so that their edges do not change) and restore the selection after the edit.


But if it is a scenario that one will encounter at some point, then we have to agree on the expected outcome. I can implement any behavior.

[andyp24]

Originally Posted by amagalma

Show if we start with this:



We end with this:


Right?

(and another example)
Before:


After:

That looks perfect to me, yes

[andyp24]

Originally Posted by amagalma

Is Scenario 2 a real world scenario? Is it something that one would encounter while editing?
If not, then there is no reason to try to find a solution. The script could easily unselect the offending items while dragging (so that their edges do not change) and restore the selection after the edit.


But if it is a scenario that one will encounter at some point, then we have to agree on the expected outcome. I can implement any behavior.

For scenario 2, it's not something that I personally would really expect to do except maybe VERY occasionally, although I suppose it's possible that if SNAP is turned off (which it always is for speech work) then you could be working on a scenario where two items on different tracks start at SLIGHTLY different times (but mostly overlap).

The idea of picking two non-overlapping items and extending both of them from the edge seems very likely to mess things up elsewhere whatever behaviour you choose :-)

I'll try and have a look later at what SADiE does in this scenario, but I'm in someone else's studio today, so I don't know if I can do a screen capture here and I don't have Reaper available.

Andy

[amagalma]

No need for a mock up. If you could have a look at what Sadie does, maybe it could help..

However, Behavior C seems to be the most logical outcome now that I see it again...

In all cases, what is important is that later items on different tracks do not get out of sync.

[X-Raym]

Here how it is done in davinci resolve:





So as we can see, scenario C for one selected items is good.


For multiple selected items, it is in fact simple: leave selected items in place, extend them and ripple the rest.


This behavior sounds good to me as well.

EDIT:

Same in Premiere Pro

[amagalma]

Thanks for the GIFs!

Does the same thing happen if you grab the edge of the first item?(=second selected item does not ripple)

[andyp24]

I can certainly see the logic in that approach, and it does have some advantages.

However, here's an alternative perspective.

Look at the Green items in your DaVinci gif. The "sheep" are in sync with each other. Now, when you move the right edge of the two selected items, the Green sheep are no longer in sync with each other.

As I say, this is not an operation I would tend to use often for audio-only work. But I think I might argue that the Green sheep should stay in sync, just as all the others do. If I'm rolling the edge of an item to expose hidden audio, I think it's far more likely that I'd want audio that was time-aligned before the operation to stay that way than for "in sync" items to follow the edge.

(Of course, there will be items (for example one big item overlapping both the orange and the green) which CAN'T stay in sync with everything, and then you have to make a decision whether it Ripples or not.)

Now in the gif above, if we fix the position of the Green items (in other words, if the logic is that only items which begin at or after the LATEST edge being moved will Ripple), then it is possible that when we extend the orange and green items' edges, the orange will end up overlapping the green (like it would if we extended the edge with Ripple off). That migbt be disastrous for video editing workflows, but much less so for mine.

I will build a SADiE project this afternoon and see what it actually does. (Crash, probably :-) )

[X-Raym]

@amagalma
Yes it is the same. No matter what item edges you drag, it will ripple evrything after the first item edge. This make things simpler


When you drag left, they just stay in place but their content is extended right (similar to the one track version, but with everything rippling after first item edge).

[X-Raym]

@andyp24
They are still in sync, but from a different reference point :P (the end of items)



If we want to extend other items edges as well, we can just selected them. having only items selected changing length has the big advantage of being simply predictable.



In real usage, selecting one item from each columns like that is a bit of a rare case, and could be less friendly that doing it in two times, so I think the more transparent integration is to do what is found in most other softwares as they have brainstormed this already,
As I dont remember having noticed any problem with these behaviors in video editing context (note: video editing projects also contains lots of audio tracks for editing and want to preserve stuffs in sync, so I'm note there is that a distinction between editing in DAW than in NLE),
but I dont know audio specific software which have this.


or maybe have different modes ?


Sure thing, when we dig the details, we understand that this "basic" request (ripple from edge) leads to lots of brainstorming haha :P

[andyp24]

Originally Posted by X-Raym

@andyp24
They are still in sync, but from a different reference point :P (the end of items)

Haha :-) Think of it as a Drum Multitrack recording for example. The beats of the Green drums will not stay in time - their relation to the edge point is irrelevant, surely.

(Yeah, I can't imagine ever doing this on drums, either, but you know what I mean. A multi-tracked interview with 3 different mics for example).

[amagalma]

So, it seems that Behavior C is the only one in which items do not loose sync in that scenario.

[andyp24]

OK I've tried it out in SADiE.

To be honest, because the "Ripple from Edge" function that you're building here is a bit different from the SADiE Playlist Edit feature (although it's designed to do the same job), it is not possible to recreate the same logic entirely.

So, for selecting a single item or multiple items which (fully or partially) occupy the same time location on different tracks, how about this:

Dragging the right edge will Ripple all items whose start time is equal to or later than the <earliest "start of fade-out" of the selected items>

Dragging the left edge will Ripple all items whose start time is equal to or later than the <start time of the fade in of the item whose edge is dragged AT THE START OF THE MOVEMENT>

This means that at the moment of picking up the left edge to start dragging it, the items which will Ripple are fixed, and do not alter according to how far we drag the edge.

For non-concurrent items on separate tracks (ie where the start of one selected item is later than the end of another selected item), do whatever X-Raym wants! I don't think I'd use this enough to be that bothered about how it works, so if the "video editing" mode will make it more useful to others and make them more likely to buy your scripts, that's good for me.

[andyp24]

Originally Posted by amagalma

So, it seems that Behavior C is the only one in which items do not loose sync in that scenario.

In this situation, yes, but your items are all neatly separated in time. What happens to items on other tracks which are "in the middle" (eg start midway through the red and finish midway through the green)?

[amagalma]

Originally Posted by andyp24

In this situation, yes, but your items are all neatly separated in time. What happens to items on other tracks which are "in the middle" (eg start midway through the red and finish midway through the green)?

This would happen:
Before:



After:

[amagalma]

Originally Posted by andyp24

Dragging the right edge will Ripple all items whose start time is equal to or later than the <earliest "start of fade-out" of the selected items>

In the following situation:



The pink item would ripple.. Are we ok with this?

[andyp24]

Originally Posted by amagalma

In the following situation:



The pink item would ripple.. Are we ok with this?

For me, yes. That's a very unusual fade out for my kind of work :-)

[andyp24]

Originally Posted by amagalma

This would happen:
Before:



After:

Looks OK, yes. Most important thing is that anything "OUTSIDE" the area where edges are being moved stays in exactly the same relationship that it was before, which it does here.

[andyp24]

Of course, the most important thing when items are Rippling like this is to be able to see at a glance which ones are going to move.... with them temporarily changing colour, for instance ;-)

[amagalma]

Originally Posted by X-Raym

@andyp24
They are still in sync, but from a different reference point :P (the end of items)

Actually, they are not.. Look closer

[andyp24]

Yeah, I think he knew that and was making a bit of a joke ;-)

But for me, what's important is that the CONTENTS of items which are in sync at the beginning remain in sync as much as possible when edges are dragged.

[amagalma]

Originally Posted by andyp24

Of course, the most important thing when items are Rippling like this is to be able to see at a glance which ones are going to move.... with them temporarily changing colour, for instance ;-)

Colors in Reaper are set in this way:
- items inherit the track's color
- if there is a custom item color set, it overrides the inherited track color

- if there is a custom take color set, it overrides the set item color


I can do that for both Ripple modes.. but it may (or not) slow down a bit the script.. don't know if and by how much.. Are we willing to risk it?


I'll have to get the Active Take, get its color, save it to a table, set a new take color for all the items that will move and when the editing stops, restore all colors. For empty items (that have no take), the item color will be used instead.
For items with many takes, only the active take will change color

[amagalma]

Originally Posted by andyp24

Yeah, I think he knew that and was making a bit of a joke ;-)

I hope I didn't sound offensive! :S It was not my intention!

But for me, what's important is that the CONTENTS of items which are in sync at the beginning remain in sync as much as possible when edges are dragged.

Yeah, I think that behavior is the best. I' ll just make sure that selected items that are before the reference item (the one whose edge you drag) are unselected first, otherwise it would not work.

[andyp24]

Originally Posted by amagalma

Colors in Reaper are set in this way:
- items inherit the track's color
- if there is a custom item color set, it overrides the inherited track color

- if there is a custom take color set, it overrides the set item color


I can do that for both Ripple modes.. but it may (or not) slow down a bit the script.. don't know if and by how much.. Are we willing to risk it?


I'll have to get the Active Take, get its color, save it to a table, set a new take color for all the items that will move and when the editing stops, restore all colors. For empty items (that have no take), the item color will be used instead.
For items with many takes, only the active take will change color

Personally, >90% of the time my items are the inherited track colour. I do sometimes set Custom colours for items if I need to mark them as possible cuts when the programme is too long for example. Storing and restoring it afterwards would be great - I guess (it is just a guess!) that it might slow up the initial move of an edge as it has to build the table, but then shouldn't need to do anything more until you let go again? So there might be a little "lag" built in at first, but then it'd work the same once you were moving?

What I was actually thinking was that I could run this with your "Coloured Rippling" script when that's finished too :-) But I don't know if that will work, as you may well be doing some trickery within this one to choose items for Rippling which would be different from the ones Reaper would expect to Ripple normally.

I would imagine the "change colour of items which will Ripple" would need to be an optional feature, as some people may not want it to do that at all. I would be interested to see if it slows up the script significantly, though, but getting the logic of the script and its Rippling right is the priority of course. Leave colours as a possible "nice to have" in future if you're still willing to continue developing the script.

[andyp24]

Originally Posted by amagalma

I hope I didn't sound offensive! :S It was not my intention!

Yeah, I think that behavior is the best. I' ll just make sure that selected items that are before the reference item (the one whose edge you drag) are unselected first, otherwise it would not work.

No, you didn't sound offensive all all, don't worry.

So, just to be clear what you say about deselecting items, does this mean that if I have several items selected on different tracks at different times, I need to drag the edges of the earliest one for it to work properly?

[X-Raym]

@amagalma

Actually, they are not.. Look closer

To be precize, the end point of these clips is still in sync, (but the content at right edge pose has changed for the extended clip of course)



Also, Don't be fooled by the clip thumbnails, these doesn't tell anything about sync :P It is just the "first image of the clip" repeated in a tiled pattern, in this case, just a single image.