I've been attempting to do some FFT and amplitude analysis on a song, loaded into two arrays (L&R) as quickly as possible. I'm able to do this effectively by creating a playback system that uses phasor~ & tabread4~ to parse through each index of the array in real-time, such as the player in Cheetomoskeeto's tutorial on Youtube, "PURE DATA: 22 Advanced Audio with [tabread4~]"

But what's my best option if I want to parse through each block of audio data from an array as fast as possible? Here's what I have so far, but I don't think I'm on the right track: https://imgur.com/a/aXa4Qan

My attempt uses [Until] to iterate though every index of the L & R channels, in blocks of 512 samples at a time. Since the result of each analyzed block is also stored in an array, the [s dataIndex] value is sent and later used to write the result to the correct index.

My patch doesn't work as expected, and while I'm still investigating why, I'm curious if there's a more straight-forward approach to offline analysis. Thanks for taking the time to read all this, any help is greatly appreciated.

@JamesWN I am not very much into FFT, but I think you can do offline analysis with the timbreID library (it is a very nice library). You can get it from deken. Here you can download additional examples: https://github.com/wbrent/timbreID And it is better to upload a patch than a screenshot (or both), that way it is easier to help.

Thank you very much for your suggestion! I'll certainly check it out.

I'd love to be able to define my own implementations of the analysis though, that may span beyond fft in the future. For this reason, I'd still like to discover a way to comb through arrays as fast as possible, decoupled from the task of analysis. I'd love to hear any other thoughts that anyone may have on the issue.

@JamesWN I'm going out on a limb here, but I think if you want to go faster than real time you shouldn't use signal lines in your path, because I think that will automatically restrict the speed to sample rate and do automatic blocking. Plus, things like tabread4~ will give you interpolated samples. I'm not sure why you want to block if you are processing offline anyway. Just use [until] to step through each sample in your wave table, apply the math you want to, and then store it in another table (or the same table if you're not writing into the future and the table length doesn't change).

Thanks! I think that's more along the lines of what I'm looking for. I still want to do analysis in chunks, which is why I was hoping I could utilize the built-in block feature of PD to analyze N samples at a time, which I'll need to do for things like RMS or FFT anyhow. I suppose that solution would iterate through N samples, add them to some sort of buffer (is there a good object for this? List?) send that through a [sig~], pass that off to any number of analyses, and then write those values to their own tables.

I'll begin looking into this tonight. I appreciate both of your suggestions & guidance, and if you have any further recommendations with the above method, please let me know.

@JamesWN I think FFTs can be done in place, so you wouldn't need an additional buffer. Where you do, wouldn't another table/array suffice? Not sure how you are planning to use [sig~] but it won't convert your control stream of audio samples into the audio stream you might expect. I think you'd have to fill a table and then play the table out to get back to audio.

@jameslo, you're absolutely right. The one issue I see with not using signal channels is that I don't get use of some of the built-in analysis tools. As an example, lp~, bp~, and hp~ filters and env~ measurements.

Thanks to your help, I understand very clearly how I would go about chunking up the audio data into smaller buffer chunks for analysis, but feel like that limits my opportunities for analysis, at least with what PD provides out of the box.

@JamesWN just guessing, but perhaps the partialtracer from the data structure examples could be a starting point...

@Jona, Thanks for the suggestion! That patch does look quite promising! Swapping the [metro 50] for something much shorter ran through the whole track quite quickly. I'll have to stare at this patch a while longer to really understand what's happening.

Edit: So after taking a close look at the patch, it works via Sigmund~'s ability to accept a list of samples / indices in a table, rather than a signal inlet. To my knowledge, there is no way to get the 'raw' output of bins from Sigmund, the way I was hoping to do with the normal fft~ object. Still leaves the filters and some other signal-analysis objects out of the picture, but it very well be that there isn't a silver bullet for what I'm looking to do. Again, I appreciate everyone's input on the matter!

@JamesWN offline rendering is possible with pd if you use the -batch flag.

here is an example patch:
batchexample.zip
it will render 20sec of 440hz sine tone to a "osc440.wav" file. run it with

pd -batch batchexample.pd

in your console.

if you want to study the patch be quick and delete the connection to the "pd quit;" message or it will quit pd after 20 sec...

If you don't want to do fft in a signal you could also use the vasp library https://github.com/grrrr/vasp

Solipp - It works perfectly! I can't believe I've been casually using PD for over 5 years and never come across this option. Thank you so much for your help, I think that marks this issue solved! And thank you to everyone else for contributing and growing my knowledge around other solutions for this offline approach.