Sample Slicer Improvements (Version 2?)


This is mostly aimed at It-Alien as the original developer of Sample Slicer add-on, but I would like the opinion of others on the board too.

I was having a play with the sample slicer add-on and found it to be really good. Then I had an idea.

If we took the difference beween each sample point throughout the whole sample we would then have a crude ‘rate of change’ against time graph.

We would then, in a ‘pop-up’, have a slider control. As we increased the value on the slider a threshold value would gradually decrease. When a ‘rate of change’ value is above the threshold a line is drawn vertically through the sample at that point.

Then, after confirmation from the user, the sample would be sliced at each of these lines. Optionally, we could then delete the original sample and call the create drum map function, spreading our sample across the keys.

Wouldn’t think be a very basic re-implementation of the slicing feature from Recycle?

We could calculate all the ‘rate of change’ values on creation of the pop-up (to avoid duplicate calculations), so the feedback and responsiveness should be fairly quick.

I don’t know if it is possible to draw on the sample view window through the API at the moment, but if it is then this sounds like a really powerful feature to add to Renoise.

This would probably be an option, so the original equal splits could also be generated.

I’m currently very busy with work at the moment (also the reason for the slow development of the pitch bend-> 01/02 command tool) but I would assist with the development of this tool where I could.

Any feedback?

+1 for proper slicing, according to threshold settings & peak detection, but maybe this should be done internally and is hard to do through scripting?

actually, although I am the author of the sample slicer, I never used it because I am not in the genres of music in which it is usually used.

I have done it just because I was fed up with sample slicer requests :)

I then encourage anyone willing to expand it to give a look to the code and try to do by himself. It’s not that I’m not willing to do it, but currently I am quite busy making music so it’s not likely that I will improve this tool anytime soon

Got a feeling transient detection of samples may be outside of the API without using external libraries or not sure what you may be able to code with LUA… If somebody did manage it I’m sure they would get plenty of love from a lot of people though!

There is transient detection going on in the native compressor and/or gate, no? Could some condition be set-up using scripting in combination with dsp devices?

No, you could do it. Not in real time of course, but sample data is definately maleable via the API.

See “renoise.Sample”:

I don’t think so. I would imagine both of those only work on peak (level) detection. Transient is more rate of change of an envelope. Imagine running the sample through the Signal Follower to get the envelope, then looking at this envelope for any parts which have a sharp upright.

May be able to get something usable with just peak detection though. Or maybe LUA has enough maths functions to code your own transient detection (eg divide sample into 0.5mS slots, get peak value/calculate RMS for each section, any section where the proceeding one is XdB louder than preceding insert a marker at nearest zero crossing. Probably want a minimum level, as well as difference setting. I would imagine quite processor intensive. 0.5mS is only the full cycle time of 2kHz so maybe not small enough chunks, 0.05 or 0.01 mS could be better but far increases overhead. Probably hit all transients a little late so may want some way to track back to quite moment to get full hit and a lot of manual tweaking quite likely still required.)

Well, my original idea was to take the modulus of the difference between the value of each consecutive sample point. A fast transient should have a larger value than a slower one.

Probably would have to do some crude ‘noise detection’ to avoid multiple fast transients really close together - maybe just take the first one out of every window of X milliseconds.

No, sample by sample will just tell you whether it’s a higher frequency of high amplitude. Need to do from envelope or packets. Sample by sample 20kHz full amplitude would then trigger it 20,000 times a second or not at all.

hehe, seems like we have to fed you up some more ;)

N00b speaking :) :

I’d think the gate device would have the necessary parameters to impose envelopes on a signal over time, with the threshold slider to define the peak amplitude to take into account and the hold & release sliders to define the length of slices.

If one could run the to be sliced sample through the gate device (some kind of off-line processing) & translate every time the signal triggers the threshold and decays, releases to 0 amplitude to slices that are automatically copied into empty sample slots, that’d be awesome. There is an attack setting on the gate as well, so you can attenuate sharp attacks or impose a smoother attack at the start of slices.

The current slicer is good on perfect programmed, looped, beat-synced samples, but anything with some swing or natural groove needs the transient detecting solution.

i have started using the sample slicer tool alot lately,my main feature request right now would be some sort of “fine-tuning”

the option to be able to get more accurate slicing

One thing missing is just a regular cut by beats function, based on the top ruler

I wish I could just choose: “16 beats” for a recorded sample and it creates the samples based on current song tempo as many slices as it’s possible to create.

Right now I have to cut the sample into exactly right length for it to work, but why can’t we just use the song tempo not the calculated tempo from the sample length?