Squeaks in Simple Beat Repeat Effect
Hi, here is a patcher of mine for a kind of "beat repeat" effect. Very basic, a simple [poke~] and [count~] combo into a buffer, then using a [phasor~] and [play~] combo for playback from that buffer. Adjusting the speed of the phasor~ changes how quickly and how much (by proportionally adjusting its millisecond scaling for reading through play~) it reads back from the buffer, allowing for glitch type effects, a la the infamous Ableton beat repeat effect.
It works wonderfully, aside from occasional "squeaks". It sounds like the kind of artifacts you get from really intense bit crushing. I haven't found conditions to recreate them, but they tend to happen for shorter playback lengths and when you sequence the size of the buffer.
I turn this over to the forum to see if anyone could pin point the problem.
PS if you dont look at the patch but try to answer, i am using a hanning window to avoid clicks. clicking is not the problem, it's these strange little squeaky sounds.
Much thanks!
Did you get any further with this one?
Just researching how to build my own beat repeat....
Cheers
D
neater
sorry, yea, that patch was really messy :-/ thanks for the clean up! has anyone played around with this and found these squeaky sounds as well? S4racen, does this help you understand how to make a beat repeat effect?
I'm not seeing how it could be count~ aliasing the recording, as it's constantly an integer signal that's not being allowed to rise above the point at which it becomes inaccurate.
It looks more likely that because your record signal (count~) and playback signal (phasor~) are not synchronised, they will occasionally "pass each-other". I'm not explaining this well, but if you monitor the output of count~ and the playback signal (converted to samples) and adjust the "fraction of buffer to repeat" parameter, the signal which leads can change; if the "playhead" crosses the "record head" you'll get a glitch.
What you need to do is to double-buffer the playback. Record into one buffer, then when triggered copy however much you want to play back into another buffer that isn't being written into constantly, so will have no chance of write-glitches.
Incidentally, that's exactly what the stutter object does, so unless you need parameters that it doesn't offer, you may as well use it instead. Your "fraction of buffer to repeat" parameter is essentially the same as the "grain size" parameter in the stutter~ help patch, and your "buffer size in ms" is essentially the same as the maximum buffer length for stutter~.
Setting the count modulo with a float will not make the output signal a float; it accumulates by exactly 1 up until the number 16777216, after which it increases by 2. So count~ isn't the problem in that patch, it can't be.
The only two things I can imagine ever causing glitches in the patch are changing parameters while the patch is running, and the lack of double-buffering.
quote "(obviously output signal of count~ will not be a float, that's not my point at all!) but i'm saying 512ms multiplied by 44.1 gives you 22579.2 samples which will be truncated to 22579 samples meanwhile you send the exact float for phasor~'s multiplication by length..."
Yeah, I was in the process of editing my post because I realised that ^ was probably what you meant, but I was confusing myself thinking about it tbh.
I'll have a go at the double-buffer thing tomorrow I think. I didn't have anything specific in mind really, I sense I may have been getting ahead of myself. I'm also interested in the more efficient ways.........they might be able to help me out with similar read/write glitches in a feedback-ing circular buffer patch I was messing with a while ago.
mxj by me? no lol, I'm an utter novice with java still. Did you mean the [mxj buf.Op ] one? That could be used to copy the "fraction to repeat" into the playback buffer just like in stutter~. I'm not sure if it would be fast enough though, probably would be so it's worth a try! From looking at the help file, it seems one would have to first copy the whole buffer accross, then crop the new buffer to the desired size; or peek~ each sample out into a new buffer with uzi. Seems like it would end up clunkier than stutter~
You might also look into stutter~ writing into a named buffer~ and using other playback methods that you might prefer. That said, stutter~ is probably capable of doing most of what you want as is, if you spend some time learning the details.
hehe, fun raja! thanks for the replies, stutter seems to be the sensible alternative.
hi raja - i was curious if you knew how to augment your patch so that the grain size can be altered without creating clicks? for example, i'd like to connect a line to the grainsize to create stutter effects a la bucephalus bouncing ball. i've tried doing this with your patch, but clicks keep arising. Would i have to take out the envelope in order to do this, or is there a way to leave the envelope while still being able to alter the grainsize mid-stutter?
re: Raja's patch.
when I hit the bang button it always crashes Max. Anyone experiencing this same problem and know the cause of it?
regards
im not receiving crashes. t1inkerbot - are you sure you have the shapee~ external? are you sure you have the latest update to the external? i find crashes with patches using externals are usually related to the external.
raja - what is this thing! i don't see how or why the whole shapee~, ringmod, residentsynth portion of the patch is being used. don't need a detailed, object by object explanation, but am curious as to the general idea in using this signal chain.
thanks for the info and patches!
beautiful, raja. my many thanks, you are a max guru. now to dissect this...
hey - here's a cleaned up version that uses curve~ for exponential stuttering. Inlets are added for simple abstraction. The value to ramp to is given as a fraction the original MS value (so a value of 8 = 1/8th the size of original MS grain). some great sounding stuttering, imo :-)
Thanks a lot for sharing this patch! I've spent endless hours boxing around with the stutter object, getting stuck at clicky sounds.. You have showed me a way :) Reverse engineering this one gave a lot!!