Hi Derek, not sure exactly whether you have covered this, but
- what about a subpatch/abstraction with blocksize 1 and a [bang~]/[snapshot~] to deliver the sample?
- or at normal blocksize a [tabsend~] and then [until] to read out the frames from the buffer?
the physical timing will be more or less the same, because it all depends on the block input from the audio system.
From what i read in your email, i guess you would like (with the timer) to have a physically correct timing. But this will never be the case. It is all in logical time, with all single-frame processing happening between blocks of (usually) 64 frames input from the audio IO.
best, Thomas
Am 15.10.2022 um 17:59 schrieb Derek Holzer macumbista@gmail.com:
Dear list,
I am trying to convert an audio signal into a series of floats. I would like to do this for every sample in the audio signal, however the closest I can get using a variety of techniques is in blocks of 64 samples. I have tried snapshot with a metro set at 1 sample intervals. I have also tried using tabsend to write the audio to a table and then read it back at a rate of one sample at a time, using the timer object set to an interval of 1 sample and a block~ object to rest it at the end of every DSP block. I cannot get to single sample accuracy either way. How else could I try?
Why do I need this? Well I am using Gem's pix_data to get a new brightness value from its frame buffer for every sample in the audio signal, however pix_data only responds to messages. So alternately, I would be very interested if someone wanted to modify pix_data to respond to audio signals.
Thank you for your kind attention, Derek
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list