New oscillator, SawSine...

malc · 30 May 2005

Very nice Shif.

I see you have one of your strip based knobs in there, is that working fine now then?

Shifrin · 30 May 2005

malc wrote: Very nice Shif.

I see you have one of your strip based knobs in there, is that working fine now then?

It seems to be ok now in 0.9.3s, any further trouble and I'll let you know 🙂

Shif.

Shifrin · 30 May 2005

For those that are curious, this works by computing the derivative of a modified sine wave! When 'shape' is 0 we get a cosine wave, there is no modification of the sine wave. When shape is '1' we get a sawtooth wave, this is the derivative of a full-wave rectified/slightly shaped sine wave 😉

Shif.

unkargherth · 30 May 2005

Can i ask you some questions , Shif?

Why you used two diferent code modules ? As far as i can see, it could be done in one with a litlle rearragement ?

Thereis really any need to specify stages() explicitely ?

Anyway, nice work

Shifrin · 30 May 2005

unkargherth wrote: Can i ask you some questions , Shif?

Sure thing 🙂

unkargherth wrote: Why you used two diferent code modules ? As far as i can see, it could be done in one with a litlle rearragement ?

Well, I thought I'd be able to do it within one code component too. However I couldn't get the right behaviour from the stage(3)/Z^-1 section. Perhaps I made an error with it, if you can move it into one code component that'd be great unk! The second code section basically does out (t) = scale*(in(t) - in(t-1)).

unkargherth wrote: Thereis really any need to specify stages() explicitely ?

It *is* necessary to specifiy stage(3)/Z^-1 stuff explicitly. The code that is specified as stage(1) doesn't need to be AFAIK (SM puts all 'un-staged' code into stage(1)), but I prefer it that way for myself as it's clearer for me 😉

[edit]The problem I had having to put the differentiator into a second code component could have been down to a bug which is now fixed - I'll have a try to change it![/edit]

Shif.

Shifrin · 30 May 2005

I've got it done in one code component now, will update the .osm file 🙂

Shif.

Shifrin · 30 May 2005

Updated now, all done in one code component, thanks for the pointer unk 🙂

Here's the code for anyone just wanting to copy/paste it :-

polyin freq; polyin shape; polyout out;

float cnt,shp,prv,cur;

stage(1) { cur = sin1(cnt); cnt = cnt + freq; cnt = cnt - ((cnt >= 1.0) & 1.0); shp = (0.5 - shape)*2.0; cur = (cur < 0.0)&(shp*cur) + (cur > 0.0)&(cur); cur = cur/(1.0 + 0.25*shape*cur); out = (0.1667/freq)*(cur - prv); } stage(3) { prv = cur; }

Shif.

unkargherth · 30 May 2005

Sorry, Shif, but this code causes and inmidiate crash when i play firts note

Edit : Only crashes if i copy/paste. It seems to work if i re-download, so forget it by now

unkargherth · 30 May 2005

Well. Shif. Tested Now. Good news is that it seems that aliasing is approx 75% lesser than before. Bad news is that still exists ( especially when high shape and playing high note chords ) and is fairly noticeable (around minus20dB - sorry, i can't be more precise on maginitude - )

stefan · 30 May 2005

unkargherth wrote: Well. Shif. Tested Now. Good news is that it seems that aliasing is approx 75% lesser than before. Bad news is that still exists ( especially when high shape and playing high note chords )

You could ofcourse oversample it by using a loop and a lowpass filter within that loop 🙂

Shifrin · 30 May 2005

unkargherth wrote: Well. Shif. Tested Now. Good news is that it seems that aliasing is approx 75% lesser than before. Bad news is that still exists ( especially when high shape and playing high note chords )

I just updated the .osm and code snippet, removed unecessary variables and whatnot. Glad you got it to work. I copied the code and pasted into code component in 0.9.3s and it ran fine.

I know it aliases, but I kind of like the aliasing noise 😉

Of course there are ways to generate a sawtooth without aliasing at all, and ways to reduce aliasing in this osc (oversample it...). But it's quick and dirty and you can perform all sorts of manipulations on the sine wave before differentiating to produce a great many waveshapes/timbres - albeit with some aliasing 🙂

Shif.

Shifrin · 30 May 2005

stefancrs wrote: You could ofcourse oversample it by using a loop and a lowpass filter within that loop 🙂

I'd thought of oversampling it myself but haven't tried that yet 🙂

Shif.

Shifrin · 30 May 2005

Crude 4 x Oversampling version, reduces audible aliasing quite a lot, I like it. Also changed the tuning, so instead of blending "Sine -> Saw 2x Freq" it does "Sine 0.5x Freq -> Saw".

polyin freq; polyin shape; polyout out;

float cnt,shp,prv,cur,old,r;

stage(1) { r = 0.2; loop(4) { cur = sin1(cnt); cnt = cnt + freq*0.5*(1/4); cnt = cnt - ((cnt >= 1.0) & 1.0); shp = (0.5 - shape)*2.0; cur = (cur < 0.0)&(shp*cur) + (cur > 0.0)&(cur); cur = cur/(1.0 + 0.25*shape*cur); cur = cur*r + old*(1.0 - r); old = cur; } out = (0.333/freq)*(cur - prv); } stage(3) { prv = cur; }

Incedently, do expressions like 0.5*(1/4) get converted to 0.125 by the compiler?! If not I'll change it! I just prefer to keep things like that seperate for my own benefit!

Shif.

Shif.

jorge · 30 May 2005

Shifrin wrote: Incedently, do expressions like 0.5*(1/4) get converted to 0.125 by the compiler?!

Not at the moment, it's easy to make the compiler do those conversions but that will probably be done last as there's higher priorities at the moment.