Re: [PD] phasor~ and osc~ right inlet: exact timing
Hi, On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Hi, On Mon, Apr 19, 2010 at 09:21:35AM +0200, Frank Barknecht wrote: On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Oh, and I hope you don't mind, but I added a simplified, expr-less version to the rj library as s_vphasor as attached (giving you credit). There I added the 2 to the phase value sent into the vline~ to save on signal addition object - iDevices are slow. :) Ciao -- Frank #N canvas 118 17 879 550 10; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-s 100 float 0; #X coords 0 1 99 -1 200 140 1; #X restore 529 255 graph; #X obj 630 206 tabwrite~ \$0-s; #X obj 630 60 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 630 85 metro 150; #N canvas 377 58 827 710 REFERENCE 0; #X text 114 141 Summary: phasor~ clone with sample accurate phase setting ; #X text 114 121 Name: s_vphasor; #X text 114 164 Inlet 0: audio signal or float to set frequency; #X text 114 217 Outlet 0: phasor signal between 0 and 1; #X text 122 529 Tags: phasor \, phase \, sample accurate \, samphold ; #X text 114 184 Inlet 1: float to set phase. Range is 0 to 1 \, values outside are wrapped.; #X text 112 251 Description: s_vphasor is almost like [phasor~] in Pd \, but it allows setting the phase through the left inlet with sample accuracy and it does not support setting its frequency with an argument. Based on an approach by Mike Moser-Booth.; #X coords 0 -1 1 1 450 450 1 100 100; #X restore 5 48 pd REFERENCE; #X text 5 13 s_vphasor - phasor~ clone with sample accurate phase setting ; #X obj 526 161 s_vphasor; #X obj 527 90 sig~ 1234; #X msg 586 125 0.25; #X floatatom 527 62 5 0 0 0 - - -; #X msg 528 454 yticks 0 0.1 5; #X obj 528 475 s \$0-s; #X obj 528 432 loadbang; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 0 8 0; #X connect 6 0 1 0; #X connect 7 0 6 0; #X connect 8 0 6 1; #X connect 9 0 7 0; #X connect 10 0 11 0; #X connect 12 0 10 0; #N canvas 326 55 693 430 10; #X obj 73 44 inlet~; #X obj 72 335 outlet~; #N canvas 263 13 762 384 banghold~ 0; #X obj 101 280 samphold~; #X obj 162 255 vline~; #X obj 205 100 samplerate~; #X obj 205 122 swap 1000; #X obj 205 147 /; #X obj 205 69 loadbang; #X obj 162 198 f; #X msg 162 230 -1 \, 0 0 \$1; #X obj 162 41 inlet; #X obj 162 177 b; #X obj 102 41 inlet~; #X obj 101 304 outlet~; #X msg 289 69 bang; #X text 234 24 samples its input whenever it receives a bang at the first inlet. Accurate up to one sample duration.; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 6 1; #X connect 5 0 2 0; #X connect 6 0 7 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 10 0 0 0; #X connect 12 0 2 0; #X restore 89 127 pd banghold~; #X obj 71 165 -~; #X obj 71 297 wrap~; #X obj 71 240 +~; #X obj 72 81 phasor~; #X obj 170 43 inlet; #X obj 202 206 vline~; #X obj 202 95 wrap; #N canvas 228 198 627 317 LICENSE-BSD 0; #X text 121 56 This software is copyrighted by Miller Puckette \, Reality Jockey Ltd. and others. The terms (the Standard Improved BSD License) apply to all files associated with the software unless explicitly disclaimed in individual files.; #X text 123 148 See the file LICENSE.txt for the full license text. ; #X restore 233 40 pd LICENSE-BSD; #X obj 202 177 + 2; #X obj 170 67 t b f; #X text 235 177 workaround for a bug in [wrap~] which converts 0 to 1; #X connect 0 0 6 0; #X connect 2 0 3 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 6 0 2 0; #X connect 7 0 12 0; #X connect 8 0 5 1; #X connect 9 0 11 0; #X connect 11 0 8 0; #X connect 12 0 2 1; #X connect 12 1 9 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Thanks a lot for your explanations! On Sun, 2010-04-18 at 22:14 -0400, Matt Barber wrote: For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; By using 'sinesum' messages to [table]s? I can't think of another way to have access to more precise sinusoids in Pd, or is there any? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Thanks a lot for your explanations! On Sun, 2010-04-18 at 22:14 -0400, Matt Barber wrote: For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; By using 'sinesum' messages to [table]s? I can't think of another way to have access to more precise sinusoids in Pd, or is there any? Yes, either that (which seems to use the math.h sin or cos functions), or an [until] + [sin] + [tabwrite] routine. The former is easier, obviously, and also adds the three guard points automatically (it also seems to use the same precision of PI=3.14159 that you can get with floats in Pd patches). If you want the code, look for the function garray_dofo in g_array.c Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Hey Frank, Frank Barknecht wrote: Hi, On Mon, Apr 19, 2010 at 09:21:35AM +0200, Frank Barknecht wrote: On Sun, Apr 18, 2010 at 11:42:45AM -0400, Mike Moser-Booth wrote: Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. Yeah, that's a nasty old bug of wrap~. Miller, when can we get a fix? :) I simplified it away here just to concentrate on the other aspect. Btw.: vanilla's [wrap] in Pd can be used to replace the modf-expr you use after the phase inlet - [wrap] for messages is even correct for 0. :) Oh, and I hope you don't mind, but I added a simplified, expr-less version to the rj library as s_vphasor as attached (giving you credit). I am totally okay with this! Thanks. :-) There I added the 2 to the phase value sent into the vline~ to save on signal addition object - iDevices are slow. :) Even better. I wasn't sure about vanilla's [wrap]. I'm using extended, and it uses zexy's instead. I wanted to make sure this worked in both vanilla and extended, and since you can't do [vanilla/wrap] I just made it with [expr]. But I guess with no arguments they work the same. Good to know, thanks. .mmb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
On Fri, Apr 16, 2010 at 08:19:09PM +0200, Frank Barknecht wrote: Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset. Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion. Actually I meant two write take a [samphold~] of the original phasor. Taking a snapshot~ or rather, a vsnapshot~ is something I have also tried, but it gives the wrong results. See attached example for a comparison of [vsnapshot~]-[vline~] with Mike's [samphold~] solution (which I simplified a bit). Lesson to learn: [vsnapshot~]-[vline~] won't do what you may expect it to do. Ciao -- Frank #N canvas 31 37 914 426 10; #N canvas 0 0 450 300 vphasor.mbb 0; #X obj 73 44 inlet~; #X obj 72 265 outlet~; #N canvas 263 13 762 384 banghold~ 0; #X obj 101 280 samphold~; #X obj 162 255 vline~; #X obj 205 100 samplerate~; #X obj 205 122 swap 1000; #X obj 205 147 /; #X obj 205 69 loadbang; #X obj 162 198 f; #X msg 162 230 -1 \, 0 0 \$1; #X obj 162 41 inlet; #X obj 162 177 b; #X obj 102 41 inlet~; #X obj 101 304 outlet~; #X msg 289 69 bang; #X text 234 24 samples its input whenever it receives a bang at the first inlet. Accurate up to one sample duration.; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 1 4 1; #X connect 4 0 6 1; #X connect 5 0 2 0; #X connect 6 0 7 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 9 0 6 0; #X connect 10 0 0 0; #X connect 12 0 2 0; #X restore 89 127 pd banghold~; #X obj 71 165 -~; #X obj 71 227 wrap~; #X obj 71 200 +~; #X obj 72 81 phasor~; #X obj 138 43 inlet; #X obj 138 67 t f b; #X obj 138 166 vline~; #X connect 0 0 6 0; #X connect 2 0 3 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 3 0; #X connect 6 0 2 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 8 1 2 1; #X connect 9 0 5 1; #X restore 89 139 pd vphasor.mbb; #N canvas 297 96 450 300 vphasor.vsnap 1; #X obj 73 44 inlet~; #X obj 73 265 outlet~; #X obj 72 227 wrap~; #X obj 72 81 phasor~; #X obj 138 43 inlet; #X obj 138 166 vline~; #X obj 138 67 t b f; #X obj 138 118 vsnapshot~; #X obj 138 142 -; #X obj 73 196 -~; #X connect 0 0 3 0; #X connect 2 0 1 0; #X connect 3 0 7 0; #X connect 3 0 9 0; #X connect 4 0 6 0; #X connect 5 0 9 1; #X connect 6 0 7 0; #X connect 6 1 8 1; #X connect 7 0 8 0; #X connect 8 0 5 0; #X connect 9 0 2 0; #X restore 212 139 pd vphasor.vsnap; #X obj 125 206 -~; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-s 256 float 0; #X coords 0 1 255 -1 200 140 1; #X restore 378 195 graph; #X obj 620 282 s \$0-s; #X obj 620 198 loadbang; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-s1 256 float 0; #X coords 0 1 255 -1 200 140 1; #X restore 378 35 graph; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-s2 256 float 0; #X coords 0 1 255 -1 200 140 1; #X restore 598 35 graph; #X obj 620 304 s \$0-s1; #X obj 620 326 s \$0-s2; #X obj 231 169 r \$0-SCOPE; #X obj 145 240 r \$0-SCOPE; #X obj 108 328 r \$0-SCOPE; #X obj 88 356 tabwrite~ \$0-s1; #X obj 125 268 tabwrite~ \$0-s; #X obj 211 197 tabwrite~ \$0-s2; #X msg 620 259 yticks 0 0.1 5 \, xticks 0 64 5; #X obj 184 42 metro 150; #X obj 229 66 s \$0-SCOPE; #X obj 184 20 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 627 221 \; pd dsp 1; #X msg 184 67 0.25; #X obj 89 60 sig~ 456; #X text 222 120 wrong; #X connect 0 0 13 0; #X connect 0 0 2 0; #X connect 1 0 2 1; #X connect 1 0 15 0; #X connect 2 0 14 0; #X connect 5 0 16 0; #X connect 5 0 20 0; #X connect 10 0 15 0; #X connect 11 0 14 0; #X connect 12 0 13 0; #X connect 16 0 4 0; #X connect 16 0 8 0; #X connect 16 0 9 0; #X connect 17 0 21 0; #X connect 17 0 18 0; #X connect 19 0 17 0; #X connect 21 0 0 1; #X connect 21 0 1 1; #X connect 22 0 0 0; #X connect 22 0 1 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
On Sun, Apr 18, 2010 at 01:28:02PM +0200, Matteo Sisti Sette wrote: Actually I meant two write take a [samphold~] of the original phasor. Taking a snapshot~ or rather, a vsnapshot~ is something I have also tried, but it gives the wrong results. See attached example for a comparison of [vsnapshot~]-[vline~] with Mike's [samphold~] solution (which I simplified a bit). Lesson to learn: [vsnapshot~]-[vline~] won't do what you may expect it to do. Very very interesting. Basically you have to take into account that vsnapshot~ samples the signal with a delay of one block~ (and it couldn't be otherwise), which renders it useless for the phasor~ accurate reset application. Pd alternates message and dsp computations. So the order here is: vsnapshot~ analyses dsp, then produces a message, then vline~ gets this one during the following message pass which is already too late to change its own signal result in the previous block. Duh. So while both vsnapshot~ and vline~ are subsample-accurate in a block, the combination is not. The samplehold~ approach also uses vline~ to schedule an accurate impulse, but as samphold~ works entirely in the signal realm, no delaying message pass is needed in between. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
By the way, what about the sample-accurate-phase-resettable osc~? -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
On Sun, 2010-04-18 at 11:25 +0200, Frank Barknecht wrote: On Fri, Apr 16, 2010 at 08:19:09PM +0200, Frank Barknecht wrote: Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset. Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion. Actually I meant two write take a [samphold~] of the original phasor. Taking a snapshot~ or rather, a vsnapshot~ is something I have also tried, but it gives the wrong results. See attached example for a comparison of [vsnapshot~]-[vline~] with Mike's [samphold~] solution (which I simplified a bit). Lesson to learn: [vsnapshot~]-[vline~] won't do what you may expect it to do. Before this thread was started, I also was thinking of a [vsnapshot~] based solution. But I didn't even start to try to implement it, because it includes a loop (message - audio - message) that will certainly introduce a latency, which breaks the goal of accuracy completely. I find Mike's loopless [samphold~] based solution very elegant. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Hey guys, Thank you very much for checking this out. I'm glad you guys like. Frank, I was looking at your comparison patch and noticed you took the [+~ 2] out. The reason I put this in is because [wrap~] converts 0 to 1, so if you reset the phase to 0 you'll end up starting at the end instead of the beginning. And I did [+~ 2] instead of [+~ 1] because thought I read somewhere that [phasor~] actually goes all the way up to 1 instead of just before it. I don't know if that's actually true or not, though, but I figured adding 2 is easier than looking at the source. ;-) Thanks again, .mmb Roman Haefeli wrote: On Sun, 2010-04-18 at 11:25 +0200, Frank Barknecht wrote: On Fri, Apr 16, 2010 at 08:19:09PM +0200, Frank Barknecht wrote: Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset. Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion. Actually I meant two write take a [samphold~] of the original phasor. Taking a snapshot~ or rather, a vsnapshot~ is something I have also tried, but it gives the wrong results. See attached example for a comparison of [vsnapshot~]-[vline~] with Mike's [samphold~] solution (which I simplified a bit). Lesson to learn: [vsnapshot~]-[vline~] won't do what you may expect it to do. Before this thread was started, I also was thinking of a [vsnapshot~] based solution. But I didn't even start to try to implement it, because it includes a loop (message - audio - message) that will certainly introduce a latency, which breaks the goal of accuracy completely. I find Mike's loopless [samphold~] based solution very elegant. 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] phasor~ and osc~ right inlet: exact timing
Matteo Sisti Sette wrote: By the way, what about the sample-accurate-phase-resettable osc~? Hey Matteo, Just use [vphasor.mmb~] to look up [cos~]. .mmb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
On Sun, 2010-04-18 at 11:43 -0400, Mike Moser-Booth wrote: Matteo Sisti Sette wrote: By the way, what about the sample-accurate-phase-resettable osc~? Hey Matteo, Just use [vphasor.mmb~] to look up [cos~]. Coming up again with the 'smoother' topic: Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as an [osc~]? If not, which has less error and why? (Yeah, I know it's in the sources, I'm only asking for translation) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Roman Haefeli escribió: On Sun, 2010-04-18 at 11:43 -0400, Mike Moser-Booth wrote: Matteo Sisti Sette wrote: By the way, what about the sample-accurate-phase-resettable osc~? Hey Matteo, Just use [vphasor.mmb~] to look up [cos~]. Coming up again with the 'smoother' topic: Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as an [osc~]? If not, which has less error and why? I subscribe the same question -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Coming up again with the 'smoother' topic: Is [phasor~]-[cos~ ] precision-wise and interpolation-wise the same as an [osc~]? If not, which has less error and why? I think each one is 512-point linear interpolated. m_pd.h: #define LOGCOSTABSIZE 9 #define COSTABSIZE (1LOGCOSTABSIZE) This would give you 512 points. The code for both osc~ and cos~ have: *out++ = f1 + frac * (f2 - f1); Which, if the mnemonically named frac variable is just the fractional part of the index between f1 and f2, is a simple linear interpolation between the two points. For this reason I almost always use an 8192-point [table] and [tabread4~] if I need more accurate sinusoids; I've gotten pretty severe errors especially in cases where I need to divide a signal by the output of a cosine oscillator near 90-degrees phase (near the zero-crossing), and even more especially where the numerator is also near zero, just using [cos~], presumably both because the values from the oscillator output are near zero and because the function is changing at the greatest rate there. IIRC SuperCollider's SinOsc uses an 8192-point table with linear interpolation, and Phasor+BufRd you specify the table size and the type of interpolation (the cubic is the same as the Hermite one in [tabread4c~]). In csound's oscil* or phasor+table* opcodes you specify the table size (power of 2) and the type of interpolation (the cubic is identical to the Lagrange one in Pd). Someone please correct me if I'm mistaken. MB ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)
Sorry, if you receive that mail twice. It seems it didn't make it through the list the first time. In the meanwhile, Frank already mentioned it: A clock-exact phase reset is needed. I'm happy to see that I'm not the only one seeing that need. On Wed, 2010-04-14 at 02:10 -0700, Jaime Oliver wrote: Hi all, It would be great it phasor~ and/or osc~ could receive phase information (right inlet) as a signal. objects like *~ can recognize if they are receiving a float or a signal on their left inlet? What really would be helpful in some situations is, if the phase inlet would take exact timing (as generated by [delay] and [metro]) into account. Currently it sets the phase only on block boundaries, which prohibits some applications. For instance, I'd like to create a kick-drum synthesizer patch and I'd like the kick-drum to be triggered at any given time (also between block boundaries). Now, since the kick-drum needs to reset the phase of - let's say - an [osc~] on every trigger in order to achieve the correct attack sound, you cannot trigger it between block boundaries, because then the generated sound would turn out wrong. This has even more implications. I cannot use [vline~] and its powerfull capabilities to generate complex envelopes to be used in the kick-drum patch, because it will start at exact time and thus will be not in sync with the signal generating part, which starts at block boundaries. Thus I would have to use [line~] instead of [vline~], which is much more complicated to use. Or i would have to artificially destroy [vline~]'s feature of the exact timing and find some tweak to trigger it only on block boundaries. Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account. Otherwise, there is a high chance of mixing up exact time and block boundary time, which would create weird unexpected results. Also it is cumbersome to have to know which object classes support exact timing and which not. In many cases exact timing can be emulated by a properly crafted [vline~] at the inlet (a [vline~] generating a jump from the old value to the new value at the desired exact time). In the case of [osc~] of [phasor~] this is not possible. To sum it up, in most cases exact timing can be achieved, but the exact timing for the phase reset is _really_ missing (and is actually essential). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)
Ah yes. This is a really good point. I just read through your whole email Roman and this brings back all those times I was trying to get a click free phase reset in an oscillator but never bothered to debug it in enough detail to see that this was indeed a block boundary problem. You are right. Of course we need a [phasor~] that can be instantly reset on any sample. This is a good candidate for a Vanilla level change as I can't see much serious breakage occuring as a result. Would anyone have objections to that? a. On Fri, 16 Apr 2010 13:37:37 +0200 Roman Haefeli reduzie...@yahoo.de wrote: Sorry, if you receive that mail twice. It seems it didn't make it through the list the first time. In the meanwhile, Frank already mentioned it: A clock-exact phase reset is needed. I'm happy to see that I'm not the only one seeing that need. On Wed, 2010-04-14 at 02:10 -0700, Jaime Oliver wrote: Hi all, It would be great it phasor~ and/or osc~ could receive phase information (right inlet) as a signal. objects like *~ can recognize if they are receiving a float or a signal on their left inlet? What really would be helpful in some situations is, if the phase inlet would take exact timing (as generated by [delay] and [metro]) into account. Currently it sets the phase only on block boundaries, which prohibits some applications. For instance, I'd like to create a kick-drum synthesizer patch and I'd like the kick-drum to be triggered at any given time (also between block boundaries). Now, since the kick-drum needs to reset the phase of - let's say - an [osc~] on every trigger in order to achieve the correct attack sound, you cannot trigger it between block boundaries, because then the generated sound would turn out wrong. This has even more implications. I cannot use [vline~] and its powerfull capabilities to generate complex envelopes to be used in the kick-drum patch, because it will start at exact time and thus will be not in sync with the signal generating part, which starts at block boundaries. Thus I would have to use [line~] instead of [vline~], which is much more complicated to use. Or i would have to artificially destroy [vline~]'s feature of the exact timing and find some tweak to trigger it only on block boundaries. Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account. Otherwise, there is a high chance of mixing up exact time and block boundary time, which would create weird unexpected results. Also it is cumbersome to have to know which object classes support exact timing and which not. In many cases exact timing can be emulated by a properly crafted [vline~] at the inlet (a [vline~] generating a jump from the old value to the new value at the desired exact time). In the case of [osc~] of [phasor~] this is not possible. To sum it up, in most cases exact timing can be achieved, but the exact timing for the phase reset is _really_ missing (and is actually essential). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- --- Sent from my 3 (http://three.co.uk) mobile broadband Third world internet for a first world economy. * 20 bytes/second * 99% packet loss * 60 second latency All for only £20/month (Odious and predatory terms apply) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account. Yeah! No object should be left out! Every single object should take exact timing into accounts, or at the very least, have a v counterpart that does (I guess the objects that don't are faster, so when sub-block accuracy is not needed one may actually prefer the inaccurate version). By the way, you say all those objects that convert from message to signal domain. Why not the other way round too? I always wished there was a [vthreshold~] for example. Or is it physically impossible? I mean perhaps you get the information one block too late? Also it is cumbersome to have to know which object classes support exact timing and which not. Absolutely! thanks m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
On Fri, 2010-04-16 at 16:00 +0200, Matteo Sisti Sette wrote: Actually, I think (it's not the first time I say that, I guess), that all inlets of object classes, which have signal outlets (or all objects that convert from message domain to signal domain) should take the exact timing into account. Yeah! No object should be left out! Every single object should take exact timing into accounts, or at the very least, have a v counterpart that does (I guess the objects that don't are faster, so when sub-block accuracy is not needed one may actually prefer the inaccurate version). Actually, the most cases (such as [*~],the left inleft of [osc~]/[phasor~] etc.) can be covered with a - let's call it [vsig~] abstraction based on [vline~]. By the way, you say all those objects that convert from message to signal domain. Why not the other way round too? I always wished there was a [vthreshold~] for example. Right. There is [vsnapshot~], which does something similar, though it's not truely converting from audio domain to message domain, since only the resulting value is taken from the audio domain, whereas the timing still comes from the message domain. From what I know, the message comes one block late. Or is it physically impossible? I mean perhaps you get the information one block too late? I think so. Can someone confirm who knows? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
hi Right. There is [vsnapshot~], which does something similar, though it's not truely converting from audio domain to message domain, since only the resulting value is taken from the audio domain, whereas the timing still comes from the message domain. From what I know, the message comes one block late. but you can bang vsnapshot~ faster than the block rate and it seems it works fine. so there must be no one-block delay. alabala -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
ypatios escribió: There is [vsnapshot~] [...] From what I know, the message comes one block late. but you can bang vsnapshot~ faster than the block rate and it seems it works fine. so there must be no one-block delay. I don't know whether the messages come a block later or not, but the fact you can bang more than once per block and not loose messages is not incompatible with the possibility that there is a one-block delay: the messages can come accumulated with the correct values and timestamps but all one-block late... like out of a one-block pipe... -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
what if a timer between bang and vsnapshot's reaction shows 0? -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing
ypatios escribió: what if a timer between bang and vsnapshot's reaction shows 0? I'm not sure whether this proves or disproves the one-block-delay hypothesis. Experts of the insides of how Pd's data/dsp processing loop works can certainly answer on that - and I'm very curious too -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)
On Fri, Apr 16, 2010 at 01:37:37PM +0200, Roman Haefeli wrote: To sum it up, in most cases exact timing can be achieved, but the exact timing for the phase reset is _really_ missing (and is actually essential). Well, Mike's version for a clock-accurate phasor~ clone actually is pretty good and indeed working. And it's very simple and elegant as well. You start with making a phaseshifted phasor~ by sending the phasor~ through a [wrap~] as is used a lot in Miller's book and the docs when building synced phasor signals for granular synthesis or windowed sample playing. If you add some value to the phasor~ signal, the wrap~-phasor will just be phaseshifted by that value. So adding 0.5 to the phasor~ will give you a phasor~ in the end that is 0.5 out of phase from the original. Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset. Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)
Thanks, Frank, for mentioning it again and confirming that it works. I'll definitely check this one out. Also many thanks to Mike who provided the patch. Roman On Fri, 2010-04-16 at 20:19 +0200, Frank Barknecht wrote: On Fri, Apr 16, 2010 at 01:37:37PM +0200, Roman Haefeli wrote: To sum it up, in most cases exact timing can be achieved, but the exact timing for the phase reset is _really_ missing (and is actually essential). Well, Mike's version for a clock-accurate phasor~ clone actually is pretty good and indeed working. And it's very simple and elegant as well. You start with making a phaseshifted phasor~ by sending the phasor~ through a [wrap~] as is used a lot in Miller's book and the docs when building synced phasor signals for granular synthesis or windowed sample playing. If you add some value to the phasor~ signal, the wrap~-phasor will just be phaseshifted by that value. So adding 0.5 to the phasor~ will give you a phasor~ in the end that is 0.5 out of phase from the original. Mike's trick then is to take a snapshot~ of the original phasor at the moment of the desired phase resetting. If you substract that value from the original phasor, you get a phasor~ shifted up or down just by the value it had when the phase was last reset. Now you can add in the desired phase value again to get a wrap-phasor that is out of sync to the original phasor in exactly the desired fashion. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
