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.

@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!

@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.

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.

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.

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.

@EEight,

Thank you for your suggestion. The background to this problem is that I'm working on an external that uses the same Ogg/Vorbis libraries, so I figured if I could get oggRead~ compiling correctly that I could use the same dependencies safely without fear of any other complications when it comes time to compile my own external.

Still though, thank you for the suggestion - I will take a look at the suggested external, although I'd ideally like to know the reason behind the failed compilation.

Thanks again,
James

Hello all,

After a few weeks of reading, researching, and attempting to find a reliable way to compile externals, I have most simple cases working such as the tutorial objects found from the IEM tutorials and Eric Lyon's book on the subject.

However, trying to compile Oggread~ from the pdogg library (https://goo.gl/WvPLnW) results in an external that fails to load in PD, throwing the error:

"oggread~.pd_darwin: dlopen(/path/to/external/oggread~.pd_darwin, 10): symbol not found: _ov_bitrate referenced from: /path/to/external/oggread~.pd_darwin
Expected in: flat namespace"

the reference to ov_bitrate is contained in vorbisfile.h, and as far as I can tell, has been linked and compiled correctly.

I hate to ask for help from a community I've just joined, but I've been struggling with this for a few weeks on my own to no avail, so absolutely any insight or help would be appreciated.

I've uploaded the files in question below. The compiled external can be found in the build folder, and all vorbis/ogg header files can be found in the libs folder.

oggread~ compilation.zip

Thank you,
James