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

[Andy Farnell]

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 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
> essential).
> 
> Roman
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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)