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 <katjavet...@gmail.com>
> To: Ed Kelly <morph_2...@yahoo.co.uk>
> Cc: PD List <pd-l...@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_2...@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
> 

_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Reply via email to