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
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
Hi Thomas,
thanks for your reply!
Yes I have tried re-[block~]ing the patch to 1 sample and using snapshot.
I have also tried using [tabsend~] at normal 64 sample block size, and then various means of reading out the samples from the table, including [until] and [timer].
I got close with using an integer-based counter [i]x[f] and then either resetting it or using a modulo. Both had their downsides.
The first patch, using a modulo [%] object to cycle from 0 to 63, startsed out very precise but degraded over time as the integer from the counter structure above it increases.
The second patch, using [select] to reset the counter and cycle from 0 to 63, was far less accurate and gives periodic errors from the very start.
I thought that I had gotten it working with [block~] and [timer], but returning to that patch after a year I see that it does not in fact do it. I have attached the patch here for your scrutiny.
Best! Derek
#N canvas 790 130 932 636 12; #N canvas 399 190 1021 779 sig2float 0; #X obj 37 27 inlet~ sig; #X obj 157 27 inlet bang; #X obj 157 260 outlet float; #X text 377 225 Derek Holzer; #X text 378 281 macumbista@gmail.com; #N canvas 0 22 450 278 (subpatch) 0; #X array $0-sig 64 float 2; #X coords 0 1 64 -1 200 140 1 0 0; #X restore 380 58 graph; #X obj 256 27 inlet IntExt; #X obj 157 63 spigot; #X obj 256 51 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 157 223 tabread $0-sig; #X text 376 253 October 2021 Stockholm; #X obj 160 101 bang~; #X obj 159 145 timer 1 sample; #X obj 40 223 tabread~ $0-sig; #X obj 39 256 outlet~ sig; #X obj 256 73 switch~; #X obj 37 63 tabsend~ $0-sig; #X connect 0 0 16 0; #X connect 1 0 7 0; #X connect 6 0 8 0; #X connect 7 0 12 1; #X connect 8 0 7 1; #X connect 8 0 15 0; #X connect 9 0 2 0; #X connect 11 0 12 0; #X connect 12 0 9 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X restore 244 255 pd sig2float; #X obj 285 172 metro; #X obj 285 151 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X msg 305 147 tempo 1 samp; #X obj 244 212 osc~ 440; #X obj 325 213 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 305 112 loadbang; #X obj 53 359 cnv 15 210 219 empty empty empty 20 12 0 14 -4034 -66577 0; #N canvas 0 22 450 300 (subpatch) 0; #X array $0-sum1 1001 float 0; #X coords 0 1.02 1000 -1.02 200 50 1 0 0; #X restore 55 376 graph; #X obj 121 139 loadbang; #X msg 116 162 1; #X obj 175 319 tabwrite~ $0-sum1; #N canvas 0 22 450 300 (subpatch) 0; #X array $0-sum2 1001 float 0; #X coords 0 1.02 1000 -1.02 200 50 1 0 0; #X restore 56 441 graph; #N canvas 0 22 450 300 (subpatch) 0; #X array $0-sum3 1001 float 0; #X coords 0 1.1 1000 -1.1 200 50 1 0 0; #X restore 56 506 graph; #X obj 244 291 tabwrite~ $0-sum2; #X obj 325 320 tabwrite~ $0-sum3; #X obj 328 387 samplerate~; #X floatatom 181 563 7 0 0 1 _ms-- #0-msin #0-msout; #X obj 328 362 loadbang; #X obj 98 185 metro 200; #X obj 328 412 expr (1000 / $f1) * 1000; #X obj 389 363 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 43 562 -- 1000 samples or; #X obj 328 441 s $0-msin; #X text 352 254 <------conversion from signal to float; #X connect 0 0 14 0; #X connect 0 1 15 0; #X connect 1 0 0 1; #X connect 2 0 1 0; #X connect 3 0 1 0; #X connect 4 0 0 0; #X connect 4 0 11 0; #X connect 5 0 0 2; #X connect 6 0 3 0; #X connect 9 0 10 0; #X connect 10 0 19 0; #X connect 16 0 20 0; #X connect 18 0 16 0; #X connect 19 0 11 0; #X connect 19 0 14 0; #X connect 19 0 15 0; #X connect 20 0 23 0; #X connect 21 0 16 0;
On 2022-10-15 18:37, Thomas Grill wrote:
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.
The first patch, using a modulo [%] object to cycle from 0 to 63, startsed out very precise but degraded over time as the integer from the counter structure above it increases.
The reason is precision loss because of the limited 32-bit word size in Pd. The easy solution is to feed back the modulo result to the counter, so that it will always run only between 0 and 63 or to reset the counter at every block boundary. Does this what you want?
#N canvas 819 278 450 300 12; #X obj 95 28 inlet~; #X obj 234 101 until; #X msg 234 75 64; #X obj 235 206 outlet; #X obj 95 53 tabsend~ $0-bl; #X obj 95 101 table $0-bl 64; #X msg 287 99 0; #X obj 234 133 f; #X obj 266 133 + 1; #X obj 234 51 t b b; #X obj 235 179 tabread $0-bl; #X text 292 208 spit out frames; #X obj 234 25 inlet; #X connect 0 0 4 0; #X connect 1 0 7 0; #X connect 2 0 1 0; #X connect 6 0 7 1; #X connect 7 0 8 0; #X connect 7 0 10 0; #X connect 8 0 7 1; #X connect 9 0 2 0; #X connect 9 1 6 0; #X connect 10 0 3 0; #X connect 12 0 9 0;
why you used an [until] ?
I should put a [metro] there. speed @ 1/64 of the block.
(not tested)
--
Mensaje telepatico asistido por maquinas.
On 15/10/2022 15:04, Thomas Grill wrote:
The first patch, using a modulo [%] object to cycle from 0 to 63, startsed out very precise but degraded over time as the integer from the counter structure above it increases.
The reason is precision loss because of the limited 32-bit word size in Pd. The easy solution is to feed back the modulo result to the counter, so that it will always run only between 0 and 63 or to reset the counter at every block boundary. Does this what you want?
#N canvas 819 278 450 300 12; #X obj 95 28 inlet~; #X obj 234 101 until; #X msg 234 75 64; #X obj 235 206 outlet; #X obj 95 53 tabsend~ $0-bl; #X obj 95 101 table $0-bl 64; #X msg 287 99 0; #X obj 234 133 f; #X obj 266 133 + 1; #X obj 234 51 t b b; #X obj 235 179 tabread $0-bl; #X text 292 208 spit out frames; #X obj 234 25 inlet; #X connect 0 0 4 0; #X connect 1 0 7 0; #X connect 2 0 1 0; #X connect 6 0 7 1; #X connect 7 0 8 0; #X connect 7 0 10 0; #X connect 8 0 7 1; #X connect 9 0 2 0; #X connect 9 1 6 0; #X connect 10 0 3 0; #X connect 12 0 9 0;
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[pix_sig2pix~] any good?
On Sat, Oct 15, 2022 at 6:08 PM Derek Holzer macumbista@gmail.com wrote:
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
Hi Tim,
this does almost the opposite of what I want, it converts audio to colors. I need to look up the pixel values in a video image and get them out, eventually as audio.
For the deep dive, you can see my Rutt/Etra Scan Processing emulation in the Vector Synthesis library:
https://github.com/macumbista/vectorsynthesis
Work sample:
Also, the [pix_sig2pix~] object is also limited by the blocksize.
Best! D.
On 2022-10-15 18:38, tim vets wrote:
[pix_sig2pix~] any good?
On Sat, Oct 15, 2022 at 6:08 PM Derek Holzer <macumbista@gmail.com mailto:macumbista@gmail.com> wrote:
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 <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
-
Derek Holzer -
Lucas Cordiviola -
Thomas Grill -
tim vets