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