Peiman

I've been banging my head against the wall for a few days now trying to figure this one out.

I'm looking for a way of 'poking' into a buffer, but instead of overwriting the value I need to add to what's already there. This needs to be done at signal rate but there is no obvious way of ordering the execution of signals so I'm at a loss...

I've been banging my head against the wall for a few days now trying to figure this one out. 

adding-to-buffer-index-like-poke-but-not-overwriting

Is gen~ or java the only way to do it without writing an external?

Use count~ and index~ to get the value held at each sample in the buffer~, add that to the value you want to add to that sample, poke~ it back into the buffer~.

If I understand you correctly, you can:
Use count~ and index~ to get the value held at each sample in the buffer~, add that to the value you want to add to that sample, poke~ it back into the buffer~.


you can do this in regular msp, depends on how you're reading and recording though... would this work for you?

(if you have gen~ though, and you know how to use poke~ and index~, gen~ has objects like 'splat' with overdub options that are just as easy to use)

edit: oops i posted same as chris dobrian's, didn't see his til after, ignore me :D

Thanks for the replies and patches. I should have been more specific about my problem.

This needs to work inside pfft~ for frequency warping. I'm poking the value of the current bin to an arbitrary index in a buffer, but I need the amplitude values to accumulate if two or more values are written to the same index. This is the exact order things should happen in:

1- zero the buffer at the start of each frame

2- read the 'old' value from the buffer using the 'index' output of pfft~

3- add this value to the value of the current bin

Here I've simulated the scenario outside of pfft~ for simplicity (see the patch below). If this patch works correctly, the buffer should be filled with 0.99 (I think!) at index 50, but instead it is overwritten. 

1- zero the buffer at the start of each frame
2- read the 'old' value from the buffer using the 'index' output of pfft~
3- add this value to the value of the current bin
4- write the sum to the buffer

Here I've simulated the scenario outside of pfft~ for simplicity (see the patch below). If this patch works correctly, the buffer should be filled with 0.99 (I think!) at index 50, but instead it is overwritten.  


think i understand better.... but there's some weirdness here:

2- read the ‘old’ value from the buffer

if you zero the buffer at the start, reading the old will always produce 0.

in addition, whether you zero the buffer or not, if you are only constantly adding amp values to the old, eventually it will clip at 1?

(maybe you plan on creating a different transfer function and take care of the accumulation some other way...)

but i think the quickest way i can help... is to take what i did in this thread:

https://cycling74.com/forums/sharing-is-for-asswipes-the-bin-amp-sustainerer/

(because it does the adding-old-to-new already) and transfer it from gen~ to msp, while adding "noise~" as a way of scrambling the bin number (since you mention "to an arbitrary index").

The patches are zipped and attached here. It can help as a basic starter point and seems to do everything you're describing in this thread.

It provides more flexible parameter control, instead of accumulating values constantly, to have a 'feedback/overdub' amount(in addition, i give option to increase the amount of noise with which the bin numbers are scrambled).

