[PD] phasor~ and osc~ right inlet: exact timing (was: phasor~ and osc~ right inlet: signal?)
padawan12 at obiwannabe.co.uk
Fri Apr 16 13:56:57 CEST 2010
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
Would anyone have objections to that?
On Fri, 16 Apr 2010 13:37:37 +0200
Roman Haefeli <reduzierer at 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
> Pd-list at 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)
More information about the Pd-list