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 <[email protected]> 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 > > > > > > > _______________________________________________ > [email protected] 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) _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
