[PD-dev] Rewriting a unified phasor / metro object for reading tables

[me.grimm]

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 <reduzent at gmail.com> 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
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>



-- 
____________________
m.e.grimm | m.f.a | ed.m.
megrimm at gmail.com
_________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20140306/a0a48386/attachment.htm>