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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
best,
J
On 2010-04-14 11:10, 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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
what do you want to acchieve? e.g.
should:
[sig~ 3] [sig~ 0] | | [phasor~ ] |
always output "0" because the phase is constantly set to 0?
mfgasdr IOhannes
I've no idea what you're trying to achieve. However. You can always scratch something together with [snapshot~] and [bang~] (note tilde). To convert audio into signal. (This is processor heavy, you could use a [metro] for a less cpu hungry version.
Date: Wed, 14 Apr 2010 11:23:42 +0200 From: zmoelnig@iem.at To: jaime.oliver2@gmail.com CC: pd-list@iem.at Subject: Re: [PD] phasor~ and osc~ right inlet: signal?
On 2010-04-14 11:10, 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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
what do you want to acchieve? e.g.
should:
[sig~ 3] [sig~ 0] | | [phasor~ ] |
always output "0" because the phase is constantly set to 0?
mfgasdr IOhannes
http://clk.atdmt.com/UKM/go/197222280/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
As IOhannes pointed out, it doesn't make too much sense to have the phase inlets fed by a signal.
What would you probably want is to be able to constantly shift the phase over time relative to an initially set absolute phase. This can be achieve by adding a constant to the [phasor~] signal and wrapping the the result.
[phasor~] | | [inlet~ relative-phase-shift] | | [+~ ] | [wrap~] (<- use Pd's internal [wrap~] here, not zexy's)
For a similar [osc~] replacement, just connect [wrap~]'s outlet to a [cos~].
Roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
You don't actually need the [wrap~] as the domain of [cos~] is already suited.
On Wed, 14 Apr 2010 13:17:54 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
As IOhannes pointed out, it doesn't make too much sense to have the phase inlets fed by a signal.
What would you probably want is to be able to constantly shift the phase over time relative to an initially set absolute phase. This can be achieve by adding a constant to the [phasor~] signal and wrapping the the result.
[phasor~] | | [inlet~ relative-phase-shift] | | [+~ ] | [wrap~] (<- use Pd's internal [wrap~] here, not zexy's)
For a similar [osc~] replacement, just connect [wrap~]'s outlet to a [cos~].
Roman
___________________________________________________________ Der fr_he Vogel f_ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2010-04-14 at 12:51 +0100, Andy Farnell wrote:
You don't actually need the [wrap~] as the domain of [cos~] is already suited.
Ah yes, thanks.
But you still need for the [phasor~] replacement, right?
Roman
On Wed, 14 Apr 2010 13:17:54 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
As IOhannes pointed out, it doesn't make too much sense to have the phase inlets fed by a signal.
What would you probably want is to be able to constantly shift the phase over time relative to an initially set absolute phase. This can be achieve by adding a constant to the [phasor~] signal and wrapping the the result.
[phasor~] | | [inlet~ relative-phase-shift] | | [+~ ] | [wrap~] (<- use Pd's internal [wrap~] here, not zexy's)
For a similar [osc~] replacement, just connect [wrap~]'s outlet to a [cos~].
Roman
___________________________________________________________ Der fr_he Vogel f_ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hi all thanks for your responses.
Yes, the idea is to be able to slightly modify phasors~ phase to use it as an index to read a table.
those ideas should work!
best,
J
On Wed, Apr 14, 2010 at 5:13 AM, Roman Haefeli reduzierer@yahoo.de wrote:
On Wed, 2010-04-14 at 12:51 +0100, Andy Farnell wrote:
You don't actually need the [wrap~] as the domain of [cos~] is already suited.
Ah yes, thanks.
But you still need for the [phasor~] replacement, right?
Roman
On Wed, 14 Apr 2010 13:17:54 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
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?
if this feature was added in vanilla, would it break anything? is it possible, worthwhile? is there a third party external doing this?
As IOhannes pointed out, it doesn't make too much sense to have the phase inlets fed by a signal.
What would you probably want is to be able to constantly shift the
phase
over time relative to an initially set absolute phase. This can be achieve by adding a constant to the [phasor~] signal and wrapping the the result.
[phasor~] | | [inlet~ relative-phase-shift] | | [+~ ] | [wrap~] (<- use Pd's internal [wrap~] here, not zexy's)
For a similar [osc~] replacement, just connect [wrap~]'s outlet to a [cos~].
Roman
Der fr_he Vogel f_ngt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi, On Wed, Apr 14, 2010 at 01:17:54PM +0200, Roman Haefeli wrote:
As IOhannes pointed out, it doesn't make too much sense to have the phase inlets fed by a signal.
But what many people would want is clock-accurate updates of the phase inlets instead of updates being block-quantized.
Ciao
Frank
Frank Barknecht wrote:
But what many people would want is clock-accurate updates of the phase inlets instead of updates being block-quantized.
Ciao
I posted an abstraction on the forum a few days ago that does this.
http://puredata.hurleur.com/sujet-4039-phasor-sample-accurate-phase-reset
.mmb
Hi Mike,
On Thu, Apr 15, 2010 at 02:19:22AM -0400, Mike Moser-Booth wrote:
Frank Barknecht wrote:
But what many people would want is clock-accurate updates of the phase inlets instead of updates being block-quantized.
Ciao
I posted an abstraction on the forum a few days ago that does this.
http://puredata.hurleur.com/sujet-4039-phasor-sample-accurate-phase-reset
I'm not sure, if this is working correctly. I made a test patch (attached) which delays the message to set the phase by some samples. As [tabwrite~] is block-quantized, I would expect that the phase is set to 0.25 at some place inside the scope-tables. For the standard phasor~ it indeed does this (albeit block-quantized), but the vphasor just seems to ignore any request to set the phase. You can adjust the sample-delay with a number box.
(Forum admins: It would be nice to allow downloads without logging in.)
Ciao
Frank
The output~ section is now public readable for attachments. And I've added an announcement.
That means posters can choose whether to share globally, and gives a slightly more appropriate meaning to the forum section called output~
a.
On Thu, 15 Apr 2010 15:51:27 +0200 Frank Barknecht fbar@footils.org wrote:
(Forum admins: It would be nice to allow downloads without logging in.)
#N canvas 0 22 1028 637 10; #N canvas 0 22 450 300 (subpatch) 0; #X array phasor-graph 256 float 0; #X coords 0 1 255 -1 200 140 1; #X restore 555 119 graph; #N canvas 0 22 450 300 (subpatch) 0; #X array vphasor-graph 256 float 0; #X coords 0 1 255 -1 200 140 1; #X restore 555 289 graph; #X obj 98 342 tabwrite~ phasor-graph; #X obj 313 343 tabwrite~ vphasor-graph; #X msg 48 70 ; pd dsp 1; #X obj 473 469 loadbang; #X obj 163 50 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X msg 473 495 ; phasor-graph xticks 0 64 1 ; phasor-graph xlabel -1.1 0 64 128 192 256 ; vphasor-graph xticks 0 64 1 ; vphasor-graph xlabel -1.1 0 64 128 192 256 ;; #X obj 555 57 block~ 64 1; #X text 761 346 ...while [vphasor.mmb~] does not.; #X text 758 179 [phasor~] locks to block boundaries...; #X obj 48 47 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 163 107 t b b; #X text 66 47 turn on dsp; #X text 179 50 turn on to see difference; #X text 54 426 [vphasor.mmb~] acts just like [phasor~] , except the phase inlet is sample-accurate , meaning it can be updated between block boundaries.; #X text 132 363 [tabwrite~] starts writing at block boundaries.; #X obj 163 78 metro 150; #X obj 209 135 delay 2; #X msg 209 156 0.25; #N canvas 0 0 616 403 sm2ms 0; #X obj 307 142 samplerate~; #X obj 307 204 / 1000; #X obj 356 47 loadbang; #X obj 135 134 inlet; #X obj 135 228 outlet; #X obj 135 183 / 44.1; #X obj 307 51 inlet; #X obj 307 105 select 0; #X floatatom 312 229 5 0 0 0 - - -; #X msg 233 112 bang; #X connect 0 0 1 0; #X connect 1 0 5 1; #X connect 1 0 8 0; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 0 0; #X connect 7 1 1 0; #X connect 9 0 0 0; #X restore 255 110 pd sm2ms; #X floatatom 255 85 5 0 0 1 samples - -; #X text 156 183 reset phases to 0.25 sometime after the tabwrite~bang ; #X obj 313 275 vphasor.mmb~ 808; #X obj 98 275 phasor~ 808; #X connect 5 0 7 0; #X connect 6 0 17 0; #X connect 11 0 4 0; #X connect 12 0 2 0; #X connect 12 0 3 0; #X connect 12 1 18 0; #X connect 17 0 12 0; #X connect 18 0 19 0; #X connect 19 0 23 1; #X connect 19 0 24 1; #X connect 20 0 18 1; #X connect 21 0 20 0; #X connect 23 0 3 0; #X connect 24 0 2 0;
On Thu, Apr 15, 2010 at 01:04:13PM -0400, Mike Moser-Booth wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Try changing the frequency of [vphasor.mmb~] to something that doesn't divide so nicely into the [metro]'s rate. Like in the attached.<br> <br> .mmb<br> <br>
Oh, I thought I had tried this - but obviously didn't. Sorry for the noise.
Ciao
Frank
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
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 reduzierer@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
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
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
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
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
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
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
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
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
-
Andrew Faraday -
Andy Farnell -
Frank Barknecht -
IOhannes m zmoelnig -
Jaime Oliver -
Mike Moser-Booth -
Roman Haefeli