Seb Shader

hi, I'm having some trouble understanding when/how the samples are copied from the record buffer to the playback buffer with stutter~. If I use the setbuf message and send a clear message to the buffer~, it is clear that the buffer takes n/m samples to fill (as stated in the documentation).

However this doesn't seem to be the case if I send "clear" to stutter~ itself. the entire buffer is available as soon as a "bang" is sent (after recording enough material)

why is this? where is the object saving cpu/using memory by using a lower value as the 4th argument? Is it somehow continuously writing to the record and playback buffers so that all the of samples will be available when a "bang" is sent? how does a higher "samples-copied-per-perform-loop" save memory?

hi, I'm having some trouble understanding when/how the samples are copied from the record buffer to the playback buffer with stutter~. If I use the setbuf message and send a clear message to the buffer~, it is clear that the buffer takes n/m samples to fill (as stated in the documentation).
However this doesn't seem to be the case if I send "clear" to stutter~ itself. the entire buffer is available as soon as a "bang" is sent (after recording enough material)
why is this? where is the object saving cpu/using memory by using a lower value as the 4th argument? Is it somehow continuously writing to the record and playback buffers so that all the of samples will be available when a "bang" is sent? how does a higher "samples-copied-per-perform-loop" save memory?
thanks

hi, I'm having some trouble understanding when/how the samples are copied from the record buffer to the playback buffer with stutter~. If I 

help-understanding-4th-argument-to-stutter~

I believe that the way stutter~ works is that it is constantly recording. You'll note that when you activate it, it doesn't start recoding upcoming audio, it's already got a buffer full of material that's been captured into the buffer. When you trigger it, it plays the audio it's already collected in the recent past.

but the helpfile mentions that audio is copied from the record buffer to a different playback buffer.. and it seems like the 4th argument somehow determines how that happens.

The best thing I can figure right now is that the "playback buffer" is just the record buffer on the first pass, but then as it is playing it is getting sent to another buffer (as the write point writes over it) so that it can play again..

but the helpfile mentions that audio is copied from the record buffer to a different playback buffer.. and it seems like the 4th argument somehow determines how that happens.
The best thing I can figure right now is that the "playback buffer" is just the record buffer on the first pass, but then as it is playing it is getting sent to another buffer (as the write point writes over it) so that it can play again..

@SebShader, you're probably wondering mainly about this description in the docs which confused me at one point:

Screen Shot 2021-03-21 at 1.00.25 PM.png

i haven't used the object in awhile but the way i eventually came to understand it: 

