I’m applying the exact same parameters (the default values) to three excerpts of the same sound. All three excerpts contain the same material at some point (see screenshot).
Depending on the lengths of the excerpt, I’m getting very different results. This is not intuitive, as I would expect that the moment where all three examples have the SAME musical content would be segmented equally, independent from the overall length of the input sound.
I would think there would be some minor differences as things before/after those points would impact thresholds and lockouts differently, but I think that would only make small differences, and only near the edges.
This looks profoundly different, without any apparent pattern to it.
Actually scratch that, it looks like there is a pattern to the slices (staggered from the bottom one to the top, with the lowest one coming first), although the colors obscure that fact.
one question: are you using 3 files, or the same with different start point? It should not change anything, but I need to trace the error - your assumption is right that you should have the same slices, as long as you don’t have conflicts of ‘minslicelenght’
These are three tracks in reaper with the exact same sound file. Only the size of the ‘item’ is different. I chose them all and applied standard values for transientslice with the reaper scripts.
The reason for this: I made many combinations of parameters to better understand their impact on the process.
I then discovered that keeping the exact same parameters with different lengths of the sound resulted in highly varying output. Hence the test
Thanks Rodrigo for pointing to the ‘pattern’.
Here is my next test, which confirms it. Instead of using transient slice, I used novelty slice with default parameters, just to check if a similar behavior would manifest.
This is the splicing.
Now I’m moving all three tracks to start at the same time:
When zooming in it becomes clear, that they all have the same pattern.
This leads to a few questions: is this a transfer problem between the command line execution and the actual splicing in Reaper?
Is it not recommended to select more than one item in Reaper and apply the same treatment on them.
Is this a conflict, because all three treatments refer to the same original sound file on the hard drive?
Thanks for digging in…
Best, Hans
that’s what we’re here for 
@jamesbradbury this points at Reaper integration, can you check on your side first? I’ll check tomorrow morning on the CLI…
it might be that the CLI slicers do not behave correctly with @startframe too (so the slices would actually all be from the begining of the audio file and not the item, hence the exact same indices) @weefuzzy found something similar in Max… if that is the case, I’ll send you both a pre-release of the bug fix so you can confirm…
Great.
I can confirm that it also happens with three copies of the same sound file. Thus their content is the same, but file names are different.
I’ll need to take a look. Hans you are using the most recent scripts I sent you (with parameter memory) and so there might be something breaking I did on that branch. I’ll have a gander
Hello, how timely. Yes, this looks like an instance of the bug I found (and fixed) on Friday, which wasn’t limited just to Max, but did affect the usefulness of the startframes and numframes for the offline slicers.
@jamesbradbury : I tried it with both versions of the scripts: same behavior. It looks thus more like something @weefuzzy is hinting at and therefore would need a recompile of the command line tools.
I’ve tried with the latest compile and it works fine. I’ll send you and James a folder now, but will try to reproduce the bug with the version you have (which I keep like a good support person)
actually, to my surprise, the beta02 of the CLI does behave rightly with fluid-onsetslice
and so does the beta02 version of the transient slice, so @jamesbradbury it points to a bug on your side…
I will get to the bottom of this. I feel like I know what the problem is but I just need to work with the horrible script editor in reaper.
ok i can confirm a bug, I can confirm the fix is behaving as expected, with the typical error of windowed material. I can explain more on this if that is not clear. I will send compiles to the 2 of you so you can confirm (personal incremental updates - how’s that for love!)
love it
windowed material explanation would be good - is this concerning the edges of the sound?
yes, and everything in between
All windowed material will have small fluctuations of behaviour. For instance, if you do a sinusoid analysis and ofset it by something else than the overlap, you are very likely to get small variations. So you might get a different threshold if they are very ‘nervous’. If your thresholding is not crazy nervous, you will see no difference. It is true for all windowed signal, including RMS (hence so many RMS plugin being wrong, there is a good article about this here)
