Re: [PD] stop sample playback when phasor~ reset?
On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
I m curious to know which object you would recommend instead of threshold~ (the delay way is obviously not feasible as soon as you need to change the speed of phasor~ during palyback). Pierre 2011/9/20 Roman Haefeli reduz...@gmail.com On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 09:43 +0200, Pierre Massat wrote: I m curious to know which object you would recommend instead of threshold~ (the delay way is obviously not feasible as soon as you need to change the speed of phasor~ during palyback). Yeah, [threshold~] seems feasible, but this approach suffers from a few issues. As I said before, the bang comes only on block boundaries and is at least one block late, so it's not very precise. Also, a [phasor~] probably never reaches exactly 1 (or 0) and it is less likely the higher the frequency is. So you would need values like 0.001 or 0.999 for the [threshold~] which again makes it a bit more imprecise. You can also use the [vline~] approach and change the speed in the middle of the playback, though it needs a bit of patching to accomplish that. You need a delay, that is triggered at the time of the speed change. The delay value can be used to calculate the current position of the play head. Then you can use that value as a start point for a new message to [vline~]. Roman 2011/9/20 Roman Haefeli reduz...@gmail.com On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
Yeah, a threshold~ set to 1 is never triggered (or very rarely). So there's no perfect answer to the question it seems... Pierre 2011/9/20 Roman Haefeli reduz...@gmail.com On Tue, 2011-09-20 at 09:43 +0200, Pierre Massat wrote: I m curious to know which object you would recommend instead of threshold~ (the delay way is obviously not feasible as soon as you need to change the speed of phasor~ during palyback). Yeah, [threshold~] seems feasible, but this approach suffers from a few issues. As I said before, the bang comes only on block boundaries and is at least one block late, so it's not very precise. Also, a [phasor~] probably never reaches exactly 1 (or 0) and it is less likely the higher the frequency is. So you would need values like 0.001 or 0.999 for the [threshold~] which again makes it a bit more imprecise. You can also use the [vline~] approach and change the speed in the middle of the playback, though it needs a bit of patching to accomplish that. You need a delay, that is triggered at the time of the speed change. The delay value can be used to calculate the current position of the play head. Then you can use that value as a start point for a new message to [vline~]. Roman 2011/9/20 Roman Haefeli reduz...@gmail.com On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-09-19 20:33, James Dunn wrote: backwards). I've looked at edge~ and samphold~ triggered by a bang~ but what's wrong with [samphold~]? (though i don't understand what you need [bang~] for...) see attached patch. fmgadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk54SYUACgkQkX2Xpv6ydvSkeQCfYgTYoTKDt/ZFAKfjAeCRj/5y JOUAoPFXfrh5RD8qZbLQJl25PojONc8v =c4bd -END PGP SIGNATURE- #N canvas 375 261 772 469 10; #X obj 129 272 samphold~; #X obj 90 295 *~; #X floatatom 91 180 5 0 0 0 - - -; #X obj 89 366 tabwrite~ sample; #X obj 391 294 table sample 4410; #X msg 46 57 bang; #X obj 46 77 t b b; #X obj 225 69 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 225 89 select 1 0; #X obj 284 200 sig~ 1; #X obj 270 220 *~; #X msg 225 180 1; #X obj 225 200 t f f; #X msg 225 220 set \$1; #X msg 270 181 0; #X msg 128 345 bang; #X msg 109 94 1; #X msg 141 113 0; #X obj 109 114 t f; #X obj 112 70 t b b; #X obj 141 93 del 50; #X obj 91 201 phasor~ 50; #X text 320 53 1...pass phasor; #X text 319 71 0...stop phasor~ at end of next phase cycle; #X connect 0 0 1 1; #X connect 1 0 3 0; #X connect 2 0 21 0; #X connect 5 0 6 0; #X connect 6 0 3 0; #X connect 6 1 19 0; #X connect 7 0 8 0; #X connect 8 0 11 0; #X connect 8 1 14 0; #X connect 9 0 10 1; #X connect 10 0 0 0; #X connect 11 0 12 0; #X connect 12 0 13 0; #X connect 12 1 10 0; #X connect 13 0 0 0; #X connect 14 0 10 0; #X connect 15 0 3 0; #X connect 16 0 18 0; #X connect 17 0 18 0; #X connect 18 0 7 0; #X connect 19 0 16 0; #X connect 19 1 20 0; #X connect 20 0 17 0; #X connect 21 0 1 0; #X connect 21 0 0 1; smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 10:06 +0200, Pierre Massat wrote: Yeah, a threshold~ set to 1 is never triggered (or very rarely). So there's no perfect answer to the question it seems... Hm... What do you expect the perfect answer to be? The [vline~] approach works pretty well. What do you miss? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
Hi James, On 19/09/2011 20:33, James Dunn wrote: Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. After all the debate... I think it would help if you gave a little background on what you are trying to achieve and some further info :-) For example: time magnitude of the samples' playback (seconds, 100-1000 ms, 0-20 ms?)... What's your foreseen CPU-resources budget? The best way much depends on what your final goal is. E.g. as someone suggested might get away with [(v)line~], but that has its shortcomings, same goes with the other suggestions. Lorenzo. thanks James ___ 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] stop sample playback when phasor~ reset?
Thanks for all the replies. What I'm trying to do is make an abstraction in which I can load a soundfile (mono, 44100) which are all between about 2-6 mins in length. I have been using phasor~ because I want to play the files forwards and backwards and change slowly between the two. I also want to be able to pause and seek within the file using a slider. The main issue I'm having is catching the end of the phasor~ - either when it's going forwards or backwards. I've attached my patch. thanks James Quoth Lorenzo Sutton, on 20/09/2011 10:56: Hi James, On 19/09/2011 20:33, James Dunn wrote: Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. After all the debate... I think it would help if you gave a little background on what you are trying to achieve and some further info :-) For example: time magnitude of the samples' playback (seconds, 100-1000 ms, 0-20 ms?)... What's your foreseen CPU-resources budget? The best way much depends on what your final goal is. E.g. as someone suggested might get away with [(v)line~], but that has its shortcomings, same goes with the other suggestions. Lorenzo. thanks James ___ 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 #N canvas 653 259 450 300 10; #X obj 163 83 % 60; #X obj 232 83 / 60; #X obj 232 103 i; #X obj 163 123 makefilename %02d; #X obj 163 163 l2s :; #X obj 163 143 list prepend; #X obj 163 183 outlet; #X obj 163 41 inlet; #X obj 163 61 trigger f f; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 5 1; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 7 0 8 0; #X connect 8 0 0 0; #X connect 8 1 1 0; #N canvas 342 45 762 615 10; #X obj 425 207 soundfiler; #N canvas 0 22 450 300 array 0; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-track 9.52933e+06 float 2; #X coords 0 1 9.52933e+06 -1 200 140 1; #X restore 100 20 graph; #X restore 17 454 pd array; #X obj 214 10 loadbang; #X msg 214 31 \; pd dsp 1; #X obj 425 47 openpanel; #X obj 463 147 splitfilename /; #X obj 410 290 phasor~; #X obj 410 361 tabread4~ \$0-track; #X obj 410 341 *~; #X obj 425 250 expr 44100/$f1; #X obj 425 167 pack s \$0; #X obj 410 381 hip~ 5; #X obj 534 321 snapshot~; #X obj 534 296 bang~; #X obj 425 7 r \$0-open; #X obj 425 321 r \$0-sample-size; #X obj 433 229 s \$0-sample-size; #X msg 425 27 symbol /Users/james/Indifference/Final/Music; #X obj 449 270 r \$0-pos; #X obj 410 447 *~; #X obj 440 401 r \$0-vol-snd; #X obj 425 427 *; #X obj 410 487 *~; #X obj 425 467 r \$0-state; #X obj 583 429 s \$0-pos-rcv; #X obj 644 287 / 44100; #X obj 652 329 s \$0-pos-rcv; #X msg 652 309 range 0 \$1; #X obj 534 361 *; #X obj 575 409 change; #X obj 664 429 mins-secs; #X obj 664 517 l2s /; #X msg 664 537 label \$1; #X obj 664 557 s \$0-pos-rcv; #X obj 664 497 list append; #X obj 664 449 trigger b s; #X obj 664 469 init 0:00; #X msg 425 187 read -resize -maxsize 1e+09 \$1 \$2-track; #X obj 550 167 splitfilename .; #X obj 410 531 dac~; #X obj 418 511 s~ \$0-track; #X obj 410 270 *; #X obj 644 351 s \$0-secs; #X obj 664 409 r \$0-secs; #X obj 549 341 r \$0-secs; #X obj 644 267 r \$0-sample-size; #X obj 1 1 cnv 15 198 248 \$0-cnv-snd \$0-cnv-rcv Makarena 75 14 0 12 -233017 -62784 0; #X obj 9 9 bng 15 250 50 0 \$0-open empty Open 20 7 0 10 -262144 -1 -1; #X obj 9 71 bng 15 250 50 0 \$0-play-snd \$0-play-rcv Play 20 7 0 10 -262144 -1 -1; #X obj 12 46 hsl 175 15 0 216.085 0 0 \$0-pos-snd \$0-pos-rcv 0:00/3:36 -2 -8 0 10 -262144 -1 -1 0 1; #X obj 9 91 bng 15 250 50 0 \$0-stop-snd \$0-stop-rcv Stop 20 7 0 10 -262144 -1 -1; #X obj 9 151 bng 15 250 50 0 \$0-back-snd \$0-back-rcv Backwards 20 7 0 10 -262144 -1 -1; #X obj 9 171 bng 15 250 50 0 \$0-half-snd \$0-half-rcv Half 20 7 0 10 -262144 -1 -1; #X obj 12 128 hsl 175 15 -2 2 0 0 \$0-speed-snd \$0-speed-rcv Speed -2 -8 0 10 -262144 -1 -1 13050 1; #X obj 578 87 s \$0-stop-snd; #X obj 214 83 r \$0-play-snd; #X msg 214 170 1; #X obj 214 214 s \$0-state; #X obj 280 170 1; #X obj 214 123 demux; #X obj 241 103 r \$0-state; #X obj 256 123 r \$0-stop-snd; #X msg 241 170 0; #X obj 295 143 r \$0-speed-snd; #X obj 313 187 spigot; #X obj 346 167 r \$0-state; #X msg 501 107 1; #X obj 501 127 s \$0-speed-rcv; #X obj 361 201 0; #X obj 361 221 s \$0-dir; #X msg 539 87 0; #X obj 534 439 -; #X obj 534 409 t f f; #X obj 534 459 abs; #X obj 534 521 1; #X obj 534 541 change; #X obj 549 501 - 1; #X obj 549 481 r \$0-secs; #X obj 534 561 sel 1; #X obj 256 143 t b b; #X obj 256 319 s \$0-pos; #X msg 256 294 0; #X
Re: [PD] stop sample playback when phasor~ reset?
check this thread: http://puredata.hurleur.com/sujet-6194-sample-played-automated-varying-speed-detect-completion On Tue, Sep 20, 2011 at 7:38 PM, James Dunn ja...@4thharmonic.com wrote: Thanks for all the replies. What I'm trying to do is make an abstraction in which I can load a soundfile (mono, 44100) which are all between about 2-6 mins in length. I have been using phasor~ because I want to play the files forwards and backwards and change slowly between the two. I also want to be able to pause and seek within the file using a slider. The main issue I'm having is catching the end of the phasor~ - either when it's going forwards or backwards. I've attached my patch. thanks James Quoth Lorenzo Sutton, on 20/09/2011 10:56: Hi James, On 19/09/2011 20:33, James Dunn wrote: Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. After all the debate... I think it would help if you gave a little background on what you are trying to achieve and some further info :-) For example: time magnitude of the samples' playback (seconds, 100-1000 ms, 0-20 ms?)... What's your foreseen CPU-resources budget? The best way much depends on what your final goal is. E.g. as someone suggested might get away with [(v)line~], but that has its shortcomings, same goes with the other suggestions. Lorenzo. thanks James __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list ___ 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] stop sample playback when phasor~ reset?
- Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] | | [0( [0( [ | [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. Neither [line~] nor [vline~] will trigger a ramp in the middle of the current block, so if you're rule is IF sample playback THEN [vline~] [line~] there are probably times you're wasting cpu. The first paragraph of 3.audio.examples/C04.control.to.signal.pd spells it out pretty well. -Jonathan Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. What do you mean by 'triggering events sporadically using control objects'? Aren't [delay] and [metro] also control objects? If those are generating the event, you have more precise timing than only block boundaries. We actually don't know what would be triggering the [del] in the above patch (or probably I missed it?). Either way, the above patch would convert the precise timing to only block boundaries timing because the frequency inlet of [phasor~] only evaluates control messages on block boundaries. Using [vline~ ], however, would actually use the precise timing of the event. Neither [line~] nor [vline~] will trigger a ramp in the middle of the current block, so if you're rule is IF sample playback THEN [vline~] [line~] there are probably times you're wasting cpu. Sorry, if I am missing your point, but how do you know that [vline~ ] wouldn't trigger a ramp in the middle of block in this case? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
- Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 6:05 PM Subject: Re: [PD] stop sample playback when phasor~ reset? On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] | | [0( [0( [ | [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. What do you mean by 'triggering events sporadically using control objects'? Aren't [delay] and [metro] also control objects? If those are generating the event, you have more precise timing than only block boundaries. We actually don't know what would be triggering the [del] in the above patch (or probably I missed it?). Either way, the above patch would convert the precise timing to only block boundaries timing because the frequency inlet of [phasor~] only evaluates control messages on block boundaries. Using [vline~ ], however, would actually use the precise timing of the event. Neither [line~] nor [vline~] will trigger a ramp in the middle of the current block, so if you're rule is IF sample playback THEN [vline~] [line~] there are probably times you're wasting cpu. Sorry, if I am missing your point, but how do you know that [vline~ ] wouldn't trigger a ramp in the middle of block in this case? I didn't write that [vline~] cannot trigger a ramp in the middle of a block-- it obviously can. I wrote that neither object can start a ramp in the middle of the current block. In fact, [line~] will almost always trigger sooner than [vline~], because [line~] starts the ramp immediately at the next block, and [vline~] at minimum will be delayed exactly one block. I have an example patch that shows this but for some reason I can't attach it in Yahoo mail. But just make a simple amplitude envelop inside a subpatch with a large blocksize (greater than one second will do), then try triggering your envelope using [vline~]. -Jonathan Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
that sounds like a re-blocking delay, rather than anything to do with vline~ On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 6:05 PM Subject: Re: [PD] stop sample playback when phasor~ reset? On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. What do you mean by 'triggering events sporadically using control objects'? Aren't [delay] and [metro] also control objects? If those are generating the event, you have more precise timing than only block boundaries. We actually don't know what would be triggering the [del] in the above patch (or probably I missed it?). Either way, the above patch would convert the precise timing to only block boundaries timing because the frequency inlet of [phasor~] only evaluates control messages on block boundaries. Using [vline~ ], however, would actually use the precise timing of the event. Neither [line~] nor [vline~] will trigger a ramp in the middle of the current block, so if you're rule is IF sample playback THEN [vline~] [line~] there are probably times you're wasting cpu. Sorry, if I am missing your point, but how do you know that [vline~ ] wouldn't trigger a ramp in the middle of block in this case? I didn't write that [vline~] cannot trigger a ramp in the middle of a block-- it obviously can. I wrote that neither object can start a ramp in the middle of the current block. In fact, [line~] will almost always trigger sooner than [vline~], because [line~] starts the ramp immediately at the next block, and [vline~] at minimum will be delayed exactly one block. I have an example patch that shows this but for some reason I can't attach it in Yahoo mail. But just make a simple amplitude envelop inside a subpatch with a large blocksize (greater than one second will do), then try triggering your envelope using [vline~]. -Jonathan Roman ___ 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] stop sample playback when phasor~ reset?
From: hardoff goes bananas hard@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduz...@gmail.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 9:45 PM Subject: Re: [PD] stop sample playback when phasor~ reset? that sounds like a re-blocking delay, rather than anything to do with vline~ I'm not sure how to measure it without changing the blocksize to make the response time obvious. If anyone has a better idea for an example, please post it. See: http://crca.ucsd.edu/~msp/techniques/latest/book-html/node43.html#fig03.04 Notice that for all three examples of the conversion, the first time value for the control event is 2, but the earliesttime this event is reflected in the audio signal is at time value 4, which corresponds with signal index 0-- that's in part A, the fast as possible method. This corresponds to the way [line~] works, and that's as fast as you can possibly go-- updating the value at the very beginning of the next block. Parts B and C describe the type of sample accuracy you can get with [vline~], but notice that both examples actually start at time 6-- signal indexes 0 and 1 correspond to the values at time 0 and 1, and so signal index 2 coincides with the value from the previous block at time 2. That's why the 1st method is called fast as possible. That's why if you build a simple attack/release envelope in a subpatch with a large blocksize (greater than 1 sec), if you use [line~] you'll notice that the envelope starts/stops at various intervals after you trigger it (depending on how close the triggering is to the end of the current block being heard). With [vline~], you get a constant time interval between triggering and hearing the event. As in the table above, that constant time interval corresponds exactly to however long it takes to output one block of audio. Hopefully that's how it really works, I get kind of confused when dealing with this aspect of Pd. :) -Jonathan On Wed, Sep 21, 2011 at 8:42 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 6:05 PM Subject: Re: [PD] stop sample playback when phasor~ reset? On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] | | [0( [0( [ | [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. What do you mean by 'triggering events sporadically using control objects'? Aren't [delay] and [metro] also control objects? If those are generating the event, you have more precise timing than only block boundaries. We actually don't know what would be triggering the [del] in the above patch (or probably I missed it?). Either way, the above patch would convert the precise timing to only block boundaries
Re: [PD] stop sample playback when phasor~ reset?
I generally use threshold~, though it's quite tricky too... Pierre 2011/9/19 James Dunn ja...@4thharmonic.com Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. thanks James __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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] stop sample playback when phasor~ reset?
When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] You get time ms is from [soundfiler]--[/ 44.1], or the length of your table times 44.1. (assuming your sound runs at 44.1 kHz) Probably best to put a [hip~ 5] after that, in case the first sample of your table is not 0. Tim 2011/9/19 Pierre Massat pimas...@gmail.com I generally use threshold~, though it's quite tricky too... Pierre 2011/9/19 James Dunn ja...@4thharmonic.com Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. thanks James __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list ___ 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] stop sample playback when phasor~ reset?
From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] | | [0( [0( [ | [phasor] What's the benefit of this over a line~ based approach? -Jonathan You get time ms is from [soundfiler]--[/ 44.1], or the length of your table times 44.1. (assuming your sound runs at 44.1 kHz) Probably best to put a [hip~ 5] after that, in case the first sample of your table is not 0. Tim 2011/9/19 Pierre Massat pimas...@gmail.com I generally use threshold~, though it's quite tricky too... Pierre 2011/9/19 James Dunn ja...@4thharmonic.com Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. thanks James ___ 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 ___ 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] stop sample playback when phasor~ reset?
2011/9/19 Jonathan Wilkes jancs...@yahoo.com From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? It depends what you want to do, i guess, for doing granular synthesis and the like, I'd use phasor~ rather than line~. The benefit being that fast repetition is easier ( try [metro 0.5] ...). Tim -Jonathan You get time ms is from [soundfiler]--[/ 44.1], or the length of your table times 44.1. (assuming your sound runs at 44.1 kHz) Probably best to put a [hip~ 5] after that, in case the first sample of your table is not 0. Tim 2011/9/19 Pierre Massat pimas...@gmail.com I generally use threshold~, though it's quite tricky too... Pierre 2011/9/19 James Dunn ja...@4thharmonic.com Hi list, I'm controlling tabread4~ with a phasor~ but don't want my samples to loop (most of the time). What's the best way to detect a phasor~'s reset? ( in both directions - I'm playing the samples forwards and backwards). I've looked at edge~ and samphold~ triggered by a bang~ but it seems quite tricky. thanks James ___ 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 ___ 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
