Synthesising drums

Yes, this is a known, but annoying bug; I’ve posted multiple topics about it, thanks that you also mention it. At this moment the only thing I can really do is split the name in multiple sample slot names, but that is a really ugly solution and just doesn’t do right to why I’ve used this way of saving settings in the first place. IMO it’s a unnecessary bug in the xml structure of XRNIs (example: the file inside the zip could just be called
Sample00.flac
instead of
Sample00 (Overtuned !! {step1='step1=‘shape(fold(squ(X)-sin(sin(sin(X)))-.8-tri(X)+.02-sin(16-X),0.32),2)+max(rd(T,3)-04-tri(X-1024),ru(T,3)-.04-tri(X-1024))’,stepn=‘0’,steps=1,times=1,power=true,stereo=false,base_note=9}).flac
, and still be recognizable as being the sample on the 00th position in instrument).
Another way to improve the situation is if we could just have tools save extra XML info together with an instruments samples.

Anyway let’s just keep this topic positive and post drum/synth stuff! :D

Ah, hadn’t read those threads. Well then it’s ok. I thought there was something in the wavecode, that caused this… But at least it is saved as text, so nothing is lost.

I have by now made use of all the functions and the fascination still grows. Latest I have been splicing recorded samples into little frequency chunks with a bandselect filter and tried to rebuild it with overtune :D/> :D/> … welll I am still working on it… but at least I got some decent drumsamples out of it. (back to topic)

spaghettisnare
asskickdrm

(I had to add a little punch and schmutz via the instrument filter and pitch env, but the dry sound is OK I think)

as there are a lot of things, I already miss in overtune, (smoothing function would be cool, user defined sample amount, presets, larger input field, AI, pianoroll, nibbles…) maybe I will start kicking my LUA learning ambitions by tuning your tool a little.

seriously, man. I am really learning something here.

That’s the good part indeed :D

This is very ontopic actually (Y)
It’s what I do some days too, just get a drum sample from anywhere, try to rebuild it somewhat and then make a loop/song from there.

By user defined sample amount, do you mean like sample rate? As for length, I am thinking of implementing ‘make a sample of one beat, x.y lines, etc’
And on smoothing, I agree. I think it’s doable, I might look into it right now. Although I do have homework assignments.
Of course you’re free to fork the git repo.
The idea I got overnight is that OT should be even more about repetitions, like it’s for overtones now, it should be easy to program a formula like

  
sin(X + sin(X) + .5*sin(X)*sin(X*3) + .25*sin(X)*sin(X*3)*sin(X*5) + .125*sin(X)*sin(X*3)*sin(X*5)*sin(X*7))  
  

up to X*19 or whatever. Like in Excel you can type in Monday, Tuesday, then it knows when you ‘extend’ it, it needs to go to Wednesday Thursday etc. And then of course it needs more GUI/reusable formula fields so we can define envelope amounts for these pitchmods…

PS. You might have noticed already, there’s also an builtin edit function (in beta now), that can modify the ‘Y’ (signal) values with a formula too.
PPS. these drum instruments are the shit :D really cool how you also use the envelopes, especially the EQ -15dB I wouldn’t have thought of that.

One more comment to your drums: not sure if you know this, but I use this a lot; since V2.2 or so all OT info is saved into the sample name (as opposed to multiple samples taking the various properties as names), this makes it really easy to make a instrument out of multiple OTs that you can independently set level, transpose, etc for. I say this because I think either your snaredrum or kickdrum example had meticulously crafted sin(…)…+squ(…)…+tri(…)*… in it. It’s also a good method, for snares I definitely always use at least two different layers, one for pitchbent, clipped sine and one for noisehit.

@weizenkeim, and others;
Newest version of Overtune @ dropbox has an update which kind of fixes the ‘longname’ bug… if you have a “too difficult” formula that doesn’t load back into renoise from .xrns or .xrni, you just have to rerender from Overtune again. It shouldn’t fire errors anymore. I’m convinced that volume/panning/tuning information of the samples stays intact.

Some more stuff that I didn’t yet tell…

  • rnd() gives random values between 0 and 1 - so bi(rnd()) gives noise signal in newest version, rnd() is AC, use urnd for DC noise
  • lowrnd(t,n) gives rnd() value that only changes every n samples… that means you can control kind of the ‘frequency’ of the noise signal

lowrnd can be used like this for a hihat (HPF+Distort to taste):
bi(lowrnd(T, 1+flr(7*ru(T,1.7)) ))*recd(T,6)

first: a future version will of course replace rnd() with a signal [-1…1] range always <random values between 0 and 1 can then still be accessed by using math.random() or un(rnd())>
second: the n in lowrnd argument list really needs to be a nonnegative, nonzero integer. that’s why flr is used. I’m looking, right now, for a trustworthy method of fixing it implicitly.

  • quant(x,n) - like lowrnd but on a signal. implements ‘sample&hold’, or ‘bitcrushing’ to a certain samplerate. the fun is in the fact you can use it with varying values through the sample

check out this kick for instance:
0703-lpfthis.xrni (it goes well with this one: 0703-cabsimthis.xrni; figure a nice low key for both)
so also in the case of quant (and semiquant) it assumes a integer value of 1 or higher for the n arg. behaviour is even less guaranteed than normally, if you use it with negative or float numbers.

a very good argument can times be made for the sin(…)+saw(…) etc approach, try e.g. this synth: fatnoisysynth.xrni (again with detunings by AwesomeSawce tool, similar to my howto in the Bells topic)

  • abs(x) - returns absolute value, i.e. -x if x<0
  • mod(x,m) - modulo

for much used tx function there is now also these ‘waveforms’ (handy for modulation)

  • sin1(t) - gives sin(t2pi)

  • squ1(t) - dito for squ

  • tri1(t) - dito for tri

  • saw1(t) - dito for saw

  • sinsin(x,n) - e.g. if n=7, gives sin(sin(sin(sin(sin(sin(sin(x)))))))

  • muffle(x,l,m,a) - weird compressor type function that will remain undocumented for now except for this: I occasionally use it with e.g. muffle(signal,.8,.2,1.6)

I’ve already said some things about supermin/supermax, they can be used to make funny looking signals e.g.
supermin(sin(X),2.5shape(saw(X),2))
supermax(sin(X),2.5
shape(saw(X),2))
You can even combine these into a left/right combo by using the ite function:
ite(C==0,supermax(sin(X),2.5shape(saw(X),2)),supermin(sin(X),2.5shape(saw(X),2)))

Have fun

check this out
1106-a-otdrumdemo-2.xrns