I’ve just checked in the first working iPhone build!
Got it to run the juce demo - there’s a new project there to build it, and pretty much everything that you’d expect to work is working… All the graphics seem to be ok, audio’s running just fine, etc. Pretty good for a first draft!
Obviously when you put a desktop app on a handheld device it becomes blindingly obvious how badly all the controls work in that form-factor, and there’ll be some serious work needed to adapt Juce into something that’s versatile enough for all these targets, but this is step 1!
…I know is step 1 … so I’m definitely jumping the gun … but I presume the build process can be cleaned up in terms of simulator/device/iphone/mac builds.
In terms of UI it doesn’t seem too bad. The sliders are no worse than UIKit sliders even though they are generally smaller! The viewport scrollbars are a bit tricky though. (I can’t scroll down in the Audio->File Playback tab very easily.)
BTW The audio interruption stuff seems not to be working properly. It looks like you used a similar method to mine which seems not to work either now.
On the iPod touch (which is my main device platform):
[list]
[] starting with a headset NOT plugged in works fine (e.g., the audio->Synth Playback demo) [/]
[] plug in the headset: works fine[/]
[] unplug the headset
[list]
[] the alert dialog pops up
[/][] clicking resume doesn’t work (i.e. audio doesn’t come back) [/][/list][/][/list]
I spent quite a while tweaking my code to get a robust method that worked - I haven’t tested it for a while so no idea when it broke (but it could have been os3.0->3.1.2 - I don’t have 3.0 installed on my Mac or iPod now).
I seem to remember testing my code on someone else’s iPhone (rather than pod) and never seeing the alert - so it might be tricky to reproduce.
I have a partial fix which is to remove the dialog popup alltogether (which is weird since I played with this for a long time and it was the only way to get the iPod touch to resume playback when a HeadsetInOut was removed).
Anyway, perhaps Apple had bug reports and they partially fixed the issue which is why the dialog popup thing worked previously (and in hindsight maybe the reason clicking resume in the dialog rather than calling to reinitialise the audiounit in the interruption handler is that clicking resume runs on a different thread - again I thought I’d tried the performSelectorOnMainThread thing)
OK the partial fix (on 3.1.2 at least), is simply to remove lines 400-413 of juce_iphone_Audio.cpp i.e.,
if (inInterruption == kAudioSessionBeginInterruption)
{
isRunning = false;
AudioOutputUnitStop (audioUnit);
if (juce_iPhoneShowModalAlert ("Audio Interrupted",
"This could have been interrupted by another application or by unplugging a headset",
@"Resume",
@"Cancel"))
{
isRunning = true;
propertyChanged (0, 0, 0);
}
}
This works fine when plugging/unplugging a HeadsetInOut (i.e., headphones with the little mic and the 4-contact minijack connector). This is regardless of whether you start with in plugged in or not.
It also works fine if you plug/unplug a Headset (i.e., headphones but no mic - a standard 3-contact minijack).
However if you unplug a HeadsetInOut then plug in a Headset there’s no audio out not even from the Speaker if you remove the Headset again. It works again if you plug the HeadsetInOut back in.
When this happens in my code (which is slightly different, but similar to the Juce Audio code) the audio route property is an empty string rather than Headset when it should be.
So mixing up Headsets and HeadsetInOuts seems to break this but otherwise works fine.
Weird.
Can anyone test this behaviour on the iPhone? It handles interruptions differently
Thanks Martin! I’ve only got a 3GS to test with (and an old ipod touch with no microphone). It’s surprising (and annoying!) that they all behave so differently.
I’ll try your suggestion later and let you know how it runs on the phone…
But I do seem to have some snags. One is that when I tried to build, I got a lot of missing symbols. I rebuilt the juce libs, and then retried, did a few other things, even added the amalgamted files, since that’s what the config.h seems to include - still no dice.
Then I got beaten around by Git. It doesn’t seem so easy to say ‘get everything from the head’ anymore. In this case, all the new stuff came in, but anything added wasn’t in my git repo, so I couldn’t revert it. Very odd.
If I try ‘git pull origin master’ again, it won’t do it since the remote files would overwrite the local, untracked files.
OK, so it was a Git problem - it didn’t get the fresh juce lib project with the iphone target. In the end I had to checkout the head as a new branch over my existing branch. All very confusing in this context (compared to svn).
Still happy for any git & juce tips. Will I have to make a new branch every time I sync with the tip?
Martin - I tried your suggestion of removing the popup dialog, and it does seem to work really well on the 3GS. Plugging in headphones/headset etc all seems to work as you’d expect, so I’ve rolled this into the tip now.
Absolutely wicked stuff… Works like a charm. Didn’t expect that it would almost port the whole JuceDemo to the Iphone. Very well done.
A lot of people will have fun with this.
I didn’t want to make suggestions as you did a great job already but i can’t resist. How hard would it be to enable OpenGL for the IPhone?
You couldn’t add a few lines to the Juce Introduction ReadMe doc about how to create an iPhone “Hello World”-type application (i.e. what type of Xcode project/essential libraries and settings), please
I only took me 1 1/2 hours yesterday to get Iphone app running that works as a remote for our Desktop Application. It sends out OSC messages to our VJ app using the Juce socket classes. Used the Jucer to design my MainComponent and copied a part of the LookAndFeel of our Desktop application so it even looks the same
Thanx Jules!
+1 An Iphone example project would be nice indeed.
I just copied the JuceDemo and stripped all the things i didn’t need.