(some things i'd probably improve with this patch is maybe create a crossover frequency/bin-number and have separate 'feedback' options for a bass-band and a high-band... because the bass accumulates and clips faster than highs... and you could try other things, too, like 'pink~' instead 'noise~' or adding your transfer function in, etc.)

Hope it helps. (I kinda like this thing, thanks for pushing me to do it, haha ;) Cheers.

(edit: oops, i had shitty presets in the original(better with whole numbers for the bin scramble parameter between 0 - 1024 for this example), so use the 'ampbinscrambler1' attachment here)

1- zero the buffer at the start of each frame
2- read the ‘old’ value from the buffer

in addition, whether you zero the buffer or not, if you are only constantly adding amp values to the old, eventually it will clip at 1?
(maybe you plan on creating a different transfer function and take care of the accumulation some other way...)

but i think the quickest way i can help... is to take what i did in this thread:
https://cycling74.com/forums/sharing-is-for-asswipes-the-bin-amp-sustainerer/
 (because it does the adding-old-to-new already) and transfer it from gen~ to msp, while adding "noise~" as a way of scrambling the bin number (since you mention "to an arbitrary index").

The patches are zipped and attached here. It can help as a basic starter point and seems to do everything you're describing in this thread.
It provides more flexible parameter control, instead of accumulating values constantly, to have a 'feedback/overdub' amount(in addition, i give option to increase the amount of noise with which the bin numbers are scrambled).
(some things i'd probably improve with this patch is maybe create a crossover frequency/bin-number and have separate 'feedback' options for a bass-band and a high-band... because the bass accumulates and clips faster than highs... and you could try other things, too, like 'pink~' instead 'noise~' or adding your transfer function in, etc.)

(edit: oops, i had shitty presets in the original(better with whole numbers for the bin scramble parameter between 0 - 1024 for this example), so use the 'ampbinscrambler1' attachment here)


i had put clip~ in the wrong place, and noise~ is probably better smoothed to randomize bins within a range rather than randomized hi or lo :p

sounds even better(see attachment). but who knows what else i missed in my haste ;p

no wait, i'm an idiot :D
i had put clip~ in the wrong place, and noise~ is probably better smoothed to randomize bins within a range rather than randomized hi or lo :p

sounds even better(see attachment). but who knows what else i missed in my haste ;p


Thanks for the reply and the super cool patch! Nice to see how these things are done in gen~ too. (I'm still waiting for my gen authorisation to come through.)

So this is very close to what I have in mind, but with one big difference: I would like the bin values to accumulate only over one FFT frame. So it's more like building a resonance around a frequency, rather than sustaining over time. The idea is that you can remap the spectral bins according to a transfer function (the old GRM tools freq warp) so that, say, the value of bin 1-100 are added together in bin whatever...

I'm getting very close but the bin value still seem to be overwritten when the indices repeat. I've attached my patch (also pasted inline below). It actually sounds cool but it doesn't quite do what I expect! I can't think what I'm doing wrong :s

***********save this as 'freqWarp.maxpat'****************

***********save this as whatever inside the same folder****************

"I would like the bin values to accumulate only over one FFT frame."

That's why I'm zeroing the bins once per frame, once they've been read.

Sorry I'd stupidly left out the cartopol~/poltocar~ objects in that abstraction!

Here it is again. But this doesn't solve the problem.

I would like the bin values to accumulate only over one FFT frame. So it’s more like building a resonance around a frequency, rather than sustaining over time. The idea is that you can remap the spectral bins according to a transfer function (the old GRM tools freq warp) so that, say, the value of bin 1-100 are added together in bin whatever…

ah, very nice! i understand now(was wondering why you had 'fill 50' before... that makes sense too now ).

very sorry though, i can't take a further look at this til monday(still very interested, though, so if it's still hanging i'll certainly return), but here's a bump to pass it on to anyone else in-the-know/interested.

ah, very nice! i understand now(was wondering why you had 'fill 50' before... that makes sense too now ).
very sorry though, i can't take a further look at this til monday(still very interested, though, so if it's still hanging i'll certainly return), but here's a bump to pass it on to anyone else in-the-know/interested.


Low and behold!! I just authorised gen and got the hold of it within minutes. Thanks so much for your suggestion about splat. It works!! So obviously I needed a sample-accurate accumulation.

I need to delve deeper into gen. It's really something!

Low and behold!! I just authorised gen and got the hold of it within minutes. Thanks so much for your suggestion about splat. It works!! So obviously I needed a sample-accurate accumulation.  

The gen~ solution works as a subpatcher, but does not behave in the same way when embedded inside a poly~! In other words, the indices are overwritten inside a poly~ but they are over dubbed in a normal subpatch. There is definitely some mystery around the order of execution of signal inputs/outputs that I don't understand.

ALEXHARKER's post in this thread seems to relate, but his patch is way too complex for me to understand what's going on: 

https://cycling74.com/forums/spectral-stretching-and-more-nifty-fft-stuff/

So gen~ or no gen~, how can one hardcode the order of execution of single samples with poke~/index~ inside a poly~?

ALEXHARKER's post in this thread seems to relate, but his patch is way too complex for me to understand what's going on: https://cycling74.com/forums/spectral-stretching-and-more-nifty-fft-stuff/

OK, some further testing and I figured out the problem is in fact not poly per se.

It's to do with the order of spectral effects chain. For some reason, putting gizmo~ and fbinshift~ after spectral warping (and naturally after portocar~) seems to 'correct' the accumulation! Mhhhh...

OK, some further testing and I figured out the problem is in fact not poly per se. 

It's to do with the order of spectral effects chain. For some reason, putting gizmo~ and fbinshift~ after spectral warping (and naturally after portocar~) seems to 'correct' the accumulation! Mhhhh...


adding to buffer index (like poke~ but not overwriting...)