adding to buffer index (like poke~ but not overwriting...)
Hello,
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...
Many Thanks in advance
P
Is gen~ or java the only way to do it without writing an external?
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~.
Hello,
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
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.
Hi,
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****************
PS.
"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.
So here's the nasty catch:
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~?
Many Thanks.
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...