Re: [PD] Realtime-version of I07.phase.vocoder.pd
Hi list... i am working on this right now. And since i never really had a deep look into all the tabread-thingies, some questions came up. Just to give you a quick sketch of my approach: I used the I07-patch and i am working with two of them (each 1 second) so i can swap from one to another. I have two 8 second tables that record the live signal from a vd~. So here my questions, just in case someone found a solution for that (i am sure you did ;-) ) 1) How to avoid clicks when the whole contents of a table is replaced/ updated. I tried something with vlineare there some zero- crossing modules for that ? 2) It seems to be possible to replace the contents of a table (the beginning) while playing the later contents of it. Is it possible to replace just a portion of a table without overwriting until the end ? the whole patch becomes somewhat unstable because of the graphics-display, any idea for a workaround ? 3) if i have a quite fast running number (index). select seems to be to slow or unstable in any way quite unreliable. i made a workaround with moses and ...not very elegant. after cleaning up i will post the patch bye luigi ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Maybe using tabsend~ with a different blocksize in a subpatch would help with the continuous writing to an array? I dunno. I am interested in a good solution to this though! ~Kyle On 5/19/07, Luigi Rensinghoff [EMAIL PROTECTED] wrote: Hi list... i am working on this right now. And since i never really had a deep look into all the tabread-thingies, some questions came up. Just to give you a quick sketch of my approach: I used the I07-patch and i am working with two of them (each 1 second) so i can swap from one to another. I have two 8 second tables that record the live signal from a vd~. So here my questions, just in case someone found a solution for that (i am sure you did ;-) ) 1) How to avoid clicks when the whole contents of a table is replaced/ updated. I tried something with vlineare there some zero- crossing modules for that ? 2) It seems to be possible to replace the contents of a table (the beginning) while playing the later contents of it. Is it possible to replace just a portion of a table without overwriting until the end ? the whole patch becomes somewhat unstable because of the graphics-display, any idea for a workaround ? 3) if i have a quite fast running number (index). select seems to be to slow or unstable in any way quite unreliable. i made a workaround with moses and ...not very elegant. after cleaning up i will post the patch bye luigi ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Luigi Rensinghoff wrote: 1) How to avoid clicks when the whole contents of a table is replaced/ updated. I tried something with vlineare there some zero- crossing modules for that ? Fade playback volume to zero, do the switch, fade playback volume up. Vary curve to suit the sound, but that's the general approach I think. A variation uses two tables played back simultaneously, staggered like: aAa aAa aAa aAa ... . bBb bBb bBb bBb ... with volume envelopes such that the total volume is constant. I think this is used in a delay-based pitchshifting example in the docs. 2) It seems to be possible to replace the contents of a table (the beginning) while playing the later contents of it. Is it possible to replace just a portion of a table without overwriting until the end ? Yes, see [tabwrite~] help (the stop message in particular). the whole patch becomes somewhat unstable because of the graphics-display, any idea for a workaround ? Use [table] instead of a graphical array. 3) if i have a quite fast running number (index). select seems to be to slow or unstable in any way quite unreliable. i made a workaround with moses and ...not very elegant. This is a limitation of floating point arithmetic, once you go past a certain size absolute precision becomes less, so integers are missing (ie, there is a floating point number where a + 1 = a, this might also extend to for any given b, you can find an a such that a + b = a, but I'm not sure). The solution / workaround is to use chained counters all counting with [+ 1]-[mod n]-[select 0], much like a clock uses seconds, minutes, hours, etc. Either that or recompile Pd to use double-precision floats, which isn't trivial, and would only postpone the issue (although by a great deal). Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
could you post that again as an attachment? my email gives me signs before every line, so ti can't make it into a pd patch. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
On 16/05/2007, at 14.34, Damian Stewart wrote: interesting. I think it's interesting why Tunderbird and IceDove send Pd patches as inline text rather the attachments. Or rather why I receive them as inline while I receive attachments when sent from other clients. end-of-rant. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Realtime-version of I07.phase.vocoder.pd
Hi List i come back to an old question, that i havent completely resolved for myself. I need something like the phase-vocoder from the fft-examples but for live-input. Basically: variable live-time-compression-expansion-delay-something. Has someone done that before ? Or can someone give me a hint ? Cheers Luigi ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Luigi Rensinghoff wrote: Has someone done that before ? Or can someone give me a hint ? live time-compression wouldn't make any sense, since you can't travel forward in time or can you? (dun-dun-DUN) you'd need some kind of spooling/unspooling delay if you wanted live time-compression to be possible. it could get gradually 'behind' real-time as you time-expanded, and would then speed forward 'toward' real-time as you time-compressed. -- Damian Stewart f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Am 15.05.2007 um 16:03 schrieb Damian Stewart: Luigi Rensinghoff wrote: Has someone done that before ? Or can someone give me a hint ? live time-compression wouldn't make any sense, since you can't travel forward in time or can you? (dun-dun-DUN) you'd need some kind of spooling/unspooling delay if you wanted live time-compression to be possible. it could get gradually 'behind' real-time as you time-expanded, and would then speed forward 'toward' real- time as you time-compressed. Thats exactly what i mean.. a variable realtime-time-expansion ;-) -- Damian Stewart f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
maybe easier to go the granular route than mess about with fft. i just did a quick search for 'realtime timestretch' and a lot of people are saying that the granular based patches/plugins are good. makes sense toocos if you use a phase vocoder approach, you will have to speed thru the audio to get back from a delayed signal to a realtime one...but with granular, you can just merge grainclouds. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Luigi Rensinghoff wrote: Thats exactly what i mean.. a variable realtime-time-expansion ;-) i had a pretty thorough dig through I07.phase.vocoder a few months back. what you'd basically need to do is something along the lines of using [tabwrite~] to write the audio signal in to $0-sample, banging it at the end of the table to make it start recording from the beginning again. you'd also need something monitoring the current position (use [r location] to receive the current position), making it jump back to the start when it hit the end. attached is my [d-pvocst~] which is a hacked up version of the help version that a) plays in stereo (with additional logic for dealing with mono files) and b) automatically loops between adjustable start and end sample numbers in the input arrays. it should be fairly easy to rig it up to tabwrite~ a live audio stream in to $0-sample-l and $0-sample-r in the way i described above. enjoy! -- Damian Stewart f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed #N canvas 50 31 1101 773 12; #X floatatom 486 370 5 0 0 0 - #0-transpo-set -; #X floatatom 164 424 3 0 0 0 - #0-speed-set -; #X floatatom 52 426 7 0 0 0 - #0-location-set -; #X text 161 405 hundredths; #X text 490 335 in cents; #X text 415 362 normal; #N canvas 0 110 569 458 hann-window 0; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-hann 2048 float 0; #X coords 0 1 2047 0 300 100 1; #X restore 82 311 graph; #X obj 378 165 osc~; #X obj 378 190 *~ -0.5; #X obj 378 214 +~ 0.5; #X obj 331 247 tabwrite~ \$0-hann; #X obj 38 173 /; #X obj 127 142 samplerate~; #X obj 177 204 swap; #X obj 177 228 /; #X obj 49 201 * 1000; #X obj 38 115 t f b f; #X msg 173 92 resize \$1; #X obj 173 116 s \$0-hann; #X msg 382 130 0; #X obj 330 131 t f b; #X text 15 8 calculate Hann window table (variable window size) and constants window-hz (fundamental frequency of analysis) \, window-sec and window-msec (analysis window size in seconds and msec).; #X obj 37 88 r \$0-window-size; #X obj 330 105 r \$0-window-hz; #X obj 177 252 s \$0-window-hz; #X obj 48 228 s \$0-window-msec; #X obj 38 251 s \$0-window-sec; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 5 0 9 0; #X connect 5 0 20 0; #X connect 6 0 5 1; #X connect 6 0 7 1; #X connect 7 0 8 0; #X connect 7 1 8 1; #X connect 8 0 18 0; #X connect 9 0 19 0; #X connect 10 0 5 0; #X connect 10 0 7 0; #X connect 10 1 6 0; #X connect 10 2 11 0; #X connect 11 0 12 0; #X connect 13 0 1 1; #X connect 14 0 1 0; #X connect 14 1 4 0; #X connect 14 1 13 0; #X connect 16 0 10 0; #X connect 17 0 14 0; #X restore 436 570 pd hann-window; #N canvas 430 22 805 756 insample 0; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-sample-r 4e+06 float 0; #X coords 0 1 4e+06 -1 400 150 1; #X restore 277 187 graph; #X obj 27 401 unpack s f; #X obj 27 574 soundfiler; #X text 358 355 read a sample; #X obj 281 355 loadbang; #X obj 112 367 44100; #X obj 27 366 t a b; #X obj 37 598 s \$0-samplength; #X obj 124 401 s \$0-insamprate; #X obj 27 651 /; #X obj 27 675 * 1000; #X obj 27 698 s \$0-samp-msec; #X obj 65 651 r \$0-insamprate; #X obj 8 71 hip~ 5; #X obj 8 10 inlet; #X obj 128 33 samplerate~; #X obj 128 57 s \$0-insamprate; #X msg 281 384 ../soud/voice.wav; #X obj 281 414 s \$0-read-sample; #X obj 28 160 r \$0-read-sample; #X obj 27 516 pack s s s; #X obj 27 481 t s b b; #X obj 99 483 symbol \$0-sample-l; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-sample-l 4e+06 float 0; #X coords 0 1 4e+06 -1 400 150 1; #X restore 276 19 graph; #X obj 119 502 symbol \$0-sample-r; #X obj 9 97 tabwrite~ \$0-sample-l; #X obj 8 46 adc~ 1; #X obj 66 49 adc~ 2; #X obj 69 74 hip~ 5; #X obj 70 124 tabwrite~ \$0-sample-r; #X obj 27 622 moses 1; #X msg 76 325 44100; #X obj 197 306 sel mono; #X obj 331 572 soundfiler; #X obj 341 596 s \$0-samplength; #X obj 331 649 /; #X obj 331 673 * 1000; #X obj 331 696 s \$0-samp-msec; #X obj 369 649 r \$0-insamprate; #X obj 331 523 pack s s s; #X obj 331 488 t s b b; #X obj 403 490 symbol \$0-sample-l; #X obj 423 509 symbol \$0-sample-r; #X obj 331 620 moses 1; #X msg 331 548 read -resize \$1 \$2 \, read -resize \$1 \$3; #X text 395 454 read mono; #X text 157 444 read stereo; #X obj 27 225 unpack s f s; #X obj 27 443 demultiplex 0 1; #X msg 161 327 0; #X msg 201 331 1; #X obj 22 269 t b a; #X msg 27 547 read -resize \$1 \$2 \$3; #X text 11 286 reset for next time; #X text 53 202 file [samplerate] [mono]; #X connect 1 0 48 0; #X connect 1 1 8 0; #X connect 2 0 7 0; #X connect 2 0 30 0; #X connect 4 0 17 0; #X connect 5 0 8 0; #X connect 6 0 1 0; #X connect 6 1 5 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 12 0 9 1; #X connect 13 0 25 0; #X connect 14 0 15 0; #X connect 14 0 26 0; #X connect 14 0 27 0; #X connect 15 0 16 0; #X connect 17 0 18 0; #X connect 19 0 47 0; #X connect 20 0 52 0; #X connect 21 0 20 0; #X connect 21 1 22 0; #X connect 21 2 24 0; #X connect 22 0 20 1; #X connect 24 0 20 2; #X connect 26 0 13 0;
Re: [PD] Realtime-version of I07.phase.vocoder.pd
Thanks a lot to all. especially for putting my idea somewhere between Albert Einstein and Freddy Mercury ;-) welli'll post my results Luigi Am 15.05.2007 um 17:12 schrieb Damian Stewart: Luigi Rensinghoff wrote: Thats exactly what i mean.. a variable realtime-time-expansion ;-) i had a pretty thorough dig through I07.phase.vocoder a few months back. what you'd basically need to do is something along the lines of using [tabwrite~] to write the audio signal in to $0-sample, banging it at the end of the table to make it start recording from the beginning again. you'd also need something monitoring the current position (use [r location] to receive the current position), making it jump back to the start when it hit the end. attached is my [d-pvocst~] which is a hacked up version of the help version that a) plays in stereo (with additional logic for dealing with mono files) and b) automatically loops between adjustable start and end sample numbers in the input arrays. it should be fairly easy to rig it up to tabwrite~ a live audio stream in to $0- sample-l and $0-sample-r in the way i described above. enjoy! -- Damian Stewart f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed #N canvas 50 31 1101 773 12; #X floatatom 486 370 5 0 0 0 - #0-transpo-set -; #X floatatom 164 424 3 0 0 0 - #0-speed-set -; #X floatatom 52 426 7 0 0 0 - #0-location-set -; #X text 161 405 hundredths; #X text 490 335 in cents; #X text 415 362 normal; #N canvas 0 110 569 458 hann-window 0; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-hann 2048 float 0; #X coords 0 1 2047 0 300 100 1; #X restore 82 311 graph; #X obj 378 165 osc~; #X obj 378 190 *~ -0.5; #X obj 378 214 +~ 0.5; #X obj 331 247 tabwrite~ \$0-hann; #X obj 38 173 /; #X obj 127 142 samplerate~; #X obj 177 204 swap; #X obj 177 228 /; #X obj 49 201 * 1000; #X obj 38 115 t f b f; #X msg 173 92 resize \$1; #X obj 173 116 s \$0-hann; #X msg 382 130 0; #X obj 330 131 t f b; #X text 15 8 calculate Hann window table (variable window size) and constants window-hz (fundamental frequency of analysis) \, window-sec and window-msec (analysis window size in seconds and msec).; #X obj 37 88 r \$0-window-size; #X obj 330 105 r \$0-window-hz; #X obj 177 252 s \$0-window-hz; #X obj 48 228 s \$0-window-msec; #X obj 38 251 s \$0-window-sec; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 5 0 9 0; #X connect 5 0 20 0; #X connect 6 0 5 1; #X connect 6 0 7 1; #X connect 7 0 8 0; #X connect 7 1 8 1; #X connect 8 0 18 0; #X connect 9 0 19 0; #X connect 10 0 5 0; #X connect 10 0 7 0; #X connect 10 1 6 0; #X connect 10 2 11 0; #X connect 11 0 12 0; #X connect 13 0 1 1; #X connect 14 0 1 0; #X connect 14 1 4 0; #X connect 14 1 13 0; #X connect 16 0 10 0; #X connect 17 0 14 0; #X restore 436 570 pd hann-window; #N canvas 430 22 805 756 insample 0; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-sample-r 4e+06 float 0; #X coords 0 1 4e+06 -1 400 150 1; #X restore 277 187 graph; #X obj 27 401 unpack s f; #X obj 27 574 soundfiler; #X text 358 355 read a sample; #X obj 281 355 loadbang; #X obj 112 367 44100; #X obj 27 366 t a b; #X obj 37 598 s \$0-samplength; #X obj 124 401 s \$0-insamprate; #X obj 27 651 /; #X obj 27 675 * 1000; #X obj 27 698 s \$0-samp-msec; #X obj 65 651 r \$0-insamprate; #X obj 8 71 hip~ 5; #X obj 8 10 inlet; #X obj 128 33 samplerate~; #X obj 128 57 s \$0-insamprate; #X msg 281 384 ../soud/voice.wav; #X obj 281 414 s \$0-read-sample; #X obj 28 160 r \$0-read-sample; #X obj 27 516 pack s s s; #X obj 27 481 t s b b; #X obj 99 483 symbol \$0-sample-l; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-sample-l 4e+06 float 0; #X coords 0 1 4e+06 -1 400 150 1; #X restore 276 19 graph; #X obj 119 502 symbol \$0-sample-r; #X obj 9 97 tabwrite~ \$0-sample-l; #X obj 8 46 adc~ 1; #X obj 66 49 adc~ 2; #X obj 69 74 hip~ 5; #X obj 70 124 tabwrite~ \$0-sample-r; #X obj 27 622 moses 1; #X msg 76 325 44100; #X obj 197 306 sel mono; #X obj 331 572 soundfiler; #X obj 341 596 s \$0-samplength; #X obj 331 649 /; #X obj 331 673 * 1000; #X obj 331 696 s \$0-samp-msec; #X obj 369 649 r \$0-insamprate; #X obj 331 523 pack s s s; #X obj 331 488 t s b b; #X obj 403 490 symbol \$0-sample-l; #X obj 423 509 symbol \$0-sample-r; #X obj 331 620 moses 1; #X msg 331 548 read -resize \$1 \$2 \, read -resize \$1 \$3; #X text 395 454 read mono; #X text 157 444 read stereo; #X obj 27 225 unpack s f s; #X obj 27 443 demultiplex 0 1; #X msg 161 327 0; #X msg 201 331 1; #X obj 22 269 t b a; #X msg 27 547 read -resize \$1 \$2 \$3; #X text 11 286 reset for next time; #X text 53 202 file [samplerate] [mono]; #X connect 1 0 48 0; #X connect 1 1 8 0; #X connect 2 0 7 0; #X connect 2 0 30 0; #X connect 4 0 17 0; #X connect 5 0 8 0; #X connect 6 0 1 0; #X connect 6 1 5 0; #X connect 9 0
