This time, with full support for sample offset commands (Sxx). This includes support on the sliced samples themselves, but also the special syntax Renoise has for the “root sample”.
So you can slice up a sample and then scramble it further using Sxx commands like this
Pay attention to the selection in the waveform editor while commands are entered
And it also understands when you’ve used the alternative Sxx-based approach to slice triggering
The Sxx command decides which slice is active
Another small improvement - notes are now inserted using their basenote, not the first note of their mapped range.
Great tool. I would love to have more “resolution” when slicing (without live slicing).
A small suggestion: If a delay value is present at the cursor position, the vertical select line in the waveform will move accordingly and the “Slice at Cursor” will slice the the sample at the position determined not just by the line but at line x + delay xx.
Or maybe a way to slice and insert a note from the wave editor. Go to position xxx in the sample, right click, choose “slice and insert note” (or something similar) and a note will be inserted in the pattern editor at the location (line + delay) corresponding to the sample position (the distance from the root note).
A small suggestion: If a delay value is present at the cursor position, the vertical select line in the waveform will move accordingly and the “Slice at Cursor” will slice the the sample at the position determined not just by the line but at line x + delay xx.
It should already work like this. If not, then something has simply gone wrong
(must admit, I practically never use the combination of delay & slicing myself, so I might have skipped this during testing)
It should already work like this. If not, then something has simply gone wrong
(must admit, I practically never use the combination of delay & slicing myself, so I might have skipped this during testing)
Delay doesn’t do anything when slicing (that is, slicing when NOT playing). “Slice at Cursor” only remove the delay value, that’s all. Would be so sweet if it took delay values into account, e.g. the vertical select line position in the waveform would change with delay.
Delay doesn’t do anything when slicing (that is, slicing when NOT playing). “Slice at Cursor” only remove the delay value, that’s all. Would be so sweet if it took delay values into account, e.g. the vertical select line position in the waveform would change with delay.
I’m doing some tool maintenance right now and thought I would double-check this too.
But, I think I’m misunderstanding what you want, as any manually entered note-delays are indeed factored in when the slice offset/position is calculated.
For example, if I had triggered a sliced sample and then adjusted the placement of the note with a delay command, the next time I hit “Slice at Cursor” it will insert a perfectly aligned slice at that position. IOW, playback would be seamless.
But when creating new slices, the new note will never feature a delay command. Notes created by SliceMate are always “on the grid”, by design.
However, thanks to your description I discovered one case where this behavior is not consistent: when you position the cursor above a sliced note which features a delay command, the newly inserted note will “inherit” the delay command. And it really shouldn’t - will be fixed…
I didn’t mean to say anything about the how well the slices align relative to the basenote (including a delayed note). Yes, it is perfect.
But when creating new slices, the new note will never feature a delay command. Notes created by SliceMate are always “on the grid”, by design.
It does produce delay commands when clicking Slice at Cursor when playing the song live (which is good!). My idea was that you could manually enter a delay value on a line after the basenote and then, when slicing at cursor on that line, the delay value (of the note on that second line!) would be factored in. The delay value would not be erased when slicing, then.
Alternatively, you could achieve the same if it was possible to insert sliced notes from within the sample editor.
Anyway, I discovered that I can largely get the result I want with dblue’s Slices to Pattern tool. So you can disregard my request.
My idea was that you could manually enter a delay value on a line after the basenote and then, when slicing at cursor on that line, the delay value (of the note on that second line!) would be factored in. The delay value would not be erased when slicing, then.
Yes, as I wrote I had discovered (prompted by you) that the delay command was left intact when “re-slicing” on the same line.
But this was a bug - so, I’m not planning to do it the way you propose. It will just make things harder to understand. Sorry
It does produce delay commands when clicking Slice at Cursor when playing the song live (which is good!).
Ah, of course. Un-quantized real-time recordings produce delay commands, yes.
I actually considered getting rid of this, but realized that it really is useful when e.g. using the tool for playing a long sample (e.g. a vocal recording) and manually slicing it by pressing the keyboard shortcut.
In such a case, you don’t necessarily want the result to be quantized.
–
Btw - I am working on an update which will add the following feature(s):
#1 Ability to slice phrases.
Yep, ever since publishing the first version of this tool I’ve wished for this. Now it’s finally becoming reality
#2 Slice Forward / Slice Backward.
Gives you the ability to insert new (sample/phrase) slices with regular intervals, or based on existing (sample) slices.
Would it be able to add notes/slices in pattern (and further patterns) as long as the sample duration?
The idea is to insert a note at a different (previous or next) position, relative to the cursor position.
If a slice already exists at the position, it will simply reuse that one, so you should even be use to use this feature to “navigate” around the sample without causing too much of a mess (just a lot of slices… )
So, to answer you question: as far as there is a sample buffer that the tool can chew on, it should be able insert to insert additional slices.
I’m not 100% sure how to deal with phrases though - they are different scenario than samples, as SliceMate support looped phrases but not looped samples. When slicing backwards, should the tool stay within the looped part of the phrase, or go towards the start? Or perhaps even take the previous note into consideration (if such a thing exists)?
I guess I’ll have to experiment a bit to figure out what feels right.
I’ve tested phrase slicing against phrases with all sort of LPBs, and it should be able to properly detect/translate all possible combinations.
For example, slicing a phrase that goes LPB9 in a song which is running @ LPB4. In this case, the tool calculates the right amount of delay and applies it to the generated note.
Or breakcore tempo (32LPB) against a regular LPB4 phrase - in this case, the tool will only be able to insert anything on every 8th line. But even then, it’s nice enough to instruct you in how to move the cursor to a nearby, compatible line.
Also, since looping in phrases is a relatively straight-forward affair, the tool should fully support this feature.
Hint: if you’re chopping up phrases, consider enabling auto-seek on the samples used in the phrase. By doing this, samples will start playing from their relative positions, the very moment the phrase is triggered. Otherwise, you might hear small gaps, etc.
Also squeezed in a couple of nice additions: especially that the tool no longer tracks things in the pattern while the GUI is hidden (the option is called “Suspend while hidden”).
This doesn’t mean that slicing per keyboard no longer works - just that the tool doesn’t have any (noticable) impact on the CPU when you’re not using it. Before, itcouldslow down things, especially with large songs spanning many patterns.
## 0.21
- Fix issue when placing cursor at last line of phrase
- Preserve effect-column indices for Sxx, Zxx commands
- Don't overwrite existing effect-columns (allocate new cols if needed)
- Option to suspend "selection" updates while GUI is hidden (less CPU usage)
- Add link to github documentation [www]
- Add MIDI mappings for navigating to prev/next line
I use this tool a lot since producing some raw material from vcv, usually to cut a one sample instrument, its really doing the job! I’ve not tried the phrase uses for now, but I sense an interesting composition opportunity there…
For now I would have a suggestion after trying something new with it:
I imported 6 longs equal duration samples from a session recording to build a layered timbres bass instrument.
Unfortunatly, I learned that it’s currently not possible to slice multi-sample instruments.
Was it a feature you thought to implement Danoise ? It would be a nice addition as a checkbox option !
Would it be a useful feature to some other users or am I again trying to make weird uses of Renoise?
True, and this tool can’t easily work around that limitation.
Actually, it relies on slices and the functionality they offer so it would be very complicated to do.
But what if it was possibly to “copy” slices between instruments?
Then you could slice up a “master” instrument and apply the offsets to the other ones…perhaps this could be of use?
I just found the strobotone’s slice extension tools which allow copying/transfer of slices markers. I’ll just do that master sliced instruments with slicemate and paste to other instruments as you suggest… each one having a sample of the layered bass.
My choice of putting all the bass samples in a single instrument was for a clean organization purpose… I loved the fact that it’s possible to assign each sample to a single track via the Fx Chain output, very neat way of staying organized…
I’ve started to work on beat-sync support to SliceMate
While I haven’t forgotten about the “slice forward/backward” feature (see above), I decided to spend some time on this instead: I see it a more fundamental feature. Especially when working with sliced up breakbeats, being forced to stay in the original tempo while slicing isn’t really optimal.
The best thing about beatsync support is that you won’t need to “configure” anything - it should just work.
Technically, it all depends on a function which is able to compute the pitch/note that a beat-synced sample is ‘actually’ playing at.
This allows the tool to compute the offset position, which is a requirement for slicing.
When you then perform a slice, it then looks at the beat-synced number of lines of the source sample, and divides that among the source sample and the new sample (slice). For example, positioning the cursor at the 8th line of a 64 line sample will result in 8 and 56 lines, respectively.
Similarly, when you remove a beat-synced slice using the tool, it will combine the lines back into the remaining sample.
Ideally this translates into slices that perfectly preserve the speed at all times.
Maybe hi-jacking… Is this also approaching the possibility of a simple note-aligner tool? It sounds like your functions would make it quite simple for you to make such a thing Not sure if what you’re working on is already doubling that feature, or if it’s a totally separate thing.
Ideas:
Click to view contents
In its basic form I imagine a manual one-shot shortcut, making the note under the cursor move so that its sample ends ‘exactly’ where the next note starts. (delay value being rounded so that no silence will appear).
If it also understands slices (Sxx is being used), it would be very easy to tweak the ‘end point’ with a slice marker.
(Respecting groove, group delays or tempo effects isn’t that important, since it probably makes the logic much more complex.)
Maybe hi-jacking… Is this also approaching the possibility of a simple note-aligner tool? It sounds like your functions would make it quite simple for you to make such a thing
Yes, but I would rather see this appear as a separate tool. Otherwise it would be a very useful feature “buried” somewhere inside this tool.
Also, not trying to shoehorn this into SliceMate makes it a bit easier to think/plan freely.
Click to view contents
You’re probably right about the slice marker being the sensible solution here - e.g. for the classic reverse-zoom effect with a trail after the peak.
But just ONE marker then, instead of multiple ones? Or perhaps, the FIRST marker.
