[PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)

Roman Haefeli reduzierer at yahoo.de
Fri Apr 16 13:37:37 CEST 2010

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


More information about the Pd-list mailing list