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

Ed Kelly morph_2016 at yahoo.co.uk
Fri May 10 01:46:09 CEST 2013

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 ;)

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

Gemnotes-0.2: Live music notation for Pure Data, now with dynamics!

----- Original Message -----
> From: katja <katjavetter at gmail.com>
> To: Ed Kelly <morph_2016 at yahoo.co.uk>
> Cc: PD List <pd-list at iem.at>; pddev <pd-dev at 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 at 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

More information about the Pd-list mailing list