-there is an internal record buffer and an internal playback buffer, 

 whose internal length is actually sized by the 'maximum length'(first) argument(you can actually confirm this by sending a grain size the size of the maximum length, then try to scroll larger than that, and at this point the playback speed in the helpfile will shift lower since the 'grab' operation clips at the maximum length while the playback speed is still informed by the larger-than-maximum length of samples... this means the playback buffer can't be larger than that maximum size and the record buffer would have to be that as well)

-the 'initial grain size'(second) argument is like the 'int' message sent to the object which determines what length of samples within the playback buffer you'll access for playback(if you send an int, like the helpfile does of 100, now the playback buffer only allows you access to control playback of those 100 samples alone by the phase/right-inlet)

-the 4th 'number-of-copied-samples' argument determines how many samples are copied to the playback buffer each iteration of the perform loop, and that simply determines 

the playback buffer fills up with the necessary number of samples: if it needs to write a larger value of samples while this happens, CPU will be used more until all samples are grabbed, but memory will not need to be accessed as often(because it grabs a larger number of samples in one go, doesn't need to keep grabbing as many times to fill up)

in this way, 'memory use' is decreased, it doesn't mean the size of internal memory is decreased but just the frequency with which it needs to access that memory.

given all of the above, the docs might be rewritten a bit more clearer like so:

"A larger value will decrease the stutter~ object's memory 

requirements, and increase the CPU requirements."

i think this is probably mostly all significant to how the object can keep up nicely with changing grain-sizes quickly(if you use a larger maximum size, then it's probably better to use a larger 4th argument just to keep up with drastic changes in grain-size within that larger overall range... otherwise, you could probably leave it at around 10 samples each perform-loop if you're just working with half-a-second maximum durations).

sorry for the lengthy explanation, i thought alot about this long ago... i'm not sure, but i think this object also used to be in an older form written by Eric Lyon, called "el.stutter~" 

https://github.com/ericlyon/LyonPotpourri3.0-MaxMSP/blob/master/Projects/el.stutter%7E/stutter%7E.c

and also i read Eric's book on writing externals which covers memory access for msp objects like this internally... so after awhile of looking over all of these various things, this is how my brain came to understand it.

DaddyMax writes the truth! 🙌
@SebShader, you're probably wondering mainly about this description in the docs which confused me at one point:

i haven't used the object in awhile but the way i eventually came to understand it: 
-there is an internal record buffer and an internal playback buffer, both whose internal length is actually sized by the 'maximum length'(first) argument(you can actually confirm this by sending a grain size the size of the maximum length, then try to scroll larger than that, and at this point the playback speed in the helpfile will shift lower since the 'grab' operation clips at the maximum length while the playback speed is still informed by the larger-than-maximum length of samples... this means the playback buffer can't be larger than that maximum size and the record buffer would have to be that as well)
-the 'initial grain size'(second) argument is like the 'int' message sent to the object which determines what length of samples within the playback buffer you'll access for playback(if you send an int, like the helpfile does of 100, now the playback buffer only allows you access to control playback of those 100 samples alone by the phase/right-inlet)
-the 4th 'number-of-copied-samples' argument determines how many samples are copied to the playback buffer each iteration of the perform loop, and that simply determines how fast the playback buffer fills up with the necessary number of samples: if it needs to write a larger value of samples while this happens, CPU will be used more until all samples are grabbed, but memory will not need to be accessed as often(because it grabs a larger number of samples in one go, doesn't need to keep grabbing as many times to fill up)
in this way, 'memory use' is decreased, it doesn't mean the size of internal memory is decreased but just the frequency with which it needs to access that memory.
given all of the above, the docs might be rewritten a bit more clearer like so:
"A larger value will decrease the stutter~ object's memory access requirements, and increase the CPU requirements."

sorry for the lengthy explanation, i thought alot about this long ago... i'm not sure, but i think this object also used to be in an older form written by Eric Lyon, called "el.stutter~" https://github.com/ericlyon/LyonPotpourri3.0-MaxMSP/blob/master/Projects/el.stutter%7E/stutter%7E.c
and also i read Eric's book on writing externals which covers memory access for msp objects like this internally... so after awhile of looking over all of these various things, this is how my brain came to understand it.

hope it helps 🍻

that's what I thought at first as well, but that doesn't make sense w/ some experiments:

In the help patch: with the playback speed at 2, with the grain size set to 22050 samples, with "autograb" off, and with the "number-of-copied-samples" argument set to 1 I:

1. clear the stutter~ (with the clear message)

3. send a bang to the left inlet of stutter, and a 1 to the right inlet of the phasor~, and start recording the output of stutter~ into a buffer~ (w/ size also 22050 samples) with record~.

4. stop recording into the buffer~ after another 500 ms.

first of all, I would think that if the record buffer was copied to the playback buffer when the bang is sent, that the playback head would overtake the pointer writing into the playback buffer and there would be silence, since the phasor~ is moving forward in the playback buffer 2 samples for every 1 sample written. But that isn't what happens: there's no silence and it sounds like the whole playback buffer is being read fine.

Maybe there's a lower limit to this 4th argument tho.

Exactly the same thing happens if I read the buffer backwards using a [!-~ 1] after the phasor~.. (stutter~ plays back the whole buffer on the 1st pass, regardless of whether playback starts at the end or the beginning.) So if the playback buffer were either written to starting at the end or the beginning and only writing a certain number of samples per perform loop iteration when the bang was sent, I would imagine that the 1st pass would have silence in it somewhere until the right number of samples were written to that part of the playback buffer..

In the help patch: with the playback speed at 2, with the grain size set to 22050 samples, with "autograb" off, and with the "number-of-copied-samples" argument set to 1 I:
1. clear the stutter~ (with the clear message)
2. wait 500 ms with [del]
3. send a bang to the left inlet of stutter, and a 1 to the right inlet of the phasor~, and start recording the output of stutter~ into a buffer~ (w/ size also 22050 samples) with record~.
4. stop recording into the buffer~ after another 500 ms.

I think it must be some combination: a certain number of samples per perform loop are copied to the playback buffer when the bang is sent, but samples from the record buffer are used until they are copied

(that is, if it's true that "memory used" means memory accessed.)

no prob... haha, look at you, Mr. Super Sleuth Seb Shader! nice work :) it's stumped me as well:

i thought for a second, because the wording is "each iteration of the perform loop", even with 4th argument set to 1, the perform loop iterates over a vector-size worth of samples faster than real-time(allowing them to then stream at sample-rate reliably), so this might mean a vector-size worth of samples could be available at first, plus some internal interpolation would add just a bit more history probably over that, but then no matter what ridiculously high speed i try above the vector-size, i can't detect any delay/silence anywhere in the playback buffer's output. 🤷‍♂️

@Cycling74: we suspect thy help-file 'tis spinning a web of LIES to protectst thine dark sorcery behindst the stutter~! 🧙‍♂️🧟‍♀️ (i can't seem to prove anything yet though🧐)

no prob... haha, look at you, Mr. Super Sleuth Seb Shader! nice work :) it's stumped me as well:
 i thought for a second, because the wording is "each iteration of the perform loop", even with 4th argument set to 1, the perform loop iterates over a vector-size worth of samples faster than real-time(allowing them to then stream at sample-rate reliably), so this might mean a vector-size worth of samples could be available at first, plus some internal interpolation would add just a bit more history probably over that, but then no matter what ridiculously high speed i try above the vector-size, i can't detect any delay/silence anywhere in the playback buffer's output. 🤷‍♂️

@Cycling74: we suspect thy help-file 'tis spinning a web of LIES to protectst thine dark sorcery behindst the stutter~! 🧙‍♂️🧟‍♀️ (i can't seem to prove anything yet though🧐)

help understanding 4th argument to stutter~