New Tool (3.1.1): Slice Importer v1.1 (February 2019)

SLICE IMPORTER. What is this?
Slice Importer include a double function allows copying or pasting the slice markers of the first sample between instruments.

Remember that it is necessary to always work on the first sample! If you copy more slice markers than those allowed by the target sample, they will only be pasted until the last allowed marker.

Access: “Sample Editor/Slices/~Copy Markers… (or ~Paste Markers)”.

DOWNLOAD
https://www.renoise.com/tools/slice-importer

2 Likes

This has probably been mentioned before somewhere (Ledger might have posted similar), but I’ll mention it here as you are copying slice markers etc with this tool.

I have a sample in instrument 0 that is 600 samples long. I ask Renoise to verify:

print(renoise.song().instruments[1].samples[1].sample_buffer.number_of_frames)
600

All good. Notice that when manipulating slice markers via a script it is one based. So to put a marker right at the beginning I can write:

renoise.song().instruments[1].samples[1]:insert_slice_marker(1)

Ok. Now I want to put a slice marker right at the end of the sample (of course you wouldn’t really need to do this…but you can via the GUI sample editor) with:

renoise.song().instruments[1].samples[1]:insert_slice_marker(601)

I get this error:

*** std::logic_error: 'invalid slice sample_position index '601'. valid values are (1 to 601).'
*** stack traceback:
***   [C]: in function 'insert_slice_marker'

Via the sample editor GUI I’ve placed the marker right at the end of the sample. Let’s ask Renoise where that marker is:

rprint(renoise.song().instruments[1].samples[1].slice_markers)
[1] => 601

Ask Renoise to delete that marker:

renoise.song().instruments[1].samples[1]:delete_slice_marker(601)

I get:

*** std::logic_error: 'invalid slice sample_position index '601'. valid values are (1 to 601).'
*** stack traceback:
***   [C]: in function 'delete_slice_marker'

Just somethings to keep in mind Raul…just in case you write more slice marker manipulative tools.

btw slide importer is in your logo graphic? Mind you, slide importer sounds like an interesting tool Raul
Fixed :slight_smile:

Hahaha, thanks for the warnings! Sorry for the slip in the logo. I know I should change the D for C. I’ll correct it!

It seems that there is another small bug in Renoise. I remember that something very similar happens in the automation editor in the last point (the maximum value). And I do not remember very well if it had the same behavior in Windows as in Linux. They look like little hidden mistakes of Renoise, which could lead to occasional tool errors. They should be corrected!

I guess that @taktik will know both cases…

Thanks for the info!

1 Like

Thanks for a very useful tool! I’ve been having some issues getting slice markers to copy correctly to timestretched and beatsynced samples though. I’m quite new to Renoise so I’m not sure if the issue lies with Renoise, Akaizer, Slice Importer, or just my plain old stupidity :slight_smile:

I’ve got two samples I want to copy slice markers between: an original sample of a break loop which is beatsynced to 64 lines and is about 8 seconds long, and a timestretched version of this sample (16 seconds long, but beatsynced to 64 lines so now an identical length to the original sample). Here’s what I’m doing:

  1. Load original sample into an instrument slot and beatsync to 64 lines (sample is now about 8 seconds long)

  2. Load the same break sample into another instrument slot, then timestretch with Akaizer (time factor 200%, cycle length 1000 cycles). The break is now about 16 seconds long, but after beatsyncing it to 64 lines again it’s about 8 seconds (i.e. identical to original break)

  3. Add some slice markers to the original break at the 2 and 4 second marks

  4. When I copy/paste these slices from the original break to the timestretched/beatsynced one, the slice markers are pasted at about 1.4 seconds and 2.4 seconds, rather than at 2 and 4 seconds.

Since both samples are beatsynced to 64 lines and should therefore be identical lengths, I would expect the slices to paste across to exactly the same position on each break.

There seems to be something funny going on when the second break is beatsynced, because when I turn off the beatsyncing on the timestretched break, (i.e. leave it at its original 16 second timestretched length), the slice markers paste at the correct 2 and 4 second positions. However, because the sample is timestretched to twice its length, this is the wrong position in the break in relative terms. It’s as if Slice Importer is only reading the length of the underlying sample rather than the beatsynced version?

Is there something obvious I’m missing about how to get the slice markers to copy across correctly between samples which are beatsynced to the same length? The weird thing, I did mange to successfully copy slice markers between untouched and timestretched/beatsynced samples like this a few weeks ago, but try as I might I can’t manage to get it to work again!

@Lauvdal, I’m sorry for not answering before…

Basically an audio wave is divided into frames (two consecutives frames indicate the length of a sample, the smallest unit). For example, if an audio wave has 101 frames, it has 100 samples (the 100 smallest chunks to be able to reproduce).
Each slice marks the starting position of a sample and at the same time the final position of the previous sample. That is, a slice is superimposed on a frame (is a number). If you have a single sample inside the audio wave, you can only add 2 slices, at start (frame 0) and finish (frame 1).

FRAME 0 - FIRST SAMPLE - FRAME 1 - SECOND SAMPLE - FRAME 2 …

At the programming level, these slices are a number within a table. When the code copies the table with those numbers, it is limited to a maximum number which is the maximum number of frames of the original audio wave.

When the code pastes the table to import the slices into the target audio wave, you will only be able to paste the number of slices from the table. If the target audio wave has fewer frames, it will only paste the amount that will fit. If the destination audio wave has more frames, it will paste all the slices, and you will see at the end of the audio wave that there is a part without slices.

If the destination audio wave has other readjustments it shouldn’t matter. You should only check that the number of frames is the same in each slice in both audio waves.

To compare, use the rule in “Samples”:
image

This tool does not do any additional readjustment.
Basically just copy and paste tables with numbers, regardless of the number of samples of each audio wave.

Thanks for the explanation, I think I get it now :slight_smile: When I change the sampler waveform unit view to use samples as the units, what’s been happening in my case makes sense - I can see that my original sample has about 400k samples and the timestretched one has about 800k, so it’s irrelevant that it’s been beatsynced to the same length. When I zoom in on the slice markers pasted into the timestretched sample I can see that they’re being pasted at the same sample number (though obviously that’s a different relative position in the overall sample), so the tool is working as intended.

Would it be feasible to add an option to the tool to toggle between using sample numbers and using seconds (and fractions of seconds) to determine the position of slices when copying between samples? That would give much more flexibility when working with different samples, because then you could copy slices between any two samples as long as they were beatsynced to the same length, rather than having to worry about the number of samples in each and whether any one sample has the same address in each waveform. I don’t know anything about the nuts and bolts and Renoise though, so I’ve no idea if this would be possible or how much work it might involve – just an idea :slight_smile:

This would not be reasonable. Unfortunately, the resolution of the fraction of a second is too great (in “Minutes”).
The smallest form of measurement is in “Samples”.

Ah OK no worries, thanks for the help anyway :slight_smile: