Hi Pd-people!

I'd like some advice on how to set up tabwrite to write values for each index of an array while moving forward through them at a set pace of time. I feel like i'm making it more complicated than it needs to be, and so i'd love some input.

The concept of time feels very straightforward when recording audio data to an array, say by using adc~, in which the time to move through it is defined by a samplerate. But since I want to work with control values as actual numerical values I can't quite figure it out.

What I'd like to use it for is to write amplitude values of summed group of FFT blocks that are read from another array, and write these to each index during the duration of the playing file. Right now I've only managed to constantly update the same index, that being index 0, so how do i move it forward in time from there? The arraysize is set to match the actual numbers of seconds in the given track.

I hope I've made my question clear, my head is kinda spinning around this patch by now. I'd love to explain it further if needed be.

These concepts is a continuation of a patch i discussed here, and got some great input; https://forum.pdpatchrepo.info/topic/11084/analyze-audio-file-from-table-detect-bpm-and-or-amplitude-within-a-spectrum

Thanks for discussing!

@Jocketor [metro] (desired write interval) and a counter (f... +1) to right inlet (index) of [tabwrite].

Or use the data to index the counter (banging f for each piece of data).
David.

@Jocketor Hi, could you share the patch the does the fft?

If I understand correctly you have array1 (containing an audio file you've loaded) and you want to read that array1, do a real time fft to get the peaks and write those peaks in realtime to array2. Did I get that right?

As far as I know there is one external called [ipoke~] that allows you to write to a table sample by sample at audio rate. http://puredata.info/Members/ipoke/ipoke_v.3_test1.zip/view

@whale-av Of course. So simple! I knew I was overthinking things. Big thanks for helping me yet again!

@weightless Thanks for chiming in! Yes, you are correct in describing what i'm doing. Thanks for suggesting that external, i'll have a look at it, even though i've succeeded in what I set out to do.

Now to figure out a way to do the FFT-analysis faster than real-time to circumvent having to play through a whole track.... Might have do divide the track by chunks in C# and multithread each chunk to seperate instances of the patch, to then reorder the indexes with their values in a list. I'll figure something out, thanks for all your help!

@weightless Also, if you're interested in the patch I can share it. I have to do some cleaning-up first though, it's more spaghetti than needed be right now!

@Jocketor No problem, it was just that sometimes it's easier to help out by looking at the patch. I didn't understand if you wanted to write the data to a table at audio rate or if you already managed to convert the data from the fft to control rate, in which case @whale-av suggestion of using tabwrite with metro is the way to do it.

@Jocketor If you are inputting audio from an [adc~] I cannot see how you could analyse it faster than real-time. You could have asked Einstein...... but it's too late for that.

If you are reading from a wav file then you can do so with [soundfiler] ........ like this....... speed and reverse.zip although you will have to calculate a "stop" for a single pass.
Or if you are reading the file with [readsf~] then you can use [block~] like this....... https://forum.pdpatchrepo.info/topic/10894/readsf-and-sample-rates ...... although you might run into problems if you are trying to output audio as well, and of course resampling will lose you some information.

Although having slept on this..... I guess it can be done almost instantaneously if you analyse the saved audio file outside of the audio domain.
David.

@whale-av Yeah - i've also started experimenting with using phasor (well, phasorshot really) to read the signal using tabread4~ instead of tabplay~ which i use to analyse the signal in real-time. It all "works", but by using tabdump to print the values of the array after processing the wavfile I can clearly see that I get different values compared to when doing it in real-time. Somehow it seems that upping the rate of the phasor seems to make it go faster than how my plotting to the array can handle. I don't know if plotting using a faster metro would solve this. Again, might have to analyse in real-time, but doing it on smaller chuncks simultaneously to save time.

"Although having slept on this..... I guess it can be done almost instantaneously if you analyse the saved audio file outside of the audio domain." Could you explain what you meant there? Sorry, i'm slow.

@Jocketor I mean that it can be done very fast as an analysis once you have all the data in an array..... so if you load an audio file into an array... or you have written a live input to an array..... then the analysis will be much quicker than doing it "live" in the audio domain where you are waiting all the time for audio blocks to complete their processing.
Do you want to show the user the results "live" while they are recording the audio..... is that why you want to use audio objects for analysis?
If you want amplitude values during a "live" [adc~] recording you can use [env~] to output those values (although in dB) at the end of each audio block (or set a wider..... or a narrower window if you wish for [env~]...... right down to a single sample if you set the block size to 1).
David.

@whale-av I see what you mean. What i'm doing here, in broad terms, is;

1. Upload any wavfile to an array, This goes through soundfiler and all that jazz.

2. I run through the wavfile at the normal rate times 100 (so very fast), to get the data needed for soundfiler_info to send correct values to resize the next array....

3. ...which is a new array that is ready to recieve the data of the wavfile being run through a FFT-chain. This array has the size of wavfile-time in deciseconds and plots out the magnitude values of a chosen frequency range over the time of the song (here's why i asked for the metro-timeline-array setup). This array plots it's values continiously during the course of the FFT-analysis. This is the part that currently happens in real-time and if this could be sped up in Pd using tabread4~ without getting skewed values from the FFT-analysis, which is happening right now, then that is something that i'd like to explore.

So yes - the original data is being read from an array. I'm not looking to be able to read data while this is all happening, at the end of the day I just want to get the correct values from the FFT, arranged sequentially during the duration of the chosen track, as fast as possible to then pack it and send it over OSC.

Always appreciate your input and knowledge!

@Jocketor I might have grabbed the stick by the wrong end...... but this patch will output instant data as the audio arrives............ decile.zip
Open [mother_live].
Do any math you want inside [test_decile], click "continuous" and connect the output to your oscsend.
It should output the same as [tab_sum] for the window size.
Window side has to be 4096 samples though unfortunately..... to be as close as possible to 1/10 of a second at 44.1K. Exactly 1/10 is not possible like this......

It can be adapted to examine a large file already written by [soundfiler] or [tabwrite]......... by getting the total arraysize and scanning chunks of samples in order. Then it would not need to run at audio rate and the chunks could be 4410 samples (or 4800)....... but that should be the same as [tab_sum] and such.

The differences you are getting might be because of the different window sizes in your patch between audio and data analysis...... because you have selected a 1/10 second chunk size.

If you want to post your patch then someone might spot why you get different data depending on your approach, and it will be easier to try to help by modification.
What I have posted above contains no FFT analysis...... so it is not yet what you are looking for.... but it might be a stepping stone.
David.

@Jocketor My understanding is that Pd is designed for real-time audio processing, so if you want to load a wav file and do the fft analysis quicker than real-time, it means reading the wav-file at a faster speed, therefore the resulting fft analysis data would reflect that output which will be higher-pitched. I'm not sure if simply scaling down the fft results would compensate for that, though.