Layout, Testing

13May09

Today I worked on further layout details for buttons and their click behaviour. The mainscreen shows only one button at startup so the user won’t be confused by controls. After the user pressed the “Start” button he/she has to wait until the phone as a good satellite fix. Then the first scene starts automatically and a “Pause” and “Stop” buttons appear on the bottom of the screen. So playback controls are on the screen only when they are useful, just to keep the interface simple and to avoid static layouts. Further I redesigned the gps settings view where’s only a slider for the distance filter and a short explanation of the settings. I’m working on saving the settings for later startups.
Field test
After a test with cloudy conditions, some bugs appeard in the playback logic. It needs some minor fixes to get the drama running as it was meant to be. But basically it works quite good.

Next steps: Design, saving settings, modifiy playback code

Advertisements

Newly restored phone on a new day made things easier. Now the error has gone and I continued bugfixing and trying to design various layouts. After a memory leak check I discovered a few things to fix, which were not very grave (~64 byte/min) but still demanding for some care.
New is a GPS signal indicator, represented by a smiley in 3 moods. Depending on the signal strength, it laughs, looks sheepish or is sad.


First thing, when I tried to build and run a new version on the phone, was an error, telling me no iphone could be found 😦
I tried various resets, starting from xcode, cleaning the whole project and now resetting the iphone…
So I tried to push forward the design of the application. First a short startscreen to give little information what you’ve started. Meanwhile the xml could be read, but this has to be implemented (no big deal because the xml reader has its own thread anyway). Next is the mainscreen which will have max 3 big buttons. First to start the play and the others for playback control. Maybe an extra volume slider, but as you can control the volume very easily with the hardware buttons, it’s not necessary. The extra view to choose the mediascape won’t be included in the final version, because there’s at the moment only this play and it makes things easier for the user. The gps settings will be still there, but with other presets which will be more suitable for this play.

Next steps: restore the phone (timeconsuming when your phone was “freed”), implement startup with simultaneous xml reading, designing the layout


The drama works

08May09

Now since all bugs have gone, the drama works really good. I finished today the playback logic code, so the drama works correctly. Some modifications to the location info update were important, because at startup CLLocationManager had stored the last coordinates, and therefore initializing was sometimes little buggy. I solved this by an accuracy filter and compared the incoming location timestamp with startup time of the application. So the drama starts as soon as coordinates are accurate enough. Depending on the gps signal quality the phone starts after a few seconds. Today the first startup took about 15-20 seconds (agps) until the phone got a good satellite fix. (good weather, some clouds) Following startups went much faster (~3-10sec) as the phone’s gps chip stored the almanach of satellite positions.

Scratch
Walking through the scenes gives a very fluent experience and as soon as I found my landmarks where a scene starts (this version is not dependent on a certain area), it is quite fun to interact with the story. Now there are boundaries between different drama places (e.g. you hear the door you walked through, atmos changes..) which gives the user a better understanding of his/her position between the scenes.
Some things need a little refinement:

  • fades between some atmospheres
  • an automatic gain adjustment of atmos during a scene
  • Next steps are: designing a user interface, trying various interaction possibilities (e.g. vibration when entering a scene), optimizing code


    After a modification of PlaybackLogic class and AudioPlaybackHandler I have the possibility to switch between “trigger modes” of scenes. The original code to trigger audiofiles directly by regions as a functionality in regions remains, accompanied by the new features fo the PlaybackLogic class. It enables to trigger audiofiles directly by their scene name in the playback logic of the drama. This makes it very easy, to write playback code with predefined methods, without any worries about their background.
    Work continues with bugfixing.


    Today I tried the new structure with the audio handler. It’s possible now to play multiple audio files simultaneously with the AVAudioPlayer framework. It’s important that you convert your files to aif, caf etc…
    MP3s won’t work. AIF files can be huge, but when you convert your files with the IMA 4:1 format (*) a mp3 file with ~3mb is about 8-9mb as a aif file. Okay it’s 3 times bigger than an mp3, but much better than Linear PCM aif’s which will have for the same file about 33 mb.
    I also changed the triggering of audio objects for this version of “Scratch“. First I designed it that a region triggers the playback of an audio object. Now a region calls the class PlaybackLogic which implements the playback behaviour, especially for this locative drama. In this class, is the implementation what happens if the user is in this or that region. Here the author of the locative drama writes his code and just need to call the audio files (scenes) per “play” command.

    Next steps are: implementing locative aware stops, rewriting PlaybackLogic code for new interface

    (*)just open file with quicktime (i guess pro) and choose File->Export. There you choose “Sound -> AIFF” and click the option button on the right. In the new window select IMA 4:1 for the format.


    After the threading problems were solved, I made a major change to the program structure. I introduced a new class “AudioPlayerHandler” which manages all audio players during playback. Now simultaneous playback works with 2 tracks. But for boundaries between scene atmospheres it happens that 3 tracks will be needed for playback. I have to try this, but it shouldn’t be much problem.
    This “AudioPlayerHandler” now provides an interface where you can easily dock your own code for the playback logic. Theoretically you just have to “say” in your code “play this region” (…in objective c code..) and the handler will manage to delete unused players, allocate new players and control playback.