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