Thanks Katja.

I'm doing things in a quick and dirty manner, to see if they work and so that they can be implemented quickly for the 100,000 or so downloads we've had, but I want to get it right. We'll have a testflight version next week so we'll be able to test the new version (it's like a heart transplant for the app).

The first thing is that it has to work with the limited resources of the iPhone4 (the most basic device we are supporting). The second is to make it better, so that we can move from tabread~ s to tabread4~s, but I think this'll be just for the iPhone5. I really want it to be super efficient, so I'll study your code.

Interesting that the original phasor~ relies on a double precision variable for the wrap. Sometime we need to move onto 128bit architecture, but probably not too soon ;)

Cheers, Ed   PS thanks for answering the question I asked.   Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/

Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/

----- Original Message -----

From: katja katjavetter@gmail.com To: Ed Kelly morph_2016@yahoo.co.uk Cc: PD List pd-list@iem.at; pddev pd-dev@iem.at Sent: Thursday, 9 May 2013, 10:12 Subject: Re: [PD-dev] Rewriting a unified phasor / metro object for reading tables

On Wed, May 8, 2013 at 11:00 PM, Ed Kelly morph_2016@yahoo.co.uk wrote:

...

... 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...

...

...

A [phasor~] ramp should start with the remainder after wrapping, which is non-zero in most cases.

For pd-double I had to rewrite [phasor~], and it turned out that an implementation with branching is more efficient on current Intel processors. ARM processors do branch predication, it could be efficient as well. You could try the code from here and put message triggers in the branches:

https://github.com/pd-projects/pd-double/blob/master/src/d_osc.c

Katja

On Tue, Mar 4, 2014 at 8:53 PM, Chris McCormick chris@mccormick.cx wrote:

Not sure if this is relevant or already common knowledge but newer versions of Pd allow you to specify metro and delay tempo & units, including in samples. e.g. [metro 500 1 samp].

Does anybody know if sample-accurate [metros] are available in libpd? I'm making an application that allows for fairly arbitrary divisions of a tempo. Originally I was going to make clocks out of metros, but I wasn't aware that you could set a [metro] faster than one bang per ms. If I wanted a bunch of different rhythms, not just eigths and sixteenths, but triplets and divisions of fives or sevens or whatever, I would need to make a bunch of [metro] objects (or maybe one running at the least common multiple of the various divisions).

In the end, I settled on handling this logic in the Java side of my application by counting samples and doing some math. I can schedule bangs at arbitrary divisions of a base amount of time (so I can make seven-tuplets or fiftythree-uplets or whatever strange rhythm I want to). In theory my solution should be sample-accurate, and it sounds like it's working fine.

But is there a straightforward way to do this in pd that I completely overlooked?

On Fri, 2014-03-07 at 11:18 +0800, Chris McCormick wrote:

Hi Brian,

On 07/03/14 08:22, Brian Fay wrote:

...

Does anybody know if sample-accurate [metros] are available in libpd?

Looking at x_time.c in libpd it does not seem like those changes from Miller's branch have been merged into libpd yet. I am sure somebody will get to it soon, or you could do it yourself and submit a patch.

I believe we're discussing to separate things, that don't necessarily relate to each other. One topic is [metro]'s precision. It has been sub-sample precise at least since I started understanding the concept (~ 0.40). So I think it is very likely the [metro] in libpd is precise as well (though I haven't used libpd myself and cannot test).

Then there have been a lot of methods added to [metro] in Pd 0.45. Those just make it simpler to use it and save the user to do timing calculations on her/his own. They are just a convenience, but don't affect [metro]'s precision.

Roman

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