Anyone else ever had this?

It works fine on the simulator, but I get no sound at all on my iPod....

This is my setup in the app delate:

dispatcher = [[PdDispatcher alloc] init]; 
[PdBase setDelegate:dispatcher];
  
 self.audioController = [[PdAudioController alloc] init];
[self.audioController configurePlaybackWithSampleRate:44100 numberChannels:2 inputEnabled:YES mixingEnabled:YES];  
         
    [self.audioController setActive:YES];

ok... I tried another PD patch and now it works... looks like I was overloading the CPU on the iPod...

me again... yes I am now talking to myself on a forum. Maybe its time for bed!

Anyway... im having the same problem with another patch... this is not a CPU issue after all... and to be honest im none the wiser!

Any help / advise would be greatly appreciated

Thanks

Carl.

Hi maybe you could post your patch to see what could be a pb.

On the top of my mind, I had an issue with arguments of [*~] objects, for instance an object [*~ 0.5] would block the signal

[loadbang]
|
[0.5(
|
[*~]

is a better option.

But actually the first thing to check is that your patches use only vanilla object, or that you compiled and gave the right path for your externals.

Hi BerengerRecoules... thanks for the reply...

What you have pointed out sounds interesting (proving all sorts can cause issues)... though it did actually turn out to be the CPU (I was tired).. I have just done a blog post about it actually:

http://objectiveapple.blogspot.co.uk/2012/08/74-ios-libpd-37-cpu-issues-with-lib-pd.html

I am now trying to find a way to reduce this / up the buffer size in PD...

I am just looking at block~ and trying to see if it will solve my problem...

Actually when I started working on iOS and android I thought I could port my patches right away. But you actually need to think things through and take care of cpu cycles, either you developp your patches with that in mind or optimize your patches (using switch~ to turn off some parts of your patches when they are not used is a good start)

You may get more help on the noisepages forum there are a lot of iOS people over there. I believe there's some tricks to use some cpu optimization on iOS, but i couldn't tell you more, searching the archives of pdeverywhere could help too

cheers and have fun

I didn't notice your patch was actually posted over there.

So you might want to get rid of all the gui elements inside your patch, there have been several discussions about this, normally it wouldn't affect perfomances, but just to be sure I would get rid of them...

in your waveTableOsc you use :
[metro 2]
|
[snapshot~]
this might be a bit expansive see if you can work with a slower rate

the pvoclooprandom ... ouch !
I'm not surprised it eats up your cpu. Plus inside this one you have a [bang~], this is pretty heavy to handle banging at samplerate on a mobile device is bold (it's in [pd reading-windows], you definitely should rewrite that with something less expansive

cheers

Hi CT43,

Your link doesn't load for me so I can't check your patch, but I would echo what Bérenger says. It might be obvious to say but mobile devices != desktop computers. Try using a really simple patch to test if it's your libpd implementation or a CPU issue.

IIRC the Pd core by itself uses ~30% of the CPU on an iPhone (4 I think), and this is with vector optimisations. It's important to be as efficient as possible, especially when doing some really crazy stuff

cheers guys... yeah it looks as if I will have to re-think my approach. I have already made some massive saving by lowing the sample rate to 22050 in Xcode + upping the 'ticks' property to 64....

http://objectiveapple.blogspot.co.uk/2012/08/75-ios-libpd-37-improving-cpu-issues.html

One thing I've just asked over at Noise pages actually: would a compiled external but more efficient than a vanilla clone (as in RJLIB). I appreciate its difficult to compare these things, but on principle should it be?

@CT43 said:

cheers guys... yeah it looks as if I will have to re-think my approach. I have already made some massive saving by lowing the sample rate to 22050 in Xcode + upping the 'ticks' property to 64....

Unless you're trying to filter everyone's mind I would personally recommend not lowering down to 22050 Hz if you can help it. We switched to 44100 Hz in some of our latest apps and the difference is vast. It was such a bummer making some cools sounds and then having to down-sample them and lose half the frequencies. In reality I think any iOS device from 3GS onwards can handle a fair amount @ 44100Hz.

What device are you testing on? Don't forget that the majority of consumers (ours anyway) use iPhone 4 and 4s. They're beasts when it comes to handling heavier patches. What we did do was increase the buffer size on lower end devices to forgo latency over sound quality - that might be worth looking into.

@CT43 said:

One thing I've just asked over at Noise pages actually: would a compiled external but more efficient than a vanilla clone (as in RJLIB). I appreciate its difficult to compare these things, but on principle should it be?

What do you mean by a vanilla clone? The RjLib is just a bunch of abstractions, although there are some externals for detecting zero-crossings and average energy, etc..

An external would only be faster if it was written in a way to be faster than what it's trying to faster than Can you give an example?

p.s. for iOS you'll need to include the external's source code in your Xcode project and call it's setup function in your AppDelegate

Cheers,
Joe

Hi Joe... I did some tests and 44.1 was killing my iPad 2 and not even running on my iPod 4th Gen...

http://objectiveapple.blogspot.co.uk/2012/08/74-ios-libpd-37-cpu-issues-with-lib-pd.html

Increasing the buffer size in Xcode to the max setting (64 ticks) only got me 7% more CPU on my iPad 2. halving the sample rate was needed...

Regarding the other point: what I mean by 'vanilla clone' was an RJLib library object compiled equivalent PD external

Cheers

Carl.

I'm assuming your patch is on the link you keep posting, but as I said before the page won't load for me sorry. Will it not load at all without Javascript?

ticks != bufferSize ---> https://github.com/libpd/libpd/blob/master/objc/PdAudioController.m#L175

Setting libpd to the maximum 64 ticks would give you a bufferSize of 4096 -> nearly a 100ms latency @44100Hz. That's a pretty long time. I can't see your patch but it sounds like you're doing something mental to kill an iPad 2. Can you upload it here?

Most of the abstractions in the RjLib are wrappers around some of the examples given in the Pd help files for easy access. I can't think of any that are clones of existing externals in Pd-extended. Not to say there aren't more efficient externals around that do similar jobs. Still, if you could provide a example we might be able to answer.

Cheers,
Joe

yeah the latency is quite long, and yes I would like it to be shorter

Here is a link to the patch:

https://skydrive.live.com/redir?resid=6F0E6DB89466FF7!163&authkey=!ABMFzSROkWu5vQI

This uses about 35% on my iPad 2 at the moment.

Thanks for the offer of help on the externals, ill see what I can find.

Carl.