Rotterdam, Netherlands
Stutter effect: max/msp WIP
StoreTags: help, stutter, max/msp, wip
Author: cbit on April 06 2008
Viewed 3121 times. 14 people liked this blog. You can rate it below if you haven't already.
People who enjoyed reading this: lematt, ejectorset, room, Roshi, yghartsyrt, hecanjog, Logo, skab, minim, flies, dustmite, kwyj, mlbot, p
--> Hi guys, here's a stutter effect i'm working on in max/msp.



At the moment it's not stuttering as 'smoothly' as i'd like. Sometimes you hear clicks, and some 'grains' are not muted when they should be. I'm looking for help to identify why that is, and to figure out how to remedy it.

If anyone is interested in taking a look at the patch you can get it here: link

cheers!

oh *Some info about the effect.*

Anytime it 'hears' any audio, it samples a small piece of the onset of the sound into a buffer, and repeatedly plays that buffer for as long as sound is entering the device.

When it plays the buffer back, it mutes itself after playing the fist X miliseconds of the buffer.

The rate at which the playback of the buffer repeats changes ovver time. (giving that 'bouncing ball delay'-ish result)

The controls are:

* Repeat rate start (how fast the repeating happens at the beginning of a 'run')
* Repeat rate end (the final repeat rate that it will end up at)
* Duration (how long the transition between start and end rates is)
* Curve (control over the 'shape' of the transition, 50%=linear)
* Grain len (length of grains. ie, how soon the grains get muted)
Read cbit's other blogs.cbit's Recent Blogs
Comments

1 | 2
that's pretty fun.

i love the clicks...

thanks lematt, its a shame i'm no fan of the clicks ;)

the first and most obvious suspect for the clicks would be non-zero crossings.

from your description it sounds to me like you are moving/muting the start point of the loop/buffer. so maybe the end point sometimes is at a particularly non-zero point and causing the noticeable clicks?

from your description it sounds to me like you are moving/muting the start point of the loop/buffer. so maybe the end point sometimes is at a particularly non-zero point and causing the noticeable clicks?


Yes. But i'm using an adsr to control the 'grain' amplitudes. and i thought that when the adsr object got retriggered, it did a rapid fade out to avoid clicks. There is probably something i've misunderstood to do with the adsr though.. (i have 5ms attack, 5ms release and 5ms retrigger values at the moment)

I was wondering whether the inconsistencies might have to do with not using audio rate conections in some places where i should be doing. But i'm not sure about that.

clever stuff - good luck with completing it - it sounds like it has a lot of potential.....

let me know if you want it added to the audiobulb CREATE section when it is done....

I would suggest looking into using a two window grain system with a sin/cos based cross fading for each grain. ADSR are no very good for grains in the work i have done. I have a patch in Reaktor that does this kind of stuff if you are interested in looking at it.

room: that'd be good. I'll let you know when its done.

em978, i'd be very interested to learn more about the sin/cos technique you mentioned. If convenient, you could mail the ens to stutter.5.cbit AT NOSPAM spamgourmet.com or let me know if its online somewhere already.
cbit said: "I was wondering whether the inconsistencies might have to do with not using audio rate conections in some places where i should be doing. But i'm not sure about that."


I think you are right and I think the culprit is the adsr. since it receives it's input max time (and so is at the mercy of the scheduler). I've gotten best results when the window is generated from the same signal as the one that plays back the sample (or in this case the sync signal from the third outlet of the groove~) so thebuffer and window are synced at audio rate. this wold probably involve buffer~ing the adsr data and reading it with wave~.

p said: "
cbit said: "I was wondering whether the inconsistencies might have to do with not using audio rate conections in some places where i should be doing. But i'm not sure about that."


I think you are right and I think the culprit is the adsr. since it receives it's input max time (and so is at the mercy of the scheduler). I've gotten best results when the window is generated from the same signal as the one that plays back the sample (or in this case the sync signal from the third outlet of the groove~) so thebuffer and window are synced at audio rate. this wold probably involve buffer~ing the adsr data and reading it with wave~."


Aha. yes that makes sense. So the audio rate 'position' output of the groove~ would be being fed to a wave~ which would be looking up amplitude values from a 'shape' in a buffer that had been predefined somehow. Have i got that right?

If i'm on the right track, do you know what would be a sensible way to get a simple window 'shape' into a buffer so that i can read back from it to control the amplitude of the grains that way?

cbit said: "

Aha. yes that makes sense. So the audio rate 'position' output of the groove~ would be being fed to a wave~ which would be looking up amplitude values from a 'shape' in a buffer that had been predefined somehow. Have i got that right?

If i'm on the right track, do you know what would be a sensible way to get a simple window 'shape' into a buffer so that i can read back from it to control the amplitude of the grains that way?"


the groove~ object will gve you a sync signal 0. to 1. which is the format the wave~ uses to play back samples.

I've used peek~ and multisliders, but there should be a way to make something that behaves like the adsr. I"m not sure what would be the best way. but I'm toying with stuff now.

this thing is fun.

also look at help on pong~. for this kind of stuff. you can foldover phasor~/line~ signals allowing you to generate synced signals at various lengths. a good way to shorten/lengthen the window while keeping it in sync with the main signl.

looks really great cbit.
i'm pretty amazed how quick you got used to max.
i think p methods sounds quite reasonable. haven't tried em978's method yet.

thanks a lot p. I have to take a closer look at pong~ phasor~ and line~ to see how i could get these working as audio driven envelope generators (its not obvious to me yet!)

cheers ygh! farting around with synthedit, synthmaker, sonicbirth and reaktor gave me a headstart with max (which is the most 'straightforward' of all of them imo)

1 | 2

Register / login
You must be a member to reply or post. signup or login