I changed how it was going through the samples. Before, it was trying to go through all of the channel 1, then channel 2, etc, and somewhere it was getting confused and coming up with negative time values - that is, a split point before the start of the item.
Now it goes through the samples as they come from Reaper - channel 1 sample 1, channel 2 sample 1, channel 1 sample 2, channel 2 sample 2... tracking the RMS for each channel separately, and then stopping if one of them passes the threshold.
The actual behavior should be unchanged, so it's possible what you were getting before was incorrect due to the stereo issues it had. The logic it uses for a split point is:
- Cannot be within __ms of the item start, as set by "Protect left", so that transients are protected.
- Must be far enough from the end of the item that the tail's stretch rate won't be less than the value you set, so it can't find an acceptable RMS value right off the hop and stretch out a ten sample segment over 300ms or something.
- Within that range, find the last (furthest right) position where the given RMS window is over the threshold.
Hey would it be possible to give the possibility to apply the script to items on one single track, and adjust the Grouped items in the other tracks accordingly?
The way it works now, if I have items on different tracks (say kick, snare, hi-hat) the script makes different decisions for each track, so the result is misaligned, since I have bleeding across tracks it should process the items in different tracks exactly the same way
And thanks so much for all your great commenting. I just found out (with X-Raym's kind sharing) about AudioAccessor commands. They look like they could be a lot of fun (or not :O )... but thanks for little tidbits like this:
Code:
-- It's significantly faster to use locals for CPU-intensive tasks
local GetSamples = reaper.GetAudioAccessorSamples
Cheers!
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
I tried really hard to make the audio function in this one modular, so in theory it should be copy-pasteable straight into other scripts and given whatever callback function you want.
I tried really hard to make the audio function in this one modular, so in theory it should be copy-pasteable straight into other scripts and given whatever callback function you want.
Whoa... very cool. Thanks so much for that!
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
Hi, it seems that UNDO doesn't really undo the whole job done by Smart Fill Gaps... leaving dirty items around
Could you fix this?
g
Reaper is sometimes a bit weird about what things it includes in a given undo "block" and what things it doesn't. I can certainly have a look and see if it's something on my end though.
The script hasn't changed at all, but it's certainly possible. Will try to have a look over the weekend.
That's really strange. Maybe something inside Reaper changed. FWIW, I have the same issue on my Windows and OSX machine.
Sure thing man, take your time. It's such a great script, would be a pity to lose it.
Turns out it was me - scripts made with my GUI Builder weren't having their menu items picked up. I've added a fix, so you should see a GUI library update on your ReaPack shortly.
As for Gianfini's undo issue... I'm not sure that there's anything I can do. The script tells Reaper to put all of the processing in an undo block and to track everything that changes.
Loka's approach is the more desirable: cut the transients from the tail and ONLY timestretch the tail. Because timestretched transients sound really awful. This is really a very clever script that Loka wrote
Can anyone explain to my idiot brain in which way is this better than "SWS/AW: Fill gaps between selected items (advanced)"?
Or maybe how is this solution just different and why would i prefer it?
The SWS action is "dumb", in the sense that it's just splitting at X milliseconds from the beginning and then stretching the rest.
Mine takes the transient length and stretch amount that they use and adds an RMS threshold - it won't split the item until the tail has dropped below the threshold, so that you only end up stretching unimportant content and leaving as much of the good bit intact as possible.
The SWS action is "dumb", in the sense that it's just splitting at X milliseconds from the beginning and then stretching the rest.
Mine takes the transient length and stretch amount that they use and adds an RMS threshold - it won't split the item until the tail has dropped below the threshold, so that you only end up stretching unimportant content and leaving as much of the good bit intact as possible.
Wouldn't another way of doing this (without splitting the items first) be to dynamic split (creating stretch markers) and snap to grid as normal, but then set the start of each stretch marker to x1.00 so that the tail of the audio is stretched while the transient is (more or less) untouched?
This looks awesome and would be the very thing for some projects I am working on.
I've installed it from Reapack, and also set the Lokasenna GUI library path, but unfortunately get an error message then trying to run the smart fill gips command. It says;
Core.lua:57: attempt to call a nil value (field 'ReaPack_GetOwner')
I've been using your script Lokasenna, it's great thanks.
I'm also experiencing the same thing as Gianfini, is there something I can do to change this behaviour?
Cheers!
Jennifer
Quote:
Originally Posted by Gianfini
Hey would it be possible to give the possibility to apply the script to items on one single track, and adjust the Grouped items in the other tracks accordingly?
The way it works now, if I have items on different tracks (say kick, snare, hi-hat) the script makes different decisions for each track, so the result is misaligned, since I have bleeding across tracks it should process the items in different tracks exactly the same way
Hi I really cannot understand how this work... I set Protect Left to 100ms and then it insert stretch split at 44ms from left of item...
How does RMS Thershold work?
Is there a way to proess one track and move along all other tracks with Grouped items according to splits/moves done in the first track? Otherwise it's pretty useless when you have 8+ mics to align
Lokasenna has committed an update Reapack that should address this. It's version 1.3, I'm going to try it later. Maybe try updating the script via Reapack if you haven't tried that already?
Edit: I've just tried version 1.3 and it seems to be doing the trick, thanks Lokasenna.
Hi I really cannot understand how this work... I set Protect Left to 100ms and then it insert stretch split at 44ms from left of item...
It shouldn't be, unless you have the "match the first item at each position" option on and the first item was split at 44ms. Can you share a project and the script settings you're using to make it do that?
Quote:
How does RMS Thershold work?
My algorithm might not be entirely correct, but it's meant to look for the last (furthest-right) position where the specified RMS window (effectively the average level) is above the given threshold, and then takes the next zero crossing to the right for a split point.
Quote:
Is there a way to proess one track and move along all other tracks with Grouped items according to splits/moves done in the first track? Otherwise it's pretty useless when you have 8+ mics to align
Grouping, no. I worked on that for a bit this afternoon but it would require a lot of rewriting to work with grouped items that aren't all at the same position (room mics that are few milliseconds later, etc).
I did add an option earlier today to use the first (lowest track number) item at each time position and match the others with it though.
Grouping, no. I worked on that for a bit this afternoon but it would require a lot of rewriting to work with grouped items that aren't all at the same position (room mics that are few milliseconds later, etc).
I did add an option earlier today to use the first (lowest track number) item at each time position and match the others with it though.
That's what I used, it worked well.
That you didn't use groups puzzled me, but I understand why now. I try to do all this sort of editing before moving any parts out of sync with the group, but I can see that this wouldn't always be the case.
It shouldn't be, unless you have the "match the first item at each position" option on and the first item was split at 44ms. Can you share a project and the script settings you're using to make it do that?
See below. The split on the forefront item happens at around 43ms, even if protect left is 80
I did add an option earlier today to use the first (lowest track number) item at each time position and match the others with it though.
Yes, this is what I need. To have a reference track (be it the lowest number or the currently selected track) and match the others with the movements done in reference track items
Why not using Grouping then (so the tracks to be matched are the ones gropued with the reference track)?
With groups, it's possible that the items aren't all at the same position (overheads being a bit later, etc) so I have to make it bypass much more of the logic. It's possible, it'll just require a pretty big rewrite.
Thanks for the .gif, I'll try to have a look tonight.
I've just pushed what I think is a fix for the Protect Left issue above. I had to rewrite a big chunk of the audio code, so I really really really hope I didn't break anything else.
With groups, it's possible that the items aren't all at the same position (overheads being a bit later, etc) so I have to make it bypass much more of the logic. It's possible, it'll just require a pretty big rewrite.
Thanks for the .gif, I'll try to have a look tonight.
No I'll try to make my point better
Give that I have 8 tracks. They are all aligned as *I did align them and put into phase* before (except room mic that must be few ms later by construction)
Now don't worry about other tracks being one/few milliseconds later/earlier anymore
I need to process one track (where i usually combine kick+snare) and have all the others move exacly as the one i'm processing without checking transients or else anymore in the other tracks.
Just item movement/splits/stretches be replicated on all grouped tracks as per the first track
Give that I have 8 tracks. They are all aligned as *I did align them and put into phase* before (except room mic that must be few ms later by construction)
Now don't worry about other tracks being one/few milliseconds later/earlier anymore
I completely understand what you're suggesting.
The script was originally written to do all of that checking and processing for every single item. Making it use the first item's values isn't as simple as you think; it requires rewriting a fair amount of the code to be able to bypass the checks and error handling.
Having the items all at the same position (and length) is easy because all I have to do is tell it "split here" and the rest of the processing will come out the same as the first item.
The script was originally written to do all of that checking and processing for every single item. Making it use the first item's values isn't as simple as you think; it requires rewriting a fair amount of the code to be able to bypass the checks and error handling.
Having the items all at the same position (and length) is easy because all I have to do is tell it "split here" and the rest of the processing will come out the same as the first item.
I understand.
Just to be sure: I mean to process items on one track and have items on other tracks to follow. Not first item to bereplicated to other items in the same track.
Anyway don't worry. It is so good already and usable
There are actually two different ways it could be done:
1. Doing what the current "match the first item" behavior does, where it finds the distance from the start of the item to the split and then splits at that same distance for the other items.
i.e. If it split at 100ms into the first item, it'll split at the second item's start + 100ms.
2. Splitting all of them at the actual time the first item was split, which means that for the reverb tracks you'd actually be splitting earlier in the content.
i.e. If it split at 100ms into the first item, and your reverb tracks are 30ms late, the reverb items will be split at their start + 70ms.
There are actually two different ways it could be done:
1. Doing what the current "match the first item" behavior does, where it finds the distance from the start of the item to the split and then splits at that same distance for the other items.
i.e. If it split at 100ms into the first item, it'll split at the second item's start + 100ms.
2. Splitting all of them at the actual time the first item was split, which means that for the reverb tracks you'd actually be splitting earlier in the content.
i.e. If it split at 100ms into the first item, and your reverb tracks are 30ms late, the reverb items will be split at their start + 70ms.
Ok it’s manageable anyway, I prefer method 2.
Otherwise you end up with different lenght items across tracks
And then how often ones have printed materia with 30msl delay...
Linear Mode
