[Done 2.7] Mapped Sample Offsets

The problem:
Sample offsetting (the 9 command) is based on a percentage, so as the sample gets larger, your precision gets smaller. This method is inaccurate (and obsolete). A (destructive) process of cutting/pasting is the only solution for byte accurate sample access.

The solution:
Create markers in the sample editor, which can be referenced in a tracker.

Markers can be accessed via a tracker-command, or via the more traditional key map. (depending on what floats your boat). Offsets can be configured to stop at the next marker, or to continue until the sample ends.

This is both non-destructive and easy to manage. Offsets could be automated to match actual transients rather than even spacing.

(This the idea/solution was also expressed in a similar way by Anko at http://www.renoise.c…showtopic=26371)

yes please! votes +inf.

also would be spiffy if marked ranges could be given ‘aliases’ (names) and then treated just like any stand alone sample by renoise…

edit: just to clarify, for instance by being able to assign the alias to sample or instrument slots etc.

This has been suggested quite a few times by different people (myself included) using slightly different wording like ‘slices’, ‘markers’, ‘regions’, etc., and there have even been a couple of screenshots made in different threads, but your mockup is one of the clearest and easiest to understand that I’ve seen so far. I also fully agree with the optional behaviour to stop playback before the next slice. Great work, mate ;)

In my particular ideal version of this, it would also be possible to give each individual slice/region/offset its own loop settings, which I often do manually when working with breakbeat loops. I will cut each individual sound out of the drum loop, then apply a pingpong loop to the tail-end portion of each hit (typically the ‘air’ inbetween hits), which then allows me to play the entire loop slower and still maintain the overall air/ambience, rather than having choppy silence between each hit.

Even without individual loops at first, implementing what you have outlined here would be a huge step in the right direction.

I’ve thought about this multiple times too (the command mapped offset idea).
Only problem is there aren’t any commands free anymore. In your example you use 99xx, what happens to the 9th parameter of the 9th device in the DSP chain?

The only solution I can think of is making two different effect columns, one for controlling parameters of dsp’s and one for the sample commands.

nice feature idea and a good tip as well!

A simpler solution proposed in other threads has been to add a ‘sample offset mode’ selector in the instrument properties.

The options would be something like:

  • 256 equally-divided regions mapped to 00-FF
  • 256 user-defined regions mapped to 00-FF
  • 256 user-defined regions mapped to notes

You would choose the appropriate 09xx behaviour for that instrument, and then the 09xx pattern command would remain the same.

This is of course just a quick/temporary suggestion. Most people argue that it should be possible to handle any situation at any time without being limited to one particular mode, but this will require new pattern commands to be created, which itself requires that pattern command identifiers break out of the hexadecimal naming scheme. A lot of this has already been talked about and argued for/against in the past, hehe.


Here’s a quick example, which I forgot to include in my earlier reply:


The idea of having ANOTHER column seems crazy (but still feasible I guess!)

What about “0G” (g) as a command? Is hex a necessity? Or something more relevant like “S” or “O (for offset)”. 0G-0Z are still unused if there’s no technical limitations.

Key-mapping is perhaps the way to go in conjuction with a key-transposer metadevice if you want to change pitch :P (now there’s an interesting idea) :)


Also just as a general comment, the instrument editor is ancient. Would love to see it get a makeover in the near future.

The existing xrni format is more or less the .xi (ft2) instrument format with filters & polyphony/NNA. So the technology is around 15 years old.

It would probably be better if they developed a special API for the instrument format so you can add oscillators + filters/effects - something like SynthEdit for Renoise would be perfect. It’s wishful thinking and maybe too much work.

All this stuff is priority number one for me personally, development wise. Especially the 09xx user definable / NNA stuff, that is my bread and butter!

+1 :)
it will be very very useful!

this is an awesome idea. +1



I am in for this! +1 <_<

+1’s for everyone!

good idea because who really prefers inaccuracy rather than accuracy.

bump. hoping this feature makes its way into renoise eventually.

Dblue’s ‘Sample offset mode’ idea works for me. I doubt that I’d use the usual 09xx command if slices (or whatever it’d be called) was available.