Roman, >> wrapping points. The only drawback compared to [phasor~] is that the >> latter allows to control the frequency with a signal and the >> [metro]/[vline~] based phasor obviously doesn't.
I never did quite figure it out but how do you do more advanced things with [vline~] such as updating/increasing ramp speed mid ramp? >> I'll be glad to help you build the [phasor~] replacement that has an >> additional bang outlet, if you need it. Are you saying this is possible with just metro/vline~ combo? I would be curious what that looks like if you did build it.... m On Wed, Mar 5, 2014 at 3:18 AM, Roman Haefeli <[email protected]> wrote: > On Wed, 2013-05-08 at 22:00 +0100, Ed Kelly wrote: > > Hi Lists(s), > > > > > > I'm rewriting phasor~ and unifying it with metro so that a pulse is > > generated from the boundaries of each ramp - so that bars of music can > > be read using tabread~ objects with a sample-accurate metro. > > > > > > I'm sure someone will say this can already be done, > > Yes! > > > but it has to be dropped into the Ninja Jamm patch, so there isn't > > really time to rewrite the rest of the patch. > > Frankly, I am pretty sure, just using what Pd provides is too easy to > use and likely less time consuming than writing your custom external. > (Or I am totally missing the point of this adventure). > > > > I don't fully understand the way phasor~ wraps, but I have the object > > firing out bar numbers correctly. I'm putting clocks in for 16ths and > > 24ths of the beat, initiated on each wrap. I need to minimise CPU, so > > what I want to know is this: > > > > > > Does phasor~ always start from 0 and go to 1, i.e. is there always a > > signal value of 0 at the start of the ramp and a signal value of 1 at > > the end? As I write this, my common sense tells me it should be "yes" > > but I want to make sure. I suppose I should just try it really... > > No, it's not the case. A [phasor~] ramp virtually starts always at 0 and > ends at 1 - true, but most of the time the wrapping point doesn't lie > exactly on sample boundaries. This means the sample values around the > wrapping point are almost never 1 or 0, respectively. > > Trying to derive precise timing from the audio domain is a moot exercise > anyway, in my opinion. The best you can get from this approach is sample > precision and analyzing all samples of a signal is relatively > expensive. > > If you truly care about CPU consumption and a proper design from the > start, use [metro] - which is as precise as 32-bit floats can be - and > [vline~] - which actually uses the precise timing from [metro] (as > opposed to [line~] that doesn't). > > With this combo [metro]/[vline~] you can rebuild [phasor~] with the > additional benefit of giving you more-than-sample-exact bangs at the > wrapping points. The only drawback compared to [phasor~] is that the > latter allows to control the frequency with a signal and the > [metro]/[vline~] based phasor obviously doesn't. > > I'll be glad to help you build the [phasor~] replacement that has an > additional bang outlet, if you need it. > > Roman > > > > > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev > -- ____________________ m.e.grimm | m.f.a | ed.m. [email protected] _________________________________
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
