improved multisampling

Ideas & suggestions
1

okay, recently i’ve been experimenting with making kit drum sets (and other multi-sampled instruments), and have found renoise a little limiting in this aspect. two major problems:

-only 16 samples. if you’re aiming for realism, you’re gonna have multiple samples of each hit. once you’ve done the bass drums and the hihats, you’re nearly out of room. i’m sure this would be easy to upgrade, and i think the sky’s the limit, really. 64 samples would be great. even 128.

-it is VERY tiresome. even with the drumkit map button, loading in a lot of samples for the same instrument takes a long time, seeing as only 3-4 samples for each instrument can be seen at a time. you have to scroll a lot.

my solution is quite a large thing to add, but i believe that people (especially myself) would find it EXTREMELY useful. plus aside from the want for more samples, it’s basically just a different front-end for the technology that is already there, so it may not be ‘hard’ to program.

it’s a separate screen, designed solely for multisampling. not sure what it would be called. multisampler, perhaps.

very quick sketch of idea:

the piano doesn’t neccessarily have to run vertically, but i figured it would make it easier to write the sample names on the keys if it was this way.

the basic operation would be that you click the note, then click on a sample from either of the two menus (one is basically a disk-op; the other is a list of all the samples loaded into the RNS file, or perhaps just the RNI - for if someone wants to use the same sample twice in an instrument). simple as that.

i should have drawn this next to each piano note:
[<] 0 [>]

the zero value means that the sample plays at its ‘normal’ pitch when that key is pressed. you click the arrows to change the value to plus or minus x amount of semitones. i was thinking that the fine-tuning would be in the ‘useful things’ section, but i suppose it could go next to the key as well.

i should’ve also drawn a scroll-bar on the piano graphic, because obviously you cannot show the entire range of the instrument ;)

other little detail - if the same sample is to be used for a range of keys, the user simply loads the sample for one key, shift-right clicks it, and then right-clicks to ‘paste’ that sample over every other key they want to play it.

the ‘other useful things’ would mainly be up to the programmers; i know you’re good at thinking of thinks that are useful. :P

so does it sound good? i believe it does. someone back me up! :D
try and get the programmers interested in this.

p.s. another thing that would make kit drumming a lot easier would be to make it so each note’s volume affects only that note, and not its decay when the next note comes in (bad description - i mean if you’ve got an instrument set to fade out quickly when a new note comes in, and you play a note with a volume of 40 following one of 10 - the decay of the previous note will become louder when the second note is triggered), but i think you’re doing this already. ;)

2

I like it, it doesn’t have to be in this excact form, but as a general idea it’s good.
Right now we’ve got our hands full with other stuff, but keep on brainstorming. :)

3

Gwilym: i think an advanced softsampler in Renoise is only a question of time and you named only some features for this theme …

not only more more single samples per instrument are needed, also velocity dependent sample-sounds etc. etc. …

older suggestions:

Sampler improvements
AKAI/Giga import

4

I have a new one I think :)

Velocity dependent instrument envelopes :)

5

yeah, i figured out an OBVIOUS inclusion for the ‘useful things!’ area - volume envelope ;)

but yay, it’s good to hear interest in this sorta thing

velocity-based multisampling would be GR9!!

6

okay, here’s a radical idea: instrument trees and randomization.

hard to explain, i’ll just try to recreate an example:

PARENT INSTRUMENT ‘drumkit a’

sub instruments:
bass drum
c hihat
o hihat
snare

this is mapped to a keyboard; you don’t need much imagination to figure out how that would be done.

but the radical part: there are x amount of samples for each drum type! when you enter a note, it selects a random one and inserts that! now i don’t want it to be real-time randomisation (so it sounds different every time you play), which is why i call this an instrument tree… as far as the pattern data is concerned, it just looks like you’re using a different snare each time. the instrument you’re using to input them could be considered almost a ‘front end’ - a controller for all your other instruments. know what i mean?

i’m not good at describing, but you’re good at understanding. maybe it will even out.

7

How do you mean randomly selecting an instrument should happen if it’s not completely random? The rest of your idea is basically a way to realize multisampled instruments, I understand that part.

8

well, i’m not sure how randomise coding works…so i’ll just give an example.

let’s say that instruments 00 through 08 are all different recordings of a snare drum

on this ‘parent instrument’ (the drumkit), you have E-5 mapped as a snare drum. when using this parent instrument, every time you hit E-5, renoise randomly selects a sample from 0 through 8, and inserts that into the song (or just plays it, if you’re not in record mode).

make more sense this time? :)

9

what would be the purpose of random sample selection?
Realism?

Just asking.

(btw, that famous day on which multitimbrality would be supported and so I would be able to separate different drum elements into different tracks, I will add a LFO-driven filter to the snare. Try to play sometime with this and see how much realism it gives to the sound)

(btw2: more than random, I would prefer a volume-controlled selection, as it is for every multisample sampler (e.g. HAlion, Kontakt, VSampler, …), as it has been already suggested into this thread and lots of time ago by me :rolleyes:)

10

yeah, realism. realism that i would put in anyway, but having this would make it MUCH faster. i wouldn’t have to select a different snare myself each time.

11

lfo for the snare is not good, we need a random cutoff (which stays where it is and does not go up and down as with an LFO). I dream of this feature too.

12

It’s probably more useful with a randomize function you can apply to any parameters in any range you want. That way it will sound the same way each time, and you can change some places manually afterwards if it sounds wrong.

13

I actually thought this was possible now by setting up a random LFO and sending a reset command (1600) on each snare. But after some testing I discovered the reset button won’t send a new randomize, it does nothing in randomize mode. I really think it should…

14

argh… :wacko:
I wrote about the LFO driven filter because I thought that this would have worked.

Yes, this should definitely work this way, though I wouldn’t be able to use it until

MULTITIMBRALITY (*)

will be implemented, possibily before skin support… <_<

still, you could manually set the cutoff and resonance (resonance counts too, looza) at each snareshot, which would be an hell of a work, but would be a good reason to let you be called a ninjatracker

(*) just to outline the concept :) :ph34r:

15

well, the humanize thing works too at this point.

16

I use the NI ‘battery’ drum machine often. It uses a system that lets you layer samples on a certain note or cell. Then it allows you to specify crossfade ranges for the layers, the velocity of the note then determines which samples sound, and how loud. not a brilliantly new idea but works well.

What it also has is a (realtime) scalable random value generator that can be routed to any parameter associated with that cell/note. using this, you can route the random vaue to velocity, and the random velocity will trigger one or more of the layered samples differently each time.

I’d really like to see realtime randomisation in renoise, its great for ‘natural’ drums, and experimental stuff too.

17

Humanize is really just for clutter. In my mind, you’d have a pane that did non-destructive editing of pattern data (Cubase MIDI plug-in-esque), and you could record the state and save it as a snapshot or preset, or you could set it to change at given intervals. By this I mean give every setting a range and an interval at which it will change to any other value within that range. You could record that as a macro or whatever. This would do away with the whole pattern clutter thing. Also, you should be able to convert it to actual pattern data and back, if you were curious about it.

One of these settings could be to choose from a given range of samples. That ongoing selection could be guided by chance (cycling through sample range, forward, reverse, ping-pong or random), interval (same, cycling at specific intervals), velocity (use designated sample for current velocity), note (like a drum instrument), etc.